mirror of
https://github.com/adulau/aha.git
synced 2024-12-28 11:46:19 +00:00
i2c: Improve the functionality documentation
Attempt to make the documentation about the I2C/SMBus functionality checking API clearer. Signed-off-by: Jean Delvare <khali@linux-fr.org>
This commit is contained in:
parent
1a31a88f4f
commit
88b283281f
1 changed files with 54 additions and 45 deletions
|
@ -51,26 +51,38 @@ A few combinations of the above flags are also defined for your convenience:
|
||||||
the transparent emulation layer)
|
the transparent emulation layer)
|
||||||
|
|
||||||
|
|
||||||
ALGORITHM/ADAPTER IMPLEMENTATION
|
ADAPTER IMPLEMENTATION
|
||||||
--------------------------------
|
----------------------
|
||||||
|
|
||||||
When you write a new algorithm driver, you will have to implement a
|
When you write a new adapter driver, you will have to implement a
|
||||||
function callback `functionality', that gets an i2c_adapter structure
|
function callback `functionality'. Typical implementations are given
|
||||||
pointer as its only parameter:
|
below.
|
||||||
|
|
||||||
struct i2c_algorithm {
|
A typical SMBus-only adapter would list all the SMBus transactions it
|
||||||
/* Many other things of course; check <linux/i2c.h>! */
|
supports. This example comes from the i2c-piix4 driver:
|
||||||
u32 (*functionality) (struct i2c_adapter *);
|
|
||||||
}
|
|
||||||
|
|
||||||
A typically implementation is given below, from i2c-algo-bit.c:
|
static u32 piix4_func(struct i2c_adapter *adapter)
|
||||||
|
|
||||||
static u32 bit_func(struct i2c_adapter *adap)
|
|
||||||
{
|
{
|
||||||
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
|
return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
|
||||||
I2C_FUNC_PROTOCOL_MANGLING;
|
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
|
||||||
|
I2C_FUNC_SMBUS_BLOCK_DATA;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
A typical full-I2C adapter would use the following (from the i2c-pxa
|
||||||
|
driver):
|
||||||
|
|
||||||
|
static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
|
||||||
|
{
|
||||||
|
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
|
||||||
|
}
|
||||||
|
|
||||||
|
I2C_FUNC_SMBUS_EMUL includes all the SMBus transactions (with the
|
||||||
|
addition of I2C block transactions) which i2c-core can emulate using
|
||||||
|
I2C_FUNC_I2C without any help from the adapter driver. The idea is
|
||||||
|
to let the client drivers check for the support of SMBus functions
|
||||||
|
without having to care whether the said functions are implemented in
|
||||||
|
hardware by the adapter, or emulated in software by i2c-core on top
|
||||||
|
of an I2C adapter.
|
||||||
|
|
||||||
|
|
||||||
CLIENT CHECKING
|
CLIENT CHECKING
|
||||||
|
@ -78,36 +90,33 @@ CLIENT CHECKING
|
||||||
|
|
||||||
Before a client tries to attach to an adapter, or even do tests to check
|
Before a client tries to attach to an adapter, or even do tests to check
|
||||||
whether one of the devices it supports is present on an adapter, it should
|
whether one of the devices it supports is present on an adapter, it should
|
||||||
check whether the needed functionality is present. There are two functions
|
check whether the needed functionality is present. The typical way to do
|
||||||
defined which should be used instead of calling the functionality hook
|
this is (from the lm75 driver):
|
||||||
in the algorithm structure directly:
|
|
||||||
|
|
||||||
/* Return the functionality mask */
|
static int lm75_detect(...)
|
||||||
extern u32 i2c_get_functionality (struct i2c_adapter *adap);
|
|
||||||
|
|
||||||
/* Return 1 if adapter supports everything we need, 0 if not. */
|
|
||||||
extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func);
|
|
||||||
|
|
||||||
This is a typical way to use these functions (from the writing-clients
|
|
||||||
document):
|
|
||||||
int foo_detect_client(struct i2c_adapter *adapter, int address,
|
|
||||||
unsigned short flags, int kind)
|
|
||||||
{
|
{
|
||||||
/* Define needed variables */
|
(...)
|
||||||
|
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
|
||||||
/* As the very first action, we check whether the adapter has the
|
I2C_FUNC_SMBUS_WORD_DATA))
|
||||||
needed functionality: we need the SMBus read_word_data,
|
goto exit;
|
||||||
write_word_data and write_byte functions in this example. */
|
(...)
|
||||||
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
|
|
||||||
I2C_FUNC_SMBUS_WRITE_BYTE))
|
|
||||||
goto ERROR0;
|
|
||||||
|
|
||||||
/* Now we can do the real detection */
|
|
||||||
|
|
||||||
ERROR0:
|
|
||||||
/* Return an error */
|
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Here, the lm75 driver checks if the adapter can do both SMBus byte data
|
||||||
|
and SMBus word data transactions. If not, then the driver won't work on
|
||||||
|
this adapter and there's no point in going on. If the check above is
|
||||||
|
successful, then the driver knows that it can call the following
|
||||||
|
functions: i2c_smbus_read_byte_data(), i2c_smbus_write_byte_data(),
|
||||||
|
i2c_smbus_read_word_data() and i2c_smbus_write_word_data(). As a rule of
|
||||||
|
thumb, the functionality constants you test for with
|
||||||
|
i2c_check_functionality() should match exactly the i2c_smbus_* functions
|
||||||
|
which you driver is calling.
|
||||||
|
|
||||||
|
Note that the check above doesn't tell whether the functionalities are
|
||||||
|
implemented in hardware by the underlying adapter or emulated in
|
||||||
|
software by i2c-core. Client drivers don't have to care about this, as
|
||||||
|
i2c-core will transparently implement SMBus transactions on top of I2C
|
||||||
|
adapters.
|
||||||
|
|
||||||
|
|
||||||
CHECKING THROUGH /DEV
|
CHECKING THROUGH /DEV
|
||||||
|
@ -116,8 +125,8 @@ CHECKING THROUGH /DEV
|
||||||
If you try to access an adapter from a userspace program, you will have
|
If you try to access an adapter from a userspace program, you will have
|
||||||
to use the /dev interface. You will still have to check whether the
|
to use the /dev interface. You will still have to check whether the
|
||||||
functionality you need is supported, of course. This is done using
|
functionality you need is supported, of course. This is done using
|
||||||
the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect
|
the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
|
||||||
program, is below:
|
below:
|
||||||
|
|
||||||
int file;
|
int file;
|
||||||
if (file = open("/dev/i2c-0", O_RDWR) < 0) {
|
if (file = open("/dev/i2c-0", O_RDWR) < 0) {
|
||||||
|
|
Loading…
Reference in a new issue