简介tp28xx_kdrv_tp9930.tar.gz 是一份面向 Linux 平台、针对 TP2828/TP2831 系列芯片与 TP9930 触摸屏控制器模块的内核驱动源码包。适用于嵌入式开发工程师、系统集成人员及需要在 Linux 环境中驱动上述硬件的维护者解决设备初始化、寄存器配置、数据交互与内核模块加载等实际问题。整个压缩包约 76KB共 14 个文件以 9 个 C 源码、3 个 Makefile 和 2 个头文件为主涵盖 tp2802、tp2827、tp2829、tp2831 等具体芯片驱动分支Makefile 用于内核模块编译构建头文件则提供寄存器定义与接口声明。解包后可直接查阅驱动实现、编译脚本与模块入口便于对照芯片手册二次开发或移植对初学者也能借此理解内核驱动框架、ioremap/中断处理等典型写法。目前已有 1432 人学习下载适合需要快速接入该系列硬件的开发与运维人员参考。1. 手头多了一个 tp28xx_kdrv_tp9930.tar.gz这是一份能帮你跳过驱动深坑的触摸屏代码包做嵌入式 Linux 的人十有八九都经历过这种场景量产的工业平板或 HMI 设备换了触摸屏芯片选的是 TP9930厂商只扔给你一个压缩包说“驱动在这里你们自己搞”。这个 tp28xx_kdrv_tp9930.tar.gz 就是典型的触摸屏控制器驱动源码包里面包含 I2C 驱动、设备树配置样例和 Demo 代码目标是把 TP9930 这颗芯片在 Linux 内核里跑起来让 input 子系统能正常上报触摸坐标。它解决的是从拿到裸芯片到getevent能出数据这一段最烦人的工作适合嵌入式驱动开发、BSP 维护、以及做产品选型评估的工程师。这篇笔记我就按实际拆包和移植的路径把它内部怎么组织、怎么编译、怎么配设备树、有哪些坑一次讲完。2. 驱动包内部结构与 probe 流程先看懂 TP9930 是怎么挂进 input 子系统的2.1 解包后先看文件组成Makefile 和源码文件的职责分布拿到 tp28xx_kdrv_tp9930.tar.gz我习惯先解压到一个干净的目录用tar -tzf看文件清单再决定编译方式。常见的结构是tp9930.c、tp9930.h、Makefile有的版本还带tp9930_fw.h或tp9930_config.h后者一般放固件数组和分辨率宏。mkdir ~/tp9930 cd ~/tp9930 tar -xzf tp28xx_kdrv_tp9930.tar.gz find . -maxdepth 2 -type f | sort先把tp9930.c打开确认它注册的 I2C driver name 是tp9930还是tp28xx这决定了设备树 compatible 字符串怎么填。我遇到过包内 name 和文档不一致的情况以源码为准设备树里的 compatible 必须和of_match_table完全匹配否则内核根本不调用 probe。Makefile通常是单一 obj-m 形式形如obj-m tp9930.o如果你要把驱动编进内核而不是模块需要改成obj-$(CONFIG_TOUCHSCREEN_TP9930)并去 Kconfig 里加对应配置项。这一步虽然简单但直接决定后面make menuconfig时能不能看到这个驱动。2.2 probe 函数里发生了什么I2C 验证、中断申请、input_dev 注册TP9930 是一个 I2C 接口的电容触摸控制芯片内核驱动走的是 input 子系统标准路径。probe 函数的典型顺序是读取client-irq中断号用devm_request_threaded_irq注册一个中断处理函数然后在中断底半部里通过 I2C 读坐标寄存器最后用input_report_abs上报 ABS_MT_POSITION_X / Y。这个流程里最关键的一点是TP9930 支持的是 Type B 多点触摸协议所以要用input_mt_init_slots初始化 slot并在每次上报前调用input_mt_slot和input_mt_report_slot_state。static int tp9930_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct tp9930_ts *ts; struct input_dev *input; int ret; if (!i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) return -EIO; ts devm_kzalloc(client-dev, sizeof(*ts), GFP_KERNEL); input devm_input_allocate_device(client-dev); input-id.bustype BUS_I2C; input-dev.parent client-dev; __set_bit(EV_SYN, input-evbit); __set_bit(EV_ABS, input-evbit); __set_bit(INPUT_PROP_DIRECT, input-propbit); input_set_abs_params(input, ABS_X, 0, ts-x_max, 0, 0); input_set_abs_params(input, ABS_Y, 0, ts-y_max, 0, 0); input_mt_init_slots(input, 5, 0); input_set_drvdata(input, ts); ts-input input; }上面这段是精简后的关键逻辑。ts-x_max和ts-y_max通常从tp9930.h里读厂商默认给的是 1024×600 或 1280×800要根据实际屏幕分辨率核对否则坐标比例会偏。input_mt_init_slots的第二个参数传 5意思是支持 5 点触摸如果 TP9930 实际只支持 2 点这里传 5 也不会出错内核只会浪费一点内存但如果是旧内核slot 数超过芯片能力可能导致 ABS_MT_SLOT 状态错乱。中断号这块如果设备树里没配 interruptsclient-irq拿到的是 0probe 里应该加一个检查否则后面request_threaded_irq会直接失败这类问题在内核 log 里表现为No IRQ错误而且是 probe 直接返回 -EINVAL。2.3 上报坐标的分辨率换算驱动里的坐标不是物理像素TP9930 的坐标寄存器返回值和屏幕物理分辨率往往不是一一对应的。芯片内部有一个固定的采样范围厂商驱动通常在tp9930_read_coords函数里做线性映射。常见的写法是用tp9930_parse_coords解析原始坐标后再根据设备树里的touchscreen-size-x和touchscreen-size-y做归一化。static void tp9930_report_coords(struct tp9930_ts *ts, u16 x_raw, u16 y_raw) { struct input_dev *input ts-input; int x (x_raw * ts-x_max) / TP9930_RAW_MAX; int y (y_raw * ts-y_max) / TP9930_RAW_MAX; input_mt_slot(input, 0); input_mt_report_slot_state(input, MT_TOOL_FINGER, true); input_report_abs(input, ABS_MT_POSITION_X, x); input_report_abs(input, ABS_MT_POSITION_Y, y); input_sync(input); }这段代码里TP9930_RAW_MAX是芯片寄存器能返回的最大原始值一般定义在头文件里。如果你发现触摸点了但光标位置偏到角落先查这个宏是否和芯片手册一致而不是急着改设备树。还有一种情况是面板本身的触控区域有偏移这需要加一个swap-x-y或x-invert的修正逻辑。我看到很多驱动直接把原始值上报不经过归一化这在某些 TP9930 固件版本上会导致触摸区域和显示区域错位。厂商源码包里如果带了tp9930.cfg这类配置文件里面往往能找到分辨率映射的参考值直接抄进去比自己猜靠谱。3. 编译与设备树配置把 TP9930 驱动挂到内核里的完整操作3.1 Kconfig 与 Makefile 对接让 menuconfig 里出现 tp9930 条目如果你是第一次移植建议先把驱动编成模块试试水这样不用反复烧写整个内核镜像。操作分三步把tp9930.c放到drivers/input/touchscreen/目录下面在Kconfig里加一段config TOUCHSCREEN_TP9930再到Makefile里加obj-$(CONFIG_TOUCHSCREEN_TP9930) tp9930.o。cd kernel/drivers/input/touchscreen/ cp ~/tp9930/tp9930.c . vim Kconfig vim Makefile make ARCHarm menuconfigKconfig 里的内容一般是这样的结构tristate 表示可以编成 y/n/m 三种状态depends on 通常写I2C INPUT。我一般会在这个条目后面加一句help描述方便其他人知道这个驱动对应什么芯片。菜单路径是 Device Drivers Input device support Touchscreens进入之后应该能看到TP9930 touchscreen support。如果看不到多半是 Kconfig 的缩进格式不对内核的 Kconfig 对 tab 和空格极其敏感我在这上面浪费过一下午后来学乖了改完 Kconfig 先跑scripts/kconfig检查语法。3.2 设备树节点interrupts、reg、reset-gpios 的取值与写法TP9930 挂在某个 I2C 总线上设备树节点要写在对应的 I2C controller 下面。以 Linux 4.x 内核常见的写法为例i2c2 { tp993038 { compatible tp9930,touch; reg 0x38; pinctrl-names default; pinctrl-0 tp9930_int_pin; interrupts-extended gpio1 13 IRQ_TYPE_EDGE_FALLING; reset-gpios gpio1 12 GPIO_ACTIVE_LOW; touchscreen-size-x 1024; touchscreen-size-y 600; }; };reg 0x38这一项要特别小心。TP9930 的 7 位 I2C 地址是 0x38但有些芯片手册上给的是 8 位地址 0x70写设备树必须以 7 位地址为准否则 I2C core 会按 0x70 去匹配probe 永远不会被调用。interrupts-extended里的IRQ_TYPE_EDGE_FALLING是 TP9930 比较常见的触发方式驱动里如果request_threaded_irq的 flags 和设备树不一致会出现中断风暴或者干脆没中断。reset-gpios不是必须的但如果芯片上电后没有完成自检驱动读寄存器会超时加上这个引脚并在 probe 里做一次拉低再拉高的复位操作能解决很多“偶然不工作”的诡异问题。这里要注意 GPIO 的 flag 是GPIO_ACTIVE_LOW复位逻辑是置低有效。先编译一遍设备树确认没有语法错误再碰驱动。用make dtbs编完以后用dtc工具反编译检查节点是否真的编译进去了make ARCHarm dtbs dtc -I dtb -O dts -o /tmp/check.dts arch/arm/boot/dts/your-board.dtb grep -n tp9930 /tmp/check.dtsdtc反编译这一步很值得做我见过有人设备树写错了但编译通过上电后I2C总线上探测不到任何设备然后开始怀疑驱动代码实际上节点压根没进 dtb。反编译后既能确认节点存在也能顺便看看interrupts-extended里的 phandle 有没有指向正确的 GPIO 控制器。3.3 加载模块与 I2C 探测确认设备地址和 probe 成功与否把编译出来的tp9930.ko推到目标板上insmod 之前先确认 I2C 总线上确实有 TP9930 这个设备。用i2cdetect扫一遍是最直接的i2cdetect -y -r 2 insmod tp9930.ko dmesg | tail -20i2cdetect后面的2是 I2C 总线号对应设备树里的i2c2。如果扫描结果里在38位置出现UU说明已经有驱动占用了如果出现38说明设备在但没有驱动绑定如果什么也没有先检查硬件连接和上电时序别急着加载驱动。insmod 之后立刻看 dmesgprobe 成功一般会打印input: TP9930 touchscreen as /devices/...之类的内容同时/dev/input/eventX会多出来一个节点。这里有个容易踩的细节insmod时如果驱动依赖input子系统但你的内核没把CONFIG_INPUT编译进去insmod 会报 unresolved symbol需要回内核配置里把CONFIG_INPUT打开这不是驱动本身的问题。4. 跨平台移植从参考板到目标板的四项硬性适配4.1 内核 API 版本差异3.10 与 5.4 的 input 上报函数区别移植时能直接编过的概率并不高。如果参考代码是从某个 3.10 内核的 SDK 里拿出来的搬到 5.4 内核上大概率要处理 input 子系统的 API 变化。最简单直接的差异是input_set_abs_params里的参数老内核是input_set_abs_params(input, ABS_MT_POSITION_X, 0, x_max, 0, 0)新内核还兼容这种写法但input_mt_init_slots的返回值从 void 变成了 int旧代码如果写成直接调用而忽略了返回值编译器会报 warning 但不影响编译。真正致命的是struct input_dev的keybit和evbit的位操作方式有些驱动用set_bit(EV_KEY, input-evbit)而 TP9930 的驱动一般只需要ABS不需要KEY但如果你从别的驱动抄了一段可能残留KEY_POWER之类的定义编进内核后行为不可预测。#if LINUX_VERSION_CODE KERNEL_VERSION(4, 0, 0) ret input_mt_init_slots(input, 5, 0); if (ret) { dev_err(client-dev, input_mt_init_slots failed\n); return ret; } #else input_mt_init_slots(input, 5, 0); #endif这种版本宏判断是内核驱动的常规做法但别过度依赖。它解决的是编译期兼容运行期的差异更隐性——比如新内核的devm_request_threaded_irq对 IRQ flags 的校验更严格IRQF_TRIGGER_FALLING这种老宏在某些平台上会被忽略导致中断完全不触发但 dmesg 里没有任何报错。我一般会在 probe 里把client-irq打出来再确认 request 时传入的 flags如果发现差异优先用设备树里的IRQ_TYPE_EDGE_FALLING而不是驱动里的硬编码让 DTB 成为唯一的中断配置来源。4.2 上电时序与复位设计reset 引脚不是摆设TP9930 的上电时序如果不能满足表现非常像“驱动 bug”设备树明明配了节点I2C 探测也偶尔能扫到但 probe 时读芯片 ID 寄存器返回全 0xFF。这时候十有八九是芯片供电或复位时序问题不是软件问题。厂商参考设计里一般会给出power-on之后至少等待 10ms 再拉高 reset 的要求驱动里如果没做延时可以在 probe 里加一段gpiod_set_value_cansleep(ts-reset_gpio, 0); msleep(20); gpiod_set_value_cansleep(ts-reset_gpio, 1); msleep(100);这段逻辑是在 probe 最开始执行一次硬复位给芯片足够时间完成内部固件加载。gpiod_set_value_cansleep用的是 GPIO descriptor 接口对应设备树里的reset-gpios。如果驱动里用的是老的gpio_set_value接口需要拿到 GPIO 号后手动gpio_request但新内核推荐直接走devm_gpiod_get_optional省去释放逻辑。我最开始移植时觉得这个 20ms 和 100ms 是随便给的直到发现某批次芯片需要 150ms 才能稳定响应 I2C 读操作才意识到时序参数不能只看参考驱动要结合具体硬件设计裕量。4.3 坐标旋转与镜像设备树里的三条属性就能解决方向问题TP9930 的屏幕方向不对是很常见的需求产品横竖屏切换、面板出线方向不同都会导致 X/Y 坐标和显示内容镜像。最简单可靠的方案是在驱动里支持设备树的touchscreen-swapped-x-y、touchscreen-x-invert、touchscreen-y-invert三个布尔属性在坐标上报前做一次坐标变换。if (ts-swap_x_y) swap(x, y); if (ts-x_invert) x ts-x_max - x; if (ts-y_invert) y ts-y_max - y;这个变换的逻辑是在归一化之后做的注意先 invert 还是先 swap 会得到不同的效果我是按先 swap 再 invert 的顺序处理的因为这样比较符合“先旋转坐标轴再翻转坐标方向”的直觉。这里有一个坑如果变换顺序写反了180 度旋转的效果会被错误地变成镜像而且视觉上差别很细微——竖屏应用里字符方向不对但触摸响应位置看起来“差不多”特别容易漏掉。设备树里设这三个属性时每次改完要重启并重新校准因为这是个非线性变换不能期望只在 x 方向加一个偏移量就能覆盖所有角度。4.4 固件版本差异为什么同一个驱动在不同批次芯片上表现不同TP9930 芯片出厂时固件版本可能不同有些驱动内部会有固件降级保护——如果芯片固件比驱动要求的版本旧probe 会尝试用内核里内置的固件数组升级芯片。如果你的源码包里没有FW_VERSION相关的头文件那说明这个驱动版本不负责升级固件纯粹当输入设备用。我遇到过一次奇怪现象A 项目上驱动工作正常B 项目拿到同型号芯片probe 报firmware version mismatch然后 touch 功能时好时坏。A 项目的根本原因是旧固件对 5 点触摸的上报协议有 bug偶尔会丢 slot 状态。解决方法是让厂商提供新版固件 bin放到/lib/firmware/下用request_firmware机制加载或者直接把固件数组替换进tp9930_fw.h重新编驱动。这个环节在没有参考文档时比较黑匣子只能多试几个固件版本找到稳定的那个我一般会留一个fw_version的 debugfs 节点方便排查。5. 避坑实录TP9930 驱动调试中的五个典型问题与定位思路5.1 现象一probe 完全不被调用dmesg 里没有任何输出芯片扫描i2cdetect能看到地址但加载驱动后 probe 不执行内核日志干净得像什么都没发生。原因几乎都是of_match_table和id_table里的名字与设备树 compatible 不匹配。有些驱动为了兼容多个 I2C 地址会在i2c_device_id里写通配符tp9930但设备树里写的是tp28xx,tp9930导致匹配失败。解决方法是统一成同一个字符串或者驱动里同时保留of_device_id和i2c_device_id两套表。static const struct of_device_id tp9930_of_match[] { { .compatible tp9930,touch, }, {} }; MODULE_DEVICE_TABLE(of, tp9930_of_match);检查这个问题的标准动作是在 probe 入口加打印然后看dmesg里有没有tp9930_probe字样。如果没打印说明匹配环节就断了对比设备树 compatible 和这个数组里的字符串一个字符都不能差。特别注意MODULE_DEVICE_TABLE宏不能省去掉它会导致设备树方式匹配失效但 I2C 地址方式还能工作这种半残状态最迷惑人。5.2 现象二probe 成功但触摸无响应getevent 没有事件dmesg里显示input: TP9930 touchscreen注册成功/dev/input/event0也存在但getevent没有任何输出。优先排查中断cat /proc/interrupts看 TP9930 对应的中断号有没有计数增加。如果没有大概率是中断触发方式配置错误TP9930 使用边沿触发如果驱动里写的IRQF_TRIGGER_HIGH或设备树里漏了IRQ_TYPE_EDGE_FALLING中断信号来了但内核不认。另一个隐蔽原因是 GPIO 的 pinctrl 配置不对GPIO 被复用成了其他功能导致中断引脚电平一直被拉高或拉低。解决方法是先测量触屏按下时 GPIO 引脚是否有电平跳变如果硬件信号没问题再逐字核对设备树里的interrupts-extended和 pinctrl 节点。5.3 现象三触摸坐标漂移点击位置与实际显示错位触摸和显示错位分两种全屏偏移固定量或者越往边缘偏得越厉害。固定偏移大多是面板贴合精度问题需要做一次触点校准把四个角的实际物理坐标读出来算一个偏移矩阵。边缘非线性偏移则是坐标归一化的问题——回到第 2.3 节提到的TP9930_RAW_MAX如果这个值比实际寄存器最大值大相当于把原始数据压缩到了一个更小的范围边缘坐标自然往中间挤。验证办法是读芯片寄存器在触摸屏幕最边缘时看原始坐标值记录真实的最大值然后改头文件里的宏。改完重新编译驱动通常立竿见影。5.4 现象四升级内核后驱动编译报错posix timer 相关错误内核版本升级后.ko文件必须重新编译这几乎是铁律。把 TP9930 驱动从 3.14 内核移植到 5.10 内核最常见的是input_mt_init_slots返回值检查、struct i2c_client里dev字段访问方式变化以及time_after/jiffies相关宏的兼容性。这类问题本质上是驱动代码使用了未稳定 API解决方法是按新内核的规范改写而不是在编译参数里强行-Wno-error屏蔽。我的血泪经验是先grep一遍源码里所有被#ifdef CONFIG_xxx包裹的片段这些往往是老内核的补丁痕迹大概率在新内核里不再适用。5.5 现象五系统休眠唤醒后触摸失灵恢复需要重新插拔休眠唤醒后触摸屏无响应是 tp9930 这类芯片的常见问题。原因是驱动在 suspend 阶段没有正确关闭中断或 resume 后没有重新初始化芯片。TP9930 在睡眠后内部状态机可能回到初始态需要重新配置分辨率并做一次坐标基准校准。解决方法是注册pm_ops结构体在resume回调里对 TP9930 做一次软复位。static int tp9930_resume(struct device *dev) { struct tp9930_ts *ts dev_get_drvdata(dev); tp9930_reset_chip(ts); enable_irq(ts-irq); return 0; }注意enable_irq之前要先确认中断没有泄漏否则唤醒瞬间中断风暴会吃掉所有 CPU 时间。有些驱动里 suspend 时只做了disable_irq但没保存芯片状态resume 后直接enable_irq结果芯片还没准备好就开始上报垃圾坐标。我一般会加一个 50ms 的延时再 enable_irq并且用mutex保证 suspend/resume 和触摸上报线程不竞争 I2C 总线。6. 事件节点验证法用 Python 脚本确认触摸坐标上报的正确性TP9930 驱动移植完成后用一个脚本验证触摸响应是最快的方式。直接用getevent能看原始事件流但不够直观。我会用 Python 读/dev/input/eventX解析input_event结构体实时打印触摸坐标。import struct import time EV_ABS 3 ABS_MT_POSITION_X 0x35 ABS_MT_POSITION_Y 0x36 ABS_MT_TRACKING_ID 0x39 ABS_MT_SLOT 0x2f fmt llHHi size struct.calcsize(fmt) with open(/dev/input/event1, rb) as f: while True: event f.read(size) if not event: break sec, usec, type, code, value struct.unpack(fmt, event) if type EV_ABS: if code ABS_MT_POSITION_X: print(fX{value}) elif code ABS_MT_POSITION_Y: print(fY{value}) elif code ABS_MT_TRACKING_ID: print(fTrackingID{value})运行这个脚本用一个手指在屏幕上划对角线观察 X 和 Y 数值是否线性变化。如果 X 从 0 到 1023 变化但 Y 始终停在某个范围只抖动不递增说明 Y 轴的数据通路有问题——可能是中断处理里读错了寄存器地址或者坐标换算时把 Y 值当成了某个固定偏移。脚本里 event 节点可能不是event1用getevent -i或者ls /dev/input/确认是哪一个。如果触摸没有任何输出除了中断问题还要检查脚本是否以 root 权限运行某些系统对/dev/input节点做了权限限制。触摸覆盖测试有个简单的办法在屏幕上画一个九宫格每个格子中心点按一下打印出九组坐标看看 X 和 Y 是否均匀分布每组之间的间距是否符合屏幕比例。如果某个格子的坐标明显偏向一边且该格子在多个方向上都偏考虑驱动里的触摸屏校准矩阵是否需要修正。这个验证脚本我会保留在板卡上之后无论升级内核还是更换其他型号触摸芯片都会先跑一遍确保回归通过。从那以后我每次移植 TP9930 都会强制走一遍编译、设备树反编译、事件读取、九宫格验证这四步一次不漏省掉了不少返工折腾。希望这篇笔记里的路径和坑位能帮到你少走点弯路。本文还有配套的精品资源点击获取 TP9930触摸屏驱动移植指南：基于Linux内核与设备树的完整实践
简介tp28xx_kdrv_tp9930.tar.gz 是一份面向 Linux 平台、针对 TP2828/TP2831 系列芯片与 TP9930 触摸屏控制器模块的内核驱动源码包。适用于嵌入式开发工程师、系统集成人员及需要在 Linux 环境中驱动上述硬件的维护者解决设备初始化、寄存器配置、数据交互与内核模块加载等实际问题。整个压缩包约 76KB共 14 个文件以 9 个 C 源码、3 个 Makefile 和 2 个头文件为主涵盖 tp2802、tp2827、tp2829、tp2831 等具体芯片驱动分支Makefile 用于内核模块编译构建头文件则提供寄存器定义与接口声明。解包后可直接查阅驱动实现、编译脚本与模块入口便于对照芯片手册二次开发或移植对初学者也能借此理解内核驱动框架、ioremap/中断处理等典型写法。目前已有 1432 人学习下载适合需要快速接入该系列硬件的开发与运维人员参考。1. 手头多了一个 tp28xx_kdrv_tp9930.tar.gz这是一份能帮你跳过驱动深坑的触摸屏代码包做嵌入式 Linux 的人十有八九都经历过这种场景量产的工业平板或 HMI 设备换了触摸屏芯片选的是 TP9930厂商只扔给你一个压缩包说“驱动在这里你们自己搞”。这个 tp28xx_kdrv_tp9930.tar.gz 就是典型的触摸屏控制器驱动源码包里面包含 I2C 驱动、设备树配置样例和 Demo 代码目标是把 TP9930 这颗芯片在 Linux 内核里跑起来让 input 子系统能正常上报触摸坐标。它解决的是从拿到裸芯片到getevent能出数据这一段最烦人的工作适合嵌入式驱动开发、BSP 维护、以及做产品选型评估的工程师。这篇笔记我就按实际拆包和移植的路径把它内部怎么组织、怎么编译、怎么配设备树、有哪些坑一次讲完。2. 驱动包内部结构与 probe 流程先看懂 TP9930 是怎么挂进 input 子系统的2.1 解包后先看文件组成Makefile 和源码文件的职责分布拿到 tp28xx_kdrv_tp9930.tar.gz我习惯先解压到一个干净的目录用tar -tzf看文件清单再决定编译方式。常见的结构是tp9930.c、tp9930.h、Makefile有的版本还带tp9930_fw.h或tp9930_config.h后者一般放固件数组和分辨率宏。mkdir ~/tp9930 cd ~/tp9930 tar -xzf tp28xx_kdrv_tp9930.tar.gz find . -maxdepth 2 -type f | sort先把tp9930.c打开确认它注册的 I2C driver name 是tp9930还是tp28xx这决定了设备树 compatible 字符串怎么填。我遇到过包内 name 和文档不一致的情况以源码为准设备树里的 compatible 必须和of_match_table完全匹配否则内核根本不调用 probe。Makefile通常是单一 obj-m 形式形如obj-m tp9930.o如果你要把驱动编进内核而不是模块需要改成obj-$(CONFIG_TOUCHSCREEN_TP9930)并去 Kconfig 里加对应配置项。这一步虽然简单但直接决定后面make menuconfig时能不能看到这个驱动。2.2 probe 函数里发生了什么I2C 验证、中断申请、input_dev 注册TP9930 是一个 I2C 接口的电容触摸控制芯片内核驱动走的是 input 子系统标准路径。probe 函数的典型顺序是读取client-irq中断号用devm_request_threaded_irq注册一个中断处理函数然后在中断底半部里通过 I2C 读坐标寄存器最后用input_report_abs上报 ABS_MT_POSITION_X / Y。这个流程里最关键的一点是TP9930 支持的是 Type B 多点触摸协议所以要用input_mt_init_slots初始化 slot并在每次上报前调用input_mt_slot和input_mt_report_slot_state。static int tp9930_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct tp9930_ts *ts; struct input_dev *input; int ret; if (!i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) return -EIO; ts devm_kzalloc(client-dev, sizeof(*ts), GFP_KERNEL); input devm_input_allocate_device(client-dev); input-id.bustype BUS_I2C; input-dev.parent client-dev; __set_bit(EV_SYN, input-evbit); __set_bit(EV_ABS, input-evbit); __set_bit(INPUT_PROP_DIRECT, input-propbit); input_set_abs_params(input, ABS_X, 0, ts-x_max, 0, 0); input_set_abs_params(input, ABS_Y, 0, ts-y_max, 0, 0); input_mt_init_slots(input, 5, 0); input_set_drvdata(input, ts); ts-input input; }上面这段是精简后的关键逻辑。ts-x_max和ts-y_max通常从tp9930.h里读厂商默认给的是 1024×600 或 1280×800要根据实际屏幕分辨率核对否则坐标比例会偏。input_mt_init_slots的第二个参数传 5意思是支持 5 点触摸如果 TP9930 实际只支持 2 点这里传 5 也不会出错内核只会浪费一点内存但如果是旧内核slot 数超过芯片能力可能导致 ABS_MT_SLOT 状态错乱。中断号这块如果设备树里没配 interruptsclient-irq拿到的是 0probe 里应该加一个检查否则后面request_threaded_irq会直接失败这类问题在内核 log 里表现为No IRQ错误而且是 probe 直接返回 -EINVAL。2.3 上报坐标的分辨率换算驱动里的坐标不是物理像素TP9930 的坐标寄存器返回值和屏幕物理分辨率往往不是一一对应的。芯片内部有一个固定的采样范围厂商驱动通常在tp9930_read_coords函数里做线性映射。常见的写法是用tp9930_parse_coords解析原始坐标后再根据设备树里的touchscreen-size-x和touchscreen-size-y做归一化。static void tp9930_report_coords(struct tp9930_ts *ts, u16 x_raw, u16 y_raw) { struct input_dev *input ts-input; int x (x_raw * ts-x_max) / TP9930_RAW_MAX; int y (y_raw * ts-y_max) / TP9930_RAW_MAX; input_mt_slot(input, 0); input_mt_report_slot_state(input, MT_TOOL_FINGER, true); input_report_abs(input, ABS_MT_POSITION_X, x); input_report_abs(input, ABS_MT_POSITION_Y, y); input_sync(input); }这段代码里TP9930_RAW_MAX是芯片寄存器能返回的最大原始值一般定义在头文件里。如果你发现触摸点了但光标位置偏到角落先查这个宏是否和芯片手册一致而不是急着改设备树。还有一种情况是面板本身的触控区域有偏移这需要加一个swap-x-y或x-invert的修正逻辑。我看到很多驱动直接把原始值上报不经过归一化这在某些 TP9930 固件版本上会导致触摸区域和显示区域错位。厂商源码包里如果带了tp9930.cfg这类配置文件里面往往能找到分辨率映射的参考值直接抄进去比自己猜靠谱。3. 编译与设备树配置把 TP9930 驱动挂到内核里的完整操作3.1 Kconfig 与 Makefile 对接让 menuconfig 里出现 tp9930 条目如果你是第一次移植建议先把驱动编成模块试试水这样不用反复烧写整个内核镜像。操作分三步把tp9930.c放到drivers/input/touchscreen/目录下面在Kconfig里加一段config TOUCHSCREEN_TP9930再到Makefile里加obj-$(CONFIG_TOUCHSCREEN_TP9930) tp9930.o。cd kernel/drivers/input/touchscreen/ cp ~/tp9930/tp9930.c . vim Kconfig vim Makefile make ARCHarm menuconfigKconfig 里的内容一般是这样的结构tristate 表示可以编成 y/n/m 三种状态depends on 通常写I2C INPUT。我一般会在这个条目后面加一句help描述方便其他人知道这个驱动对应什么芯片。菜单路径是 Device Drivers Input device support Touchscreens进入之后应该能看到TP9930 touchscreen support。如果看不到多半是 Kconfig 的缩进格式不对内核的 Kconfig 对 tab 和空格极其敏感我在这上面浪费过一下午后来学乖了改完 Kconfig 先跑scripts/kconfig检查语法。3.2 设备树节点interrupts、reg、reset-gpios 的取值与写法TP9930 挂在某个 I2C 总线上设备树节点要写在对应的 I2C controller 下面。以 Linux 4.x 内核常见的写法为例i2c2 { tp993038 { compatible tp9930,touch; reg 0x38; pinctrl-names default; pinctrl-0 tp9930_int_pin; interrupts-extended gpio1 13 IRQ_TYPE_EDGE_FALLING; reset-gpios gpio1 12 GPIO_ACTIVE_LOW; touchscreen-size-x 1024; touchscreen-size-y 600; }; };reg 0x38这一项要特别小心。TP9930 的 7 位 I2C 地址是 0x38但有些芯片手册上给的是 8 位地址 0x70写设备树必须以 7 位地址为准否则 I2C core 会按 0x70 去匹配probe 永远不会被调用。interrupts-extended里的IRQ_TYPE_EDGE_FALLING是 TP9930 比较常见的触发方式驱动里如果request_threaded_irq的 flags 和设备树不一致会出现中断风暴或者干脆没中断。reset-gpios不是必须的但如果芯片上电后没有完成自检驱动读寄存器会超时加上这个引脚并在 probe 里做一次拉低再拉高的复位操作能解决很多“偶然不工作”的诡异问题。这里要注意 GPIO 的 flag 是GPIO_ACTIVE_LOW复位逻辑是置低有效。先编译一遍设备树确认没有语法错误再碰驱动。用make dtbs编完以后用dtc工具反编译检查节点是否真的编译进去了make ARCHarm dtbs dtc -I dtb -O dts -o /tmp/check.dts arch/arm/boot/dts/your-board.dtb grep -n tp9930 /tmp/check.dtsdtc反编译这一步很值得做我见过有人设备树写错了但编译通过上电后I2C总线上探测不到任何设备然后开始怀疑驱动代码实际上节点压根没进 dtb。反编译后既能确认节点存在也能顺便看看interrupts-extended里的 phandle 有没有指向正确的 GPIO 控制器。3.3 加载模块与 I2C 探测确认设备地址和 probe 成功与否把编译出来的tp9930.ko推到目标板上insmod 之前先确认 I2C 总线上确实有 TP9930 这个设备。用i2cdetect扫一遍是最直接的i2cdetect -y -r 2 insmod tp9930.ko dmesg | tail -20i2cdetect后面的2是 I2C 总线号对应设备树里的i2c2。如果扫描结果里在38位置出现UU说明已经有驱动占用了如果出现38说明设备在但没有驱动绑定如果什么也没有先检查硬件连接和上电时序别急着加载驱动。insmod 之后立刻看 dmesgprobe 成功一般会打印input: TP9930 touchscreen as /devices/...之类的内容同时/dev/input/eventX会多出来一个节点。这里有个容易踩的细节insmod时如果驱动依赖input子系统但你的内核没把CONFIG_INPUT编译进去insmod 会报 unresolved symbol需要回内核配置里把CONFIG_INPUT打开这不是驱动本身的问题。4. 跨平台移植从参考板到目标板的四项硬性适配4.1 内核 API 版本差异3.10 与 5.4 的 input 上报函数区别移植时能直接编过的概率并不高。如果参考代码是从某个 3.10 内核的 SDK 里拿出来的搬到 5.4 内核上大概率要处理 input 子系统的 API 变化。最简单直接的差异是input_set_abs_params里的参数老内核是input_set_abs_params(input, ABS_MT_POSITION_X, 0, x_max, 0, 0)新内核还兼容这种写法但input_mt_init_slots的返回值从 void 变成了 int旧代码如果写成直接调用而忽略了返回值编译器会报 warning 但不影响编译。真正致命的是struct input_dev的keybit和evbit的位操作方式有些驱动用set_bit(EV_KEY, input-evbit)而 TP9930 的驱动一般只需要ABS不需要KEY但如果你从别的驱动抄了一段可能残留KEY_POWER之类的定义编进内核后行为不可预测。#if LINUX_VERSION_CODE KERNEL_VERSION(4, 0, 0) ret input_mt_init_slots(input, 5, 0); if (ret) { dev_err(client-dev, input_mt_init_slots failed\n); return ret; } #else input_mt_init_slots(input, 5, 0); #endif这种版本宏判断是内核驱动的常规做法但别过度依赖。它解决的是编译期兼容运行期的差异更隐性——比如新内核的devm_request_threaded_irq对 IRQ flags 的校验更严格IRQF_TRIGGER_FALLING这种老宏在某些平台上会被忽略导致中断完全不触发但 dmesg 里没有任何报错。我一般会在 probe 里把client-irq打出来再确认 request 时传入的 flags如果发现差异优先用设备树里的IRQ_TYPE_EDGE_FALLING而不是驱动里的硬编码让 DTB 成为唯一的中断配置来源。4.2 上电时序与复位设计reset 引脚不是摆设TP9930 的上电时序如果不能满足表现非常像“驱动 bug”设备树明明配了节点I2C 探测也偶尔能扫到但 probe 时读芯片 ID 寄存器返回全 0xFF。这时候十有八九是芯片供电或复位时序问题不是软件问题。厂商参考设计里一般会给出power-on之后至少等待 10ms 再拉高 reset 的要求驱动里如果没做延时可以在 probe 里加一段gpiod_set_value_cansleep(ts-reset_gpio, 0); msleep(20); gpiod_set_value_cansleep(ts-reset_gpio, 1); msleep(100);这段逻辑是在 probe 最开始执行一次硬复位给芯片足够时间完成内部固件加载。gpiod_set_value_cansleep用的是 GPIO descriptor 接口对应设备树里的reset-gpios。如果驱动里用的是老的gpio_set_value接口需要拿到 GPIO 号后手动gpio_request但新内核推荐直接走devm_gpiod_get_optional省去释放逻辑。我最开始移植时觉得这个 20ms 和 100ms 是随便给的直到发现某批次芯片需要 150ms 才能稳定响应 I2C 读操作才意识到时序参数不能只看参考驱动要结合具体硬件设计裕量。4.3 坐标旋转与镜像设备树里的三条属性就能解决方向问题TP9930 的屏幕方向不对是很常见的需求产品横竖屏切换、面板出线方向不同都会导致 X/Y 坐标和显示内容镜像。最简单可靠的方案是在驱动里支持设备树的touchscreen-swapped-x-y、touchscreen-x-invert、touchscreen-y-invert三个布尔属性在坐标上报前做一次坐标变换。if (ts-swap_x_y) swap(x, y); if (ts-x_invert) x ts-x_max - x; if (ts-y_invert) y ts-y_max - y;这个变换的逻辑是在归一化之后做的注意先 invert 还是先 swap 会得到不同的效果我是按先 swap 再 invert 的顺序处理的因为这样比较符合“先旋转坐标轴再翻转坐标方向”的直觉。这里有一个坑如果变换顺序写反了180 度旋转的效果会被错误地变成镜像而且视觉上差别很细微——竖屏应用里字符方向不对但触摸响应位置看起来“差不多”特别容易漏掉。设备树里设这三个属性时每次改完要重启并重新校准因为这是个非线性变换不能期望只在 x 方向加一个偏移量就能覆盖所有角度。4.4 固件版本差异为什么同一个驱动在不同批次芯片上表现不同TP9930 芯片出厂时固件版本可能不同有些驱动内部会有固件降级保护——如果芯片固件比驱动要求的版本旧probe 会尝试用内核里内置的固件数组升级芯片。如果你的源码包里没有FW_VERSION相关的头文件那说明这个驱动版本不负责升级固件纯粹当输入设备用。我遇到过一次奇怪现象A 项目上驱动工作正常B 项目拿到同型号芯片probe 报firmware version mismatch然后 touch 功能时好时坏。A 项目的根本原因是旧固件对 5 点触摸的上报协议有 bug偶尔会丢 slot 状态。解决方法是让厂商提供新版固件 bin放到/lib/firmware/下用request_firmware机制加载或者直接把固件数组替换进tp9930_fw.h重新编驱动。这个环节在没有参考文档时比较黑匣子只能多试几个固件版本找到稳定的那个我一般会留一个fw_version的 debugfs 节点方便排查。5. 避坑实录TP9930 驱动调试中的五个典型问题与定位思路5.1 现象一probe 完全不被调用dmesg 里没有任何输出芯片扫描i2cdetect能看到地址但加载驱动后 probe 不执行内核日志干净得像什么都没发生。原因几乎都是of_match_table和id_table里的名字与设备树 compatible 不匹配。有些驱动为了兼容多个 I2C 地址会在i2c_device_id里写通配符tp9930但设备树里写的是tp28xx,tp9930导致匹配失败。解决方法是统一成同一个字符串或者驱动里同时保留of_device_id和i2c_device_id两套表。static const struct of_device_id tp9930_of_match[] { { .compatible tp9930,touch, }, {} }; MODULE_DEVICE_TABLE(of, tp9930_of_match);检查这个问题的标准动作是在 probe 入口加打印然后看dmesg里有没有tp9930_probe字样。如果没打印说明匹配环节就断了对比设备树 compatible 和这个数组里的字符串一个字符都不能差。特别注意MODULE_DEVICE_TABLE宏不能省去掉它会导致设备树方式匹配失效但 I2C 地址方式还能工作这种半残状态最迷惑人。5.2 现象二probe 成功但触摸无响应getevent 没有事件dmesg里显示input: TP9930 touchscreen注册成功/dev/input/event0也存在但getevent没有任何输出。优先排查中断cat /proc/interrupts看 TP9930 对应的中断号有没有计数增加。如果没有大概率是中断触发方式配置错误TP9930 使用边沿触发如果驱动里写的IRQF_TRIGGER_HIGH或设备树里漏了IRQ_TYPE_EDGE_FALLING中断信号来了但内核不认。另一个隐蔽原因是 GPIO 的 pinctrl 配置不对GPIO 被复用成了其他功能导致中断引脚电平一直被拉高或拉低。解决方法是先测量触屏按下时 GPIO 引脚是否有电平跳变如果硬件信号没问题再逐字核对设备树里的interrupts-extended和 pinctrl 节点。5.3 现象三触摸坐标漂移点击位置与实际显示错位触摸和显示错位分两种全屏偏移固定量或者越往边缘偏得越厉害。固定偏移大多是面板贴合精度问题需要做一次触点校准把四个角的实际物理坐标读出来算一个偏移矩阵。边缘非线性偏移则是坐标归一化的问题——回到第 2.3 节提到的TP9930_RAW_MAX如果这个值比实际寄存器最大值大相当于把原始数据压缩到了一个更小的范围边缘坐标自然往中间挤。验证办法是读芯片寄存器在触摸屏幕最边缘时看原始坐标值记录真实的最大值然后改头文件里的宏。改完重新编译驱动通常立竿见影。5.4 现象四升级内核后驱动编译报错posix timer 相关错误内核版本升级后.ko文件必须重新编译这几乎是铁律。把 TP9930 驱动从 3.14 内核移植到 5.10 内核最常见的是input_mt_init_slots返回值检查、struct i2c_client里dev字段访问方式变化以及time_after/jiffies相关宏的兼容性。这类问题本质上是驱动代码使用了未稳定 API解决方法是按新内核的规范改写而不是在编译参数里强行-Wno-error屏蔽。我的血泪经验是先grep一遍源码里所有被#ifdef CONFIG_xxx包裹的片段这些往往是老内核的补丁痕迹大概率在新内核里不再适用。5.5 现象五系统休眠唤醒后触摸失灵恢复需要重新插拔休眠唤醒后触摸屏无响应是 tp9930 这类芯片的常见问题。原因是驱动在 suspend 阶段没有正确关闭中断或 resume 后没有重新初始化芯片。TP9930 在睡眠后内部状态机可能回到初始态需要重新配置分辨率并做一次坐标基准校准。解决方法是注册pm_ops结构体在resume回调里对 TP9930 做一次软复位。static int tp9930_resume(struct device *dev) { struct tp9930_ts *ts dev_get_drvdata(dev); tp9930_reset_chip(ts); enable_irq(ts-irq); return 0; }注意enable_irq之前要先确认中断没有泄漏否则唤醒瞬间中断风暴会吃掉所有 CPU 时间。有些驱动里 suspend 时只做了disable_irq但没保存芯片状态resume 后直接enable_irq结果芯片还没准备好就开始上报垃圾坐标。我一般会加一个 50ms 的延时再 enable_irq并且用mutex保证 suspend/resume 和触摸上报线程不竞争 I2C 总线。6. 事件节点验证法用 Python 脚本确认触摸坐标上报的正确性TP9930 驱动移植完成后用一个脚本验证触摸响应是最快的方式。直接用getevent能看原始事件流但不够直观。我会用 Python 读/dev/input/eventX解析input_event结构体实时打印触摸坐标。import struct import time EV_ABS 3 ABS_MT_POSITION_X 0x35 ABS_MT_POSITION_Y 0x36 ABS_MT_TRACKING_ID 0x39 ABS_MT_SLOT 0x2f fmt llHHi size struct.calcsize(fmt) with open(/dev/input/event1, rb) as f: while True: event f.read(size) if not event: break sec, usec, type, code, value struct.unpack(fmt, event) if type EV_ABS: if code ABS_MT_POSITION_X: print(fX{value}) elif code ABS_MT_POSITION_Y: print(fY{value}) elif code ABS_MT_TRACKING_ID: print(fTrackingID{value})运行这个脚本用一个手指在屏幕上划对角线观察 X 和 Y 数值是否线性变化。如果 X 从 0 到 1023 变化但 Y 始终停在某个范围只抖动不递增说明 Y 轴的数据通路有问题——可能是中断处理里读错了寄存器地址或者坐标换算时把 Y 值当成了某个固定偏移。脚本里 event 节点可能不是event1用getevent -i或者ls /dev/input/确认是哪一个。如果触摸没有任何输出除了中断问题还要检查脚本是否以 root 权限运行某些系统对/dev/input节点做了权限限制。触摸覆盖测试有个简单的办法在屏幕上画一个九宫格每个格子中心点按一下打印出九组坐标看看 X 和 Y 是否均匀分布每组之间的间距是否符合屏幕比例。如果某个格子的坐标明显偏向一边且该格子在多个方向上都偏考虑驱动里的触摸屏校准矩阵是否需要修正。这个验证脚本我会保留在板卡上之后无论升级内核还是更换其他型号触摸芯片都会先跑一遍确保回归通过。从那以后我每次移植 TP9930 都会强制走一遍编译、设备树反编译、事件读取、九宫格验证这四步一次不漏省掉了不少返工折腾。希望这篇笔记里的路径和坑位能帮到你少走点弯路。本文还有配套的精品资源点击获取 
