2005-04-17 06:20:36 +08:00
|
|
|
#
|
2006-08-14 05:39:11 +08:00
|
|
|
# I2C subsystem configuration
|
2005-04-17 06:20:36 +08:00
|
|
|
#
|
|
|
|
|
|
2014-05-20 20:59:24 +08:00
|
|
|
menu "I2C support"
|
|
|
|
|
|
|
|
|
|
config I2C
|
2005-04-17 06:20:36 +08:00
|
|
|
tristate "I2C support"
|
2009-12-07 00:06:22 +08:00
|
|
|
select RT_MUTEXES
|
2005-04-17 06:20:36 +08:00
|
|
|
---help---
|
2011-07-09 06:33:24 +08:00
|
|
|
I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
|
2005-04-17 06:20:36 +08:00
|
|
|
many micro controller applications and developed by Philips. SMBus,
|
|
|
|
|
or System Management Bus is a subset of the I2C protocol. More
|
|
|
|
|
information is contained in the directory <file:Documentation/i2c/>,
|
|
|
|
|
especially in the file called "summary" there.
|
|
|
|
|
|
|
|
|
|
Both I2C and SMBus are supported here. You will need this for
|
|
|
|
|
hardware sensors support, and also for Video For Linux support.
|
|
|
|
|
|
|
|
|
|
If you want I2C support, you should say Y here and also to the
|
|
|
|
|
specific driver for your bus adapter(s) below.
|
|
|
|
|
|
|
|
|
|
This I2C support can also be built as a module. If so, the module
|
|
|
|
|
will be called i2c-core.
|
|
|
|
|
|
2014-08-15 13:38:59 +08:00
|
|
|
config ACPI_I2C_OPREGION
|
|
|
|
|
bool "ACPI I2C Operation region support"
|
|
|
|
|
depends on I2C=y && ACPI
|
2014-05-20 20:59:24 +08:00
|
|
|
default y
|
|
|
|
|
help
|
2014-08-15 13:38:59 +08:00
|
|
|
Say Y here if you want to enable ACPI I2C operation region support.
|
|
|
|
|
Operation Regions allow firmware (BIOS) code to access I2C slave devices,
|
|
|
|
|
such as smart batteries through an I2C host controller driver.
|
2014-05-20 20:59:24 +08:00
|
|
|
|
2007-05-02 05:26:34 +08:00
|
|
|
if I2C
|
|
|
|
|
|
i2c: Add i2c_board_info and i2c_new_device()
This provides partial support for new-style I2C driver binding. It builds
on "struct i2c_board_info" declarations that identify I2C devices on a given
board. This is needed on systems with I2C devices that can't be fully probed
and/or autoconfigured, such as many embedded Linux configurations where the
way a given I2C device is wired may affect how it must be used.
There are two models for declaring such devices:
* LATE -- using a public function i2c_new_device(). This lets modules
declare I2C devices found *AFTER* a given I2C adapter becomes available.
For example, a PCI card could create adapters giving access to utility
chips on that card, and this would be used to associate those chips with
those adapters.
* EARLY -- from arch_initcall() level code, using a non-exported function
i2c_register_board_info(). This copies the declarations *BEFORE* such
an i2c_adapter becomes available, arranging that i2c_new_device() will
be called later when i2c-core registers the relevant i2c_adapter.
For example, arch/.../.../board-*.c files would declare the I2C devices
along with their platform data, and I2C devices would behave much like
PNPACPI devices. (That is, both enumerate from board-specific tables.)
To match the exported i2c_new_device(), the previously-private function
i2c_unregister_device() is now exported.
Pending later patches using these new APIs, this is effectively a NOP.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-05-02 05:26:31 +08:00
|
|
|
config I2C_BOARDINFO
|
2014-12-21 04:41:11 +08:00
|
|
|
bool
|
i2c: Add i2c_board_info and i2c_new_device()
This provides partial support for new-style I2C driver binding. It builds
on "struct i2c_board_info" declarations that identify I2C devices on a given
board. This is needed on systems with I2C devices that can't be fully probed
and/or autoconfigured, such as many embedded Linux configurations where the
way a given I2C device is wired may affect how it must be used.
There are two models for declaring such devices:
* LATE -- using a public function i2c_new_device(). This lets modules
declare I2C devices found *AFTER* a given I2C adapter becomes available.
For example, a PCI card could create adapters giving access to utility
chips on that card, and this would be used to associate those chips with
those adapters.
* EARLY -- from arch_initcall() level code, using a non-exported function
i2c_register_board_info(). This copies the declarations *BEFORE* such
an i2c_adapter becomes available, arranging that i2c_new_device() will
be called later when i2c-core registers the relevant i2c_adapter.
For example, arch/.../.../board-*.c files would declare the I2C devices
along with their platform data, and I2C devices would behave much like
PNPACPI devices. (That is, both enumerate from board-specific tables.)
To match the exported i2c_new_device(), the previously-private function
i2c_unregister_device() is now exported.
Pending later patches using these new APIs, this is effectively a NOP.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-05-02 05:26:31 +08:00
|
|
|
default y
|
|
|
|
|
|
2009-09-19 04:45:46 +08:00
|
|
|
config I2C_COMPAT
|
2014-12-21 04:41:11 +08:00
|
|
|
bool "Enable compatibility bits for old user-space"
|
2009-09-19 04:45:46 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you intend to run lm-sensors 3.1.1 or older, or any
|
|
|
|
|
other user-space package which expects i2c adapters to be class
|
|
|
|
|
devices. If you don't know, say Y.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config I2C_CHARDEV
|
|
|
|
|
tristate "I2C device interface"
|
|
|
|
|
help
|
|
|
|
|
Say Y here to use i2c-* device files, usually found in the /dev
|
|
|
|
|
directory on your system. They make it possible to have user-space
|
|
|
|
|
programs use the I2C bus. Information on how to do this is
|
|
|
|
|
contained in the file <file:Documentation/i2c/dev-interface>.
|
|
|
|
|
|
|
|
|
|
This support is also available as a module. If so, the module
|
|
|
|
|
will be called i2c-dev.
|
|
|
|
|
|
2010-08-12 00:21:02 +08:00
|
|
|
config I2C_MUX
|
|
|
|
|
tristate "I2C bus multiplexing support"
|
2012-10-06 04:23:52 +08:00
|
|
|
depends on HAS_IOMEM
|
2010-08-12 00:21:02 +08:00
|
|
|
help
|
|
|
|
|
Say Y here if you want the I2C core to support the ability to
|
|
|
|
|
handle multiplexed I2C bus topologies, by presenting each
|
|
|
|
|
multiplexed segment as a I2C adapter.
|
|
|
|
|
|
|
|
|
|
This support is also available as a module. If so, the module
|
|
|
|
|
will be called i2c-mux.
|
|
|
|
|
|
2010-08-12 00:21:03 +08:00
|
|
|
source drivers/i2c/muxes/Kconfig
|
|
|
|
|
|
2008-08-11 04:56:15 +08:00
|
|
|
config I2C_HELPER_AUTO
|
|
|
|
|
bool "Autoselect pertinent helper modules"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Some I2C bus drivers require so-called "I2C algorithm" modules
|
|
|
|
|
to work. These are basically software-only abstractions of generic
|
|
|
|
|
I2C interfaces. This option will autoselect them so that you don't
|
|
|
|
|
have to care.
|
|
|
|
|
|
|
|
|
|
Unselect this only if you need to enable additional helper
|
|
|
|
|
modules, for example for use with external I2C bus drivers.
|
|
|
|
|
|
|
|
|
|
In doubt, say Y.
|
|
|
|
|
|
2010-03-02 19:23:43 +08:00
|
|
|
config I2C_SMBUS
|
2010-11-07 05:30:25 +08:00
|
|
|
tristate "SMBus-specific protocols" if !I2C_HELPER_AUTO
|
2010-03-02 19:23:43 +08:00
|
|
|
help
|
|
|
|
|
Say Y here if you want support for SMBus extensions to the I2C
|
|
|
|
|
specification. At the moment, the only supported extension is
|
|
|
|
|
the SMBus alert protocol.
|
|
|
|
|
|
|
|
|
|
This support is also available as a module. If so, the module
|
|
|
|
|
will be called i2c-smbus.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
source drivers/i2c/algos/Kconfig
|
|
|
|
|
source drivers/i2c/busses/Kconfig
|
|
|
|
|
|
2012-10-06 04:23:52 +08:00
|
|
|
config I2C_STUB
|
|
|
|
|
tristate "I2C/SMBus Test Stub"
|
2013-01-17 10:53:37 +08:00
|
|
|
depends on m
|
2012-10-06 04:23:52 +08:00
|
|
|
default 'n'
|
|
|
|
|
help
|
|
|
|
|
This module may be useful to developers of SMBus client drivers,
|
|
|
|
|
especially for certain kinds of sensor chips.
|
|
|
|
|
|
|
|
|
|
If you do build this module, be sure to read the notes and warnings
|
|
|
|
|
in <file:Documentation/i2c/i2c-stub>.
|
|
|
|
|
|
|
|
|
|
If you don't know what to do here, definitely say N.
|
|
|
|
|
|
2014-11-19 00:04:54 +08:00
|
|
|
config I2C_SLAVE
|
|
|
|
|
bool "I2C slave support"
|
|
|
|
|
|
|
|
|
|
if I2C_SLAVE
|
|
|
|
|
|
|
|
|
|
config I2C_SLAVE_EEPROM
|
|
|
|
|
tristate "I2C eeprom slave driver"
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config I2C_DEBUG_CORE
|
|
|
|
|
bool "I2C Core debugging messages"
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want the I2C core to produce a bunch of debug
|
|
|
|
|
messages to the system log. Select this if you are having a
|
|
|
|
|
problem with I2C support and want to see more of what is going on.
|
|
|
|
|
|
|
|
|
|
config I2C_DEBUG_ALGO
|
|
|
|
|
bool "I2C Algorithm debugging messages"
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want the I2C algorithm drivers to produce a bunch
|
|
|
|
|
of debug messages to the system log. Select this if you are having
|
|
|
|
|
a problem with I2C support and want to see more of what is going
|
|
|
|
|
on.
|
|
|
|
|
|
|
|
|
|
config I2C_DEBUG_BUS
|
|
|
|
|
bool "I2C Bus debugging messages"
|
2012-10-06 04:23:52 +08:00
|
|
|
depends on HAS_IOMEM
|
2005-04-17 06:20:36 +08:00
|
|
|
help
|
|
|
|
|
Say Y here if you want the I2C bus drivers to produce a bunch of
|
|
|
|
|
debug messages to the system log. Select this if you are having
|
|
|
|
|
a problem with I2C support and want to see more of what is going
|
|
|
|
|
on.
|
|
|
|
|
|
2007-05-02 05:26:34 +08:00
|
|
|
endif # I2C
|
2014-05-20 20:59:24 +08:00
|
|
|
|
|
|
|
|
endmenu
|