4. Linux I2C 子系统框架：三层架构详解

在 RK 平台 Sensor 驱动开发中，理解 Linux I2C 子系统的三层架构是进行通信故障排查的理论基础。该架构将复杂的 I2C 通信过程抽象为三个层次，实现了硬件无关性与驱动代码复用的设计目标。任何 I2C 通信故障，最终都可以映射到这三层中的某一层或层间接口上。

4.1 I2C 核心层 (I2C Core)

I2C 核心层是 Linux I2C 子系统的中枢，它不直接操作硬件，而是提供一套统一的框架和 API，用于管理 I2C 总线、设备和驱动。核心层的主要职责包括：

• 总线管理： 维护系统中的所有 I2C 总线适配器 (Adapter) 列表。
• 设备与驱动管理： 负责 I2C 设备的注册、注销以及驱动的匹配 (Match) 与绑定 (Bind)。
• 协议抽象： 提供标准的 I2C 消息传输接口 (i2c_transfer)，并兼容 SMBus 协议。
• 锁机制： 提供总线访问锁，防止多线程/多进程并发访问导致的数据混乱。

4.2 I2C 总线驱动 (I2C Bus Driver / Adapter)

I2C 总线驱动直接与 SoC 内部的 I2C 控制器硬件交互，负责最底层的时序生成、起始/停止条件、数据收发、ACK/NACK 检测等物理层操作。在 RK 平台上，常见的 I2C 控制器驱动包括：

总线驱动通过 struct i2c_algorithm 结构体向上层提供通信能力，其中最核心的函数指针是 master_xfer：

// 定义在 include/linux/i2c.h
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.3 I2C 设备驱动 (I2C Device Driver)

I2C 设备驱动是离 Sensor 硬件最近的软件抽象层，也是驱动开发者主要编码的地方。它通过 I2C 核心层提供的 API 与总线驱动通信，实现对 Sensor 芯片的寄存器读写控制。一个标准的 I2C 设备驱动包含以下关键部分：

1. 设备树匹配表 (of_match_table)： 用于与设备树中的 Sensor 节点进行匹配。
2. I2C 设备 ID 表 (i2c_device_id)： 用于传统非设备树方式的匹配。
3. probe 函数： 设备与驱动匹配成功后调用，完成硬件初始化、数据结构和 sysfs 接口创建。
4. remove 函数： 设备移除或驱动卸载时调用，释放资源。
5. regmap 或直接 I2C 读写函数： 封装对 Sensor 寄存器的读写操作。

以下是一个典型的 RK 平台 Sensor I2C 设备驱动框架代码：

#include <linux/i2c.h>
#include <linux/module.h>
#include <linux/of.h>

static const struct of_device_id sensor_of_match[] = {
    { .compatible = "rockchip,example-sensor" },
    { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sensor_of_match);

static const struct i2c_device_id sensor_id[] = {
    { "example-sensor", 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, sensor_id);

static int sensor_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
    struct device *dev = &client->dev;
    int ret;

    dev_info(dev, "Sensor probe start, addr=0x%02x\n", client->addr);

    /* 1. 检查 I2C 通信是否正常：读取 WHO_AM_I 寄存器 */
    ret = i2c_smbus_read_byte_data(client, 0x0F);
    if (ret < 0) {
        dev_err(dev, "Failed to read WHO_AM_I: %d\n", ret);
        return ret;
    }
    dev_info(dev, "WHO_AM_I = 0x%02x\n", ret);

    /* 2. 初始化 Sensor 配置 */
    /* ... */

    /* 3. 注册输入设备或 IIO 设备 */
    /* ... */

    return 0;
}

static int sensor_remove(struct i2c_client *client)
{
    dev_info(&client->dev, "Sensor remove\n");
    /* 释放资源 */
    return 0;
}

static struct i2c_driver sensor_driver = {
    .driver = {
        .name   = "example-sensor",
        .of_match_table = sensor_of_match,
    },
    .probe    = sensor_probe,
    .remove   = sensor_remove,
    .id_table = sensor_id,
};

module_i2c_driver(sensor_driver);

MODULE_AUTHOR("RK Platform Expert");
MODULE_DESCRIPTION("Example Sensor I2C Driver for RK Platform");
MODULE_LICENSE("GPL");

4.4 三层架构的协作关系与数据流

当 Sensor 驱动需要读取一个寄存器时，完整的调用链如下：

4.5 故障排查中的分层定位法

在实际的 RK 平台 Sensor 调试中，建议按照以下分层策略快速定位 I2C 通信故障：

• 硬件层 (物理层)： 使用示波器或逻辑分析仪测量 SCL/SDA 波形。检查上拉电阻 (通常 4.7kΩ)、电平匹配 (1.8V vs 3.3V)、以及 Sensor 供电是否正常。
• 总线驱动层： 使用 i2cdetect -y <bus_number> 命令扫描总线，确认 Sensor 的 I2C 地址是否出现在正确的总线上。如果地址显示为 UU 表示驱动已占用，显示为 -- 表示无应答。
• 核心层： 检查 /sys/bus/i2c/devices/ 下是否生成了正确的设备节点。检查内核日志 (dmesg) 中是否有 i2c core 相关的错误信息。
• 设备驱动层： 在 probe 函数中添加调试打印，确认驱动是否被成功加载。使用 i2cget 命令手动读取 Sensor 寄存器，验证驱动逻辑是否正确。