Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1183345
  • 博文数量: 221
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 2139
  • 用 户 组: 普通用户
  • 注册时间: 2012-11-27 19:53
个人简介

JustForFun

文章分类

全部博文(221)

文章存档

2024年(6)

2023年(8)

2022年(2)

2021年(2)

2020年(29)

2019年(11)

2018年(23)

2017年(41)

2016年(76)

2015年(23)

我的朋友
最近访客

分类: LINUX

2016-11-25 16:16:43

//////////////////////////////////////////////////////////

/**
 * 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)
 * @list: list of active/busy clients (DEPRECATED)
 * @detected: member of an i2c_driver.clients list
 * @released: used to synchronize client releases & detaches and references
 *
 * 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.
 */
//描述一个从设备的信息,和i2c_driver进行匹配。
struct i2c_client {
    unsigned short flags;        /* div., see below        */
    unsigned short addr;        /* chip address - NOTE: 7bit    */从设备地址,7位
                    /* addresses are stored in the    */
                    /* _LOWER_ 7 bits        */
    char name[I2C_NAME_SIZE];       //name 和driver进行匹配
    struct i2c_adapter *adapter;    /* the adapter we sit on    */指向把自己client创建出来的那个 i2c_adapter总线控制器
    struct i2c_driver *driver;    /* and our access routines    */
    struct device dev;        /* the device structure        */       父类
    int irq;            /* irq issued by device        */
    struct list_head list;        /* DEPRECATED */
    struct list_head detected;
    struct completion released;
};         



//////////////////////////////////////////////////////////

/**
 * 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)
 * @detach_client: Callback for device removal (for legacy drivers)
 * @probe: Callback for device binding (new-style drivers)
 * @remove: Callback for device unbinding (new-style drivers)
 * @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.
 */
struct i2c_driver {
    int id;
    unsigned int class;

    /* Notifies the driver that a new bus has appeared. This routine
     * can be used by the driver to test if the bus meets its conditions
     * & seek for the presence of the chip(s) it supports. If found, it
     * registers the client(s) that are on the bus to the i2c admin. via
     * i2c_attach_client.  (LEGACY I2C DRIVERS ONLY)
     */
    int (*attach_adapter)(struct i2c_adapter *);
    int (*detach_adapter)(struct i2c_adapter *);

    /* tells the driver that a client is about to be deleted & gives it
     * the chance to remove its private data. Also, if the client struct
     * has been dynamically allocated by the driver in the function above,
     * it must be freed here.  (LEGACY I2C DRIVERS ONLY)
     */
    int (*detach_client)(struct i2c_client *);

    /* Standard driver model interfaces, for "new style" i2c drivers.
     * With the driver model, device enumeration is NEVER done by drivers;
     * it's done by infrastructure.  (NEW STYLE DRIVERS ONLY)
     */
    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_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).
 */
struct i2c_msg {
    __u16 addr;    /* slave address            */该消息发送给哪个从设备
    __u16 flags;      //读还是写
#define I2C_M_TEN        0x0010    /* this is a ten bit chip address */
#define I2C_M_RD        0x0001    /* read data, from slave to master */
#define I2C_M_NOSTART        0x4000    /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_REV_DIR_ADDR    0x2000    /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_IGNORE_NAK    0x1000    /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_NO_RD_ACK        0x0800    /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_RECV_LEN        0x0400    /* length will be first received byte */
    __u16 len;        /* msg length                *///读写的长度,以字节为单位
    __u8 *buf;        /* pointer to msg data            */指向要读写数据的缓冲区
};

//////////////////////////////////////////////////////////


/*
 * i2c_adapter is the structure used to identify a physical i2c bus along
 * with the access algorithms necessary to access it.
 */
//适配器     相当于i2c总线控制器
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;

    /* --- administration stuff. */
    int (*client_register)(struct i2c_client *);
    int (*client_unregister)(struct i2c_client *);

    /* data fields that are valid for all devices    */
    u8 level;             /* nesting level for lockdep */
    struct mutex bus_lock;
    struct mutex clist_lock;

    int timeout;
    int retries;
    struct device dev;        /* the adapter device */

//  /sys/bus/i2c/devices/i2c-0
// /sys/bus/i2c/devices/i2c-1
//末尾的数字就是 nr成员的值
    int nr; //号码,第几组寄存器
    struct list_head clients;    /* DEPRECATED */
    char name[48];
    struct completion dev_released;
};





阅读(2558) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~