diff options
Diffstat (limited to 'Documentation/i2c/writing-clients')
| -rw-r--r-- | Documentation/i2c/writing-clients | 68 |
1 files changed, 15 insertions, 53 deletions
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 43d7928056ae..97e138cbb2a9 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -155,8 +155,8 @@ NOTE: If you want to write a `sensors' driver, the interface is slightly -Probing classes (i2c) ---------------------- +Probing classes +--------------- All parameters are given as lists of unsigned 16-bit integers. Lists are terminated by I2C_CLIENT_END. @@ -171,12 +171,18 @@ The following lists are used internally: ignore: insmod parameter. A list of pairs. The first value is a bus number (-1 for any I2C bus), the second is the I2C address. These addresses are never probed. - This parameter overrules 'normal' and 'probe', but not the 'force' lists. + This parameter overrules the 'normal_i2c' list only. force: insmod parameter. A list of pairs. The first value is a bus number (-1 for any I2C bus), the second is the I2C address. A device is blindly assumed to be on the given address, no probing is done. +Additionally, kind-specific force lists may optionally be defined if +the driver supports several chip kinds. They are grouped in a +NULL-terminated list of pointers named forces, those first element if the +generic force list mentioned above. Each additional list correspond to an +insmod parameter of the form force_<kind>. + Fortunately, as a module writer, you just have to define the `normal_i2c' parameter. The complete declaration could look like this: @@ -186,61 +192,17 @@ parameter. The complete declaration could look like this: /* Magic definition of all other variables and things */ I2C_CLIENT_INSMOD; + /* Or, if your driver supports, say, 2 kind of devices: */ + I2C_CLIENT_INSMOD_2(foo, bar); + +If you use the multi-kind form, an enum will be defined for you: + enum chips { any_chip, foo, bar, ... } +You can then (and certainly should) use it in the driver code. Note that you *have* to call the defined variable `normal_i2c', without any prefix! -Probing classes (sensors) -------------------------- - -If you write a `sensors' driver, you use a slightly different interface. -Also, we use a enum of chip types. Don't forget to include `sensors.h'. - -The following lists are used internally. They are all lists of integers. - - normal_i2c: filled in by the module writer. Terminated by I2C_CLIENT_END. - A list of I2C addresses which should normally be examined. - probe: insmod parameter. Initialize this list with I2C_CLIENT_END values. - A list of pairs. The first value is a bus number (ANY_I2C_BUS for any - I2C bus), the second is the address. These addresses are also probed, - as if they were in the 'normal' list. - ignore: insmod parameter. Initialize this list with I2C_CLIENT_END values. - A list of pairs. The first value is a bus number (ANY_I2C_BUS for any - I2C bus), the second is the I2C address. These addresses are never - probed. This parameter overrules 'normal' and 'probe', but not the - 'force' lists. - -Also used is a list of pointers to sensors_force_data structures: - force_data: insmod parameters. A list, ending with an element of which - the force field is NULL. - Each element contains the type of chip and a list of pairs. - The first value is a bus number (ANY_I2C_BUS for any I2C bus), the - second is the address. - These are automatically translated to insmod variables of the form - force_foo. - -So we have a generic insmod variabled `force', and chip-specific variables -`force_CHIPNAME'. - -Fortunately, as a module writer, you just have to define the `normal_i2c' -parameter, and define what chip names are used. The complete declaration -could look like this: - /* Scan i2c addresses 0x37, and 0x48 to 0x4f */ - static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c, - 0x4d, 0x4e, 0x4f, I2C_CLIENT_END }; - - /* Define chips foo and bar, as well as all module parameters and things */ - SENSORS_INSMOD_2(foo,bar); - -If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2 -you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to -bother with chip types, you can use SENSORS_INSMOD_0. - -A enum is automatically defined as follows: - enum chips { any_chip, chip1, chip2, ... } - - Attaching to an adapter ----------------------- |