Phase 3: touchpad, touchscreen and the Ti50 TPM (2026-11-03)

Attempts 2026-11-03-15 (image b5f533fb178c67a2, kernel #13, commit 7bffb22) and 2026-11-03-16 (image bf2dd269aa121412, same kernel, /init from commit a9d7aeb). Owner pick after the retro (2026-11-03): touchpad, touchscreen and TPM. Sources: the netlog dumps/firstboot/2026-11-03-netlog.txt and the AP and EC console logs dumps/firstboot/2026-11-03-{ap,ec}.log (all gitignored), and the pinned tree a804c57.

Why

The retro’s gap check (scripts/dt-kconfig-map.py --gaps, commit 4e1f825) listed hid-over-i2c I2C_HID_OF=m touchscreen@10,touchpad@2c and google,cr50 TCG_TIS_I2C_CR50=m tpm@50. Both drivers are =m in arm64 defconfig and the initramfs loads no modules, so none of the three nodes had ever bound.

Changes (commit 7bffb22)

• kernel/mica-touch.config: I2C_HID_OF, I2C_HID_CORE, HID_MULTITOUCH built in.
• kernel/mica-tpm.config: TCG_TIS_I2C_CR50 built in; TCG_TPM2_HMAC forbidden at =y (it creates a primary key in the null hierarchy at every boot, tpm2-sessions.c:1408-1412). TPM traffic is probe-time startup, self-test and capability reads, and TPM2_Shutdown(CLEAR) at reboot (tpm-chip.c:272).
• Both compatibles left kernel/dt-gaps.txt.
• /init: touch-* captures with a touch window, tpm and hwrng captures; from b6b6662 and a9d7aeb the hid-over-i2c IRQ counts around the window and a 30 s window behind a banner.

TPM: pass (attempt -15)

• cr50_i2c 1-0050: ti50 OT TPM 2.0 (i2c 0x50 irq 177 id 0x5066) at 2.80 s (the driver’s Ti50 name, tpm_tis_i2c_cr50.c:693-702).
• tpm=tpm0 tpmrm0 major=2 driver=cr50_i2c; hwrng lists tpm-rng-0 beside smccc_trng (current).

Touchpad: pass (attempt -16)

• hid-multitouch 0018:27C6:0D4F: Mouse (event0) and Touchpad (event1) on 2-002c, both boots.
• -15: 0 events, but the owner missed the 20 s prompt. -16: touch-events=event1 bytes=373296 events=15554 in the 30 s window; IRQ msmgpio 3 Level hid-over-i2c went 646 to 2888.

Touchscreen: probes on one boot of two, reports never arrive whole

• -15: hid-multitouch 0018:1FD2:5010 bound (event2, and event3 named UNKNOWN, likely a vendor collection; inference); no touch in the missed window.
• -16: the descriptor read at probe came back garbled: hid-generic 0018:FFA5:FFFF.0001: unexpected long global item, probe with driver hid-generic failed with error -22. In the window the IRQ (msmgpio 51) still went 305 to 921, and each report failed i2c_hid_of 0-0010: i2c_hid_get_input: incomplete report (64/106) (i2c-hid-core.c:570-573: 64 is the buffer size from the bad descriptor, 106 the size the panel sent).
• So the panel answers and reports touches; the descriptor read at probe is unreliable (inference: power-on timing). The node matches stock (descriptor address 0, TLMM 51 level-low, L15B and the TLMM 88 3.3 V switch with startup-delay-us = <150000> and regulator-boot-on, overlay entry01 fragments 69 and 75). The 9345’s panel is a different one (descriptor address 1), so it gives no precedent.
• Candidate fix (not tried): post-power-on-delay-ms on touchscreen@10 (i2c-hid-of.c:58-59, :105). Not in the stock tree, so it would be marked unverified (ADR 0004). Judge it over several boots: one good probe in two is the baseline.

Other results on these boots

• compare printed start: cold for both (the retro’s boot_start.py fix works) and no WRONG IMAGE.
• unbound= lists 1dfa000.crypto, the four CPU bandwidth-monitor PMUs, 3d6a000.gmu, aaf0000 and ade0000 clock controllers: the gap list’s leads, as expected.
• SCMI failed on both cold starts (Firmware version 0x0, cpufreq=none): four of the last five cold starts (scmi-2026-11-03.md).

Update: touchscreen attempts -17 to -19 (2026-11-03, 7:32 PM ET)

The -18 dump (i2c_hid_of 0-0010: HID Descriptor:): 1e 00 00 01 a7 03 21 00 24 00 6a 00 25 00 6c 00 22 00 23 00 a5 ff ff ff ff ff ff ff ff ff.

• The first 20 bytes are a valid HID-over-I2C descriptor: length 30, version 1.00, report descriptor 0x3a7 (935) bytes at register 0x21, input register 0x24, wMaxInputLength 0x6a = 106, output 0x25/108, command 0x22, data 0x23.
• From byte 20 the read returns 0xff: vendor a5 ff instead of d2 1f, then ff to the end. The report descriptor read gives 05 0d 09 04 43 and then 0xff (a valid one starts 05 0d 09 04 a1 01).
• The touchpad’s dump on 2-002c (another bus) is clean: ... 2f 00 ... c6 27 4f 0d ... (27C6:0D4F, wMaxInputLength 47).
• So the panel’s descriptor is right and the read loses data partway: the line reads high (0xff) once the device stops driving it (inference). The “64” on -16/-17 was a corrupted wMaxInputLength. The 30-byte read uses the GENI FIFO path (DMA starts at 32 bytes, i2c-qcom-geni.c:528), so SE DMA is not the cause.

-19 at 100 kHz is inconclusive: the probe ran earlier than on any other boot (touchpad at 1.5 s against 3.2 to 5.4 s), and the one silent failure path in i2c-hid is nothing at this address (i2c-hid-core.c:1055, dev_dbg, not enabled). Speed and timing are mixed.

Reverted (commits 9126648, 6d66b05): the 100 kHz bus and the power-on delay, neither shown to help; the DTS traces to stock again. Three boots did not converge, so the touchscreen is parked.

Leads for a later session (inference, untested):

• Stock reaches the panel through Qualcomm’s vendor GENI I2C driver at 400 kHz; mainline’s GENI clock table and transfer handling differ. Compare the SCL timing values (i2c-qcom-geni.c clock table) with a stock-side read.
• Enable i2c-hid-core.c:1055 and the GENI I2C error lines in the next touch boot, so a silent probe failure shows.
• The panel’s own reset or report-enable line (TLMM 89, dts/README.md) and its timing against the first read.

Update: the touchscreen on the wire, attempt -21 (2026-11-03, about 8 PM ET)

Attempt 2026-11-03-21 (kernel #16, commit 778abbf) traced the i2c and qcom_geni_i2c events (kernel/mica-debug.config, debug-tools.md); the probe-time trace is in the netlog.

• Descriptor read clean this time (30 bytes, FIFO path): … 22-00-23-00-d2-1f-10-50-30-50-00-00-00-00 (1FD2:5010, version 0x5030).
• Report descriptor (935 bytes, DMA path): 05-0d-09-04 then ff to the end; hid-generic failed -22.
• Input reports (64-byte reads, the fallback buffer): every one starts 6a-00-10-03-01-48-36-1d-33 (length 106, report ID 0x10), and about half turn to ff after 9 to 12 bytes.
• No controller error: geni-err is empty; the GENI status shows ordinary done interrupts (m_stat=0x08000081).
• Bus setup identical on both touch buses: clk_freq=400000 clk_div=2 t_high=5 t_low=11 t_cycle=22 (i2c-qcom-geni.c:188, the 19.2 MHz table). By the driver’s formula (:180-182) that is about 1.15 µs low and 0.52 µs high, under the I2C Fast-mode minimums (1.3 µs, 0.6 µs); the comment says the firmware adds cycles the formula leaves out (:176-178), so the real timing is unknown (inference). The touchpad tolerates it.
• Reading: the panel answers and starts each reply correctly, then lets the data line float (0xff) at a varying byte, with no error the controller sees. Bus timing that this touch controller does not tolerate fits (inference); -19’s 100 kHz boot was inconclusive and is worth repeating with the trace on.

Update: 100 kHz with the trace, attempt -22 (2026-11-03, 8:14 PM ET)

i2c8 at 100 kHz again (commit 20a1f8a), with tracing and dyndbg on i2c-hid-core.c:1055 and i2c-qcom-geni.c:235-306. The bus came up at 100 kHz (clk_div=7 t_high=10 t_low=12 t_cycle=26), and the touchscreen did not acknowledge its address: geni_i2c a80000.i2c: NACK: target device unresponsive, check its power/reset-ln twice, then i2c_hid_of 0-0010: nothing at this address: -6. That is -19’s silent failure. So the panel answers at 400 kHz (and drops out mid-read) and not at all at 100 kHz: the slower bus made it worse, so “too fast for the panel” does not fit (inference). Reverted (commit 6671f61); the DTS traces to stock again. Parked. Untested leads: the panel’s own enable and reset sequencing before the first read (TLMM 89, the 3.3 V switch on TLMM 88, vreg_l15b), compared with what stock does at boot; and the stock driver’s I2C settings.

Update: panel follower and a full stock comparison, attempt 2026-11-04-1 (2026-11-04, 12:15 AM ET)

Offline first: the touchscreen’s DT matches stock line for line. ts0_default (int-n gpio51; reset-n gpio48 output low; report-enable gpio89 output low), the 3.3 V switch on gpio88 with a 150 ms startup delay, vdd L15B, IRQ_TYPE_LEVEL_LOW, hid-descr-addr 0 (stock entry01-overlay.dts fragment@68 and fragment@75). The bus pins match as well: stock sets bias-pull-up plus qcom,i2c_pull, and mainline’s bias-pull-up = <2200> selects the same TLMM I2C strong pull (pinctrl-msm.c:467, i2c_pull_bit = 13 in pinctrl-x1e80100.c at a804c57).

Attempt 2026-11-04-1 (kernel #18, dts/diag/touch-panel-follower.dtsi, commit 5b9ee4e): panel on the touchscreen node points at the eDP panel, so i2c-hid powers and probes it only after the panel is prepared, as the ChromeOS in-cell boards do (sc7180-trogdor-homestar.dtsi:119). The owner touched the screen during the prompt.

• The link works and changes nothing. The panel came up at 3.95 s and the touchscreen probed after it, at 4.30 s. The 30-byte HID descriptor read cleanly. The 935-byte report descriptor read 05-0d-09-04-43 and then 0xff to the end (unknown main item tag 0x4, -22).
• The interrupt fires and the controller reports. There were 1936 msmgpio 51 interrupts on CPU 0 and 1940 input reads (64 bytes each; the device announces 106). 1549 of them turn to 0xff from byte 5 to 8, while the rest read cleanly (6a-00-10-03-01-b6-47-cc-3a-c6-07-cc-04-00 …). There was no controller error.
• Reading (inference): the controller starts every reply right and then stops driving SDA at a random byte. With the DT, pins and pull-ups as stock and the panel timing ruled out, what is left is the controller side: the GENI SCL timing (19.2 MHz table: t_low ≈ 1.15 µs, t_high ≈ 0.52 µs by the formula, under the Fast-mode minimums, i2c-qcom-geni.c:174-188) or clock stretching that the controller does not honour. Stock runs a vendor GENI driver whose timing cannot be read from the image. -22’s 100 kHz NACK does not fit timing alone.
• The fragment stays until the owner decides (status: failed for the probe; the link itself is harmless).

Update: in-spec GENI timing, attempt 2026-11-04-2 (2026-11-04, 12:26 AM ET)

kernel/patches/0008 (kernel #19) set the GENI 400 kHz entry to 2/6/13/24, and the trace confirms it on both touch buses (geni_i2c_bus_setup: a80000.i2c: … t_high=6 t_low=13 t_cycle=24, the same on b80000.i2c). No panel follower. No change: the touchscreen’s HID descriptor read FFFF:FFFF this time (-22), 608 of 773 reads ended in 0xff, and there was one NACK: target device unresponsive. The touchpad (27C6:0D4F) and the TPM worked at the new timing. SCL timing is ruled out (within the formula’s view of it). The touchscreen is parked again. Every setting readable from the stock tree matches; what is left is the vendor GENI driver’s behaviour, or the panel controller’s own state. The patch goes (a failed diagnostic, ADR 0007), as does dts/diag/touch-panel-follower.dtsi.