Android TP驱动开发实战：从I2C通信到input子系统全解析

1. 先搞明白 TP 驱动到底在做什么

很多做 Android 应用或者 Framework 开发的同事，可能一辈子都没碰过 TP 驱动，觉得它不过是“把坐标报上去”而已。可真到了项目里，触摸不灵、乱跳、休眠唤醒后没反应，最后背锅的往往就是驱动。我在嵌入式这一行做了不少年，经手的 TP 项目少说也有十几个，从早期的电阻屏到现在的电容触摸屏，从老掉牙的 I2C 接口到部分平台开始用的 SPI 接口，踩过的坑能写满一页纸。

先说清楚 TP 驱动在整个 Android 系统里的位置。一条触摸事件从手指按到屏幕上，到应用层收到坐标，中间其实要经过好几层：触摸屏硬件（触控 IC + sensor 走线）、内核驱动（I2C 读写 + 中断处理 + 上报）、HAL 层（EventHub 读取 /dev/input/eventX）、Framework 的 InputManagerService，最后才到应用。TP 驱动干的核心事情就两件：一是通过 I2C 或 SPI 从触控 IC 里把坐标数据读出来，二是通过 Linux 的 input 子系统把数据上报给上层。听起来简单，但中间每个环节都有讲究。

这篇文章主要面向三类人：刚接手 TP 驱动开发的初级工程师、需要排查触摸相关问题的系统工程师、以及想搞懂“点一下屏幕背后发生了什么”的应用开发同学。我会把驱动框架、硬件链路、报点协议、常见问题排查这些内容串起来讲，不会只贴源码，重点放在“为什么这么做”和“实际项目里怎么踩坑”。

刚入行那会儿，我拿到一个 TP 项目，第一反应就是找厂商要驱动源码，然后往内核里一放，编过就以为完事了。结果是触摸完全没反应，或者坐标是镜像的，折腾了一星期才发现是设备树配置错了。从那以后我养成了一个习惯：不管厂商给的驱动多完整，先把硬件原理图看清楚，把 I2C 地址、中断引脚、复位引脚、供电电压这些关键信息摸清楚，再动手改代码。这个习惯帮我省了无数次返工。

2. 硬件链路：I2C、中断引脚与电源时序

2.1 触控 IC 在 I2C 总线上的视角

绝大多数电容触控 IC 都是通过 I2C 和主控通信的。你去看原理图，触控 IC 一般会引出 SCL、SDA、INT（中断）、RST（复位）四根关键信号线，另外还有供电引脚和 GPIO 分别接 VCC 和 AVDD。

对主控来说，触控 IC 就是 I2C 总线上的一个从设备。在设备树里需要配置它的地址。比如某颗常见的触控 IC，I2C 地址是 0x38，那么设备树节点里就要写reg = <0x38>。这个地址怎么确定？看 IC 的 datasheet，通常会有一个或多个地址引脚，通过外部上拉下拉来选择 I2C 地址。实际项目里最常见的问题就是设备树里地址写错，导致 i2cdetect 扫不到设备。

先放下设备树，说说 I2C 读写本身。Linux 内核里 I2C 驱动有两种写法：一种是直接用i2c_transfer或者i2c_master_send/i2c_master_recv这些 API；另一种是使用 Regmap 框架。TP 厂商给的代码里，两种都有，早期很多用i2c_transfer，新一些的用 regmap。我自己更推荐用 regmap，因为 regmap 帮你把缓存、总线访问、lock 都管好了，在 PM 休眠时对 I2C 总线的处理也更统一。

读坐标数据的时候，大部分 IC 的寄存器设计是分组的。比如 0x00 到 0x0F 是状态和坐标寄存器，0x80 以后是配置寄存器。驱动要做的是：中断来了之后，先读状态寄存器确认有触摸事件，再读坐标寄存器拿到X、Y、pressure、touch id这些信息。

有个细节要注意，I2C 读数据时有些 IC 需要先写要读的寄存器地址，再重新发起读操作。这时候如果你用i2c_master_send和i2c_master_recv分两次调用，中间可能会被其他 I2C 设备插入访问，导致读到的数据错位。正确的做法是用i2c_transfer一次提交两个msg，第一个写寄存器地址，第二个读数据，保证原子性。厂商代码里有的没注意这个，发生 I2C 总线复用时就容易偶发读数异常。

