i2c的数据结构
来源:互联网 发布:虎嗅网 源码 2016 编辑:程序博客网 时间:2024/05/22 06:48
1、i2c_adapter
struct i2c_adapter{struct module *owner;unsigned int id;unsigned int class; /* classes to allow probing for */const struct i2c_algorithm *algo; /* the algorithm to access the bus */void *algo_data;/* data fields that are valid for all devices*/u8 level; /* nesting level for lockdep */struct mutex bus_lock;int timeout;/* in jiffies */int retries;struct device dev;/* the adapter device */int nr;char name[48];struct completion dev_released;};
i2c_adapter is the structure used to identify a physical i2c bus along with the access algorithms necessary to access it.2、i2c_algorithm
struct i2c_algorithm{/* If an adapter algorithm can't do I2C-level access, set master_xfer to NULL. If an adapter algorithm can do SMBus access, set smbus_xfer. If set to NULL, the SMBus protocol is simulated using common I2C messages *//* master_xfer should return the number of messages successfully processed, or a negative value on error */int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs, int num);int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, unsigned short flags, char read_write, u8 command, int size, union i2c_smbus_data *data);/* To determine what the adapter supports */u32 (*functionality) (struct i2c_adapter *);};
/** The following structs are for those who like to implement new bus drivers:
* i2c_algorithm is the interface to a class of hardware solutions which can
* be addressed using the same bus algorithms - i.e. bit-banging or the PCF8584
* to name two of the most common.
*/
3、i2c_client
struct i2c_client{unsigned short flags;/* div., see below*/unsigned short addr;/* chip address - NOTE: 7bit*//* addresses are stored in the*//* _LOWER_ 7 bits*/char name[I2C_NAME_SIZE];struct i2c_adapter *adapter;/* the adapter we sit on*/struct i2c_driver *driver;/* and our access routines*/struct device dev;/* the device structure*/int irq;/* irq issued by device*/struct list_head detected;};
/*** struct i2c_client - represent an I2C slave device
* @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
* I2C_CLIENT_PEC indicates it uses SMBus Packet Error Checking
* @addr: Address used on the I2C bus connected to the parent adapter.
* @name: Indicates the type of the device, usually a chip name that's
* generic enough to hide second-sourcing and compatible revisions.
* @adapter: manages the bus segment hosting this I2C device
* @driver: device's driver, hence pointer to access routines
* @dev: Driver model device node for the slave.
* @irq: indicates the IRQ generated by this device (if any)
* @detected: member of an i2c_driver.clients list or i2c-core's
* userspace_devices list
*
* An i2c_client identifies a single device (i.e. chip) connected to an
* i2c bus. The behaviour exposed to Linux is defined by the driver
* managing the device.
*/
4、i2c_driver
struct i2c_driver{int id;unsigned int class;/* Notifies the driver that a new bus has appeared or is about to be * removed. You should avoid using this if you can, it will probably * be removed in a near future. */int (*attach_adapter)(struct i2c_adapter *);int (*detach_adapter)(struct i2c_adapter *);/* Standard driver model interfaces */int (*probe)(struct i2c_client *, const struct i2c_device_id *);int (*remove)(struct i2c_client *);/* driver model interfaces that don't relate to enumeration */void (*shutdown)(struct i2c_client *);int (*suspend)(struct i2c_client *, pm_message_t mesg);int (*resume)(struct i2c_client *);/* a ioctl like command that can be used to perform specific functions * with the device. */int (*command)(struct i2c_client *client, unsigned int cmd, void *arg);struct device_driver driver;const struct i2c_device_id *id_table;/* Device detection callback for automatic device creation */int (*detect)(struct i2c_client *, int kind, struct i2c_board_info *);const struct i2c_client_address_data *address_data;struct list_head clients;};
/*** struct i2c_driver - represent an I2C device driver
* @id: Unique driver ID (optional)
* @class: What kind of i2c device we instantiate (for detect)
* @attach_adapter: Callback for bus addition (for legacy drivers)
* @detach_adapter: Callback for bus removal (for legacy drivers)
* @probe: Callback for device binding
* @remove: Callback for device unbinding
* @shutdown: Callback for device shutdown
* @suspend: Callback for device suspend
* @resume: Callback for device resume
* @command: Callback for bus-wide signaling (optional)
* @driver: Device driver model driver
* @id_table: List of I2C devices supported by this driver
* @detect: Callback for device detection
* @address_data: The I2C addresses to probe, ignore or force (for detect)
* @clients: List of detected clients we created (for i2c-core use only)
*
* The driver.owner field should be set to the module owner of this driver.
* The driver.name field should be set to the name of this driver.
*
* For automatic device detection, both @detect and @address_data must
* be defined. @class should also be set, otherwise only devices forced
* with module parameters will be created. The detect function must
* fill at least the name field of the i2c_board_info structure it is
* handed upon successful detection, and possibly also the flags field.
*
* If @detect is missing, the driver will still work fine for enumerated
* devices. Detected devices simply won't be supported. This is expected
* for the many I2C/SMBus devices which can't be detected reliably, and
* the ones which can always be enumerated in practice.
*
* The i2c_client structure which is handed to the @detect callback is
* not a real i2c_client. It is initialized just enough so that you can
* call i2c_smbus_read_byte_data and friends on it. Don't do anything
* else with it. In particular, calling dev_dbg and friends on it is
* not allowed.
*/
5、i2c_msg
struct i2c_msg {__u16 addr;/* slave address*/__u16 flags;#define I2C_M_TEN0x0010/* this is a ten bit chip address */#define I2C_M_RD0x0001/* read data, from slave to master */#define I2C_M_NOSTART0x4000/* if I2C_FUNC_PROTOCOL_MANGLING */#define I2C_M_REV_DIR_ADDR0x2000/* if I2C_FUNC_PROTOCOL_MANGLING */#define I2C_M_IGNORE_NAK0x1000/* if I2C_FUNC_PROTOCOL_MANGLING */#define I2C_M_NO_RD_ACK0x0800/* if I2C_FUNC_PROTOCOL_MANGLING */#define I2C_M_RECV_LEN0x0400/* length will be first received byte */__u16 len;/* msg length*/__u8 *buf;/* pointer to msg data*/};
/*** struct i2c_msg - an I2C transaction segment beginning with START
* @addr: Slave address, either seven or ten bits. When this is a ten
* bit address, I2C_M_TEN must be set in @flags and the adapter
* must support I2C_FUNC_10BIT_ADDR.
* @flags: I2C_M_RD is handled by all adapters. No other flags may be
* provided unless the adapter exported the relevant I2C_FUNC_*
* flags through i2c_check_functionality().
* @len: Number of data bytes in @buf being read from or written to the
* I2C slave address. For read transactions where I2C_M_RECV_LEN
* is set, the caller guarantees that this buffer can hold up to
* 32 bytes in addition to the initial length byte sent by the
* slave (plus, if used, the SMBus PEC); and this value will be
* incremented by the number of block data bytes received.
* @buf: The buffer into which data is read, or from which it's written.
*
* An i2c_msg is the low level representation of one segment of an I2C
* transaction. It is visible to drivers in the @i2c_transfer() procedure,
* to userspace from i2c-dev, and to I2C adapter drivers through the
* @i2c_adapter.@master_xfer() method.
*
* Except when I2C "protocol mangling" is used, all I2C adapters implement
* the standard rules for I2C transactions. Each transaction begins with a
* START. That is followed by the slave address, and a bit encoding read
* versus write. Then follow all the data bytes, possibly including a byte
* with SMBus PEC. The transfer terminates with a NAK, or when all those
* bytes have been transferred and ACKed. If this is the last message in a
* group, it is followed by a STOP. Otherwise it is followed by the next
* @i2c_msg transaction segment, beginning with a (repeated) START.
*
* Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then
* passing certain @flags may have changed those standard protocol behaviors.
* Those flags are only for use with broken/nonconforming slaves, and with
* adapters which are known to support the specific mangling options they
* need (one or more of IGNORE_NAK, NO_RD_ACK, NOSTART, and REV_DIR_ADDR).
*/
- i2c的数据结构
- I2C 驱动核心的数据结构
- I2C驱动的4个数据结构间的关系
- I2C驱动的4个数据结构间的关系
- linux的i2c驱动中的函数和数据结构的分析
- 基于I2C子系统的I2C驱动编写
- DM355的I2C调试
- pdk7105的I2C配置
- I2C总线的学习
- Linux的I2C体系结构
- linux的i2c体系结构
- i2c驱动的编写
- Linux 的 I2C 体系结构
- hi3531的i2c部分
- i2c tool 的使用
- I2C的总线电容
- 树莓派的I2C配置
- Verilog的I2C实现
- C语言中使用静态函数的好处
- OSG-2.8.2在VS2008下的配置安装(介绍一个开源的三维渲染引擎的编译)
- J2me 矩阵相交检测,矩阵碰撞检测,点与矩阵检测
- Android的UI设计与后台线程交互
- 常用正则表达式小结
- i2c的数据结构
- JavaScript函数以及基础写法
- 简易覆盖率信息收集框架
- Android入门教程 Android开发环境配置
- UML常识知识
- OpenOCD + ARM-USB-TINY-H 在ubuntu下
- viewdidload
- 强大的g++呢还是强大的C++?太假了吧
- 一道不错的算法题-判断链表是否有环