深入RK3568 I2C总线锁机制：从i2c_transfer看Linux并发控制设计

原创

于 2026-02-27 01:55:11 发布 · 848 阅读

标签

#RK3568 #I2C #Linux驱动 #并发控制

深入RK3568 I2C总线锁机制：从i2c_transfer看Linux并发控制设计

在嵌入式Linux驱动开发中，I2C总线作为连接各类传感器、EEPROM和外围芯片的桥梁，其稳定性和可靠性直接决定了整个系统的表现。然而，当多个线程、中断处理程序或内核任务同时尝试访问同一I2C总线时，如果没有恰当的并发控制机制，数据冲突、总线锁死等灾难性后果几乎不可避免。RK3568作为一款面向中高端应用的多核SoC，其I2C子系统承载着连接多种外设的重任，理解其底层的并发控制逻辑，对于构建稳定高效的嵌入式系统至关重要。

今天，我们不满足于仅仅调用i2c_transfer()完成数据传输，而是要深入Linux内核的I2C核心层，剖析i2c_transfer函数中那些精妙的锁机制设计。你会发现，看似简单的I2C读写背后，隐藏着一套针对原子上下文、中断环境、多核竞争等复杂场景的周全考量。对于中高级驱动开发者而言，掌握这些机制不仅能帮助你在调试时快速定位诡异的时序问题，更能让你在设计自己的驱动时，做出更符合内核哲学、更稳健的架构选择。

1. I2C总线并发访问的挑战与内核的应对策略

I2C总线本质上是一种共享资源。在典型的嵌入式场景中，一个I2C控制器（Adapter）可能连接着温度传感器、RTC时钟、EEPROM存储器等多个从设备。当系统中有多个执行流（比如用户空间的多个进程、内核中的多个线程、或者硬件中断服务例程）都需要通过这个控制器与各自的从设备通信时，冲突就产生了。

想象一下这样的场景：一个用户态进程正在通过I2C读取温度传感器的数据，此时一个高优先级的中断触发，中断处理程序也需要通过同一个I2C总线向RTC芯片写入时间。如果两者同时操作，I2C总线时序就会完全混乱，导致两个操作都失败，甚至可能损坏从设备。更复杂的是，在SMP（对称多处理）系统中，不同的CPU核心可能同时发起I2C传输请求，这进一步加剧了竞争的复杂性。

Linux内核解决这类共享资源访问冲突的经典方法是锁。但在I2C这个特定场景下，锁的选择和运用需要格外小心。为什么？因为I2C传输本身可能涉及较长的等待时间（特别是时钟拉伸或从设备响应慢的情况），如果在原子上下文（比如中断处理程序、软中断、持有自旋锁的代码区）中错误地使用了可能导致睡眠的锁，就会引发内核死锁或系统崩溃。

i2c_transfer函数的聪明之处在于，它根据当前执行上下文动态选择锁策略。让我们先看看它的函数签名和基本逻辑框架：

int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
    int ret;
    
    if (adap->algo->master_xfer) {
#ifdef DEBUG
        /* 调试信息输出 */
#endif
        /* 关键部分：根据上下文选择锁定方式 */
        if (in_atomic() || irqs_disabled()) {
            ret = i2c_trylock_bus(adap, I2C_LOCK_SEGMENT);
            if (!ret)
                return -EAGAIN;
        } else {
            i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
        }
        
        /* 执行实际的传输 */
        ret = __i2c_transfer(adap, msgs, num);
        
        /* 解锁总线 */
        i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
        return ret;
    } else {
        dev_dbg(&adap->dev, "I2C level transfers not supported\n");
        return -EOPNOTSUPP;
    }
}

这个看似简单的函数，实际上包含了Linux内核并发控制思想的精髓。它首先检查适配器是否实现了master_xfer方法（这是硬件相关的传输函数），然后根据in_atomic()和irqs_disabled()的判断结果，决定使用i2c_trylock_bus（尝试获取锁）还是i2c_lock_bus（阻塞式获取锁）。这种区分对待的设计，正是为了应对不同执行上下文的约束。

