aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/i2c.h
diff options
context:
space:
mode:
Diffstat (limited to 'include/linux/i2c.h')
-rw-r--r--include/linux/i2c.h62
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 */
218struct 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 */
245extern struct i2c_client *
246i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info);
247
248extern 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 */
254extern int
255i2c_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