3. 触摸驱动基础

做触摸屏驱动调优，首先得搞清楚数据是怎么从你的手指尖跑到应用层的。我见过不少工程师一上来就调参数，结果发现瓶颈根本不在自己负责的那一层——说白了，方向错了，再努力也白搭。

这一章，我们就来拆解智能座舱触摸屏的驱动架构，把数据流路径画清楚。你想想看，只有知道每个环节的延迟从哪里来，才能精准地下刀。

3.1 典型的四层驱动架构

目前主流的智能座舱方案，触摸驱动基本都遵循四层架构。我个人习惯把它分成下面这几层：

层级	名称	主要职责	典型延迟
L1	硬件接口层	I2C/SPI/USB 总线读写，原始数据采集	1-5 ms
L2	协议解析层	解析触摸控制器上报的协议包，去抖、滤波	0.5-2 ms
L3	事件合成层	将原始触摸点合成 input 事件，坐标转换	0.1-0.5 ms
L4	应用分发层	通过 Input 子系统或 Wayland 协议分发到应用	1-10 ms

嗯，这里要注意：L4 的延迟波动最大，因为它涉及进程调度和 IPC。我在项目中遇到过，明明 L1-L3 都优化到极致了，但用户还是觉得跟手度不够，最后发现是应用层的事件队列被其他任务阻塞了。

3.2 数据流的核心路径

数据从触摸屏到应用，到底走了哪些路？我画了一张图，帮你把整个流程串起来。

3.3 各层的关键优化点

知道了路径，我们来看看每一层具体能做什么。我按自己的经验，把最值得投入精力的优化点列出来。

3.3.1 硬件接口层（L1）

• 总线频率调优：I2C 标准模式 100kHz，快速模式 400kHz。我建议直接上 400kHz，前提是信号完整性没问题。
• 中断触发方式：用边沿触发代替电平触发，减少 CPU 不必要的唤醒。
• DMA 传输：如果控制器支持，一定要开 DMA。我在一个项目中，开了 DMA 后单次读取时间从 1.2ms 降到了 0.3ms。

3.3.2 协议解析层（L2）

这一层最容易踩坑。我曾经花了一周时间，才发现问题出在协议解析的算法上。

• 去抖算法：不要用简单的延时去抖，用状态机+计数的方式，延迟可控。
• 滤波策略：中值滤波对孤立噪声点效果好，均值滤波对连续噪声效果好。根据你的触摸屏噪声特性选一个。
• 协议包校验：CRC 校验放在中断上下文之外做，别阻塞数据读取。

3.3.3 事件合成层（L3）

事件合成层是驱动调优的「黄金地带」。为什么？因为这里离硬件近，又离应用近，改动效果立竿见影。

优化项	做法	预期效果
坐标转换	用查表法代替浮点运算	减少 0.2ms
事件合并	将多个触摸点打包成一个事件	减少 30% 的事件数量
上报频率	根据屏幕刷新率动态调整	避免无效上报

3.3.4 应用分发层（L4）

这一层往往不是驱动工程师能完全控制的，但你可以给应用层提供一些「友好」的接口。

• 使用 evdev 协议：标准 input 事件协议，兼容性最好。
• 设置合理的上报频率：不要超过屏幕刷新率的 2 倍，否则浪费 CPU。
• 提供调试接口：在 debugfs 中暴露延迟统计信息，方便应用层排查问题。

3.4 数据流中的常见瓶颈

根据我的经验，下面这几个地方最容易成为瓶颈：

1. I2C 总线竞争：座舱里挂了很多 I2C 设备（传感器、音频、触摸），总线仲裁会导致延迟抖动。
2. 中断处理过长：在中断上下文里做了太多事，导致其他中断被延迟。
3. 内存分配：在数据路径上做动态内存分配，很容易触发页面回收，造成毫秒级延迟。
4. 进程优先级：触摸事件处理线程的优先级不够，被其他任务抢占。

3.5 实战：如何快速定位延迟在哪一层

最后，分享一个我常用的方法。当用户反馈触摸不跟手时，我会这样做：

1. 在驱动中打时间戳，记录从硬件中断到事件上报的耗时。
2. 用 ftrace 跟踪 input 事件在内核中的流转时间。
3. 在应用层用 getevent 工具测量事件到达的时间间隔。
4. 对比这三组数据，延迟最大的那一层就是优化目标。

举个例子，有一次我发现驱动内耗时只有 3ms，但应用层收到事件已经是 15ms 后了。问题出在应用层的线程被其他任务阻塞了。调整了线程优先级后，延迟降到了 5ms 以内。

嗯，这一章的内容就到这里。记住，调优之前先画图，把数据流路径搞清楚，你才能知道刀往哪里砍。