diff options
author | Jean Delvare <khali@linux-fr.org> | 2007-05-01 17:26:32 -0400 |
---|---|---|
committer | Jean Delvare <khali@hyperion.delvare> | 2007-05-01 17:26:32 -0400 |
commit | ce9e0794c23fb1d0222cb10009a198b427dcf6ad (patch) | |
tree | 6e8a1e8ce894fa46b26550764d3b09e802c485b2 /Documentation | |
parent | 12b5053ac58709c7d475888bc18d1f61958afc4e (diff) |
i2c: Document i2c_new_device()
Document the new i2c_new_device(), i2c_new_probed_device() and
i2c_unregister_device() functions.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/i2c/writing-clients | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 54255fd68ec7..e62fbfa1282d 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -200,6 +200,44 @@ device typing support in the hardware. The driver and module name should | |||
200 | match, so hotplug/coldplug mechanisms will modprobe the driver. | 200 | match, so hotplug/coldplug mechanisms will modprobe the driver. |
201 | 201 | ||
202 | 202 | ||
203 | Device Creation (Standard driver model) | ||
204 | --------------------------------------- | ||
205 | |||
206 | If you know for a fact that an I2C device is connected to a given I2C bus, | ||
207 | you can instantiate that device by simply filling an i2c_board_info | ||
208 | structure with the device address and driver name, and calling | ||
209 | i2c_new_device(). This will create the device, then the driver core will | ||
210 | take care of finding the right driver and will call its probe() method. | ||
211 | If a driver supports different device types, you can specify the type you | ||
212 | want using the type field. You can also specify an IRQ and platform data | ||
213 | if needed. | ||
214 | |||
215 | Sometimes you know that a device is connected to a given I2C bus, but you | ||
216 | don't know the exact address it uses. This happens on TV adapters for | ||
217 | example, where the same driver supports dozens of slightly different | ||
218 | models, and I2C device addresses change from one model to the next. In | ||
219 | that case, you can use the i2c_new_probed_device() variant, which is | ||
220 | similar to i2c_new_device(), except that it takes an additional list of | ||
221 | possible I2C addresses to probe. A device is created for the first | ||
222 | responsive address in the list. If you expect more than one device to be | ||
223 | present in the address range, simply call i2c_new_probed_device() that | ||
224 | many times. | ||
225 | |||
226 | The call to i2c_new_device() or i2c_new_probed_device() typically happens | ||
227 | in the I2C bus driver. You may want to save the returned i2c_client | ||
228 | reference for later use. | ||
229 | |||
230 | |||
231 | Device Deletion (Standard driver model) | ||
232 | --------------------------------------- | ||
233 | |||
234 | Each I2C device which has been created using i2c_new_device() or | ||
235 | i2c_new_probed_device() can be unregistered by calling | ||
236 | i2c_unregister_device(). If you don't call it explicitly, it will be | ||
237 | called automatically before the underlying I2C bus itself is removed, as a | ||
238 | device can't survive its parent in the device driver model. | ||
239 | |||
240 | |||
203 | Legacy Driver Binding Model | 241 | Legacy Driver Binding Model |
204 | --------------------------- | 242 | --------------------------- |
205 | 243 | ||