Linux I2C（一）之常用的几种实例化(i2c_client )

最新推荐文章于 2024-08-18 23:57:57 发布

慢几步-深几度-前行

最新推荐文章于 2024-08-18 23:57:57 发布

阅读量1.3w

点赞数 4

分类专栏： linux驱动 Android 文章标签： linux I2C i2c-client

本文链接：https://blog.csdn.net/lugandong/article/details/48092397

版权

前言：

因为工作是音频驱动，所以经常涉及到I2C、I2S等常用的总线，想将I2C相关的东西总结一下，让自己更加了解I2C。

基于：Linux3.10

方式一：

使用arch/arm/mach-s3c24xx/mach-mini2440.c举例：

static struct i2c_board_info mini2440_i2c_devs[] __initdata = {
    {
/* 遇到与”24c08一样的名称”的驱动就会与之绑定，0x50是I2C设备的地址 */
        I2C_BOARD_INFO("24c08", 0x50),
        .platform_data = &at24c08,
    },
};

/* 这里的0代表：i2c-0总线 */
    i2c_register_board_info(0, mini2440_i2c_devs,
                ARRAY_SIZE(mini2440_i2c_devs));

到这里我们可以说就完成了第一种方式的实例化。
使用i2c_register_board_info去实例化必须知道我们使用的I2C设备是挂载到哪个总线上，并知道设备的地址。
在Linux启动的时候会将信息进行收集，i2c适配器会扫描已经静态注册的i2c_board_info，通过调用i2c_register_board_info函数将包含所有I2C设备的i2c_board_info信息的i2c_devinfo变量加入到__i2c_board_list链表中，并调用i2c_new_device为其实例化一个i2c_client。在驱动加载的时候遇到同名的i2c_board_info就会将i2c_client和driver绑定，并且执行driver的probe函数。
这种方式一般放在平台的代码中。

struct i2c_board_info :

/**
 * struct i2c_board_info - template for device creation
 * @type: chip type, to initialize i2c_client.name
 * @flags: to initialize i2c_client.flags
 * @addr: stored in i2c_client.addr
 * @platform_data: stored in i2c_client.dev.platform_data
 * @archdata: copied into i2c_client.dev.archdata
 * @of_node: pointer to OpenFirmware device node
 * @acpi_node: ACPI device node
 * @irq: stored in i2c_client.irq
 *
 * I2C doesn't actually support hardware probing, although controllers and
 * devices may be able to use I2C_SMBUS_QUICK to tell whether or not there's
 * a device at a given address.  Drivers commonly need more information than
 * that, such as chip type, configuration, associated IRQ, and so on.
 *
 * i2c_board_info is used to build tables of information listing I2C devices
 * that are present.  This information is used to grow the driver model tree.
 * For mainboards this is done statically using i2c_register_board_info();
 * bus numbers identify adapters that aren't yet available.  For add-on boards,
 * i2c_new_device() does this dynamically with the adapter already known.
 */
struct i2c_board_info {
    char        type[I2C_NAME_SIZE];
    unsigned short  flags;
    unsigned short  addr;
    void        *platform_data;
    struct dev_archdata *archdata;
    struct device_node *of_node;
    struct acpi_dev_node acpi_node;
    int     irq;
};

i2c_register_board_info:

/**
 * i2c_register_board_info - statically declare I2C devices
 * @busnum: identifies the bus to which these devices belong
 * @info: vector of i2c device descriptors
 * @len: how many descriptors in the vector; may be zero to reserve
 *  the specified bus number.
 *
 * Systems using the Linux I2C driver stack can declare tables of board info
 * while they initialize.  This should be done in board-specific init code
 * near arch_initcall() time, or equivalent, before any I2C adapter driver is
 * registered.  For example, mainboard init code could define several devices,
 * as could the init code for each daughtercard in a board stack.
 *
 * The I2C devices will be created later, after the adapter for the relevant
 * bus has been registered.  After that moment, standard driver model tools
 * are used to bind "new style" I2C drivers to