4. Linux内核I2C子系统架构：三层模型与关键数据结构

在车载嵌入式Linux系统中（如IVI、T-Box、ADAS），I2C总线用于连接大量外设：触摸控制器、音频编解码器、电源管理芯片、温度传感器、摄像头传感器配置通道等。理解Linux内核I2C子系统的三层架构，是编写稳定、可移植的车载I2C设备驱动的核心基础。

Linux内核将I2C子系统抽象为三个层次，自下而上分别为：I2C核心层（i2c-core）、I2C总线驱动层（i2c-bus driver）、I2C设备驱动层（i2c-client driver）。这种分层设计实现了硬件适配与设备控制的解耦，使得驱动开发人员可以专注于各自层次的逻辑。

4.1 三层模型职责详解

4.2 关键数据结构详解

I2C子系统的四个核心数据结构构成了三层模型之间的通信桥梁。理解它们的成员含义和生命周期，是编写正确驱动的必要条件。

4.2.1 struct i2c_adapter —— 总线适配器

代表一个I2C控制器硬件实例，是总线驱动层向核心层注册的实体。每个I2C控制器对应一个adapter。

struct i2c_adapter {
    struct module *owner;
    unsigned int class;               // 适配器支持的设备类
    const struct i2c_algorithm *algo; // 通信算法（核心！）
    void *algo_data;
    struct device dev;                // 内核设备模型
    int nr;                           // 总线编号（如i2c-0, i2c-1）
    struct list_head userspace_clients;
    // ... 其他成员
};

4.2.2 struct i2c_algorithm —— 通信算法

定义I2C控制器如何执行数据传输。总线驱动层必须实现master_xfer()回调。

struct i2c_algorithm {
    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);
    u32 (*functionality)(struct i2c_adapter *adap);
};

4.2.3 struct i2c_client —— I2C从设备

代表一个连接到I2C总线上的具体从设备。通常在设备驱动probe()时由核心层根据设备树信息创建。

struct i2c_client {
    unsigned short flags;       // 标志位（如I2C_CLIENT_TEN）
    unsigned short addr;        // 7位或10位从设备地址（关键！）
    char name[I2C_NAME_SIZE];   // 设备名称
    struct i2c_adapter *adapter;// 所属的adapter
    struct device dev;          // 内核设备模型
    int irq;                    // 中断号（设备树中指定）
    struct list_head detected;  // 用于设备检测链表
};

4.2.4 struct i2c_driver —— I2C设备驱动

设备驱动层需要定义并注册的结构体，核心层通过它进行匹配和回调。

struct i2c_driver {
    unsigned int class;
    int (*probe)(struct i2c_client *client,
                 const struct i2c_device_id *id);
    int (*remove)(struct i2c_client *client);
    void (*shutdown)(struct i2c_client *client);
    struct device_driver driver;        // 内核驱动模型
    const struct i2c_device_id *id_table;// 传统匹配表
    const struct of_device_id *of_match_table; // 设备树匹配表（车载首选！）
    // ... 其他成员
};

4.3 数据结构关系与数据流

下图展示了四个核心数据结构之间的协作关系，以及一次典型I2C读操作的数据流路径。

4.4 设备驱动层核心API与使用模式

在车载I2C设备驱动中，最常用的API集中在i2c-core提供的传输函数和SMBus兼容函数。以下是最核心的API及其适用场景。

4.5 设备树与三层模型的关联

设备树（Device Tree）是车载Linux中描述硬件拓扑的标准方式。I2C子系统的三层模型与设备树的对应关系如下：

• I2C控制器节点 → 对应 struct i2c_adapter，由总线驱动层解析并注册。
• I2C子节点（挂在控制器节点下） → 对应 struct i2c_client，由核心层在设备树解析时创建。
• 子节点的compatible属性 → 匹配 i2c_driver.of_match_table，触发probe()。
• 子节点的reg属性 → 赋值给 i2c_client.addr，即从设备地址。
• 子节点的interrupts属性 → 赋值给 i2c_client.irq。

// 设备树示例：I2C控制器节点与子节点
&i2c3 {  // 对应 i2c_adapter nr=3
    clock-frequency = <400000>;  // 400kHz快速模式
    pinctrl-0 = <&pinctrl_i2c3>;
    status = "okay";

    touch: touch@38 {  // 对应 i2c_client addr=0x38
        compatible = "edt,edt-ft5x06";  // 匹配 of_match_table
        reg = <0x38>;
        interrupt-parent = <&gpio1>;
        interrupts = <9 IRQ_TYPE_EDGE_FALLING>;  // 对应 client->irq
        reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
        touchscreen-size-x = <1024>;
        touchscreen-size-y = <600>;
    };

    codec: audio-codec@1a {
        compatible = "wlf,wm8960";
        reg = <0x1a>;
        #sound-dai-cells = <0>;
    };
};

4.6 车载开发中的常见陷阱与最佳实践