2.2 为什么触摸一定要用中断而不是轮询

有些刚入门的朋友会问：既然 I2C 读数据那么简单，为什么不写个定时器每 10ms 轮询一次坐标？原因有两个：功耗和实时性。

手机是电池供电的设备，触控 IC 本身在没触摸时会进入低功耗模式，扫描频率也降下来了。如果用内核定时器不断唤醒 I2C 去读，整个系统根本没法休眠，而且 CPU 也被无谓地占用。用中断的方式，手指按下的瞬间触控 IC 会拉高或拉低 INT 引脚，内核在中断上下文里被唤醒，然后再去读数据。平时没有触摸时，CPU 可以该睡就睡，该忙别的就忙别的。

再者，轮询的延迟不好控制。触摸事件的实时性要求挺高，尤其是滑动、双击这种手势，如果轮询周期太长，upper 层看到的就是一顿一顿的轨迹。

项目里配置中断的时候有几个关键点。第一，设备树里要指定中断 GPIO 和触发方式，比如irq-gpios = <&pio 15 IRQ_TYPE_EDGE_FALLING>表示 GPIO15，下降沿触发。第二，中断触发方式必须和 IC 的行为匹配。有的 IC 在触摸发生时 INT 拉低，没有触摸时拉高，那就要用IRQ_TYPE_EDGE_FALLING；有的 IC 用 LEVEL 模式，触摸期间一直保持低电平。用错触发方式最典型的现象是中断风暴，系统日志里刷屏，功耗飙升。

2.3 上电时序的坑：少一个延时，一整天白干

我遇到过一件特别诡异的事：TP 驱动加载时，触摸偶尔不工作，但按一下电源键唤醒屏幕再锁屏，触摸就正常了。查了很久，最后定位到是上电时序问题。触控 IC 的 AVDD 电源起来之后，需要等电源稳定，再拉高复位引脚，复位结束之后还要延时一段时间才能开始 I2C 通信。这段延时有的 IC 要 10ms，有的要 50ms 甚至更久，datasheet 的 power-up sequence 部分会写。

厂商的驱动里一般会在 probe 函数里做这些事：先使能 regulator 或直接操作 GPIO 开电源，然后延时，再拉高复位引脚，再延时，然后才去读 IC 的 ID 寄存器做校验。如果你把这些顺序搞反了，或者延时被优化掉了（没错，有的同事觉得延时没用直接删了），IC 根本没准备好，I2C 读写自然全部失败。

我曾经做过一个平台，GPIO 复位引脚和另一颗芯片的引脚复用，上电默认状态被 bootloader 拉低了，导致 TP 的复位始终无效。这种问题看起来像 IC 死掉，实际是引脚复用配置错了。所以看原理图的时候，不仅要看 TP 自己那部分，还要注意 GPIO 是否被其他模块复用，特别是 pinctrl 的 default 状态配置。

3. 内核侧的关键框架：设备树与 input 子系统

3.1 设备树里怎么描述一块触摸屏

现在做 Android 内核驱动，基本离不开设备树了。设备树不仅仅是“描述硬件长什么样”，它还决定了驱动的加载顺序、资源分配和运行时配置。TP 驱动在设备树里通常长这样：

&i2c3 { status = "okay"; touchscreen@38 { compatible = "vendor,tsc2018"; reg = <0x38>; interrupt-parent = <&pio>; interrupts = <15 IRQ_TYPE_EDGE_FALLING>; irq-gpios = <&pio 15 0>; reset-gpios = <&pio 16 GPIO_ACTIVE_LOW>; avdd-supply = <&reg_ldo1>; vdd-supply = <&reg_ldo2>; touchscreen-max-x = <1080>; touchscreen-max-y = <2400>; }; };

这里有几个字段要特别注意。

