diff options
author | Jean Delvare <khali@linux-fr.org> | 2008-07-14 16:38:36 -0400 |
---|---|---|
committer | Jean Delvare <khali@mahadeva.delvare> | 2008-07-14 16:38:36 -0400 |
commit | 4735c98f8447acb1c8977e2b8024640f7bf36dd6 (patch) | |
tree | 7f7c65b1feef6a0213caa20218cd6080488cc62b /Documentation/i2c | |
parent | 8508159e2f3b82bf109f0ec77bcbd8ff3f3a7e17 (diff) |
i2c: Add detection capability to new-style drivers
Add a mechanism to let new-style i2c drivers optionally autodetect
devices they would support on selected buses and ask i2c-core to
instantiate them. This is a replacement for legacy i2c drivers, much
cleaner.
Where drivers had to implement both a legacy i2c_driver and a
new-style i2c_driver so far, this mechanism makes it possible to get
rid of the legacy i2c_driver and implement both enumerated and
detected device support with just one (new-style) i2c_driver.
Here is a quick conversion guide for these drivers, step by step:
* Delete the legacy driver definition, registration and removal.
Delete the attach_adapter and detach_client methods of the legacy
driver.
* Change the prototype of the legacy detect function from
static int foo_detect(struct i2c_adapter *adapter, int address, int kind);
to
static int foo_detect(struct i2c_client *client, int kind,
struct i2c_board_info *info);
* Set the new-style driver detect callback to this new function, and
set its address_data to &addr_data (addr_data is generally provided
by I2C_CLIENT_INSMOD.)
* Add the appropriate class to the new-style driver. This is
typically the class the legacy attach_adapter method was checking
for. Class checking is now mandatory (done by i2c-core.) See
<linux/i2c.h> for the list of available classes.
* Remove the i2c_client allocation and freeing from the detect
function. A pre-allocated client is now handed to you by i2c-core,
and is freed automatically.
* Make the detect function fill the type field of the i2c_board_info
structure it was passed as a parameter, and return 0, on success. If
the detection fails, return -ENODEV.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Diffstat (limited to 'Documentation/i2c')
-rw-r--r-- | Documentation/i2c/writing-clients | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 63722d3c9cdf..6b61b3a2e90b 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -44,6 +44,10 @@ static struct i2c_driver foo_driver = { | |||
44 | .id_table = foo_ids, | 44 | .id_table = foo_ids, |
45 | .probe = foo_probe, | 45 | .probe = foo_probe, |
46 | .remove = foo_remove, | 46 | .remove = foo_remove, |
47 | /* if device autodetection is needed: */ | ||
48 | .class = I2C_CLASS_SOMETHING, | ||
49 | .detect = foo_detect, | ||
50 | .address_data = &addr_data, | ||
47 | 51 | ||
48 | /* else, driver uses "legacy" binding model: */ | 52 | /* else, driver uses "legacy" binding model: */ |
49 | .attach_adapter = foo_attach_adapter, | 53 | .attach_adapter = foo_attach_adapter, |
@@ -217,6 +221,31 @@ in the I2C bus driver. You may want to save the returned i2c_client | |||
217 | reference for later use. | 221 | reference for later use. |
218 | 222 | ||
219 | 223 | ||
224 | Device Detection (Standard driver model) | ||
225 | ---------------------------------------- | ||
226 | |||
227 | 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 | ||
229 | devices on a PC's SMBus. In that case, you may want to let your driver | ||
230 | detect supported devices automatically. This is how the legacy model | ||
231 | was working, and is now available as an extension to the standard | ||
232 | driver model (so that we can finally get rid of the legacy model.) | ||
233 | |||
234 | You simply have to define a detect callback which will attempt to | ||
235 | identify supported devices (returning 0 for supported ones and -ENODEV | ||
236 | for unsupported ones), a list of addresses to probe, and a device type | ||
237 | (or class) so that only I2C buses which may have that type of device | ||
238 | connected (and not otherwise enumerated) will be probed. The i2c | ||
239 | core will then call you back as needed and will instantiate a device | ||
240 | for you for every successful detection. | ||
241 | |||
242 | Note that this mechanism is purely optional and not suitable for all | ||
243 | devices. You need some reliable way to identify the supported devices | ||
244 | (typically using device-specific, dedicated identification registers), | ||
245 | otherwise misdetections are likely to occur and things can get wrong | ||
246 | quickly. | ||
247 | |||
248 | |||
220 | Device Deletion (Standard driver model) | 249 | Device Deletion (Standard driver model) |
221 | --------------------------------------- | 250 | --------------------------------------- |
222 | 251 | ||