aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/i2c/writing-clients
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2009-03-28 16:34:40 -0400
committerJean Delvare <khali@linux-fr.org>2009-03-28 16:34:40 -0400
commit764c16918fb2347b3cbc8f6030b2b6561911bc32 (patch)
tree0420f4263f89f5a5658af473c39168189a02b300 /Documentation/i2c/writing-clients
parent5d80f8e5a9dc9c9a94d4aeaa567e219a808b8a4a (diff)
i2c: Document the different ways to instantiate i2c devices
On popular demand, here comes some documentation about how to instantiate i2c devices in the new (standard) i2c device driver binding model. I have also clarified how the class bitfield lets driver authors control which buses are probed in the auto-detect case, and warned more loudly against the abuse of this method. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Michael Lawnick <nospam_lawnick@gmx.de> Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Diffstat (limited to 'Documentation/i2c/writing-clients')
-rw-r--r--Documentation/i2c/writing-clients19
1 files changed, 15 insertions, 4 deletions
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 6b9af7d479c2..c1a06f989cf7 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -207,15 +207,26 @@ You simply have to define a detect callback which will attempt to
207identify supported devices (returning 0 for supported ones and -ENODEV 207identify supported devices (returning 0 for supported ones and -ENODEV
208for unsupported ones), a list of addresses to probe, and a device type 208for unsupported ones), a list of addresses to probe, and a device type
209(or class) so that only I2C buses which may have that type of device 209(or class) so that only I2C buses which may have that type of device
210connected (and not otherwise enumerated) will be probed. The i2c 210connected (and not otherwise enumerated) will be probed. For example,
211core will then call you back as needed and will instantiate a device 211a driver for a hardware monitoring chip for which auto-detection is
212for you for every successful detection. 212needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
213with a class including I2C_CLASS_HWMON would be probed by this driver.
214Note that the absence of matching classes does not prevent the use of
215a device of that type on the given I2C adapter. All it prevents is
216auto-detection; explicit instantiation of devices is still possible.
213 217
214Note that this mechanism is purely optional and not suitable for all 218Note that this mechanism is purely optional and not suitable for all
215devices. You need some reliable way to identify the supported devices 219devices. You need some reliable way to identify the supported devices
216(typically using device-specific, dedicated identification registers), 220(typically using device-specific, dedicated identification registers),
217otherwise misdetections are likely to occur and things can get wrong 221otherwise misdetections are likely to occur and things can get wrong
218quickly. 222quickly. Keep in mind that the I2C protocol doesn't include any
223standard way to detect the presence of a chip at a given address, let
224alone a standard way to identify devices. Even worse is the lack of
225semantics associated to bus transfers, which means that the same
226transfer can be seen as a read operation by a chip and as a write
227operation by another chip. For these reasons, explicit device
228instantiation should always be preferred to auto-detection where
229possible.
219 230
220 231
221Device Deletion 232Device Deletion