The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "François Roux" <info@humanlearning.ch>
To: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: "Harrison van der Byl" <harrison.vanderbyl@gmail.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"François Roux" <info@humanlearning.ch>
Subject: Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs
Date: Tue,  4 Aug 2026 15:05:38 +0200	[thread overview]
Message-ID: <20260804130603.86693-1-info@humanlearning.ch> (raw)

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

                 reply	other threads:[~2026-08-04 13:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260804130603.86693-1-info@humanlearning.ch \
    --to=info@humanlearning.ch \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=harrison.vanderbyl@gmail.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox