记一次高通平台触摸屏失效分析

现象

高通sm6375平台某次亮屏以后触摸屏失效，再次灭屏亮屏让TP重新reset后依然无法恢复

Log分析

TP的resume打印出来的Log并无异常

[  209.238676] [2023-01-07 14:56:42.463548739].(7)[341:crtc_commit:78][NVT-ts] nvt_drm_panel_notifier_callback 2494: drm event=1, *blank=0
[  209.239118] [2023-01-07 14:56:42.463989364].(7)[364:kworker/u16:8][NVT-ts] nvt_ts_resume 2422: start
[  209.239125] [2023-01-07 14:56:42.463997750].(7)[364:kworker/u16:8][NVT-ts] update_firmware_request 341: filename is novatek_ts_fw_sentry.bin
[  209.242449] [2023-01-07 14:56:42.467320250].(7)[364:kworker/u16:8][NVT-ts] nvt_get_fw_need_write_size 65: fw_need_write_size = 131072(0x20000), NVT end flag
[  209.242456] [2023-01-07 14:56:42.467329104].(7)[364:kworker/u16:8][NVT-ts] nvt_bin_header_parser 164: cascade_2nd_header_info = 0
[  209.242459] [2023-01-07 14:56:42.467331916].(7)[364:kworker/u16:8][NVT-ts] nvt_bin_header_parser 196: ovly_info = 0, ilm_dlm_num = 2, ovly_sec_num = 0, info_sec_num = 13, partition = 15
[  209.250607] [2023-01-07 14:56:42.475478271].(7)[364:kworker/u16:8][NVT-ts] nvt_bootloader_reset 524: end

[  209.344806] [2023-01-07 14:56:42.569672958].(5)[364:kworker/u16:8][NVT-ts] nvt_update_firmware 1022: Update firmware success! <102328 us>
[  209.344999] [2023-01-07 14:56:42.569868062].(5)[364:kworker/u16:8][NVT-ts] nvt_get_fw_info 697: fw_ver=0x03, fw_type=0x01, PID=0x5112

[  209.355558] [2023-01-07 14:56:42.580424781].(3)[364:kworker/u16:8][NVT-ts] nvt_ts_resume 2454: end 

 抓Dump分析

• 保证机器是处于亮屏状态，即TP是处于跑完resume后的状态，长按power键触发ramdump
• 使用QSPT将dump抓出

使用linux-ramdump-parser-v2解析dump 

• 将符号表vmlinux,和dump文件放在一起
• python3 ramparse.py --vmlinux ./Port_COM12/vmlinux  --auto-dump ./Port_COM12 --force-hardware blair -o ./out --everything

查看解析出来的out目录下的tasks.txt

查看TP的中断函数，可以看到在调度出去之前是没有拿锁的

=======================================================
Process: irq/263-NVT-ts, [affinity: 0xffffffff] cpu: 3 pid: 355 start: 0xffffff82570f5e80
=====================================================
    Task name: irq/263-NVT-ts [affinity: 0xffffffff] pid: 355 cpu: 3 prio: 49 start: ffffff82570f5e80
    state: 0x1[S] exit_state: 0x0 stack base: 0xffffffc017fb0000
    Last_enqueued_ts:   26101.960225979 Last_sleep_ts:   26101.960375041
    Stack:
    [] __switch_to+0x304
    [] __schedule+0x5e0
    [] schedule+0x8c
    [] irq_thread$86dde301a0893ea166114b7ba122cbc9+0x154
    [] kthread$bdfae7274f17a094019e62b74615f335+0x16c
    [] ret_from_fork+0x10

同样查看TP的中断后起的work，可以看到在调度出去之前是没有拿锁的,通过这两点可以确认TP失效不是死锁造成的

=======================================================
Process: nvt_wq, [affinity: 0xff] cpu: 5 pid: 357 start: 0xffffff82570f0fc0
=====================================================
    Task name: nvt_wq [affinity: 0xff] pid: 357 cpu: 5 prio: 100 start: ffffff82570f0fc0
    state: 0x402[D] exit_state: 0x0 stack base: 0xffffffc017fc0000
    Last_enqueued_ts:       1.470344686 Last_sleep_ts:       1.470350154
    Stack:
    [] __switch_to+0x304
    [] __schedule+0x5e0
    [] schedule+0x8c
    [] rescuer_thread$f31e2447a3fdcb60f4b193f95acd647c[jt]+0x84
    [] kthread$bdfae7274f17a094019e62b74615f335+0x16c
    [] ret_from_fork+0x10

使用Trace32分析

• 运行out目录下的launch_t32.sh打开trace32
• 在B::task.dtask这个窗口根据前面的task.txt找到TP中断处理函数的pid:355
• 选择这项右键在弹出的菜单选择Switch Context
• 在最下面的命令输入框输入v.f 然后回车
• 把Args Locals Caller全部勾选上
• 这个irq的desc里面包含了depth这个变量，1说明tp的irq是disable的，dump是亮屏的时候抓的，这时TP要工作irq要处于enable的状态