做嵌入式Linux开发的朋友肯定绕不开I2C这个总线。不管你是接了个温度传感器、触摸屏、音频Codec还是EEPROM存储芯片I2C都是最常见的外设通信方式之一。做Linux嵌入式驱动开发I2C驱动这块属于入门必修课它既不像GPIO那么单薄又不像USB/PCIe那样复杂到让人头皮发麻是个很适合用来理解内核设备模型、总线驱动框架、设备树机制的切入点。这篇内容我打算从一个实际开发者的角度把从底层协议到内核框架、从设备树配置到数据读写、从调试手段到抗坑经验的完整链路捋一遍。适合刚接触Linux驱动的同学也适合那些写过几个驱动但还没系统梳理过I2C子系统的朋友。注意这里的“I2C驱动开发”不是指像单片机裸机那样直接操作寄存器地址去翻转SCL/SDA那是协议层的底层实现。在Linux内核里大部分情况下你根本不需要关心硬件时序是怎么产生的内核的I2C核心层已经帮你把控制器的适配层做好了。你要做的核心事情是写一个“设备驱动”来告诉内核这个I2C从设备挂在哪个总线上、地址多少、如何通信、如何与上层交互。理解清楚这个分工后面所有的代码结构就都好理解了。1. I2C协议与Linux I2C子系统架构1.1 I2C总线上的一次完整通信聊驱动之前先花点篇幅把I2C物理层的通信模型说清楚因为你写代码时的很多参数、回调、标志位其实都是从这层模型衍生出来的。I2C是主从结构的双线总线一条SCL时钟线、一条SDA数据线。所有通信由主设备发起从设备被动响应。平时两条线都被上拉电阻拉到高电平一旦主设备想要发起传输先将SDA从高拉低同时SCL保持高电平这个状态叫起始条件。所有从设备看到起始条件后开始监听地址主设备随后发送7位或者10位从设备地址地址的最后一位是读写方向位0表示接下来主设备要写1表示要读。地址匹配的从设备会在第9个时钟周期把SDA拉低回一个ACK应答没匹配上的设备保持释放状态主设备读到NACK就知道总线上没有这个设备。数据传输完毕后主设备在SCL高电平期间把SDA拉高产生停止条件一次完整的通信就结束了。这套机制中有几个细节直接决定了驱动代码怎么写。比如7位地址规则看起来很简单但很多新手第一次用i2cdetect扫设备时会困惑芯片手册写设备地址是0xA0结果扫描出来却是0x50因为手册往往直接写的是“8位地址”也就是包含了读写标志位的完整字节而I2C子系统里i2c_client的addr字段用的是7位地址也就是把0xA0右移一位变成0x50。还有一块芯片对应多个物理地址的情况通常是把地址引脚的接法决定低位的A2/A1/A0驱动里要根据硬件实际接线写对地址。再有就是速度等级标准模式100kbps、快速模式400kbps、高速模式3.4Mbps。设备树里的clock-frequency配置直接影响控制器生成的SCL频率配太快而硬件走线抗不住就会出现数据字节位移、偶尔读到0xFF这类玄学问题。1.2 Linux内核的I2C三层结构内核的I2C子系统不是铁板一块而是分了三层适配器层、核心层和设备驱动层。这三层各自扮演不同角色理解透了你才会明白自己写的代码到底属于哪一层。适配器层也就是adapter对应硬件上的I2C控制器。每个I2C控制器都有自己不同的寄存器布局和时序控制方式比如某ARM平台自带两个I2C控制器另外一个平台可能通过GPIO模拟出I2C时序。这两者的寄存器操作完全不一样所以内核为每种控制器适配器写了一个独立的驱动比如i2c-xxx某个平台控制器的驱动、i2c-gpio注册成platform_driver。控制器驱动做的事情是向I2C核心层注册一个struct i2c_adapter绑定一个叫algorithm的结构体里面放了master_xfer函数指针指向这个控制器具体怎么发时序的实现。也就是说控制器驱动负责把“你要传输的数据”翻译成“SCL/SDA线上实际的电平跳变”。核心层也就是drivers/i2c/目录下的核心代码负责把设备端、适配器端、用户态访问等好几种模块串起来。它维护一张adapter列表每个adapter下面挂着一堆i2c_client每个client就代表一个逻辑上的从设备负责设备驱动的匹配、注册、卸载以及最常用的i2c_transfer接口的调度。值得强调的是你在设备驱动里调用的i2c_transfer最终会走到对应adapter的master_xfer所以你的设备驱动不需要关心总线到底是用硬件控制器还是GPIO软模拟的。上面这两层绝大多数写板级驱动和应用驱动的开发者碰不到。设备驱动层才是我们日常写的代码。你要做的是声明一个struct i2c_driver把自己的probe、remove、id_table、of_match_table填好然后注册到I2C核心层。核心层会根据设备树或者ACPI表找到和这个driver匹配的client调用你的probe函数。等probe被调用时你拿到的是一个已经确认“确实存在”的设备接下来在probe里做初始化、创建子设备节点、注册中断、提供读写接口被调用的时机非常清晰。这种分层设计内核官方文档里叫“将控制器和客户端分离”好处是显而易见的同一个温度传感器芯片放在一个带硬件I2C控制器的平台上跑没问题换到另一个GPIO模拟I2C的平台上设备驱动代码一行都不用改因为适配器层和核心层已经把差异都消化掉了。2. 开工前必做的环境确认与内核配置2.1 硬件侧的确定工作我见过不少开发者的习惯是上来就写代码代码写完烧进去i2cdetect啥也扫不到然后开始怀疑人生。其实I2C开发的第一步不在编辑器里而是在原理图和芯片手册上。第一件事确认你的I2C控制器在板卡上的引脚分配。很多SoC的同一个I2C控制器可以映射到不同的物理引脚比如I2C1既能放到GPIO_A组又能放到GPIO_B组。设备树里的pinctrl配置要是写错了驱动日志里会报引脚冲突或者总线注册失败。第二件事确认电源和上拉电阻。I2C总线的SDA和SCL必须要有上拉电阻一般接3.3V或1.8V阻值根据总线电容和速率在2.2k到4.7k之间选。如果某些EEPROM模块上已经自带上拉你板子上又加了一组总线的等效上拉就会过强表现为设备可以识别但偶尔通信出错。第三件事确认从设备的7位地址引脚接法很多传感器芯片有A0/A1地址选择引脚高电平还是低电平直接决定最终的设备地址。第四件事最好把SCL/SDA引出来接到逻辑分析仪上I2C只有两根线波形非常清晰凡是“偶尔能读到一次假数据”“时好时坏”这种问题示波器一看波形就明白了。提示开发初期尽量先用IO模拟I2C的方案验证芯片通信时序等稳定了再切到硬件控制器。这在排查“到底是芯片问题还是控制器配置问题”时能省下大把时间。2.2 内核相关配置项梳理I2C子系统在内核编译时有一些核心开关虽然大部分默认开启但裁剪过内核的嵌入式项目经常在这里栽跟头。配置项里最关键的有CONFIG_I2C这是I2C核心层的总开关不选它整个I2C子系统都是空的。CONFIG_I2C_CHARDEV这个对应/dev/i2c-N设备节点是用户态调试工具i2c-tools的依赖强烈建议开发阶段选上。CONFIG_I2C_GPIO这是用GPIO软模拟I2C控制器的驱动当你的SoC硬件I2C控制器引脚冲突、引脚复用有问题或者暂时想绕过硬件控制器排查问题时这个可以临时救命。CONFIG_I2C_XXX对应你平台自带的控制器驱动不同平台不一样一般名字里带i2c字样在菜单Device Drivers - I2C support - I2C Hardware Bus support里面。最后是CONFIG_OF这个一般跟设备树绑定基本所有现代嵌入式Linux平台都会开启它决定了系统能不能从设备树解析出I2C子节点。另外一个容易被忽略的配置是CONFIG_I2C_SLAVE默认不选但如果你开发的板卡本身需要作为从设备被别的CPU访问就要自己选上。还经常有人问需要不需要开CONFIG_I2C_SMBUS这个主要是SMBus协议支持绝大多数I2C设备驱动都要用到SMBus接口函数建议开启。2.3 设备树里I2C节点的标准写法设备树描述I2C地址和总线拓扑的方式属于每个做嵌入式Linux开发的人必须熟练掌握的基本功。内核从设备树解析I2C外设时走的是“控制器节点子节点”的两级结构。控制器节点一般由SoC厂商的设备树文件定义好你可以查看它是否使能如果需要使用就设置status okay。子节点则是你自己的设备要描述清楚compatible、reg地址、还有供电、中断、复位引脚等在具体驱动中要用到的属性。一个典型的写法在设备树里是这样的i2c1 { status okay; clock-frequency 400000; pinctrl-names default; pinctrl-0 pinctrl_i2c1; temp_sensor48 { compatible example,tmp-sensor; reg 0x48; vdd-supply reg_3v3; interrupt-parent gpio1; interrupts 17 IRQ_TYPE_LEVEL_LOW; }; };这里reg的值必须和芯片的地址选择跳线实际设置匹配比如芯片地址支持0x48到0x4F你的A2/A1/A0都接地那reg就填0x48。compatible里通常会有厂商前缀和型号名这要和驱动里的of_match_table完全一致包括大小写和标点。clock-frequency设成400000后和下行速率相关的问题也要特别注意很多开发板整个I2C总线上同时挂了Codec、传感器、触摸屏其中某个设备就只能在100k模式工作此时全部设备只能都降速到100k不然总线冲突和NACK就来了。有一些平台会有“i2c-mux”这种结构也就是一条控制器总线通过多路选择器分出多条子总线这种结构在服务器板卡上挺常见。设备树写法会多一层比如在控制器节点下面加一个i2c-mux节点里面再挂i2c0、i2c1等子总线节点。出现这种复杂结构时驱动开发也要跟着调整因为你在某个mux子总线上的设备根本不会出现在i2cdetect -l的主总线列表里需要先把mux驱动加载起来子总线才会注册。3. 核心实现I2C设备驱动开发的完整流程3.1 i2c_driver结构体与匹配机制设备驱动层代码的结构其实高度模板化。内核的I2C子系统通过i2c_bus_type类型维护总线上所有设备。每当设备树添加了一个I2C子节点内核会把它解析成一个i2c_client每当一个I2C驱动注册进来核心层就去遍历当前总线上的所有client看看有没有匹配的。匹配条件有三条一是设备树里的compatible和驱动of_match_table里的compatible字符串一致二是i2c_device_id表里有匹配的name三是传统方式通过driver的id_table和client的name字段一致。实际开发中90%的匹配都是通过compatible完成的因为它直观简单而且不需要维护额外表格。驱动结构体的各项字段含义再展开一下因为很多新手分不清id_table和of_match_table的作用。看下面这个标准模板#include linux/module.h #include linux/i2c.h #include linux/of_device.h #define XXX_DRV_NAME tmp-sensor static int tmp_probe(struct i2c_client *client, const struct i2c_device_id *id) { /* 设备初始化逻辑 */ return 0; } static void tmp_remove(struct i2c_client *client) { /* 清理逻辑 */ } // 传统非设备树方式的匹配表 static const struct i2c_device_id tmp_ids[] { { tmp-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(i2c, tmp_ids); // 设备树方式匹配表 static const struct of_device_id tmp_of_match[] { { .compatible example,tmp-sensor }, { } }; MODULE_DEVICE_TABLE(of, tmp_of_match); static struct i2c_driver tmp_driver { .driver { .name XXX_DRV_NAME, .of_match_table tmp_of_match, }, .probe tmp_probe, .remove tmp_remove, .id_table tmp_ids, }; module_i2c_driver(tmp_driver); MODULE_LICENSE(GPL);这段代码里最有意思的是module_i2c_driver这个宏它帮我们省掉了module_init/module_exit的模板代码自动把i2c_add_driver和i2c_del_driver封装好。用这个宏时文件编译成模块就可以insmod编进内核也会在系统启动时自动初始化。匹配机制里还有一个坑设备树节点里指定了compatible但真正的匹配键不一定是“名字完全一样”内核有时候会做一些兼容性别名匹配。比如你的驱动compatible写的是example,tmp-sensor-v2而设备树里写的是example,tmp-sensor-v1驱动注册时不会自动匹配。需要的是在of_match_table里把v1也列成一个条目或者设备树用内核推荐的方式加上“fallback compatible”。很多原厂SDK在移植时为了同时支持多个板卡版本会把兼容字符串弄得比较复杂自己写驱动时就要严格对应。3.2 probe函数里你需要做什么probe函数是整个驱动逻辑的入口也是代码最容易写得杂乱的地方。I2C设备驱动里probe要做的事情主要可以归成几类。第一类是获取资源。通过client来获取电源、中断、复位引脚等比如用devm_regulator_get获取vdd-supply指定的供电用device_get_named_gpio获取复位GPIO用irq_of_parse_and_map获取中断号。所有使用devm_前缀的API都不用手动释放内核的devres机制会在设备移除时自动回收你可以省去大量错误处理路径里的kfree、gpio_free之类的代码。第二类是初始化设备。这里通常要对芯片进行一次读操作确认芯片存在比如读一个厂商ID或者设备ID寄存器读出来不对就直接返回-ENODEV。这一步很有必要它可以让无法匹配到真实芯片的设备不继续占用资源。第三类是创建接口。你可以创建procfs节点、sysfs属性、字符设备节点、输入子系统设备或者注册一个内核其他子系统的接口比如注册hwmon设备。具体怎么做取决于你的芯片形态。第四类是注册中断如果是中断驱动的芯片注册工作队列或threaded irq保证后续数据能异步上报。probe里最需要克制的是不要在probe中加入阻塞操作。I2C传输本身是休眠等待的如果你的probe里连续做几十次I2C读写每次几百微秒到几毫秒就会导致整个系统的启动阶段卡顿一旦等待的设备初始化应答慢还可能引发看门狗复位。我习惯的做法是把耗时的初始化拆成两步probe函数里只做必需的ID校验和最小配置真正繁琐的完整配置放到一个workqueue里延后执行。3.3 一个真实驱动程序框架的拆解下面用一个I2C温度传感器为例把整个驱动的骨架串起来。这个示例不绑定任何具体芯片但结构完整可以直接改改compatible和寄存器操作后用在你的板子上。假设芯片有一个16位的温度寄存器地址为0x00读取条件是先写寄存器地址再读两个字配置寄存器地址为0x01需要写入0x80才能启动连续转换#include linux/i2c.h #include linux/slab.h #include linux/delay.h #include linux/sysfs.h #include linux/device.h struct tmp_data { struct i2c_client *client; struct mutex lock; }; static int tmp_read_reg16(struct i2c_client *client, u8 reg, u16 *val) { struct i2c_msg msgs[2]; u8 reg_buf[1] { reg }; u8 data[2] { 0 }; int ret; // 第一段写寄存器地址 msgs[0].addr client-addr; msgs[0].flags 0; msgs[0].len 1; msgs[0].buf reg_buf; // 第二段读两个字节数据 msgs[1].addr client-addr; msgs[1].flags I2C_M_RD; msgs[1].len 2; msgs[1].buf data; ret i2c_transfer(client-adapter, msgs, 2); if (ret ! 2) { dev_err(client-dev, read reg 0x%02x failed: %d\n, reg, ret); return ret 0 ? ret : -EIO; } *val ((u16)data[0] 8) | data[1]; return 0; } static ssize_t temp_show(struct device *dev, struct device_attribute *attr, char *buf) { struct tmp_data *priv dev_get_drvdata(dev); u16 raw; int temp; int ret; mutex_lock(priv-lock); ret tmp_read_reg16(priv-client, 0x00, raw); mutex_unlock(priv-lock); if (ret 0) return ret; // 假设是12位温度分辨率满量程0xFFF对应4096测量范围-40~125 temp (s16)(raw 4) 4; return sprintf(buf, %d.%d\n, temp / 100, (temp 0 ? -temp : temp) % 10); } static DEVICE_ATTR_RO(temp); static const struct attribute *tmp_attrs[] { dev_attr_temp.attr, NULL, }; static const struct attribute_group tmp_group { .attrs (struct attribute **)tmp_attrs, }; static int tmp_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct tmp_data *priv; u16 chip_id 0; int ret; // 第一步读芯片ID校验 ret tmp_read_reg16(client, 0xFE, chip_id); if (ret 0) { dev_err(client-dev, failed to read chip id\n); return -ENODEV; } if (chip_id ! 0x1234) { dev_err(client-dev, unexpected chip id: 0x%04x\n, chip_id); return -ENODEV; } priv devm_kzalloc(client-dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; priv-client client; mutex_init(priv-lock); dev_set_drvdata(client-dev, priv); // 第二步初始化芯片把配置寄存器写一下开启转换 ret i2c_smbus_write_byte_data(client, 0x01, 0x80); if (ret 0) { dev_err(client-dev, failed to configure chip\n); return ret; } // 第三步注册sysfs属性用户态直接cat /sys/.../temp查看 ret sysfs_create_group(client-dev.kobj, tmp_group); if (ret 0) return ret; dev_info(client-dev, temperature sensor initialized\n); return 0; } static void tmp_remove(struct i2c_client *client) { sysfs_remove_group(client-dev.kobj, tmp_group); } static const struct i2c_device_id tmp_ids[] { { tmp-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(i2c, tmp_ids); static const struct of_device_id tmp_of_match[] { { .compatible example,tmp-sensor }, { } }; MODULE_DEVICE_TABLE(of, tmp_of_match); static struct i2c_driver tmp_driver { .driver { .name tmp_sensor, .of_match_table tmp_of_match, }, .probe tmp_probe, .remove tmp_remove, .id_table tmp_ids, }; module_i2c_driver(tmp_driver); MODULE_LICENSE(GPL);这段代码里比较关键的是那个读16位寄存器的函数它用了i2c_transfer配合两个i2c_msg。为什么不用i2c_smbus_read_word_dataSMBus和I2C在协议层有个重要区别SMBus的读word操作规定从设备自动递增地址而I2C的读操作则是先写寄存器地址再发起读取。很多I2C芯片并不保证这种PEC和自动递增行为符合SMBus规范所以最通用的办法就是显式构建两个msg先写地址再读数据。只要你掌握了这种“写地址读数据”的组合几乎所有的I2C传感器读操作都能通吃。还有一个细节要提一下probe里用devm_kzalloc分配私有数据用sysfs_create_group创建属性。如果你把驱动编译成模块modprobe加载后设备会凭空出现一个/sys/bus/i2c/devices/0-0048/temp节点这个过程非常直观非常适合新手用来理解Linux设备模型是如何把驱动和设备绑到一起的。4. 数据传输细节与并发控制4.1 i2c_msg结构与i2c_transfer的原子性I2C数据传输的内核级接口最常用的是两个一个是i2c_smbus_xxx系列函数一个是i2c_transfer配合i2c_msg数组。前者适合简单的单字节读、多字节读、写命令操作使用起来非常方便对大多数EEPROM、传感器足够后者更底层、更自由可以组合出任意复杂的事务。关键要理解i2c_transfer一次传入多个msg时这多个msg在总线上构成一个不可分割的原子事务。比如你在一个i2c_msg里写命令字紧接着在另一个i2c_msg里从同一地址读数据那么在物理层上硬件控制器会连续执行起始条件 - 写地址读标志 - N个字节 - 重启条件 - 写地址读标志 - N个字节 - 停止条件。这点对很多芯片非常重要因为某些芯片在“写入寄存器地址后如果总线出现停止条件就会内部复位取消刚才的地址设置”。如果使用两次独立的i2c_transfer先写地址、再读数据两次传输之间总线上会出现一个停止/起始条件部分严格的芯片会因此失败这是个真真切切踩过很多次的坑。i2c_msg结构里还有一个不太起眼但很重要的字段是flags。读写方向靠I2C_M_RD标志控制发送时地址字节的低位会自动带上方向位。还有一些特殊标志比如I2C_M_IGNORE_NAK可以让控制器在收到NACK时不中止本次传输I2C_M_NO_RD_ACK用于一些从设备在data阶段不应答的场合I2C_M_RECV_LEN则用在SMBus的block read里。对于普通传感器驱动平时能用到的其实只有I2C_M_RD一个标志但理解这些标志能帮你以后阅读平台自带的控制器驱动代码时不那么费劲。4.2 并发访问保护与调用上下文约束如果你写的I2C驱动同时被多个进程打开或者同时有中断处理例程和用户态读取在调用读写函数你就必须考虑并发问题。I2C控制器每次只能执行一个master_xfer事务如果有两个线程同时调用i2c_transfer内核的I2C核心层会通过adapter内部的bus_lock锁来串行化这些请求但这里有两点你得重新自己想清楚。第一锁只保证了每次i2c_transfer调用本身不会被交错执行但并没有保证“你的多步操作”不会被其他请求打断。比如你正在执行“写配置寄存器A - 读状态寄存器B”的两步操作第一步完成后另一个线程先插进来读写别的寄存器然后你再做第二步这时这个两步操作就不是事务性的了。如果你的芯片要求这两步必须连续你需要在驱动自己的互斥锁里把它们保护起来。这就是上面示例代码里mutex_lock作用的场景永远不要在并发驱动里丢了这把锁。第二i2c_transfer是会休眠的函数因为需要等待硬件完成传输所以它不能在原子上下文里调用。这意味着你不能在spinlock保护的区域里调用i2c_transfer不能在普通的硬件中断处理函数里直接调用不能在没有睡眠安全的定时器回调里直接调用。正确的姿势是把数据传输放到threaded irq或者workqueue里。在实际项目中我看到过不少同事在中断里直接调用i2c_smbus_read结果那个IRQ是共享的一旦I2C控制器响应慢整个系统卡死。后来改成request_threaded_irq就稳定了在这里特别提醒一句I2C驱动的数据读取路径几乎永远都应该是进程上下文或者线程化中断上下文。4.3 控制传输频率与延时策略与I2C芯片交互时延时控制常常是“看起来能跑用一阵就出问题”的根源。不同芯片的转换时间、写周期、EEPROM的写page时间都不同需要给出恰当的延时。在驱动代码里延时可以用msleep、usleep_range甚至忙等待。原则是这样的如果延时在10ms以上用msleep它会让出CPU系统整体功耗表现好如果延时在10微秒到几毫秒之间用usleep_range它允许调度器适当提前或推迟一点唤醒实测更稳如果延时在微秒级别甚至更短可以考虑udelay。但要注意udelay是忙等的它不会休眠所以在延时期间虽然不会导致上下文切换的问题却会浪费CPU。I2C时序本来就比较慢这种忙等很少会成为性能瓶颈。一个比较经典的坑是msleep的最小精度有些内核配置下HZ是100此时msleep的最小实际粒度是10ms如果你只睡了1ms实际可能睡了10ms某些需要快速连续操作的场景就显得慢。但反过来说如果你以为它睡10ms结果它睡1ms设备初始化时序就崩了这种问题要靠查看平台实际HZ来定不能想当然。5. 调试工具与常见问题排查5.1 高效利用i2c-tools用户态工具对于I2C驱动的调试最有价值的“武器”反而不在内核源码里而是用户态的i2c-tools。它的作用在于让你不必先编译一个完整的内核模块就能先验证芯片功能、时序、地址是否都正确。这套工具包括i2cdetect、i2cget、i2cset、i2cdump、i2ctransfer各自干不同的事。i2cdetect -l先看系统里有哪些I2C总线每一条总线对应一个adapter数字和/dev/i2c-N对应。i2cdetect -y 总线号扫描这条总线上所有7位地址。第一次测新板子时不要加-y参数因为工具会提示确认实际在量产测试脚本里-y是必需的但个人手动调试时宁可多按一下确认免得误操作破坏了某个就在总线上的关键设备状态。i2cdetect扫出来一个地址后用i2cdump -y 总线号 地址读一遍寄存器非常直观。i2cget/i2cset用来测试单个寄存器读写比如你想验证某个寄存器能不能写0x80直接i2cset -y 0 0x48 0x01 0x80然后i2cget读回来对比就知道硬件通路正不正常。当你要验证类似“先写地址再连读”的复杂时序时i2ctransfer就派上用场了。比如想验证某传感器读取命令的时序i2ctransfer -y 0 w10x48 0x00 r20x48这句话表示在总线0上对地址0x48的设备先写一个字节0x00然后连续读两个字节。这个操作和内核里i2c_transfer调用两个i2c_msg是完全等效的。我调试新板卡时习惯先把数据通路用i2ctransfer全部验证通过再回头写内核驱动能少烧很多次板子。提示在开发板上i2c-tools通常需要自己交叉编译apt-get install的是主机版不能直接用。下载源码交叉编译时记得指定CC为交叉编译工具链并配置好sysroot整个过程不算复杂但别照搬主机的./configure --prefix/usr否则装到板子上后动态链接库路径对不上。5.2 内核侧调试开关如果用户态工具能正常读写而内核驱动不行那就是驱动代码本身的问题了。内核的I2C子系统提供了动态调式接口位于/sys/kernel/debug/i2c。这里可以看到每个adapter的注册信息、client的地址与名称、以及最后一次传输的统计信息对定位“驱动匹配了没有”“传输是否发生”非常有用。内核打印日志之前记得检查内核启动命令行是否带了quiet或者loglevel参数。很多板卡的默认cmdline里都有quiet导致内核日志被过滤掉于是你完全看不到驱动在加载时的dev_info/dev_err输出。自己加printk或者dev_dbg的时候要注意dev_dbg只有在开启DEBUG宏或者动态debug时才打印建议调试阶段先用dev_info或者dev_err正式发布再调整。内核还支持通过/sys/kernel/debug/dynamic_debug/control即时打开某个文件里的所有调试输出如果没编译dynamic_debug功能最简单的临时办法是改代码里dev_dbg改成dev_info重新编译。虽然粗暴因为在嵌入式交叉编译环境下distro的dynamic_debug默认老是没开但这个办法确实是非常有效的在量产产品上调试时我经常这么干。5.3 常见问题速查与实践经验很多I2C驱动问题极具规律性把典型的现象、原因和解决办法列出来遇到问题能快速定位。我整理了一张速查表基本覆盖开发中最常见的场景。现象可能原因排查与解决i2cdetect扫不到设备地址地址写错、设备未供电、SDA/SCL接反万用表测电压确认上拉存在核对7位地址换算比如手册给的0xA0要对应0x50能扫到地址但probe不进入设备树compatible不匹配、设备树没重新编译、驱动没加载成功检查/sys/bus/i2c/drivers/下有没有目标driver检查设备树反编译后的字符串读寄存器返回全0xFF设备没应答、误用8位地址、时钟频率太高先用i2ctransfer直接读对比波形降低clock-frequency到100k再测数据偶尔错位读出来的值颠三倒四速率过快、总线电容过大、电源噪声降低速率、换更合适的上下拉电阻、示波器查看每个bit是否清晰NACK出现在中间字节芯片不支持连续读、寄存器地址需要重启条件检查i2c_msg是否用了组合传输不要拆成两次独立transfer总线卡死SDA一直被拉低从设备进入异常状态、总线缺少复位机制检查设备是否死机必要时用GPIO模拟脉冲复位该设备或重新上电总线insmod时报missing module依赖的内核module没加载比如I2C控制器驱动本身是模块查看dmesg加载顺序使用modprobe而不是insmod反复调用write后设备失效写周期保护不够、写次数限制加上写循环延时使用i2c_smbus_write_byte_data的返回值判断重试除了这张表还有几个我自己的经验总结。一是设备树中reg字段的写法。如果芯片手册或者模块标签上写的是“A0-A2全为1地址0b10101111”换算成7位就是0b1010111即0x57要很熟练地来回切换。二是碰到总线时间异常时不要只盯驱动也要看看同一总线上其他设备在做什么。尤其是有音频Codec、触摸屏这类持续通信的设备时它们可能会占用大量总线时间导致你的传感器读取被无限期延迟。三是GPIO模拟I2C这个思路在快速定位硬件问题时特别有用。直接把设备树的I2C控制器status改为disabled在设备树里添加i2c-gpio节点把总线模拟出来测试。若GPIO模拟能通而硬件控制器不通问题九成在控制器引脚复用或者时钟配置上就可以从这两个方向继续深挖了。6. 把开发效率提上去的几点个人习惯内容写到这核心知识点基本都覆盖了。最后分享几个我在实际项目中验证过的工作习惯这些不属于某个具体函数但对开发效率和排错速度影响很大。我目前是“用户态先行、设备树居中、内核态殿后”的方式推进。拿到一个新的I2C芯片先不写一行内核代码用i2cdetect确认地址用i2ctransfer把芯片手册里的数据手册时序全部敲一遍确认每一寄存器读写都正常再动手填设备树。设备树写完加载内核驱动这时如果通信异常基本可以锁定是设备树描述或驱动匹配的问题而不是芯片本身行为异常。这样做的好处是让“芯片问题”和“驱动问题”彻底切开说白了就是把调试的变量控制到最小。在代码里我习惯在probe函数的第一行就加一条dev_info打印把client的地址和adapter的name打出来方便确认时机。很多次问题根源都能从这行日志里看出来地址和预期不符、adapter不对、probe重复被调用之类。类似地在remove函数里也要打印一句话这样当你的设备热插拔或模块卸载时可以立刻确认清理路径有没有执行不至于留下一个默默无闻的状态残留。关于锁的使用我早期犯过的错误是只在数据读取路径上加锁却在初始化路径里不加锁结果就是sysfs的read接口和probe里的初始化函数同时访问芯片程序跑着跑着就异常了。后来一律在probe里初始化mutex在任何对外暴露可访问的接口里强制拿锁宁可性能损失一点也不要留下竞态后患。最后再讲一个小技巧当驱动莫名其妙地“看起来在运行但数据不对”时使用内核的devicetree反编译功能检查一下实际生效的设备树而不是只看你写的dts源码。因为很多情况下make dtbs并没有把你的修改编译进去还有可能是多个dtb叠加或bootloader在启动时修改了某些节点。在板子的用户态执行dtc -I fs /proc/device-tree或者使用fdtdump直接看/dev/mem中实际加载的设备树可以看清当前生效的compatible和reg到底是多少避免对着错误的设备树调试半天。这个东西在量产阶段被不同的加载顺序坑过好多次值得养成习惯。