diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2008-10-23 13:10:25 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-10-23 13:10:25 -0400 |
commit | feeedc6c820e1026453ad865076cee435f24d30a (patch) | |
tree | 3eae5251bef80944048df1915e180394e5b7818c /Documentation | |
parent | a27028349ccbcec9dde9d6dbba9d4017ad9ad5ab (diff) | |
parent | 11f1f2afd6b07729b12aaba479344d7f12d88ff9 (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.txt | 8 | ||||
-rw-r--r-- | Documentation/i2c/busses/i2c-i801 | 7 | ||||
-rw-r--r-- | Documentation/i2c/porting-clients | 160 | ||||
-rw-r--r-- | Documentation/i2c/writing-clients | 491 |
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. |
361 | Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> | 361 | Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> |
362 | |||
363 | --------------------------- | ||
364 | |||
365 | What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() | ||
366 | When: 2.6.29 (ideally) or 2.6.30 (more likely) | ||
367 | Why: Deprecated by the new (standard) device driver binding model. Use | ||
368 | i2c_driver->probe() and ->remove() instead. | ||
369 | Who: 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 | ||
20 | Authors: | 21 | Authors: |
@@ -32,7 +33,7 @@ Description | |||
32 | ----------- | 33 | ----------- |
33 | 34 | ||
34 | The ICH (properly known as the 82801AA), ICH0 (82801AB), ICH2 (82801BA), | 35 | The ICH (properly known as the 82801AA), ICH0 (82801AB), ICH2 (82801BA), |
35 | ICH3 (82801CA/CAM) and later devices are Intel chips that are a part of | 36 | ICH3 (82801CA/CAM) and later devices (PCH) are Intel chips that are a part of |
36 | Intel's '810' chipset for Celeron-based PCs, '810E' chipset for | 37 | Intel's '810' chipset for Celeron-based PCs, '810E' chipset for |
37 | Pentium-based PCs, '815E' chipset, and others. | 38 | Pentium-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 @@ | |||
1 | Revision 7, 2007-04-19 | ||
2 | Jean Delvare <khali@linux-fr.org> | ||
3 | Greg KH <greg@kroah.com> | ||
4 | |||
5 | This is a guide on how to convert I2C chip drivers from Linux 2.4 to | ||
6 | Linux 2.6. I have been using existing drivers (lm75, lm78) as examples. | ||
7 | Then I converted a driver myself (lm83) and updated this document. | ||
8 | Note that this guide is strongly oriented towards hardware monitoring | ||
9 | drivers. Many points are still valid for other type of drivers, but | ||
10 | others may be irrelevant. | ||
11 | |||
12 | There are two sets of points below. The first set concerns technical | ||
13 | changes. The second set concerns coding policy. Both are mandatory. | ||
14 | |||
15 | Although reading this guide will help you porting drivers, I suggest | ||
16 | you keep an eye on an already ported driver while porting your own | ||
17 | driver. This will help you a lot understanding what this guide | ||
18 | exactly means. Choose the chip driver that is the more similar to | ||
19 | yours for best results. | ||
20 | |||
21 | Technical 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 | |||
136 | Coding 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 | ||
12 | Try to keep the kernel namespace as clean as possible. The best way to | 12 | Try to keep the kernel namespace as clean as possible. The best way to |
13 | do this is to use a unique prefix for all global symbols. This is | 13 | do this is to use a unique prefix for all global symbols. This is |
14 | especially important for exported symbols, but it is a good idea to do | 14 | especially important for exported symbols, but it is a good idea to do |
15 | it for non-exported symbols too. We will use the prefix `foo_' in this | 15 | it for non-exported symbols too. We will use the prefix `foo_' in this |
16 | tutorial, and `FOO_' for preprocessor variables. | 16 | tutorial. |
17 | 17 | ||
18 | 18 | ||
19 | The driver structure | 19 | The driver structure |
20 | ==================== | 20 | ==================== |
21 | 21 | ||
22 | Usually, you will implement a single driver structure, and instantiate | 22 | Usually, you will implement a single driver structure, and instantiate |
23 | all clients from it. Remember, a driver structure contains general access | 23 | all clients from it. Remember, a driver structure contains general access |
24 | routines, and should be zero-initialized except for fields with data you | 24 | routines, and should be zero-initialized except for fields with data you |
25 | provide. A client structure holds device-specific information like the | 25 | provide. A client structure holds device-specific information like the |
26 | driver model device node, and its I2C address. | 26 | driver model device node, and its I2C address. |
27 | 27 | ||
28 | /* iff driver uses driver model ("new style") binding model: */ | ||
29 | |||
30 | static struct i2c_device_id foo_idtable[] = { | 28 | static 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 | ||
63 | The name field is the driver name, and must not contain spaces. It | 55 | The name field is the driver name, and must not contain spaces. It |
64 | should match the module name (if the driver can be compiled as a module), | 56 | should match the module name (if the driver can be compiled as a module), |
65 | although you can use MODULE_ALIAS (passing "foo" in this example) to add | 57 | although you can use MODULE_ALIAS (passing "foo" in this example) to add |
66 | another name for the module. If the driver name doesn't match the module | 58 | another name for the module. If the driver name doesn't match the module |
67 | name, the module won't be automatically loaded (hotplug/coldplug). | 59 | name, the module won't be automatically loaded (hotplug/coldplug). |
68 | 60 | ||
69 | All other fields are for call-back functions which will be explained | 61 | All other fields are for call-back functions which will be explained |
70 | below. | 62 | below. |
71 | 63 | ||
72 | 64 | ||
@@ -74,34 +66,13 @@ Extra client data | |||
74 | ================= | 66 | ================= |
75 | 67 | ||
76 | Each client structure has a special `data' field that can point to any | 68 | Each client structure has a special `data' field that can point to any |
77 | structure at all. You should use this to keep device-specific data, | 69 | structure at all. You should use this to keep device-specific data. |
78 | especially in drivers that handle multiple I2C or SMBUS devices. You | ||
79 | do not always need this, but especially for `sensors' drivers, it can | ||
80 | be 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 | |||
88 | An 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 | ||
107 | Accessing the client | 78 | Accessing the client |
@@ -109,11 +80,9 @@ Accessing the client | |||
109 | 80 | ||
110 | Let's say we have a valid client structure. At some time, we will need | 81 | Let's say we have a valid client structure. At some time, we will need |
111 | to gather information from the client, or write new information to the | 82 | to gather information from the client, or write new information to the |
112 | client. How we will export this information to user-space is less | 83 | client. |
113 | important at this moment (perhaps we do not need to do this at all for | ||
114 | some obscure clients). But we need generic reading and writing routines. | ||
115 | 84 | ||
116 | I have found it useful to define foo_read and foo_write function for this. | 85 | I have found it useful to define foo_read and foo_write functions for this. |
117 | For some cases, it will be easier to call the i2c functions directly, | 86 | For some cases, it will be easier to call the i2c functions directly, |
118 | but many chips have some kind of register-value idea that can easily | 87 | but many chips have some kind of register-value idea that can easily |
119 | be encapsulated. | 88 | be encapsulated. |
@@ -121,33 +90,33 @@ be encapsulated. | |||
121 | The below functions are simple examples, and should not be copied | 90 | The below functions are simple examples, and should not be copied |
122 | literally. | 91 | literally. |
123 | 92 | ||
124 | int foo_read_value(struct i2c_client *client, u8 reg) | 93 | int 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) | 101 | int 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 | ||
143 | Probing and attaching | 112 | Probing and attaching |
144 | ===================== | 113 | ===================== |
145 | 114 | ||
146 | The Linux I2C stack was originally written to support access to hardware | 115 | The Linux I2C stack was originally written to support access to hardware |
147 | monitoring chips on PC motherboards, and thus it embeds some assumptions | 116 | monitoring chips on PC motherboards, and thus used to embed some assumptions |
148 | that are more appropriate to SMBus (and PCs) than to I2C. One of these | 117 | that were more appropriate to SMBus (and PCs) than to I2C. One of these |
149 | assumptions is that most adapters and devices drivers support the SMBUS_QUICK | 118 | assumptions was that most adapters and devices drivers support the SMBUS_QUICK |
150 | protocol to probe device presence. Another is that devices and their drivers | 119 | protocol to probe device presence. Another was that devices and their drivers |
151 | can be sufficiently configured using only such probe primitives. | 120 | can be sufficiently configured using only such probe primitives. |
152 | 121 | ||
153 | As Linux and its I2C stack became more widely used in embedded systems | 122 | As 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 | |||
164 | objects after SMBus style probing, while the Linux driver model expects | 133 | objects after SMBus style probing, while the Linux driver model expects |
165 | drivers to be given such device objects in their probe() routines. | 134 | drivers to be given such device objects in their probe() routines. |
166 | 135 | ||
136 | The legacy model is deprecated now and will soon be removed, so we no | ||
137 | longer document it here. | ||
138 | |||
167 | 139 | ||
168 | Standard Driver Model Binding ("New Style") | 140 | Standard 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 | |||
193 | the driver knows which one in the table matched. | 165 | the driver knows which one in the table matched. |
194 | 166 | ||
195 | 167 | ||
196 | Device Creation (Standard driver model) | 168 | Device Creation |
197 | --------------------------------------- | 169 | --------------- |
198 | 170 | ||
199 | If you know for a fact that an I2C device is connected to a given I2C bus, | 171 | If you know for a fact that an I2C device is connected to a given I2C bus, |
200 | you can instantiate that device by simply filling an i2c_board_info | 172 | you 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 | |||
221 | reference for later use. | 193 | reference for later use. |
222 | 194 | ||
223 | 195 | ||
224 | Device Detection (Standard driver model) | 196 | Device Detection |
225 | ---------------------------------------- | 197 | ---------------- |
226 | 198 | ||
227 | Sometimes you do not know in advance which I2C devices are connected to | 199 | Sometimes you do not know in advance which I2C devices are connected to |
228 | a given I2C bus. This is for example the case of hardware monitoring | 200 | a 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 | |||
246 | quickly. | 218 | quickly. |
247 | 219 | ||
248 | 220 | ||
249 | Device Deletion (Standard driver model) | 221 | Device Deletion |
250 | --------------------------------------- | 222 | --------------- |
251 | 223 | ||
252 | Each I2C device which has been created using i2c_new_device() or | 224 | Each I2C device which has been created using i2c_new_device() or |
253 | i2c_new_probed_device() can be unregistered by calling | 225 | i2c_new_probed_device() can be unregistered by calling |
@@ -256,264 +228,37 @@ called automatically before the underlying I2C bus itself is removed, as a | |||
256 | device can't survive its parent in the device driver model. | 228 | device can't survive its parent in the device driver model. |
257 | 229 | ||
258 | 230 | ||
259 | Legacy Driver Binding Model | 231 | Initializing the driver |
260 | --------------------------- | 232 | ======================= |
233 | |||
234 | When the kernel is booted, or when your foo driver module is inserted, | ||
235 | you have to do some initializing. Fortunately, just registering the | ||
236 | driver module is usually enough. | ||
261 | 237 | ||
262 | Most i2c devices can be present on several i2c addresses; for some this | 238 | static int __init foo_init(void) |
263 | is determined in hardware (by soldering some chip pins to Vcc or Ground), | 239 | { |
264 | for others this can be changed in software (by writing to specific client | 240 | return i2c_add_driver(&foo_driver); |
265 | registers). Some devices are usually on a specific address, but not always; | 241 | } |
266 | and some are even more tricky. So you will probably need to scan several | 242 | |
267 | i2c addresses for your clients, and do some sort of detection to see | 243 | static void __exit foo_cleanup(void) |
268 | whether 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 */ | ||
249 | MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>" | ||
250 | MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices"); | ||
269 | 251 | ||
270 | To give the user a maximum of possibilities, some default module parameters | 252 | /* a few non-GPL license types are also allowed */ |
271 | are defined to help determine what addresses are scanned. Several macros | 253 | MODULE_LICENSE("GPL"); |
272 | are defined in i2c.h to help you support them, as well as a generic | 254 | |
273 | detection algorithm. | 255 | module_init(foo_init); |
274 | 256 | module_exit(foo_cleanup); | |
275 | You do not have to use this parameter interface; but don't try to use | 257 | |
276 | function i2c_probe() if you don't. | 258 | Note that some functions are marked by `__init'. These functions can |
277 | 259 | be removed after kernel booting (or module loading) is completed. | |
278 | 260 | Likewise, functions marked by `__exit' are dropped by the compiler when | |
279 | Probing classes (Legacy model) | 261 | the code is built into the kernel, as they would never be called. |
280 | ------------------------------ | ||
281 | |||
282 | All parameters are given as lists of unsigned 16-bit integers. Lists are | ||
283 | terminated by I2C_CLIENT_END. | ||
284 | The 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 | |||
301 | Additionally, kind-specific force lists may optionally be defined if | ||
302 | the driver supports several chip kinds. They are grouped in a | ||
303 | NULL-terminated list of pointers named forces, those first element if the | ||
304 | generic force list mentioned above. Each additional list correspond to an | ||
305 | insmod parameter of the form force_<kind>. | ||
306 | |||
307 | Fortunately, as a module writer, you just have to define the `normal_i2c' | ||
308 | parameter. 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 | |||
319 | If you use the multi-kind form, an enum will be defined for you: | ||
320 | enum chips { any_chip, foo, bar, ... } | ||
321 | You can then (and certainly should) use it in the driver code. | ||
322 | |||
323 | Note that you *have* to call the defined variable `normal_i2c', | ||
324 | without any prefix! | ||
325 | |||
326 | |||
327 | Attaching to an adapter (Legacy model) | ||
328 | -------------------------------------- | ||
329 | |||
330 | Whenever a new adapter is inserted, or for all adapters if the driver is | ||
331 | being registered, the callback attach_adapter() is called. Now is the | ||
332 | time to determine what devices are present on the adapter, and to register | ||
333 | a client for each of them. | ||
334 | |||
335 | The attach_adapter callback is really easy: we just call the generic | ||
336 | detection function. This function will scan the bus for us, using the | ||
337 | information as defined in the lists explained above. If a device is | ||
338 | detected 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 | |||
345 | Remember, structure `addr_data' is defined by the macros explained above, | ||
346 | so you do not have to define it yourself. | ||
347 | |||
348 | The i2c_probe function will call the foo_detect_client | ||
349 | function only for those i2c addresses that actually have a device on | ||
350 | them (unless a `force' parameter was used). In addition, addresses that | ||
351 | are already in use (by some other registered client) are skipped. | ||
352 | |||
353 | |||
354 | The detect client function (Legacy model) | ||
355 | ----------------------------------------- | ||
356 | |||
357 | The detect client function is called by i2c_probe. The `kind' parameter | ||
358 | contains -1 for a probed detection, 0 for a forced detection, or a positive | ||
359 | number for a forced detection with a chip type forced. | ||
360 | |||
361 | Returning an error different from -ENODEV in a detect function will cause | ||
362 | the detection to stop: other addresses and adapters won't be scanned. | ||
363 | This should only be done on fatal or internal errors, such as a memory | ||
364 | shortage or i2c_attach_client failing. | ||
365 | |||
366 | For 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 | |||
461 | Removing the client (Legacy model) | ||
462 | ================================== | ||
463 | |||
464 | The detach_client call back function is called when a client should be | ||
465 | removed. It may actually fail, but only when panicking. This code is | ||
466 | much 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 | |||
481 | Initializing the module or kernel | ||
482 | ================================= | ||
483 | |||
484 | When the kernel is booted, or when your foo driver module is inserted, | ||
485 | you have to do some initializing. Fortunately, just attaching (registering) | ||
486 | the 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 | |||
514 | Note that some functions are marked by `__init', and some data structures | ||
515 | by `__initdata'. These functions and structures can be removed after | ||
516 | kernel booting (or module loading) is completed. | ||
517 | 262 | ||
518 | 263 | ||
519 | Power Management | 264 | Power Management |
@@ -548,33 +293,35 @@ Command function | |||
548 | 293 | ||
549 | A generic ioctl-like function call back is supported. You will seldom | 294 | A generic ioctl-like function call back is supported. You will seldom |
550 | need this, and its use is deprecated anyway, so newer design should not | 295 | need this, and its use is deprecated anyway, so newer design should not |
551 | use it. Set it to NULL. | 296 | use it. |
552 | 297 | ||
553 | 298 | ||
554 | Sending and receiving | 299 | Sending and receiving |
555 | ===================== | 300 | ===================== |
556 | 301 | ||
557 | If you want to communicate with your device, there are several functions | 302 | If you want to communicate with your device, there are several functions |
558 | to do this. You can find all of them in i2c.h. | 303 | to do this. You can find all of them in <linux/i2c.h>. |
559 | 304 | ||
560 | If you can choose between plain i2c communication and SMBus level | 305 | If you can choose between plain I2C communication and SMBus level |
561 | communication, please use the last. All adapters understand SMBus level | 306 | communication, please use the latter. All adapters understand SMBus level |
562 | commands, but only some of them understand plain i2c! | 307 | commands, but only some of them understand plain I2C! |
563 | 308 | ||
564 | 309 | ||
565 | Plain i2c communication | 310 | Plain 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 | ||
571 | These routines read and write some bytes from/to a client. The client | 317 | These routines read and write some bytes from/to a client. The client |
572 | contains the i2c address, so you do not have to include it. The second | 318 | contains the i2c address, so you do not have to include it. The second |
573 | parameter contains the bytes the read/write, the third the length of the | 319 | parameter contains the bytes to read/write, the third the number of bytes |
574 | buffer. Returned is the actual number of bytes read/written. | 320 | to read/write (must be less than the length of the buffer.) Returned is |
575 | 321 | the 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 | ||
579 | This sends a series of messages. Each message can be a read or write, | 326 | This sends a series of messages. Each message can be a read or write, |
580 | and they can be mixed in any way. The transactions are combined: no | 327 | and 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 | |||
583 | and the message data itself. | 330 | and the message data itself. |
584 | 331 | ||
585 | You can read the file `i2c-protocol' for more information about the | 332 | You can read the file `i2c-protocol' for more information about the |
586 | actual i2c protocol. | 333 | actual I2C protocol. |
587 | 334 | ||
588 | 335 | ||
589 | SMBus communication | 336 | SMBus 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 | 343 | This is the generic SMBus function. All functions below are implemented | |
597 | This is the generic SMBus function. All functions below are implemented | 344 | in 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 | ||
622 | These ones were removed from i2c-core because they had no users, but could | 366 | These ones were removed from i2c-core because they had no users, but could |
623 | be added back later if needed: | 367 | be 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 | ||
630 | All these transactions return a negative errno value on failure. The 'write' | 373 | All these transactions return a negative errno value on failure. The 'write' |
631 | transactions return 0 on success; the 'read' transactions return the read | 374 | transactions return 0 on success; the 'read' transactions return the read |
@@ -642,7 +385,5 @@ General purpose routines | |||
642 | Below all general purpose routines are listed, that were not mentioned | 385 | Below all general purpose routines are listed, that were not mentioned |
643 | before. | 386 | before. |
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 | |||