aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2008-10-23 13:10:25 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-23 13:10:25 -0400
commitfeeedc6c820e1026453ad865076cee435f24d30a (patch)
tree3eae5251bef80944048df1915e180394e5b7818c /Documentation
parenta27028349ccbcec9dde9d6dbba9d4017ad9ad5ab (diff)
parent11f1f2afd6b07729b12aaba479344d7f12d88ff9 (diff)
Merge branch 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: i2c: Add info->archdata field i2c: Inform about deprecated chips directory i2c: Use pci_ioremap_bar() Schedule removal of the legacy i2c device driver binding model i2c: Clean up <linux/i2c.h> i2c: Update and clean up writing-clients document i2c: Drop 2-byte address block transfer defines i2c: Delete legacy model documentation i2c: Constify i2c_get_clientdata's parameter i2c: Delete outdated client porting guide i2c: Make clear what the class field of i2c_adapter is good for i2c-algo-pcf: Fix typo in debugging log message i2c-algo-pcf: Add adapter hooks around xfer begin and end i2c-algo-pcf: Pass adapter data into ->waitforpin() method i2c-i801: Add support for Intel Ibex Peak
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/feature-removal-schedule.txt8
-rw-r--r--Documentation/i2c/busses/i2c-i8017
-rw-r--r--Documentation/i2c/porting-clients160
-rw-r--r--Documentation/i2c/writing-clients491
4 files changed, 128 insertions, 538 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index f5f812daf9f4..05d71b4b9430 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -359,3 +359,11 @@ Why: The 2.6 kernel supports direct writing to ide CD drives, which
359 eliminates the need for ide-scsi. The new method is more 359 eliminates the need for ide-scsi. The new method is more
360 efficient in every way. 360 efficient in every way.
361Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> 361Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
362
363---------------------------
364
365What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
366When: 2.6.29 (ideally) or 2.6.30 (more likely)
367Why: Deprecated by the new (standard) device driver binding model. Use
368 i2c_driver->probe() and ->remove() instead.
369Who: Jean Delvare <khali@linux-fr.org>
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index c31e0291e167..81c0c59a60ea 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -13,8 +13,9 @@ Supported adapters:
13 * Intel 631xESB/632xESB (ESB2) 13 * Intel 631xESB/632xESB (ESB2)
14 * Intel 82801H (ICH8) 14 * Intel 82801H (ICH8)
15 * Intel 82801I (ICH9) 15 * Intel 82801I (ICH9)
16 * Intel Tolapai 16 * Intel EP80579 (Tolapai)
17 * Intel ICH10 17 * Intel 82801JI (ICH10)
18 * Intel PCH
18 Datasheets: Publicly available at the Intel website 19 Datasheets: Publicly available at the Intel website
19 20
20Authors: 21Authors:
@@ -32,7 +33,7 @@ Description
32----------- 33-----------
33 34
34The ICH (properly known as the 82801AA), ICH0 (82801AB), ICH2 (82801BA), 35The ICH (properly known as the 82801AA), ICH0 (82801AB), ICH2 (82801BA),
35ICH3 (82801CA/CAM) and later devices are Intel chips that are a part of 36ICH3 (82801CA/CAM) and later devices (PCH) are Intel chips that are a part of
36Intel's '810' chipset for Celeron-based PCs, '810E' chipset for 37Intel's '810' chipset for Celeron-based PCs, '810E' chipset for
37Pentium-based PCs, '815E' chipset, and others. 38Pentium-based PCs, '815E' chipset, and others.
38 39
diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
deleted file mode 100644
index 7bf82c08f6ca..000000000000
--- a/Documentation/i2c/porting-clients
+++ /dev/null
@@ -1,160 +0,0 @@
1Revision 7, 2007-04-19
2Jean Delvare <khali@linux-fr.org>
3Greg KH <greg@kroah.com>
4
5This is a guide on how to convert I2C chip drivers from Linux 2.4 to
6Linux 2.6. I have been using existing drivers (lm75, lm78) as examples.
7Then I converted a driver myself (lm83) and updated this document.
8Note that this guide is strongly oriented towards hardware monitoring
9drivers. Many points are still valid for other type of drivers, but
10others may be irrelevant.
11
12There are two sets of points below. The first set concerns technical
13changes. The second set concerns coding policy. Both are mandatory.
14
15Although reading this guide will help you porting drivers, I suggest
16you keep an eye on an already ported driver while porting your own
17driver. This will help you a lot understanding what this guide
18exactly means. Choose the chip driver that is the more similar to
19yours for best results.
20
21Technical changes:
22
23* [Driver type] Any driver that was relying on i2c-isa has to be
24 converted to a proper isa, platform or pci driver. This is not
25 covered by this guide.
26
27* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
28 Includes typically look like that:
29 #include <linux/module.h>
30 #include <linux/init.h>
31 #include <linux/slab.h>
32 #include <linux/jiffies.h>
33 #include <linux/i2c.h>
34 #include <linux/hwmon.h> /* for hardware monitoring drivers */
35 #include <linux/hwmon-sysfs.h>
36 #include <linux/hwmon-vid.h> /* if you need VRM support */
37 #include <linux/err.h> /* for class registration */
38 Please respect this inclusion order. Some extra headers may be
39 required for a given driver (e.g. "lm75.h").
40
41* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses
42 are no more handled by the i2c core. Address ranges are no more
43 supported either, define each individual address separately.
44 SENSORS_INSMOD_<n> becomes I2C_CLIENT_INSMOD_<n>.
45
46* [Client data] Get rid of sysctl_id. Try using standard names for
47 register values (for example, temp_os becomes temp_max). You're
48 still relatively free here, but you *have* to follow the standard
49 names for sysfs files (see the Sysctl section below).
50
51* [Function prototypes] The detect functions loses its flags
52 parameter. Sysctl (e.g. lm75_temp) and miscellaneous functions
53 are off the list of prototypes. This usually leaves five
54 prototypes:
55 static int lm75_attach_adapter(struct i2c_adapter *adapter);
56 static int lm75_detect(struct i2c_adapter *adapter, int address,
57 int kind);
58 static void lm75_init_client(struct i2c_client *client);
59 static int lm75_detach_client(struct i2c_client *client);
60 static struct lm75_data lm75_update_device(struct device *dev);
61
62* [Sysctl] All sysctl stuff is of course gone (defines, ctl_table
63 and functions). Instead, you have to define show and set functions for
64 each sysfs file. Only define set for writable values. Take a look at an
65 existing 2.6 driver for details (it87 for example). Don't forget
66 to define the attributes for each file (this is that step that
67 links callback functions). Use the file names specified in
68 Documentation/hwmon/sysfs-interface for the individual files. Also
69 convert the units these files read and write to the specified ones.
70 If you need to add a new type of file, please discuss it on the
71 sensors mailing list <lm-sensors@lm-sensors.org> by providing a
72 patch to the Documentation/hwmon/sysfs-interface file.
73
74* [Attach] The attach function should make sure that the adapter's
75 class has I2C_CLASS_HWMON (or whatever class is suitable for your
76 driver), using the following construct:
77 if (!(adapter->class & I2C_CLASS_HWMON))
78 return 0;
79 Call i2c_probe() instead of i2c_detect().
80
81* [Detect] As mentioned earlier, the flags parameter is gone.
82 The type_name and client_name strings are replaced by a single
83 name string, which will be filled with a lowercase, short string.
84 The labels used for error paths are reduced to the number needed.
85 It is advised that the labels are given descriptive names such as
86 exit and exit_free. Don't forget to properly set err before
87 jumping to error labels. By the way, labels should be left-aligned.
88 Use kzalloc instead of kmalloc.
89 Use i2c_set_clientdata to set the client data (as opposed to
90 a direct access to client->data).
91 Use strlcpy instead of strcpy or snprintf to copy the client name.
92 Replace the sysctl directory registration by calls to
93 device_create_file. Move the driver initialization before any
94 sysfs file creation.
95 Register the client with the hwmon class (using hwmon_device_register)
96 if applicable.
97 Drop client->id.
98 Drop any 24RF08 corruption prevention you find, as this is now done
99 at the i2c-core level, and doing it twice voids it.
100 Don't add I2C_CLIENT_ALLOW_USE to client->flags, it's the default now.
101
102* [Init] Limits must not be set by the driver (can be done later in
103 user-space). Chip should not be reset default (although a module
104 parameter may be used to force it), and initialization should be
105 limited to the strictly necessary steps.
106
107* [Detach] Remove the call to i2c_deregister_entry. Do not log an
108 error message if i2c_detach_client fails, as i2c-core will now do
109 it for you.
110 Unregister from the hwmon class if applicable.
111
112* [Update] The function prototype changed, it is now
113 passed a device structure, which you have to convert to a client
114 using to_i2c_client(dev). The update function should return a
115 pointer to the client data.
116 Don't access client->data directly, use i2c_get_clientdata(client)
117 instead.
118 Use time_after() instead of direct jiffies comparison.
119
120* [Interface] Make sure there is a MODULE_LICENSE() line, at the bottom
121 of the file (after MODULE_AUTHOR() and MODULE_DESCRIPTION(), in this
122 order).
123
124* [Driver] The flags field of the i2c_driver structure is gone.
125 I2C_DF_NOTIFY is now the default behavior.
126 The i2c_driver structure has a driver member, which is itself a
127 structure, those name member should be initialized to a driver name
128 string. i2c_driver itself has no name member anymore.
129
130* [Driver model] Instead of shutdown or reboot notifiers, provide a
131 shutdown() method in your driver.
132
133* [Power management] Use the driver model suspend() and resume()
134 callbacks instead of the obsolete pm_register() calls.
135
136Coding policy:
137
138* [Copyright] Use (C), not (c), for copyright.
139
140* [Debug/log] Get rid of #ifdef DEBUG/#endif constructs whenever you
141 can. Calls to printk for debugging purposes are replaced by calls to
142 dev_dbg where possible, else to pr_debug. Here is an example of how
143 to call it (taken from lm75_detect):
144 dev_dbg(&client->dev, "Starting lm75 update\n");
145 Replace other printk calls with the dev_info, dev_err or dev_warn
146 function, as appropriate.
147
148* [Constants] Constants defines (registers, conversions) should be
149 aligned. This greatly improves readability.
150 Alignments are achieved by the means of tabs, not spaces. Remember
151 that tabs are set to 8 in the Linux kernel code.
152
153* [Layout] Avoid extra empty lines between comments and what they
154 comment. Respect the coding style (see Documentation/CodingStyle),
155 in particular when it comes to placing curly braces.
156
157* [Comments] Make sure that no comment refers to a file that isn't
158 part of the Linux source tree (typically doc/chips/<chip name>),
159 and that remaining comments still match the code. Merging comment
160 lines when possible is encouraged.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index d73ee117a8ca..6b9af7d479c2 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -10,23 +10,21 @@ General remarks
10=============== 10===============
11 11
12Try to keep the kernel namespace as clean as possible. The best way to 12Try to keep the kernel namespace as clean as possible. The best way to
13do this is to use a unique prefix for all global symbols. This is 13do this is to use a unique prefix for all global symbols. This is
14especially important for exported symbols, but it is a good idea to do 14especially important for exported symbols, but it is a good idea to do
15it for non-exported symbols too. We will use the prefix `foo_' in this 15it for non-exported symbols too. We will use the prefix `foo_' in this
16tutorial, and `FOO_' for preprocessor variables. 16tutorial.
17 17
18 18
19The driver structure 19The driver structure
20==================== 20====================
21 21
22Usually, you will implement a single driver structure, and instantiate 22Usually, you will implement a single driver structure, and instantiate
23all clients from it. Remember, a driver structure contains general access 23all clients from it. Remember, a driver structure contains general access
24routines, and should be zero-initialized except for fields with data you 24routines, and should be zero-initialized except for fields with data you
25provide. A client structure holds device-specific information like the 25provide. A client structure holds device-specific information like the
26driver model device node, and its I2C address. 26driver model device node, and its I2C address.
27 27
28/* iff driver uses driver model ("new style") binding model: */
29
30static struct i2c_device_id foo_idtable[] = { 28static struct i2c_device_id foo_idtable[] = {
31 { "foo", my_id_for_foo }, 29 { "foo", my_id_for_foo },
32 { "bar", my_id_for_bar }, 30 { "bar", my_id_for_bar },
@@ -40,7 +38,6 @@ static struct i2c_driver foo_driver = {
40 .name = "foo", 38 .name = "foo",
41 }, 39 },
42 40
43 /* iff driver uses driver model ("new style") binding model: */
44 .id_table = foo_ids, 41 .id_table = foo_ids,
45 .probe = foo_probe, 42 .probe = foo_probe,
46 .remove = foo_remove, 43 .remove = foo_remove,
@@ -49,24 +46,19 @@ static struct i2c_driver foo_driver = {
49 .detect = foo_detect, 46 .detect = foo_detect,
50 .address_data = &addr_data, 47 .address_data = &addr_data,
51 48
52 /* else, driver uses "legacy" binding model: */
53 .attach_adapter = foo_attach_adapter,
54 .detach_client = foo_detach_client,
55
56 /* these may be used regardless of the driver binding model */
57 .shutdown = foo_shutdown, /* optional */ 49 .shutdown = foo_shutdown, /* optional */
58 .suspend = foo_suspend, /* optional */ 50 .suspend = foo_suspend, /* optional */
59 .resume = foo_resume, /* optional */ 51 .resume = foo_resume, /* optional */
60 .command = foo_command, /* optional */ 52 .command = foo_command, /* optional, deprecated */
61} 53}
62 54
63The name field is the driver name, and must not contain spaces. It 55The name field is the driver name, and must not contain spaces. It
64should match the module name (if the driver can be compiled as a module), 56should match the module name (if the driver can be compiled as a module),
65although you can use MODULE_ALIAS (passing "foo" in this example) to add 57although you can use MODULE_ALIAS (passing "foo" in this example) to add
66another name for the module. If the driver name doesn't match the module 58another name for the module. If the driver name doesn't match the module
67name, the module won't be automatically loaded (hotplug/coldplug). 59name, the module won't be automatically loaded (hotplug/coldplug).
68 60
69All other fields are for call-back functions which will be explained 61All other fields are for call-back functions which will be explained
70below. 62below.
71 63
72 64
@@ -74,34 +66,13 @@ Extra client data
74================= 66=================
75 67
76Each client structure has a special `data' field that can point to any 68Each client structure has a special `data' field that can point to any
77structure at all. You should use this to keep device-specific data, 69structure at all. You should use this to keep device-specific data.
78especially in drivers that handle multiple I2C or SMBUS devices. You
79do not always need this, but especially for `sensors' drivers, it can
80be very useful.
81 70
82 /* store the value */ 71 /* store the value */
83 void i2c_set_clientdata(struct i2c_client *client, void *data); 72 void i2c_set_clientdata(struct i2c_client *client, void *data);
84 73
85 /* retrieve the value */ 74 /* retrieve the value */
86 void *i2c_get_clientdata(struct i2c_client *client); 75 void *i2c_get_clientdata(const struct i2c_client *client);
87
88An example structure is below.
89
90 struct foo_data {
91 struct i2c_client client;
92 enum chips type; /* To keep the chips type for `sensors' drivers. */
93
94 /* Because the i2c bus is slow, it is often useful to cache the read
95 information of a chip for some time (for example, 1 or 2 seconds).
96 It depends of course on the device whether this is really worthwhile
97 or even sensible. */
98 struct mutex update_lock; /* When we are reading lots of information,
99 another process should not update the
100 below information */
101 char valid; /* != 0 if the following fields are valid. */
102 unsigned long last_updated; /* In jiffies */
103 /* Add the read information here too */
104 };
105 76
106 77
107Accessing the client 78Accessing the client
@@ -109,11 +80,9 @@ Accessing the client
109 80
110Let's say we have a valid client structure. At some time, we will need 81Let's say we have a valid client structure. At some time, we will need
111to gather information from the client, or write new information to the 82to gather information from the client, or write new information to the
112client. How we will export this information to user-space is less 83client.
113important at this moment (perhaps we do not need to do this at all for
114some obscure clients). But we need generic reading and writing routines.
115 84
116I have found it useful to define foo_read and foo_write function for this. 85I have found it useful to define foo_read and foo_write functions for this.
117For some cases, it will be easier to call the i2c functions directly, 86For some cases, it will be easier to call the i2c functions directly,
118but many chips have some kind of register-value idea that can easily 87but many chips have some kind of register-value idea that can easily
119be encapsulated. 88be encapsulated.
@@ -121,33 +90,33 @@ be encapsulated.
121The below functions are simple examples, and should not be copied 90The below functions are simple examples, and should not be copied
122literally. 91literally.
123 92
124 int foo_read_value(struct i2c_client *client, u8 reg) 93int foo_read_value(struct i2c_client *client, u8 reg)
125 { 94{
126 if (reg < 0x10) /* byte-sized register */ 95 if (reg < 0x10) /* byte-sized register */
127 return i2c_smbus_read_byte_data(client,reg); 96 return i2c_smbus_read_byte_data(client, reg);
128 else /* word-sized register */ 97 else /* word-sized register */
129 return i2c_smbus_read_word_data(client,reg); 98 return i2c_smbus_read_word_data(client, reg);
130 } 99}
131 100
132 int foo_write_value(struct i2c_client *client, u8 reg, u16 value) 101int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
133 { 102{
134 if (reg == 0x10) /* Impossible to write - driver error! */ { 103 if (reg == 0x10) /* Impossible to write - driver error! */
135 return -1; 104 return -EINVAL;
136 else if (reg < 0x10) /* byte-sized register */ 105 else if (reg < 0x10) /* byte-sized register */
137 return i2c_smbus_write_byte_data(client,reg,value); 106 return i2c_smbus_write_byte_data(client, reg, value);
138 else /* word-sized register */ 107 else /* word-sized register */
139 return i2c_smbus_write_word_data(client,reg,value); 108 return i2c_smbus_write_word_data(client, reg, value);
140 } 109}
141 110
142 111
143Probing and attaching 112Probing and attaching
144===================== 113=====================
145 114
146The Linux I2C stack was originally written to support access to hardware 115The Linux I2C stack was originally written to support access to hardware
147monitoring chips on PC motherboards, and thus it embeds some assumptions 116monitoring chips on PC motherboards, and thus used to embed some assumptions
148that are more appropriate to SMBus (and PCs) than to I2C. One of these 117that were more appropriate to SMBus (and PCs) than to I2C. One of these
149assumptions is that most adapters and devices drivers support the SMBUS_QUICK 118assumptions was that most adapters and devices drivers support the SMBUS_QUICK
150protocol to probe device presence. Another is that devices and their drivers 119protocol to probe device presence. Another was that devices and their drivers
151can be sufficiently configured using only such probe primitives. 120can be sufficiently configured using only such probe primitives.
152 121
153As Linux and its I2C stack became more widely used in embedded systems 122As Linux and its I2C stack became more widely used in embedded systems
@@ -164,6 +133,9 @@ since the "legacy" model requires drivers to create "i2c_client" device
164objects after SMBus style probing, while the Linux driver model expects 133objects after SMBus style probing, while the Linux driver model expects
165drivers to be given such device objects in their probe() routines. 134drivers to be given such device objects in their probe() routines.
166 135
136The legacy model is deprecated now and will soon be removed, so we no
137longer document it here.
138
167 139
168Standard Driver Model Binding ("New Style") 140Standard Driver Model Binding ("New Style")
169------------------------------------------- 141-------------------------------------------
@@ -193,8 +165,8 @@ matches the device's name. It is passed the entry that was matched so
193the driver knows which one in the table matched. 165the driver knows which one in the table matched.
194 166
195 167
196Device Creation (Standard driver model) 168Device Creation
197--------------------------------------- 169---------------
198 170
199If you know for a fact that an I2C device is connected to a given I2C bus, 171If you know for a fact that an I2C device is connected to a given I2C bus,
200you can instantiate that device by simply filling an i2c_board_info 172you can instantiate that device by simply filling an i2c_board_info
@@ -221,8 +193,8 @@ in the I2C bus driver. You may want to save the returned i2c_client
221reference for later use. 193reference for later use.
222 194
223 195
224Device Detection (Standard driver model) 196Device Detection
225---------------------------------------- 197----------------
226 198
227Sometimes you do not know in advance which I2C devices are connected to 199Sometimes you do not know in advance which I2C devices are connected to
228a given I2C bus. This is for example the case of hardware monitoring 200a given I2C bus. This is for example the case of hardware monitoring
@@ -246,8 +218,8 @@ otherwise misdetections are likely to occur and things can get wrong
246quickly. 218quickly.
247 219
248 220
249Device Deletion (Standard driver model) 221Device Deletion
250--------------------------------------- 222---------------
251 223
252Each I2C device which has been created using i2c_new_device() or 224Each I2C device which has been created using i2c_new_device() or
253i2c_new_probed_device() can be unregistered by calling 225i2c_new_probed_device() can be unregistered by calling
@@ -256,264 +228,37 @@ called automatically before the underlying I2C bus itself is removed, as a
256device can't survive its parent in the device driver model. 228device can't survive its parent in the device driver model.
257 229
258 230
259Legacy Driver Binding Model 231Initializing the driver
260--------------------------- 232=======================
233
234When the kernel is booted, or when your foo driver module is inserted,
235you have to do some initializing. Fortunately, just registering the
236driver module is usually enough.
261 237
262Most i2c devices can be present on several i2c addresses; for some this 238static int __init foo_init(void)
263is determined in hardware (by soldering some chip pins to Vcc or Ground), 239{
264for others this can be changed in software (by writing to specific client 240 return i2c_add_driver(&foo_driver);
265registers). Some devices are usually on a specific address, but not always; 241}
266and some are even more tricky. So you will probably need to scan several 242
267i2c addresses for your clients, and do some sort of detection to see 243static void __exit foo_cleanup(void)
268whether it is actually a device supported by your driver. 244{
245 i2c_del_driver(&foo_driver);
246}
247
248/* Substitute your own name and email address */
249MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
250MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
269 251
270To give the user a maximum of possibilities, some default module parameters 252/* a few non-GPL license types are also allowed */
271are defined to help determine what addresses are scanned. Several macros 253MODULE_LICENSE("GPL");
272are defined in i2c.h to help you support them, as well as a generic 254
273detection algorithm. 255module_init(foo_init);
274 256module_exit(foo_cleanup);
275You do not have to use this parameter interface; but don't try to use 257
276function i2c_probe() if you don't. 258Note that some functions are marked by `__init'. These functions can
277 259be removed after kernel booting (or module loading) is completed.
278 260Likewise, functions marked by `__exit' are dropped by the compiler when
279Probing classes (Legacy model) 261the code is built into the kernel, as they would never be called.
280------------------------------
281
282All parameters are given as lists of unsigned 16-bit integers. Lists are
283terminated by I2C_CLIENT_END.
284The following lists are used internally:
285
286 normal_i2c: filled in by the module writer.
287 A list of I2C addresses which should normally be examined.
288 probe: insmod parameter.
289 A list of pairs. The first value is a bus number (-1 for any I2C bus),
290 the second is the address. These addresses are also probed, as if they
291 were in the 'normal' list.
292 ignore: insmod parameter.
293 A list of pairs. The first value is a bus number (-1 for any I2C bus),
294 the second is the I2C address. These addresses are never probed.
295 This parameter overrules the 'normal_i2c' list only.
296 force: insmod parameter.
297 A list of pairs. The first value is a bus number (-1 for any I2C bus),
298 the second is the I2C address. A device is blindly assumed to be on
299 the given address, no probing is done.
300
301Additionally, kind-specific force lists may optionally be defined if
302the driver supports several chip kinds. They are grouped in a
303NULL-terminated list of pointers named forces, those first element if the
304generic force list mentioned above. Each additional list correspond to an
305insmod parameter of the form force_<kind>.
306
307Fortunately, as a module writer, you just have to define the `normal_i2c'
308parameter. The complete declaration could look like this:
309
310 /* Scan 0x4c to 0x4f */
311 static const unsigned short normal_i2c[] = { 0x4c, 0x4d, 0x4e, 0x4f,
312 I2C_CLIENT_END };
313
314 /* Magic definition of all other variables and things */
315 I2C_CLIENT_INSMOD;
316 /* Or, if your driver supports, say, 2 kind of devices: */
317 I2C_CLIENT_INSMOD_2(foo, bar);
318
319If you use the multi-kind form, an enum will be defined for you:
320 enum chips { any_chip, foo, bar, ... }
321You can then (and certainly should) use it in the driver code.
322
323Note that you *have* to call the defined variable `normal_i2c',
324without any prefix!
325
326
327Attaching to an adapter (Legacy model)
328--------------------------------------
329
330Whenever a new adapter is inserted, or for all adapters if the driver is
331being registered, the callback attach_adapter() is called. Now is the
332time to determine what devices are present on the adapter, and to register
333a client for each of them.
334
335The attach_adapter callback is really easy: we just call the generic
336detection function. This function will scan the bus for us, using the
337information as defined in the lists explained above. If a device is
338detected at a specific address, another callback is called.
339
340 int foo_attach_adapter(struct i2c_adapter *adapter)
341 {
342 return i2c_probe(adapter,&addr_data,&foo_detect_client);
343 }
344
345Remember, structure `addr_data' is defined by the macros explained above,
346so you do not have to define it yourself.
347
348The i2c_probe function will call the foo_detect_client
349function only for those i2c addresses that actually have a device on
350them (unless a `force' parameter was used). In addition, addresses that
351are already in use (by some other registered client) are skipped.
352
353
354The detect client function (Legacy model)
355-----------------------------------------
356
357The detect client function is called by i2c_probe. The `kind' parameter
358contains -1 for a probed detection, 0 for a forced detection, or a positive
359number for a forced detection with a chip type forced.
360
361Returning an error different from -ENODEV in a detect function will cause
362the detection to stop: other addresses and adapters won't be scanned.
363This should only be done on fatal or internal errors, such as a memory
364shortage or i2c_attach_client failing.
365
366For now, you can ignore the `flags' parameter. It is there for future use.
367
368 int foo_detect_client(struct i2c_adapter *adapter, int address,
369 int kind)
370 {
371 int err = 0;
372 int i;
373 struct i2c_client *client;
374 struct foo_data *data;
375 const char *name = "";
376
377 /* Let's see whether this adapter can support what we need.
378 Please substitute the things you need here! */
379 if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
380 I2C_FUNC_SMBUS_WRITE_BYTE))
381 goto ERROR0;
382
383 /* OK. For now, we presume we have a valid client. We now create the
384 client structure, even though we cannot fill it completely yet.
385 But it allows us to access several i2c functions safely */
386
387 if (!(data = kzalloc(sizeof(struct foo_data), GFP_KERNEL))) {
388 err = -ENOMEM;
389 goto ERROR0;
390 }
391
392 client = &data->client;
393 i2c_set_clientdata(client, data);
394
395 client->addr = address;
396 client->adapter = adapter;
397 client->driver = &foo_driver;
398
399 /* Now, we do the remaining detection. If no `force' parameter is used. */
400
401 /* First, the generic detection (if any), that is skipped if any force
402 parameter was used. */
403 if (kind < 0) {
404 /* The below is of course bogus */
405 if (foo_read(client, FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
406 goto ERROR1;
407 }
408
409 /* Next, specific detection. This is especially important for `sensors'
410 devices. */
411
412 /* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
413 was used. */
414 if (kind <= 0) {
415 i = foo_read(client, FOO_REG_CHIPTYPE);
416 if (i == FOO_TYPE_1)
417 kind = chip1; /* As defined in the enum */
418 else if (i == FOO_TYPE_2)
419 kind = chip2;
420 else {
421 printk("foo: Ignoring 'force' parameter for unknown chip at "
422 "adapter %d, address 0x%02x\n",i2c_adapter_id(adapter),address);
423 goto ERROR1;
424 }
425 }
426
427 /* Now set the type and chip names */
428 if (kind == chip1) {
429 name = "chip1";
430 } else if (kind == chip2) {
431 name = "chip2";
432 }
433
434 /* Fill in the remaining client fields. */
435 strlcpy(client->name, name, I2C_NAME_SIZE);
436 data->type = kind;
437 mutex_init(&data->update_lock); /* Only if you use this field */
438
439 /* Any other initializations in data must be done here too. */
440
441 /* This function can write default values to the client registers, if
442 needed. */
443 foo_init_client(client);
444
445 /* Tell the i2c layer a new client has arrived */
446 if ((err = i2c_attach_client(client)))
447 goto ERROR1;
448
449 return 0;
450
451 /* OK, this is not exactly good programming practice, usually. But it is
452 very code-efficient in this case. */
453
454 ERROR1:
455 kfree(data);
456 ERROR0:
457 return err;
458 }
459
460
461Removing the client (Legacy model)
462==================================
463
464The detach_client call back function is called when a client should be
465removed. It may actually fail, but only when panicking. This code is
466much simpler than the attachment code, fortunately!
467
468 int foo_detach_client(struct i2c_client *client)
469 {
470 int err;
471
472 /* Try to detach the client from i2c space */
473 if ((err = i2c_detach_client(client)))
474 return err;
475
476 kfree(i2c_get_clientdata(client));
477 return 0;
478 }
479
480
481Initializing the module or kernel
482=================================
483
484When the kernel is booted, or when your foo driver module is inserted,
485you have to do some initializing. Fortunately, just attaching (registering)
486the driver module is usually enough.
487
488 static int __init foo_init(void)
489 {
490 int res;
491
492 if ((res = i2c_add_driver(&foo_driver))) {
493 printk("foo: Driver registration failed, module not inserted.\n");
494 return res;
495 }
496 return 0;
497 }
498
499 static void __exit foo_cleanup(void)
500 {
501 i2c_del_driver(&foo_driver);
502 }
503
504 /* Substitute your own name and email address */
505 MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
506 MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
507
508 /* a few non-GPL license types are also allowed */
509 MODULE_LICENSE("GPL");
510
511 module_init(foo_init);
512 module_exit(foo_cleanup);
513
514Note that some functions are marked by `__init', and some data structures
515by `__initdata'. These functions and structures can be removed after
516kernel booting (or module loading) is completed.
517 262
518 263
519Power Management 264Power Management
@@ -548,33 +293,35 @@ Command function
548 293
549A generic ioctl-like function call back is supported. You will seldom 294A generic ioctl-like function call back is supported. You will seldom
550need this, and its use is deprecated anyway, so newer design should not 295need this, and its use is deprecated anyway, so newer design should not
551use it. Set it to NULL. 296use it.
552 297
553 298
554Sending and receiving 299Sending and receiving
555===================== 300=====================
556 301
557If you want to communicate with your device, there are several functions 302If you want to communicate with your device, there are several functions
558to do this. You can find all of them in i2c.h. 303to do this. You can find all of them in <linux/i2c.h>.
559 304
560If you can choose between plain i2c communication and SMBus level 305If you can choose between plain I2C communication and SMBus level
561communication, please use the last. All adapters understand SMBus level 306communication, please use the latter. All adapters understand SMBus level
562commands, but only some of them understand plain i2c! 307commands, but only some of them understand plain I2C!
563 308
564 309
565Plain i2c communication 310Plain I2C communication
566----------------------- 311-----------------------
567 312
568 extern int i2c_master_send(struct i2c_client *,const char* ,int); 313 int i2c_master_send(struct i2c_client *client, const char *buf,
569 extern int i2c_master_recv(struct i2c_client *,char* ,int); 314 int count);
315 int i2c_master_recv(struct i2c_client *client, char *buf, int count);
570 316
571These routines read and write some bytes from/to a client. The client 317These routines read and write some bytes from/to a client. The client
572contains the i2c address, so you do not have to include it. The second 318contains the i2c address, so you do not have to include it. The second
573parameter contains the bytes the read/write, the third the length of the 319parameter contains the bytes to read/write, the third the number of bytes
574buffer. Returned is the actual number of bytes read/written. 320to read/write (must be less than the length of the buffer.) Returned is
575 321the actual number of bytes read/written.
576 extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg, 322
577 int num); 323 int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
324 int num);
578 325
579This sends a series of messages. Each message can be a read or write, 326This sends a series of messages. Each message can be a read or write,
580and they can be mixed in any way. The transactions are combined: no 327and they can be mixed in any way. The transactions are combined: no
@@ -583,49 +330,45 @@ for each message the client address, the number of bytes of the message
583and the message data itself. 330and the message data itself.
584 331
585You can read the file `i2c-protocol' for more information about the 332You can read the file `i2c-protocol' for more information about the
586actual i2c protocol. 333actual I2C protocol.
587 334
588 335
589SMBus communication 336SMBus communication
590------------------- 337-------------------
591 338
592 extern s32 i2c_smbus_xfer (struct i2c_adapter * adapter, u16 addr, 339 s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
593 unsigned short flags, 340 unsigned short flags, char read_write, u8 command,
594 char read_write, u8 command, int size, 341 int size, union i2c_smbus_data *data);
595 union i2c_smbus_data * data); 342
596 343This is the generic SMBus function. All functions below are implemented
597 This is the generic SMBus function. All functions below are implemented 344in terms of it. Never use this function directly!
598 in terms of it. Never use this function directly! 345
599 346 s32 i2c_smbus_read_byte(struct i2c_client *client);
600 347 s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);
601 extern s32 i2c_smbus_read_byte(struct i2c_client * client); 348 s32 i2c_smbus_read_byte_data(struct i2c_client *client, u8 command);
602 extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value); 349 s32 i2c_smbus_write_byte_data(struct i2c_client *client,
603 extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command); 350 u8 command, u8 value);
604 extern s32 i2c_smbus_write_byte_data(struct i2c_client * client, 351 s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
605 u8 command, u8 value); 352 s32 i2c_smbus_write_word_data(struct i2c_client *client,
606 extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command); 353 u8 command, u16 value);
607 extern s32 i2c_smbus_write_word_data(struct i2c_client * client, 354 s32 i2c_smbus_process_call(struct i2c_client *client,
608 u8 command, u16 value); 355 u8 command, u16 value);
609 extern s32 i2c_smbus_process_call(struct i2c_client *client, 356 s32 i2c_smbus_read_block_data(struct i2c_client *client,
610 u8 command, u16 value); 357 u8 command, u8 *values);
611 extern s32 i2c_smbus_read_block_data(struct i2c_client * client, 358 s32 i2c_smbus_write_block_data(struct i2c_client *client,
612 u8 command, u8 *values); 359 u8 command, u8 length, const u8 *values);
613 extern s32 i2c_smbus_write_block_data(struct i2c_client * client, 360 s32 i2c_smbus_read_i2c_block_data(struct i2c_client *client,
614 u8 command, u8 length, 361 u8 command, u8 length, u8 *values);
615 u8 *values); 362 s32 i2c_smbus_write_i2c_block_data(struct i2c_client *client,
616 extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, 363 u8 command, u8 length,
617 u8 command, u8 length, u8 *values); 364 const u8 *values);
618 extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
619 u8 command, u8 length,
620 u8 *values);
621 365
622These ones were removed from i2c-core because they had no users, but could 366These ones were removed from i2c-core because they had no users, but could
623be added back later if needed: 367be added back later if needed:
624 368
625 extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value); 369 s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
626 extern s32 i2c_smbus_block_process_call(struct i2c_client *client, 370 s32 i2c_smbus_block_process_call(struct i2c_client *client,
627 u8 command, u8 length, 371 u8 command, u8 length, u8 *values);
628 u8 *values)
629 372
630All these transactions return a negative errno value on failure. The 'write' 373All these transactions return a negative errno value on failure. The 'write'
631transactions return 0 on success; the 'read' transactions return the read 374transactions return 0 on success; the 'read' transactions return the read
@@ -642,7 +385,5 @@ General purpose routines
642Below all general purpose routines are listed, that were not mentioned 385Below all general purpose routines are listed, that were not mentioned
643before. 386before.
644 387
645 /* This call returns a unique low identifier for each registered adapter. 388 /* Return the adapter number for a specific adapter */
646 */ 389 int i2c_adapter_id(struct i2c_adapter *adap);
647 extern int i2c_adapter_id(struct i2c_adapter *adap);
648