compatible必须和驱动里的of_match_table匹配上，否则内核根本不会 probe 这个设备。reg是 I2C 从设备地址。interrupts和irq-gpios看起来重复，但前者是描述中断控制器视角的中断号，后者是给驱动直接操作 GPIO 用的，两者可以并存，但很多早期代码只会用其中一个，导致驱动里拿不到正确的 IRQ。我见到过一个情况：设备树里interrupts写的是IRQ_TYPE_LEVEL_LOW，但 GPIO 控制器本身对中断触发类型的解析和 IC 实际行为不匹配，结果中断一直触发，系统直接被中断风暴打挂。

avdd-supply和vdd-supply对应两颗电源 LDO。驱动里通过devm_regulator_get拿到 regulator，然后调用regulator_enable来供电。如果设备树里没配电源节点，驱动直接读寄存器就会失败，因为 IC 根本没上电。

touchscreen-max-x和touchscreen-max-y是分辨率信息，有的驱动会从这些参数里初始化 input device 的 ABS 范围。这里踩过的坑是坐标方向和分辨率不匹配：屏幕是竖屏，驱动里**报的坐标范围是横向的 2400x1080，结果触摸点全乱了。后来发现是厂商给的默认配置针对的是另一块屏，忘了改设备树参数。

3.2 input 子系统：驱动和上层之间的桥

Linux input 子系统是 TP 驱动上报数据的出口。它由三部分构成：input core、input device 驱动、event handler。TP 驱动属于 input device 驱动，它要做的事情就是创建一个input_dev，设置好能力位，然后往里上报事件。

在 probe 函数里，一般会看到这样一段：

struct input_dev *input_dev = input_allocate_device(); input_dev->name = "goodix-ts"; input_dev->id.bustype = BUS_I2C; __set_bit(EV_KEY, input_dev->evbit); __set_bit(EV_ABS, input_dev->evbit); __set_bit(BTN_TOUCH, input_dev->keybit); input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, max_x, 0, 0); input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, max_y, 0, 0); input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 255, 0, 0); input_set_abs_params(input_dev, ABS_MT_SLOT, 0, touch_num - 1, 0, 0); input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, touch_num - 1, 0, 0); input_set_drvdata(input_dev, ts); input_register_device(input_dev);

__set_bit(EV_KEY, input_dev->evbit)注册按键事件，__set_bit(EV_ABS, input_dev->evbit)注册绝对坐标事件。ABS_MT_POSITION_X/Y是触摸点的坐标轴，ABS_MT_TRACKING_ID是每个触摸点的唯一标识，ABS_MT_SLOT是当前触摸点对应的 slot 槽位。

新款内核还推荐用input_set_abs_params时设置ABS_MT_TOOL_TYPE来表示手指或笔，不过很多 TP 驱动不关心这个，默认只报坐标。

这里有个容易犯的错：忘记设置input_dev->dev.parent。内核文档里明确建议要设置input_dev->dev.parent = &client->dev，这样 input 设备的生命周期管理才能和 I2C 设备关联。如果忘了，在某些内核版本上可能没问题，但系统级调试 tool 会看不到这个 input 设备对应的 sysfs 路径，dumpsys input 的信息也不全。

3.3 报点协议：从 B 协议说起

Linux 内核为触摸屏定义了两种多点触控协议：Type A 和 Type B。Type A 是每个触点独立上报，比较古老，现在基本上没人用了；Type B 是 slot 制，用ABS_MT_SLOT指定槽位，再上报该槽位上的坐标。

Type B 协议的核心逻辑是这样的：

input_mt_slot(input_dev, slot_num); input_mt_report_slot_state(input_dev, ABS_MT_TOOL_TYPE, true); input_report_abs(input_dev, ABS_MT_POSITION_X, x); input_report_abs(input_dev, ABS_MT_POSITION_Y, y); input_report_abs(input_dev, ABS_MT_PRESSURE, pressure); input_sync(input_dev);

当一个触点抬起时，要执行：

input_mt_slot(input_dev, slot_num); input_mt_report_slot_state(input_dev, ABS_MT_TOOL_TYPE, false); input_sync(input_dev);

注意input_sync是必须的，它表示一次完整的事件包的结束。如果没有调用它，上层收不到任何有效事件。我在调试一个设备时就遇到过：触摸屏滑动时，坐标一直不变，后来发现驱动里读取坐标后，忘了在中断处理函数末尾调用input_sync，导致事件一直被缓冲。

