aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/i2c
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2005-07-31 15:49:03 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2005-09-05 12:14:21 -0400
commitf4b50261207c987913f076d867c2e154d71fd012 (patch)
tree0b50cfa93f2e1e6a877f51028f93539db0e4547e /Documentation/i2c
parent96478ef3f3f71fa929cc905cc794993e312d9a5d (diff)
[PATCH] hwmon: hwmon vs i2c, second round (06/11)
The only thing left in i2c-sensor.h are module parameter definition macros. It's only an extension of what i2c.h offers, and this extension is not sensors-specific. As a matter of fact, a few non-sensors drivers use them. So we better merge them in i2c.h, and get rid of i2c-sensor.h altogether. Signed-off-by: Jean Delvare <khali@linux-fr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/i2c')
-rw-r--r--Documentation/i2c/porting-clients8
-rw-r--r--Documentation/i2c/writing-clients68
2 files changed, 19 insertions, 57 deletions
diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
index f9099211bd0b..8b819379adcb 100644
--- a/Documentation/i2c/porting-clients
+++ b/Documentation/i2c/porting-clients
@@ -1,4 +1,4 @@
1Revision 4, 2004-03-30 1Revision 5, 2005-07-29
2Jean Delvare <khali@linux-fr.org> 2Jean Delvare <khali@linux-fr.org>
3Greg KH <greg@kroah.com> 3Greg KH <greg@kroah.com>
4 4
@@ -17,13 +17,12 @@ yours for best results.
17 17
18Technical changes: 18Technical changes:
19 19
20* [Includes] Get rid of "version.h". Replace <linux/i2c-proc.h> with 20* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
21 <linux/i2c-sensor.h>. Includes typically look like that: 21 Includes typically look like that:
22 #include <linux/module.h> 22 #include <linux/module.h>
23 #include <linux/init.h> 23 #include <linux/init.h>
24 #include <linux/slab.h> 24 #include <linux/slab.h>
25 #include <linux/i2c.h> 25 #include <linux/i2c.h>
26 #include <linux/i2c-sensor.h>
27 #include <linux/i2c-vid.h> /* if you need VRM support */ 26 #include <linux/i2c-vid.h> /* if you need VRM support */
28 #include <asm/io.h> /* if you have I/O operations */ 27 #include <asm/io.h> /* if you have I/O operations */
29 Please respect this inclusion order. Some extra headers may be 28 Please respect this inclusion order. Some extra headers may be
@@ -31,6 +30,7 @@ Technical changes:
31 30
32* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses 31* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses
33 are no more handled by the i2c core. 32 are no more handled by the i2c core.
33 SENSORS_INSMOD_<n> becomes I2C_CLIENT_INSMOD_<n>.
34 34
35* [Client data] Get rid of sysctl_id. Try using standard names for 35* [Client data] Get rid of sysctl_id. Try using standard names for
36 register values (for example, temp_os becomes temp_max). You're 36 register values (for example, temp_os becomes temp_max). You're
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
155 155
156 156
157 157
158Probing classes (i2c) 158Probing classes
159--------------------- 159---------------
160 160
161All parameters are given as lists of unsigned 16-bit integers. Lists are 161All parameters are given as lists of unsigned 16-bit integers. Lists are
162terminated by I2C_CLIENT_END. 162terminated by I2C_CLIENT_END.
@@ -171,12 +171,18 @@ The following lists are used internally:
171 ignore: insmod parameter. 171 ignore: insmod parameter.
172 A list of pairs. The first value is a bus number (-1 for any I2C bus), 172 A list of pairs. The first value is a bus number (-1 for any I2C bus),
173 the second is the I2C address. These addresses are never probed. 173 the second is the I2C address. These addresses are never probed.
174 This parameter overrules 'normal' and 'probe', but not the 'force' lists. 174 This parameter overrules the 'normal_i2c' list only.
175 force: insmod parameter. 175 force: insmod parameter.
176 A list of pairs. The first value is a bus number (-1 for any I2C bus), 176 A list of pairs. The first value is a bus number (-1 for any I2C bus),
177 the second is the I2C address. A device is blindly assumed to be on 177 the second is the I2C address. A device is blindly assumed to be on
178 the given address, no probing is done. 178 the given address, no probing is done.
179 179
180Additionally, kind-specific force lists may optionally be defined if
181the driver supports several chip kinds. They are grouped in a
182NULL-terminated list of pointers named forces, those first element if the
183generic force list mentioned above. Each additional list correspond to an
184insmod parameter of the form force_<kind>.
185
180Fortunately, as a module writer, you just have to define the `normal_i2c' 186Fortunately, as a module writer, you just have to define the `normal_i2c'
181parameter. The complete declaration could look like this: 187parameter. The complete declaration could look like this:
182 188
@@ -186,61 +192,17 @@ parameter. The complete declaration could look like this:
186 192
187 /* Magic definition of all other variables and things */ 193 /* Magic definition of all other variables and things */
188 I2C_CLIENT_INSMOD; 194 I2C_CLIENT_INSMOD;
195 /* Or, if your driver supports, say, 2 kind of devices: */
196 I2C_CLIENT_INSMOD_2(foo, bar);
197
198If you use the multi-kind form, an enum will be defined for you:
199 enum chips { any_chip, foo, bar, ... }
200You can then (and certainly should) use it in the driver code.
189 201
190Note that you *have* to call the defined variable `normal_i2c', 202Note that you *have* to call the defined variable `normal_i2c',
191without any prefix! 203without any prefix!
192 204
193 205
194Probing classes (sensors)
195-------------------------
196
197If you write a `sensors' driver, you use a slightly different interface.
198Also, we use a enum of chip types. Don't forget to include `sensors.h'.
199
200The following lists are used internally. They are all lists of integers.
201
202 normal_i2c: filled in by the module writer. Terminated by I2C_CLIENT_END.
203 A list of I2C addresses which should normally be examined.
204 probe: insmod parameter. Initialize this list with I2C_CLIENT_END values.
205 A list of pairs. The first value is a bus number (ANY_I2C_BUS for any
206 I2C bus), the second is the address. These addresses are also probed,
207 as if they were in the 'normal' list.
208 ignore: insmod parameter. Initialize this list with I2C_CLIENT_END values.
209 A list of pairs. The first value is a bus number (ANY_I2C_BUS for any
210 I2C bus), the second is the I2C address. These addresses are never
211 probed. This parameter overrules 'normal' and 'probe', but not the
212 'force' lists.
213
214Also used is a list of pointers to sensors_force_data structures:
215 force_data: insmod parameters. A list, ending with an element of which
216 the force field is NULL.
217 Each element contains the type of chip and a list of pairs.
218 The first value is a bus number (ANY_I2C_BUS for any I2C bus), the
219 second is the address.
220 These are automatically translated to insmod variables of the form
221 force_foo.
222
223So we have a generic insmod variabled `force', and chip-specific variables
224`force_CHIPNAME'.
225
226Fortunately, as a module writer, you just have to define the `normal_i2c'
227parameter, and define what chip names are used. The complete declaration
228could look like this:
229 /* Scan i2c addresses 0x37, and 0x48 to 0x4f */
230 static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
231 0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
232
233 /* Define chips foo and bar, as well as all module parameters and things */
234 SENSORS_INSMOD_2(foo,bar);
235
236If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2
237you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to
238bother with chip types, you can use SENSORS_INSMOD_0.
239
240A enum is automatically defined as follows:
241 enum chips { any_chip, chip1, chip2, ... }
242
243
244Attaching to an adapter 206Attaching to an adapter
245----------------------- 207-----------------------
246 208