diff options
author | David Brownell <david-b@pacbell.net> | 2007-05-01 17:26:31 -0400 |
---|---|---|
committer | Jean Delvare <khali@hyperion.delvare> | 2007-05-01 17:26:31 -0400 |
commit | 9c1600eda42e52796f49b36cf15b9debcfd09bea (patch) | |
tree | fe93f5924c7777cd5c3cc1ef6033dd2dfae542b5 /include/linux/i2c.h | |
parent | 4298cfc3eb6110df989f784be516c6340c597a66 (diff) |
i2c: Add i2c_board_info and i2c_new_device()
This provides partial support for new-style I2C driver binding. It builds
on "struct i2c_board_info" declarations that identify I2C devices on a given
board. This is needed on systems with I2C devices that can't be fully probed
and/or autoconfigured, such as many embedded Linux configurations where the
way a given I2C device is wired may affect how it must be used.
There are two models for declaring such devices:
* LATE -- using a public function i2c_new_device(). This lets modules
declare I2C devices found *AFTER* a given I2C adapter becomes available.
For example, a PCI card could create adapters giving access to utility
chips on that card, and this would be used to associate those chips with
those adapters.
* EARLY -- from arch_initcall() level code, using a non-exported function
i2c_register_board_info(). This copies the declarations *BEFORE* such
an i2c_adapter becomes available, arranging that i2c_new_device() will
be called later when i2c-core registers the relevant i2c_adapter.
For example, arch/.../.../board-*.c files would declare the I2C devices
along with their platform data, and I2C devices would behave much like
PNPACPI devices. (That is, both enumerate from board-specific tables.)
To match the exported i2c_new_device(), the previously-private function
i2c_unregister_device() is now exported.
Pending later patches using these new APIs, this is effectively a NOP.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Diffstat (limited to 'include/linux/i2c.h')
-rw-r--r-- | include/linux/i2c.h | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/include/linux/i2c.h b/include/linux/i2c.h index 6802c3a0a3a3..382a43bf3ad5 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h | |||
@@ -172,6 +172,7 @@ struct i2c_client { | |||
172 | int usage_count; /* How many accesses currently */ | 172 | int usage_count; /* How many accesses currently */ |
173 | /* to the client */ | 173 | /* to the client */ |
174 | struct device dev; /* the device structure */ | 174 | struct device dev; /* the device structure */ |
175 | int irq; /* irq issued by device (or -1) */ | ||
175 | char driver_name[KOBJ_NAME_LEN]; | 176 | char driver_name[KOBJ_NAME_LEN]; |
176 | struct list_head list; | 177 | struct list_head list; |
177 | struct completion released; | 178 | struct completion released; |
@@ -193,6 +194,67 @@ static inline void i2c_set_clientdata (struct i2c_client *dev, void *data) | |||
193 | dev_set_drvdata (&dev->dev, data); | 194 | dev_set_drvdata (&dev->dev, data); |
194 | } | 195 | } |
195 | 196 | ||
197 | /** | ||
198 | * struct i2c_board_info - template for device creation | ||
199 | * @driver_name: identifies the driver to be bound to the device | ||
200 | * @type: optional chip type information, to initialize i2c_client.name | ||
201 | * @flags: to initialize i2c_client.flags | ||
202 | * @addr: stored in i2c_client.addr | ||
203 | * @platform_data: stored in i2c_client.dev.platform_data | ||
204 | * @irq: stored in i2c_client.irq | ||
205 | |||
206 | * I2C doesn't actually support hardware probing, although controllers and | ||
207 | * devices may be able to use I2C_SMBUS_QUICK to tell whether or not there's | ||
208 | * a device at a given address. Drivers commonly need more information than | ||
209 | * that, such as chip type, configuration, associated IRQ, and so on. | ||
210 | * | ||
211 | * i2c_board_info is used to build tables of information listing I2C devices | ||
212 | * that are present. This information is used to grow the driver model tree | ||
213 | * for "new style" I2C drivers. For mainboards this is done statically using | ||
214 | * i2c_register_board_info(), where @bus_num represents an adapter that isn't | ||
215 | * yet available. For add-on boards, i2c_new_device() does this dynamically | ||
216 | * with the adapter already known. | ||
217 | */ | ||
218 | struct i2c_board_info { | ||
219 | char driver_name[KOBJ_NAME_LEN]; | ||
220 | char type[I2C_NAME_SIZE]; | ||
221 | unsigned short flags; | ||
222 | unsigned short addr; | ||
223 | void *platform_data; | ||
224 | int irq; | ||
225 | }; | ||
226 | |||
227 | /** | ||
228 | * I2C_BOARD_INFO - macro used to list an i2c device and its driver | ||
229 | * @driver: identifies the driver to use with the device | ||
230 | * @dev_addr: the device's address on the bus. | ||
231 | * | ||
232 | * This macro initializes essential fields of a struct i2c_board_info, | ||
233 | * declaring what has been provided on a particular board. Optional | ||
234 | * fields (such as the chip type, its associated irq, or device-specific | ||
235 | * platform_data) are provided using conventional syntax. | ||
236 | */ | ||
237 | #define I2C_BOARD_INFO(driver,dev_addr) \ | ||
238 | .driver_name = (driver), .addr = (dev_addr) | ||
239 | |||
240 | |||
241 | /* Add-on boards should register/unregister their devices; e.g. a board | ||
242 | * with integrated I2C, a config eeprom, sensors, and a codec that's | ||
243 | * used in conjunction with the primary hardware. | ||
244 | */ | ||
245 | extern struct i2c_client * | ||
246 | i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info); | ||
247 | |||
248 | extern void i2c_unregister_device(struct i2c_client *); | ||
249 | |||
250 | /* Mainboard arch_initcall() code should register all its I2C devices. | ||
251 | * This is done at arch_initcall time, before declaring any i2c adapters. | ||
252 | * Modules for add-on boards must use other calls. | ||
253 | */ | ||
254 | extern int | ||
255 | i2c_register_board_info(int busnum, struct i2c_board_info const *info, unsigned n); | ||
256 | |||
257 | |||
196 | /* | 258 | /* |
197 | * The following structs are for those who like to implement new bus drivers: | 259 | * The following structs are for those who like to implement new bus drivers: |
198 | * i2c_algorithm is the interface to a class of hardware solutions which can | 260 | * i2c_algorithm is the interface to a class of hardware solutions which can |