对于多指触控，触控 IC 会同时上报多个触点的坐标。驱动要注意 slot 的分配策略。有些 IC 在抬起某根手指后，剩余的触点 slot 序号会变化，如果驱动用固定 slot 去报，会出现“手指串线”。好的做法是依赖 IC 报告的手指 ID 来映射 slot，或者用input_mt_assign_slot动态分配。

4. 核心驱动流程拆解：probe、中断与坐标上报

4.1 probe 里的顺序为什么不能乱

一个标准的 TP 驱动的 probe 流程，顺序大概是这样的：

1. 解析设备树，获取 GPIO、电源、分辨率等资源。
2. 初始化电源：使能 regulator，拉高复位引脚。
3. I2C 通信自检：读取 IC 的 ID 寄存器，确认通信正常。
4. 下载/加载固件或者配置寄存器组。
5. 初始化 input device，设置能力位和坐标范围。
6. 注册中断处理函数。
7. 注册 input device。
8. 使能触摸扫描（有些 IC 有显式的 enable 寄存器）。

这个顺序不是随便定的，每一步都在为后一步铺路。比如先读 IC ID，是为了在加载固件前确认 I2C 和电源没问题，避免读数据全FF然后盲写固件把 IC 刷成砖。注册中断必须放在最后一步附近，是因为中断处理函数里会访问 input device 和 IC 的寄存器，如果 I2C 还没初始化好，中断一来就崩溃。

实际项目里我踩过一个代码执行顺序的坑：某个方案的驱动把request_threaded_irq放在input_register_device之前，结果中断注册成功后立刻来了一个触摸（人手正搭在屏上测试），中断处理函数里调用input_report_abs时 input device 还没注册，内核直接打了一堆警告，触摸的初始状态全乱了。所以标准顺序里，input_register_device必须在注册中断之前。

另外，很多 TP 驱动会用devm系列 API 做资源管理，比如devm_kzalloc、devm_request_threaded_irq、devm_input_allocate_device，这样驱动卸载时资源自动释放，不至于漏掉某个清理步骤。但有一点要注意：devm_request_threaded_irq注册的中断，在设备被移除时内核会自动释放，但如果你在中断处理函数里有额外的互斥锁或者读取操作，还是需要在 remove 函数里做好同步控制，防止中断处理半途设备已经没了。

4.2 中断处理函数里的真实工作负载

TP 中断处理一般采用线程化中断（threaded irq），而不是在硬中断上下文里干重活。原因很简单：I2C 读操作是慢速操作，动辄几百微秒到毫秒级，硬中断里不能睡、不能等，如果在硬中断里做 I2C 读，既阻塞了中断返回，又可能导致调度延迟。

所以你在驱动里看到的通常是：

static irqreturn_t tpd_irq_handler(int irq, void *dev_id) { struct touchscreen *ts = dev_id; disable_irq_nosync(irq); schedule_work(&ts->work); return IRQ_HANDLED; }

然后在线程化的 workqueue 里执行真正的数据读取：

static void tpd_work_func(struct work_struct *work) { struct touchscreen *ts = container_of(work, struct touchscreen, work); u8 buf[64]; int ret; ret = i2c_read_block(ts->client, 0x00, buf, sizeof(buf)); if (ret < 0) { enable_irq(ts->irq); return; } parse_touch_data(ts, buf); enable_irq(ts->irq); }

工作函数里读取 IC 的触摸状态寄存器，如果读到的是有效坐标就上报，最后重新使能中断。这里要注意disable_irq_nosync和enable_irq的配合。有些驱动用的是disable_irq，它会在中断处理函数结束前一直等待，如果处理函数里有 I2C 操作可能会死锁。disable_irq_nosync则直接返回，不等中断处理函数结束，适合在中断上下文里快速关断，然后在 workqueue 里重新打开。

中断处理里常见的 bug：没有清中断标志。有些 IC 触摸事件是 LEVEL 类型，如果不写清除寄存器，INT 引脚一直保持有效电平，中断触发一次之后再也不触发（因为电平没有变化），表现为“触摸死掉”。所以每次读完数据后，要检查 IC 是否有软清标志寄存器的需求，很多厂商驱动在读完 0x00 寄存器数据后，会自动清掉该寄存器，但如果你读的寄存器不对，这个清标志动作就没生效。

4.3 坐标上报的完整时机链

从 touch IC 到 input 事件，中间经历“读取-解析-上报-同步”四个阶段。我画不出时序图，但可以用文字把这四个阶段的完整链条说清楚。

读取：中断通知 CPU“有触摸”，workqueue 被调度，驱动通过 I2C 突发读若干字节。比如某 IC 的一个点信息占 6 字节，5 个点就是 30 字节，一次读 30 字节。有效的读取是i2c_transfer中组合写地址+读数据的双 msg 传输。

解析：拿到原始字节流后，要按 IC 规定的比特位格式拆出 X、Y、pressure、touch id 等字段。比如 X 是 12 位，可能分散在两个字节的高低位，需要做移位和掩码。解析错误会导致坐标乱跳。厂商手册里会有寄存器定义表，驱动里的parse_touch_data就是按照这个表写的。

上报：解析完的数据通过input_report_abs报给 input 子系统。一次触摸动作包含多个事件，每个事件都走一遍 input 核心的input_handle_event，最终汇集到input_sync时一次性推给 event handler。

同步：input_sync其实就是发送EV_SYN，它的作用是把本次触摸的所有数据打包成一个“帧”提交给上层。没有 SYN，所有坐标变化都堆积在缓冲区里，上层永远拿不到最新数据，或者拿到的是多个触摸动作混在一起的数据。

我自己调试的时候最常用的验证手段是getevent：

adb shell getevent -lt /dev/input/event3

正常输出长这样：

[ 100.033533] EV_ABS ABS_MT_SLOT 00000000 [ 100.033533] EV_ABS ABS_MT_TRACKING_ID 0000a1bc [ 100.033533] EV_ABS ABS_MT_POSITION_X 00000321 [ 100.033533] EV_ABS ABS_MT_POSITION_Y 00000786 [ 100.033533] EV_ABS ABS_MT_PRESSURE 0000008a [ 100.037533] EV_SYN SYN_REPORT 00000000

如果按下手指后什么都没有，说明中断没触发、I2C 读数据失败、或者 IC 没有正确初始化。如果只有 SYN_REPORT 没有坐标数据，说明上报流程缺了 ABS 事件。这些小问题基本都能靠 getevent 快速定位。

5. 驱动调试与常见问题实录

5.1 设备枚举不上：从 i2cdetect 开始查

遇到 TP 完全没反应，第一步不要去看驱动代码，先用 i2cdetect 扫一下设备在不在总线上。

adb shell su cd /sys/bus/i2c/devices ls

如果看到类似3-0038的目录，说明 I2C 枚举已经成功了。如果没看到，用 i2cdetect 手动扫：

adb shell su echo 3 > /sys/bus/i2c/devices/i2c-3/delete_device # 先删掉已有节点，可选 i2cdetect -y -r 3

输出里如果有38，说明触控 IC 在总线上，但设备树绑定有问题，导致驱动没 probe。如果没有输出或者显示--，基本是以下几种情况：

• I2C 地址不对：检查设备树 reg 和 IC 手册。
• I2C 总线编号不对：TP 挂的 I2C 控制器不是 i2c3，你扫错总线了。
• 电源没供上：寄存器读出来全是0xff或全是0x00。
• SCL/SDA 上拉缺失或 GPIO 复用被占。

如果 i2c 能扫到设备，但驱动没加载，用 dmesg 看有没有：

dmesg | grep -i touch dmesg | grep -i "i2c.*3"

常见的是of_i2c: modalias failure或failed to find match for compatible，这种就是compatible字符串不匹配。改成和驱动of_device_id完全一致就行。

5.2 触摸断断续续或跳点：别急着怀疑 IC

触摸跳点、乱跳、断触，很多人第一反应是“触控 IC 有问题”或者“eSD 干扰”。但驱动层面也有不少原因。

I2C 时钟频率过高是常见原因。很多平台的 I2C 默认跑 400kHz，但触控 IC 的时序要求可能只能到 100kHz 或 200kHz。在设备树里降低 i2c 频率：

&i2c3 { clock-frequency = <100000>; };

如果改了频率后跳点消失，说明问题就是信号时序余量不够。量产项目中，I2C 走线过长、PCB 上靠近射频模块等都会加剧这种问题。

还有一种情况：读坐标的缓冲区大小不对。IC 支持 5 点触控，但驱动里只分配了 3 个点的读取空间，然后 IC 在 4 指触摸时，寄存器里数据格式发生变化，驱动按 3 点解析，数据错位，报出来的坐标就飞了。所以解析逻辑一定要和 IC 支持的最大点数匹配，建议直接读满整个触摸数据缓冲区，再按实际触点数量解析。

坐标乱跳还有一种容易忽视的原因：触控 IC 的自容和互容校准没完成。有些 IC 在系统刚启动时会自动校准，但校准需要保持屏幕干净 1~2 秒。如果驱动初始化过程中有电噪声，或者面板厂家没有做好贴合工序，就会导致基线不准。驱动层面只能重新触发校准标志，或者建议工厂重新做贴合。

5.3 休眠唤醒后失灵：suspend/resume 的正确姿势

“休眠唤醒后触摸失灵”是我遇到的高频问题，而且特别难定位，因为日常使用中不一定会复现，有时候锁屏半天再打开就坏了。

这类问题本质上是触控 IC 的供电方式和主控的休眠机制配合出了问题。第一种情况：系统休眠时，TP 的电源 LDO 被关闭，但 IC 没有进入正确的低功耗模式，唤醒后驱动重新访问 I2C 时 IC 状态异常。第二种情况：TP 的电源一直开，但 I2C 总线进入了低功耗状态或被时钟门控，唤醒后 I2C 通信恢复得慢，驱动的重试次数不够。第三种情况：触摸 IC 的固件在睡眠后驻留在某一个特殊状态，必须由驱动在 resume 里重新下发初始化命令。

规范的驱动会在 suspend 里做三件事：

• 关闭中断，避免休眠过程中触摸引起中断风暴。
• 把触控 IC 切到低功耗或睡眠模式，通常是写一个 power-down 寄存器。
• 释放 input 设备上所有未完成的触点，防止恢复到系统里有鬼影手指。

在 resume 里做相反的三件事：

• 唤醒 IC，等它 ready。
• 重新配置基础寄存器（有些 IC 睡眠后寄存器会恢复默认值）。
• 重新使能中断，然后上报一个 SYN 空包，清掉上一轮的残留状态。

如果厂商驱动只做了部分处理，就要自己补。我记得有个项目是在 suspend 里只关了中断但没把 IC 睡眠，结果功耗多了 2mA，后来加上了写睡眠寄存器才降到正常值。另一次是 resume 里 IC 的复位引脚没有重新拉低再拉高，导致 IC 一直处于挂了的状态，只能重启系统才能恢复触摸。

调试这种问题，最快的方式是在 suspend/resume 函数里加 printk，看 IC 的 ID 寄存器是否能正常读回来。如果读不到，说明 I2C 不通；如果能读到 ID 但上报不正常，说明初始化配置缺失，去对比厂商参考代码的唤醒序列，基本能找到漏掉的那一步。

6. 进阶：手势、固件升级与功耗控制

6.1 手势唤醒是怎么实现的

有些项目会要求“双击亮屏”或者“画 C 亮屏”，这就是手势唤醒（gesture wakeup）。它的核心思路是：系统已经进入睡眠，但触控 IC 仍然保持一个低功耗扫描模式，只检测特定手势，不报正常触摸坐标。

这种功能的实现有两层。IC 侧，固件里烧录了手势识别算法，在识别到手势后通过中断告诉主控，或者把识别结果放在某个寄存器里。驱动侧，要在 suspend 前后设置好 IC 的工作模式，不能让它进入完全睡眠，要进入“手势检测模式”。