注意：这里的I2C_LOCK_SEGMENT标志值得关注。它表示锁定的是总线的一个“段”，而不是整个总线。这种细粒度的锁定策略允许在支持多主或多段的总线上实现更高程度的并发，但在大多数单主控制器（如RK3568的I2C控制器）上，它实际上等同于锁定整个总线。

2. 原子上下文判断：in_atomic()与irqs_disabled()的深层含义

要理解i2c_transfer中的锁选择逻辑，我们必须先弄清楚in_atomic()和irqs_disabled()这两个条件判断的真实含义。它们不是随意添加的，而是内核开发者对执行环境约束的精确把握。

2.1 in_atomic()：识别不可睡眠的上下文

in_atomic()函数返回真值时，表示当前代码正运行在“原子上下文”中。什么是原子上下文？简单来说，就是不能进行进程调度、不能调用可能引起睡眠的函数的执行环境。这包括：

硬件中断处理程序（Hard IRQ）：当硬件中断发生时，内核会暂停当前进程的执行，转而运行中断处理程序。在这个上下文中，调度器被禁用，任何可能导致睡眠的操作都是禁止的。
软中断（Softirq）和tasklet：这些是中断下半部机制，同样运行在原子上下文中。
持有自旋锁（spinlock）的代码区域：自旋锁的设计初衷就是在短时间内保护共享数据，持有自旋锁时睡眠会导致死锁。
关闭本地CPU抢占的上下文：通过preempt_disable()禁用抢占后，也处于原子上下文中。

在RK3568的实际驱动开发中，你可能会在以下场景遇到原子上下文：

/* 示例：在中断处理函数中访问I2C设备 */
static irqreturn_t sensor_irq_handler(int irq, void *dev_id)
{
    struct sensor_data *data = dev_id;
    
    /* 这里处于原子上下文！in_atomic()返回true */
    if (in_atomic()) {
        /* 不能直接调用可能睡眠的i2c_transfer */
        schedule_work(&data->work); /* 将实际工作推迟到工作队列 */
    }
    
    return IRQ_HANDLED;
}

/* 工作队列处理函数，不在原子上下文中 */
static void sensor_work_handler(struct work_struct *work)
{
    struct sensor_data *data = container_of(work, struct sensor_data, work);
    struct i2c_msg msg;
    u8 reg = SENSOR_DATA_REG;
    
    /* 此时可以安全调用i2c_transfer */
    msg.addr = data->client->addr;
    msg.flags = 0;
    msg.len = 1;
    msg.buf = &reg;
    
    /* i2c_transfer内部会使用i2c_lock_bus，可能睡眠 */
    i2c_transfer(data->client->adapter, &msg, 1);
}

2.2 irqs_disabled()：中断状态的考量

irqs_disabled()检查当前CPU的中断是否被禁用。当中断被禁用时，同样不能进行可能导致睡眠的操作，因为：

调度依赖中断：进程调度通常由定时器中断触发，如果中断被禁用，调度器可能无法正常运行。
死锁风险：某些锁的实现（如信号量）在获取失败时可能睡眠并等待中断唤醒，如果中断被禁用，这种等待可能永远无法结束。

在驱动代码中，你可能会看到这样的模式：

static void critical_section_with_i2c(struct i2c_client *client)
{
    unsigned long flags;
    struct i2c_msg msg;
    u8 buffer[32];
    
    /* 关闭本地中断，保护与中断处理程序共享的数据 */
    local_irq_save(flags);
    
    /* 此时irqs_disabled()返回true */
    
    /* 准备I2C消息 */
    msg.addr = client->addr;
    msg.flags = I2C_M_RD;
    msg.len = sizeof(buffer);
    msg.buf = buffer;
    
    /* 尝试获取I2C总线锁 */
    if (i2c_trylock_bus(client->adapter, I2C_LOCK_SEGMENT)) {
        /* 成功获取锁，执行传输 */
        __i2c_transfer(client->adapter, &msg, 1);
        i2c_unlock_bus(client->adapter, I2C_LOCK_SEGMENT);
    } else {
        /* 获取锁失败，需要采取其他策略 */
        printk(KERN_WARNING "Failed to acquire I2C bus lock in critical section\n");
    }
    
    /* 恢复中断状态 */
    local_irq_restore(flags);
}