1. 为什么需要regmap从一次I2C传感器驱动的重复劳动说起做过Linux内核驱动的人大概都有过这种体验手里拿到一颗新的传感器挂在I2C总线上寄存器地址是8位数据宽度也是8位于是打开编辑器开始写i2c_transfer、拼struct i2c_msg、处理返回值、加锁、判断寄存器位宽……写完一算光寄存器读写就占了驱动代码的一半。过两天又拿到一颗类似的芯片挂在SPI上寄存器地址变成16位数据宽度变成32位于是又得把之前那套逻辑重写一遍只是把i2c_transfer换成spi_write把地址拼装方式改一改。这种重复劳动在Linux内核里存在了很多年。每一颗芯片的驱动都在自己实现一套寄存器访问逻辑代码风格各异出错概率高调试起来也麻烦。更头疼的是有些芯片同时支持I2C和SPI两种接口驱动作者不得不用#ifdef把两套总线访问代码都塞进去维护成本翻倍。regmap框架就是在这个背景下被引入内核的。它的核心思路非常朴素把“寄存器访问”这件事从具体的总线协议里抽象出来让驱动开发者只需要描述“我要读哪个寄存器、写什么值”至于底层是I2C、SPI还是MMIO交给regmap去处理。你可以把它理解成寄存器操作层面的“统一接口层”——上层驱动不关心总线差异下层总线通过regmap_bus对接进来中间由regmap核心完成地址拼装、数据格式化、缓存管理、锁保护等一系列脏活累活。这个框架从2011年前后进入主线内核到现在已经成为绝大多数新驱动的事实标准。如果你去看drivers/目录下近几年新增的传感器、PMIC、Codec、GPIO扩展芯片驱动几乎清一色使用regmap。对于正在学习Linux驱动开发的人来说掌握regmap不是“锦上添花”而是“必须跨过的一道门槛”。本文会从设计思路、核心数据结构、实操步骤、常见问题几个维度把regmap框架拆开讲透适合已经写过简单字符设备驱动、想进一步深入内核子系统开发的读者。2. regmap整体设计思路与核心抽象层拆解2.1 分层设计把“总线差异”关进笼子里regmap的架构可以粗略分成三层。最上层是驱动API层也就是你在驱动代码里直接调用的regmap_read、regmap_write、regmap_update_bits这些函数。中间是regmap核心层负责维护struct regmap实例、管理寄存器缓存、处理格式化逻辑、加锁等。最下层是总线适配层通过struct regmap_bus把I2C、SPI、MMIO等具体总线操作封装起来。这种分层带来的直接好处是驱动开发者只需要跟最上层打交道写出来的代码跟总线无关。同一份驱动逻辑只要换一个regmap_config和对应的总线初始化函数就能从I2C迁移到SPI甚至迁移到MMIO。我在实际项目中遇到过一颗PMIC芯片前期调试用I2C后期量产切换到SPI接口因为驱动用的是regmap整个迁移过程只改了三处总线初始化、regmap_config里的read_flag_mask、以及设备树节点驱动核心逻辑一行没动。2.2 核心数据结构regmap_config是灵魂理解regmap最关键的是理解struct regmap_config。这个结构体描述了“这颗芯片的寄存器长什么样”包括寄存器地址位宽、数据位宽、是否有缓存、缓存的类型、读写标志位、最大寄存器地址等。下面这张表列出了最常用的几个字段及其含义字段名含义常见取值reg_bits寄存器地址位宽8、16、32val_bits寄存器数据位宽8、16、32max_register最大有效寄存器地址根据芯片手册填写cache_type缓存类型REGCACHE_NONE、REGCACHE_RBTREE、REGCACHE_FLATvolatile_reg回调函数判断寄存器是否易变返回true表示不缓存readable_reg回调函数判断寄存器是否可读用于权限检查writeable_reg回调函数判断寄存器是否可写用于权限检查read_flag_mask读操作时地址上或的标志位如0x80write_flag_mask写操作时地址上或的标志位如0x00reg_bits和val_bits这两个字段看起来简单但实际配置时很容易搞错。有些芯片手册里写“寄存器地址16位”但实际传输时高8位是页地址低8位是寄存器偏移这种情况就需要用regmap_bus的自定义读写函数来处理不能简单靠reg_bits16解决。我在调试一颗音频Codec时就踩过这个坑手册上写寄存器地址是16位我直接配了reg_bits16结果读写全乱后来发现芯片实际用的是“页偏移”的寻址方式需要自定义regmap_bus。2.3 缓存机制为什么需要它什么时候不该用regmap的缓存机制是一个容易被忽视但非常重要的特性。对于有大量寄存器的芯片比如PMIC、Codec如果每次读寄存器都走总线效率很低。regmap提供了三种缓存类型REGCACHE_NONE表示不缓存REGCACHE_FLAT用数组做平坦缓存REGCACHE_RBTREE用红黑树做稀疏缓存。选择哪种缓存类型取决于寄存器的分布特征。如果寄存器地址连续且数量不多比如0x00到0x3F用REGCACHE_FLAT最合适访问速度快内存占用也可控。如果寄存器地址稀疏分布比如0x00、0x100、0x2000用REGCACHE_RBTREE更节省内存。但要注意缓存不是万能的对于状态寄存器、中断标志寄存器这类“读一次就变”的寄存器必须通过volatile_reg回调标记为易变否则读到的是缓存里的旧值会导致驱动逻辑出错。提示volatile_reg回调返回true表示该寄存器不参与缓存每次读都走总线。对于中断状态寄存器、FIFO数据寄存器务必标记为易变。3. 从零搭建一个regmap驱动实操步骤与关键细节3.1 环境准备与最小驱动骨架假设我们要为一颗挂在I2C总线上的假想传感器写驱动芯片有8位寄存器地址、8位数据宽度寄存器范围0x00到0x7F。首先需要包含头文件#include linux/regmap.h #include linux/i2c.h #include linux/module.h然后定义regmap_configstatic const struct regmap_config sensor_regmap_config { .reg_bits 8, .val_bits 8, .max_register 0x7F, .cache_type REGCACHE_RBTREE, .volatile_reg sensor_volatile_reg, };volatile_reg回调的实现很关键它决定了哪些寄存器不缓存static bool sensor_volatile_reg(struct device *dev, unsigned int reg) { switch (reg) { case SENSOR_STATUS_REG: case SENSOR_FIFO_REG: return true; default: return false; } }接下来在probe函数里初始化regmapstatic int sensor_probe(struct i2c_client *client) { struct sensor_data *data; data devm_kzalloc(client-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; >static int my_bus_read(void *context, const void *reg, size_t reg_size, void *val, size_t val_size) { struct my_device *dev context; /* 自定义读取逻辑 */ return 0; } static int my_bus_write(void *context, const void *data, size_t count) { struct my_device *dev context; /* 自定义写入逻辑 */ return 0; } static const struct regmap_bus my_regmap_bus { .read my_bus_read, .write my_bus_write, };然后用devm_regmap_init初始化data-regmap devm_regmap_init(client-dev, my_regmap_bus, data, sensor_regmap_config);自定义regmap_bus的难点在于理解regmap核心层传给read/write回调的数据格式。write回调收到的data是“寄存器地址数据”拼接后的缓冲区count是总长度。read回调收到的reg是寄存器地址val是输出缓冲区。理解这一点后实现起来就不难了。4.2 多总线适配的实战经验我做过一个项目同一颗芯片有I2C和SPI两个版本驱动需要同时支持。使用regmap后代码结构变得非常清晰static int chip_probe(struct device *dev, struct regmap *regmap) { /* 所有芯片相关的初始化逻辑与总线无关 */ } static int chip_i2c_probe(struct i2c_client *client) { struct regmap *regmap; regmap devm_regmap_init_i2c(client, chip_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); return chip_probe(client-dev, regmap); } static int chip_spi_probe(struct spi_device *spi) { struct regmap *regmap; regmap devm_regmap_init_spi(spi, chip_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); return chip_probe(spi-dev, regmap); }这样chip_probe里的逻辑完全复用只需要为I2C和SPI分别注册i2c_driver和spi_driver。这种模式在内核里非常常见比如很多PMIC、Codec驱动都是这么写的。4.3 调试regmapdebugfs与tracepointregmap提供了debugfs接口可以查看寄存器缓存内容、读写统计等信息。挂载debugfs后在/sys/kernel/debug/regmap/目录下可以看到每个regmap实例的节点。读取registers文件可以dump出当前缓存的所有寄存器值读取access文件可以看到读写次数统计。这个功能在调试时非常有用。比如怀疑某个寄存器配置没生效可以先dump缓存确认写入的值是否正确如果缓存里的值是对的但硬件行为不对说明问题出在总线传输或硬件本身。另外内核还提供了regmap的tracepoint可以用ftrace跟踪每次寄存器读写适合分析时序问题。提示debugfs需要内核配置CONFIG_DEBUG_FSyregmap debugfs需要CONFIG_REGMAP_DEBUGFSy。5. 常见问题与排查技巧实录5.1 寄存器读写失败排查表现象可能原因排查方法读写返回-EIO总线通信失败用逻辑分析仪抓总线波形确认地址和数据读到的值全为0或全为0xFF地址位宽配置错误检查reg_bits和val_bits是否与手册一致写入后读回值不变寄存器被缓存检查volatile_reg回调是否正确标记regmap_update_bits无效寄存器不可写检查writeable_reg回调批量读数据错位芯片不支持地址递增改用单寄存器循环读取中断里读状态寄存器死机在中断上下文调用了会睡眠的API改用工作队列5.2 几个容易忽视的细节第一个细节是max_register的设置。这个值不仅影响缓存分配还影响regmap_read的边界检查。如果设置得比实际寄存器范围小访问高位寄存器会返回-EINVAL如果设置得太大会浪费内存。建议严格按照芯片手册的最大寄存器地址填写。第二个细节是read_flag_mask和write_flag_mask。有些SPI芯片的读操作需要在地址最高位或上0x80写操作不需要。这个标志位如果配错表现为读写完全无响应。我调试SPI Flash时就遇到过读ID一直返回0xFF后来发现是read_flag_mask没设对。第三个细节是regmap的锁粒度。regmap内部有一把锁保护寄存器的读写和缓存操作但这把锁是per-regmap实例的。如果驱动里有多个regmap实例比如一颗芯片有多个bank它们之间的操作不是原子的需要驱动自己加锁保护跨bank的原子操作。5.3 性能优化建议对于高频读写的场景regmap的缓存机制可以显著减少总线访问次数。但缓存也带来了一致性问题如果硬件自己修改了某个寄存器的值比如状态寄存器缓存里的值就过时了。所以volatile_reg的标记必须准确。另外regmap_bulk_read比循环调用regmap_read效率高得多因为前者只需要一次总线事务如果芯片支持后者需要N次。对于FIFO读取这种场景务必使用批量API。如果regmap的默认锁策略成为瓶颈比如在实时性要求高的场景可以考虑使用regmap_init的fast_io选项或者用regmap_read的无锁版本需要自己保证并发安全。不过大多数场景下默认锁策略已经足够。6. 从regmap看内核子系统设计哲学regmap框架之所以能成为内核里最成功的子系统之一核心在于它抓住了“寄存器访问”这个共性需求用一层薄薄的抽象把总线差异隔离掉。这种设计思路在内核里反复出现gpiod框架把GPIO操作抽象出来clk框架把时钟操作抽象出来regulator框架把电源管理抽象出来。它们的共同点是把硬件差异关进配置结构体把通用逻辑提取到核心层。对于驱动开发者来说学习regmap不仅仅是学一套API更是理解内核“分层抽象”的设计思维。当你能熟练使用regmap后再去看gpiod、clk、regulator这些框架会发现它们的套路是相通的定义一个描述硬件特征的配置结构体实现一组标准回调然后调用核心层提供的初始化函数。掌握这个模式后上手任何新的内核子系统都会快很多。我在实际项目中最大的体会是不要急着写代码先把芯片手册里的寄存器映射表整理清楚把regmap_config的每个字段都确认一遍把volatile_reg、readable_reg、writeable_reg这三个回调的逻辑想明白。这三步做扎实了后面的驱动逻辑就是水到渠成的事。反过来如果配置阶段偷懒后面调试时就会在各种“莫名其妙”的问题上浪费时间。regmap的debugfs和tracepoint是调试利器遇到问题时先dump缓存、再看总线波形大部分问题都能快速定位。
Linux regmap框架详解：从I2C/SPI驱动重复劳动到统一寄存器访问抽象
1. 为什么需要regmap从一次I2C传感器驱动的重复劳动说起做过Linux内核驱动的人大概都有过这种体验手里拿到一颗新的传感器挂在I2C总线上寄存器地址是8位数据宽度也是8位于是打开编辑器开始写i2c_transfer、拼struct i2c_msg、处理返回值、加锁、判断寄存器位宽……写完一算光寄存器读写就占了驱动代码的一半。过两天又拿到一颗类似的芯片挂在SPI上寄存器地址变成16位数据宽度变成32位于是又得把之前那套逻辑重写一遍只是把i2c_transfer换成spi_write把地址拼装方式改一改。这种重复劳动在Linux内核里存在了很多年。每一颗芯片的驱动都在自己实现一套寄存器访问逻辑代码风格各异出错概率高调试起来也麻烦。更头疼的是有些芯片同时支持I2C和SPI两种接口驱动作者不得不用#ifdef把两套总线访问代码都塞进去维护成本翻倍。regmap框架就是在这个背景下被引入内核的。它的核心思路非常朴素把“寄存器访问”这件事从具体的总线协议里抽象出来让驱动开发者只需要描述“我要读哪个寄存器、写什么值”至于底层是I2C、SPI还是MMIO交给regmap去处理。你可以把它理解成寄存器操作层面的“统一接口层”——上层驱动不关心总线差异下层总线通过regmap_bus对接进来中间由regmap核心完成地址拼装、数据格式化、缓存管理、锁保护等一系列脏活累活。这个框架从2011年前后进入主线内核到现在已经成为绝大多数新驱动的事实标准。如果你去看drivers/目录下近几年新增的传感器、PMIC、Codec、GPIO扩展芯片驱动几乎清一色使用regmap。对于正在学习Linux驱动开发的人来说掌握regmap不是“锦上添花”而是“必须跨过的一道门槛”。本文会从设计思路、核心数据结构、实操步骤、常见问题几个维度把regmap框架拆开讲透适合已经写过简单字符设备驱动、想进一步深入内核子系统开发的读者。2. regmap整体设计思路与核心抽象层拆解2.1 分层设计把“总线差异”关进笼子里regmap的架构可以粗略分成三层。最上层是驱动API层也就是你在驱动代码里直接调用的regmap_read、regmap_write、regmap_update_bits这些函数。中间是regmap核心层负责维护struct regmap实例、管理寄存器缓存、处理格式化逻辑、加锁等。最下层是总线适配层通过struct regmap_bus把I2C、SPI、MMIO等具体总线操作封装起来。这种分层带来的直接好处是驱动开发者只需要跟最上层打交道写出来的代码跟总线无关。同一份驱动逻辑只要换一个regmap_config和对应的总线初始化函数就能从I2C迁移到SPI甚至迁移到MMIO。我在实际项目中遇到过一颗PMIC芯片前期调试用I2C后期量产切换到SPI接口因为驱动用的是regmap整个迁移过程只改了三处总线初始化、regmap_config里的read_flag_mask、以及设备树节点驱动核心逻辑一行没动。2.2 核心数据结构regmap_config是灵魂理解regmap最关键的是理解struct regmap_config。这个结构体描述了“这颗芯片的寄存器长什么样”包括寄存器地址位宽、数据位宽、是否有缓存、缓存的类型、读写标志位、最大寄存器地址等。下面这张表列出了最常用的几个字段及其含义字段名含义常见取值reg_bits寄存器地址位宽8、16、32val_bits寄存器数据位宽8、16、32max_register最大有效寄存器地址根据芯片手册填写cache_type缓存类型REGCACHE_NONE、REGCACHE_RBTREE、REGCACHE_FLATvolatile_reg回调函数判断寄存器是否易变返回true表示不缓存readable_reg回调函数判断寄存器是否可读用于权限检查writeable_reg回调函数判断寄存器是否可写用于权限检查read_flag_mask读操作时地址上或的标志位如0x80write_flag_mask写操作时地址上或的标志位如0x00reg_bits和val_bits这两个字段看起来简单但实际配置时很容易搞错。有些芯片手册里写“寄存器地址16位”但实际传输时高8位是页地址低8位是寄存器偏移这种情况就需要用regmap_bus的自定义读写函数来处理不能简单靠reg_bits16解决。我在调试一颗音频Codec时就踩过这个坑手册上写寄存器地址是16位我直接配了reg_bits16结果读写全乱后来发现芯片实际用的是“页偏移”的寻址方式需要自定义regmap_bus。2.3 缓存机制为什么需要它什么时候不该用regmap的缓存机制是一个容易被忽视但非常重要的特性。对于有大量寄存器的芯片比如PMIC、Codec如果每次读寄存器都走总线效率很低。regmap提供了三种缓存类型REGCACHE_NONE表示不缓存REGCACHE_FLAT用数组做平坦缓存REGCACHE_RBTREE用红黑树做稀疏缓存。选择哪种缓存类型取决于寄存器的分布特征。如果寄存器地址连续且数量不多比如0x00到0x3F用REGCACHE_FLAT最合适访问速度快内存占用也可控。如果寄存器地址稀疏分布比如0x00、0x100、0x2000用REGCACHE_RBTREE更节省内存。但要注意缓存不是万能的对于状态寄存器、中断标志寄存器这类“读一次就变”的寄存器必须通过volatile_reg回调标记为易变否则读到的是缓存里的旧值会导致驱动逻辑出错。提示volatile_reg回调返回true表示该寄存器不参与缓存每次读都走总线。对于中断状态寄存器、FIFO数据寄存器务必标记为易变。3. 从零搭建一个regmap驱动实操步骤与关键细节3.1 环境准备与最小驱动骨架假设我们要为一颗挂在I2C总线上的假想传感器写驱动芯片有8位寄存器地址、8位数据宽度寄存器范围0x00到0x7F。首先需要包含头文件#include linux/regmap.h #include linux/i2c.h #include linux/module.h然后定义regmap_configstatic const struct regmap_config sensor_regmap_config { .reg_bits 8, .val_bits 8, .max_register 0x7F, .cache_type REGCACHE_RBTREE, .volatile_reg sensor_volatile_reg, };volatile_reg回调的实现很关键它决定了哪些寄存器不缓存static bool sensor_volatile_reg(struct device *dev, unsigned int reg) { switch (reg) { case SENSOR_STATUS_REG: case SENSOR_FIFO_REG: return true; default: return false; } }接下来在probe函数里初始化regmapstatic int sensor_probe(struct i2c_client *client) { struct sensor_data *data; data devm_kzalloc(client-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; >static int my_bus_read(void *context, const void *reg, size_t reg_size, void *val, size_t val_size) { struct my_device *dev context; /* 自定义读取逻辑 */ return 0; } static int my_bus_write(void *context, const void *data, size_t count) { struct my_device *dev context; /* 自定义写入逻辑 */ return 0; } static const struct regmap_bus my_regmap_bus { .read my_bus_read, .write my_bus_write, };然后用devm_regmap_init初始化data-regmap devm_regmap_init(client-dev, my_regmap_bus, data, sensor_regmap_config);自定义regmap_bus的难点在于理解regmap核心层传给read/write回调的数据格式。write回调收到的data是“寄存器地址数据”拼接后的缓冲区count是总长度。read回调收到的reg是寄存器地址val是输出缓冲区。理解这一点后实现起来就不难了。4.2 多总线适配的实战经验我做过一个项目同一颗芯片有I2C和SPI两个版本驱动需要同时支持。使用regmap后代码结构变得非常清晰static int chip_probe(struct device *dev, struct regmap *regmap) { /* 所有芯片相关的初始化逻辑与总线无关 */ } static int chip_i2c_probe(struct i2c_client *client) { struct regmap *regmap; regmap devm_regmap_init_i2c(client, chip_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); return chip_probe(client-dev, regmap); } static int chip_spi_probe(struct spi_device *spi) { struct regmap *regmap; regmap devm_regmap_init_spi(spi, chip_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); return chip_probe(spi-dev, regmap); }这样chip_probe里的逻辑完全复用只需要为I2C和SPI分别注册i2c_driver和spi_driver。这种模式在内核里非常常见比如很多PMIC、Codec驱动都是这么写的。4.3 调试regmapdebugfs与tracepointregmap提供了debugfs接口可以查看寄存器缓存内容、读写统计等信息。挂载debugfs后在/sys/kernel/debug/regmap/目录下可以看到每个regmap实例的节点。读取registers文件可以dump出当前缓存的所有寄存器值读取access文件可以看到读写次数统计。这个功能在调试时非常有用。比如怀疑某个寄存器配置没生效可以先dump缓存确认写入的值是否正确如果缓存里的值是对的但硬件行为不对说明问题出在总线传输或硬件本身。另外内核还提供了regmap的tracepoint可以用ftrace跟踪每次寄存器读写适合分析时序问题。提示debugfs需要内核配置CONFIG_DEBUG_FSyregmap debugfs需要CONFIG_REGMAP_DEBUGFSy。5. 常见问题与排查技巧实录5.1 寄存器读写失败排查表现象可能原因排查方法读写返回-EIO总线通信失败用逻辑分析仪抓总线波形确认地址和数据读到的值全为0或全为0xFF地址位宽配置错误检查reg_bits和val_bits是否与手册一致写入后读回值不变寄存器被缓存检查volatile_reg回调是否正确标记regmap_update_bits无效寄存器不可写检查writeable_reg回调批量读数据错位芯片不支持地址递增改用单寄存器循环读取中断里读状态寄存器死机在中断上下文调用了会睡眠的API改用工作队列5.2 几个容易忽视的细节第一个细节是max_register的设置。这个值不仅影响缓存分配还影响regmap_read的边界检查。如果设置得比实际寄存器范围小访问高位寄存器会返回-EINVAL如果设置得太大会浪费内存。建议严格按照芯片手册的最大寄存器地址填写。第二个细节是read_flag_mask和write_flag_mask。有些SPI芯片的读操作需要在地址最高位或上0x80写操作不需要。这个标志位如果配错表现为读写完全无响应。我调试SPI Flash时就遇到过读ID一直返回0xFF后来发现是read_flag_mask没设对。第三个细节是regmap的锁粒度。regmap内部有一把锁保护寄存器的读写和缓存操作但这把锁是per-regmap实例的。如果驱动里有多个regmap实例比如一颗芯片有多个bank它们之间的操作不是原子的需要驱动自己加锁保护跨bank的原子操作。5.3 性能优化建议对于高频读写的场景regmap的缓存机制可以显著减少总线访问次数。但缓存也带来了一致性问题如果硬件自己修改了某个寄存器的值比如状态寄存器缓存里的值就过时了。所以volatile_reg的标记必须准确。另外regmap_bulk_read比循环调用regmap_read效率高得多因为前者只需要一次总线事务如果芯片支持后者需要N次。对于FIFO读取这种场景务必使用批量API。如果regmap的默认锁策略成为瓶颈比如在实时性要求高的场景可以考虑使用regmap_init的fast_io选项或者用regmap_read的无锁版本需要自己保证并发安全。不过大多数场景下默认锁策略已经足够。6. 从regmap看内核子系统设计哲学regmap框架之所以能成为内核里最成功的子系统之一核心在于它抓住了“寄存器访问”这个共性需求用一层薄薄的抽象把总线差异隔离掉。这种设计思路在内核里反复出现gpiod框架把GPIO操作抽象出来clk框架把时钟操作抽象出来regulator框架把电源管理抽象出来。它们的共同点是把硬件差异关进配置结构体把通用逻辑提取到核心层。对于驱动开发者来说学习regmap不仅仅是学一套API更是理解内核“分层抽象”的设计思维。当你能熟练使用regmap后再去看gpiod、clk、regulator这些框架会发现它们的套路是相通的定义一个描述硬件特征的配置结构体实现一组标准回调然后调用核心层提供的初始化函数。掌握这个模式后上手任何新的内核子系统都会快很多。我在实际项目中最大的体会是不要急着写代码先把芯片手册里的寄存器映射表整理清楚把regmap_config的每个字段都确认一遍把volatile_reg、readable_reg、writeable_reg这三个回调的逻辑想明白。这三步做扎实了后面的驱动逻辑就是水到渠成的事。反过来如果配置阶段偷懒后面调试时就会在各种“莫名其妙”的问题上浪费时间。regmap的debugfs和tracepoint是调试利器遇到问题时先dump缓存、再看总线波形大部分问题都能快速定位。