驱动里需要处理的问题是，手势事件来了之后，供电和中断链条是否还活着。有些平台在睡眠时直接断掉了 TP 的电源，那手势唤醒硬件上就跑不起来，需要改成常供电。另外，手势上报一般不是走ABS_MT坐标系，而是走EV_KEY的特定 KEY 码，比如KEY_WAKEUP，然后由 Framework 层转换成亮屏动作。

这里面的坑也不少。有一回项目上要支持“双击唤醒”，但设备树里触摸屏的电源被配置成和屏幕背光共用一路 LDO，屏幕睡眠时背光关了、LDO 也关了，手势唤醒自然失效。那次的整改方案是把 TP 电源改到常电，单独增加一个 GPIO 做功耗开关，才算彻底解决。

6.2 固件升级为什么经常“悄悄进行”

触控 IC 的固件升级通常是在开机时由驱动在后台进行的，用户无感知，所以你会看到开机初始化时 UART 日志里有大段下载固件的打印。驱动要做的是：先读当前固件版本号，和驱动里预置的固件版本号做对比，如果不匹配就启动升级流程。

升级流程本质上是 I2C 写操作，把固件二进制数据分块写入 IC 的 flash 区域，写完后再校验。这里容易出现的问题有三个：

一是升级过程中断电，IC 的 bootloader 状态损坏。好一点的 IC 会保留出厂 boot 区，驱动每次启动时都会检查是否需要重刷。二是一次写入的块大小超出 IC 的 I2C 缓冲限制，导致写失败。一般建议单次写入不要超过 32 或 64 字节，具体看 IC 手册。三是在升级期间触摸事件恰好到来，IC 的处理逻辑可能冲突，所以进入升级模式之前最好先把触摸扫描关闭。

固件升级还会影响启动时间。一个几百 KB 的固件通过 400kHz 的 I2C 写，跑完整轮可能要好几秒。主板上如果是冷启动时间敏感的项目，这一块要提前评估，必要时把固件放在系统分区直接读，而不是每次开机都重复全量写。有些方案支持只升级版本差异部分，能大幅缩短时间，但需要 IC 厂商的私有协议支持。

6.3 功耗调优的几个切入点

TP 驱动在整机功耗里虽然占比不大，但处理不好会拖累整个系统。常见的问题是和“触摸扫描”相关的三个参数：扫描周期、中断触发频率、空闲电流。

第一个切入点是：没有触摸时，IC 应该进入 Idle 模式，驱动里要在 suspend 流程显式切换，而不是依赖 IC 自己判断。有些 IC 虽然号称有智能扫描，但如果没有收到“进入低功耗模式”的命令，内部仍然按全速跑，功耗差 1~2mA 很正常。

第二个切入点是中断的触发频率。如果在硬中断里频繁开关中断，或者电平触发模式下 IC 没有正确清除中断标志，中断风暴会唤醒 CPU，导致系统一直停留在浅睡眠状态，整机功耗明显上升。通过cat /proc/interrupts | grep touch可以看中断次数，如果几百毫秒内增长几千次，肯定有问题。

第三个切入点是 I2C 总线本身。速度快造成的功耗开销也大，所以有些平台在空闲时会减小 TP 的 I2C 时钟频率。另外，如果 IC 有独立的 sleep 引脚或 GPIO 控制，驱动要记得在 suspend 里置成低电平，避免各个模块同时唤醒干扰。

我在调低功耗时，习惯对比三个数据：待机电流、休眠时 TP 中断次数、唤醒后 TP 是否正常工作。这三者的平衡点需要反复测，尤其是“常供电手势唤醒”的项目，一旦手势检测功耗没控制好，待机电流直接超标，研发阶段可能看不出来，到了量产测试才暴露。所以从项目初期就要把功耗目标写进驱动设计文档里，而不是最后再回头补。

最后再说一个经验：TP 驱动调试，说到底是“时序”和“配置”两个词的反复博弈。多花时间把 I2C 时序、上电时序、中断触发方式吃透，比背一堆 API 有用得多。第一次接触 TP 的人，建议从厂商给的参考代码入手，但要先理清硬件链路，再动手改，不要上来就make menuconfig一通乱配。内核日志和getevent是调试时最亲密的两个工具，用好它们，大部分问题都会现出原形。