Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs

Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs

[François Roux]

Hi,

Reporting a hardware variant rather than sending a patch, because I do
not know how you would want it discriminated and a naive patch would
break the other units.

x1p42100-microsoft-sp12.dts describes the touchscreen as:

	/* ILIT2911 or GTCH1563 */
	touchscreen@16 {
		compatible = "hid-over-i2c";
		reg = <0x16>;
		hid-descr-addr = <0x1>;
		interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
		vddl-supply = <&vreg_l15b_1p8>;
		pinctrl-0 = <&ts0_default>;
		pinctrl-names = "default";
	};

	ts0_default: ts0-default-state {
		int-n-pins   { pins = "gpio51"; ... };
		reset-n-pins { pins = "gpio52"; ... };
	};

My unit has neither of those controllers, and different pins.

What is on this machine
=======================

	hid-over-i2c 04F3:4377 Touchscreen

04F3 is ELAN. It sits at the same address (0x16) on the same bus, but
the interrupt and reset lines differ:

	                  upstream DTS      this unit
	interrupt GPIO    51                38
	reset GPIO        52                48

Both descriptions are internally consistent -- the interrupt property
and the pinctrl state agree with each other in each case -- so this is
not a typo in either. It is a genuinely different board wiring.

The vendor DTB shipped with Windows on this unit uses 38/48, and it
works: touchscreen, pen and multitouch all register. Booting the
upstream DTS on this machine would leave the touchscreen dead, since the
driver would be waiting on a pin the controller does not drive.

The unit also has `wakeup-source` on that node in the vendor DTB, which
upstream does not carry. I have not tested whether it matters, so I
mention it only for completeness.

Machine identification
======================

	sys_vendor       Microsoft Corporation
	product_name     Surface Pro 12in 1st Ed with Snapdragon
	product_sku      Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
	product_version  124I:00125T:000M:0000000F:0B:10C:08M:00D:00U:00T:2R:10
	bios_version     9.166.235
	DT compatible    microsoft,surface-pro-12in / qcom,x1p42100

Note the DT compatible above is from the vendor DTB, which predates the
rename to `microsoft,sp12`.

Why I am not sending a patch
============================

Both variants would advertise the same compatible, and the DTB is
selected before Linux runs, so a second DTS would need something the
bootloader can key on. `product_sku` ends in `2110` here and might be
that discriminator, but I have exactly one unit and no way to confirm it
distinguishes anything.

Changing the GPIOs in place would obviously break whichever units the
current values were written for.

So: how would you like this handled? A separate board DTS, a runtime
quirk, or something else entirely? I am happy to write and test whatever
shape you prefer, and to dump any register or property from this
machine.

Environment: linux-next next-20260626 on Arch Linux ARM (aarch64), with
the vendor DTB rather than the upstream one, for exactly this reason.

Thanks,
François Roux