diff options
author | Jean Delvare <khali@linux-fr.org> | 2009-03-28 16:34:40 -0400 |
---|---|---|
committer | Jean Delvare <khali@linux-fr.org> | 2009-03-28 16:34:40 -0400 |
commit | 764c16918fb2347b3cbc8f6030b2b6561911bc32 (patch) | |
tree | 0420f4263f89f5a5658af473c39168189a02b300 /Documentation/i2c/writing-clients | |
parent | 5d80f8e5a9dc9c9a94d4aeaa567e219a808b8a4a (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-clients | 19 |
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 | |||
207 | identify supported devices (returning 0 for supported ones and -ENODEV | 207 | identify supported devices (returning 0 for supported ones and -ENODEV |
208 | for unsupported ones), a list of addresses to probe, and a device type | 208 | for 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 |
210 | connected (and not otherwise enumerated) will be probed. The i2c | 210 | connected (and not otherwise enumerated) will be probed. For example, |
211 | core will then call you back as needed and will instantiate a device | 211 | a driver for a hardware monitoring chip for which auto-detection is |
212 | for you for every successful detection. | 212 | needed would set its class to I2C_CLASS_HWMON, and only I2C adapters |
213 | with a class including I2C_CLASS_HWMON would be probed by this driver. | ||
214 | Note that the absence of matching classes does not prevent the use of | ||
215 | a device of that type on the given I2C adapter. All it prevents is | ||
216 | auto-detection; explicit instantiation of devices is still possible. | ||
213 | 217 | ||
214 | Note that this mechanism is purely optional and not suitable for all | 218 | Note that this mechanism is purely optional and not suitable for all |
215 | devices. You need some reliable way to identify the supported devices | 219 | devices. 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), |
217 | otherwise misdetections are likely to occur and things can get wrong | 221 | otherwise misdetections are likely to occur and things can get wrong |
218 | quickly. | 222 | quickly. Keep in mind that the I2C protocol doesn't include any |
223 | standard way to detect the presence of a chip at a given address, let | ||
224 | alone a standard way to identify devices. Even worse is the lack of | ||
225 | semantics associated to bus transfers, which means that the same | ||
226 | transfer can be seen as a read operation by a chip and as a write | ||
227 | operation by another chip. For these reasons, explicit device | ||
228 | instantiation should always be preferred to auto-detection where | ||
229 | possible. | ||
219 | 230 | ||
220 | 231 | ||
221 | Device Deletion | 232 | Device Deletion |