linux-kernel - Re: [PATCH 2/2] arm64: dts: qcom: sc8280xp-x13s: Fix/enable touchscreen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 26 Jan 2024 17:23:30 +0100
From: Johan Hovold <johan@...nel.org>
To: Bjorn Andersson <quic_bjorande@...cinc.com>
Cc: Daniel Thompson <daniel.thompson@...aro.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Johan Hovold <johan+linaro@...nel.org>,
	linux-arm-msm@...r.kernel.org, linux-input@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Konrad Dybcio <konrad.dybcio@...ainline.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sc8280xp-x13s: Fix/enable
 touchscreen

On Fri, Jan 26, 2024 at 06:53:46AM -0800, Bjorn Andersson wrote:
> On Fri, Jan 26, 2024 at 03:31:02PM +0100, Johan Hovold wrote:
> > On Fri, Jan 26, 2024 at 01:02:32PM +0000, Daniel Thompson wrote:

> > > In short it looks like the delays make the difference and, even a short
> > > delay, can fix the problem.
> > 
> > Right, but since the suppliers are left enabled by the bootloader (and
> > never disabled by the kernel), that only begs the question of why this
> > makes a difference.
> 
> You're right, the supply is kept on by other things, so this isn't the
> problem.
> 
> > Without the delay, the other HID devices are probing (successfully)
> > slightly before, but essentially in parallel with the touchscreen while
> > using the same resources. Is that causing trouble somehow?
> 
> The difference to those other HID devices is GPIO 99 - the reset pin,
> which is configured pull down input from boot - i.e. the chip is held in
> reset.
> 
> When the HID device is being probed, pinctrl applies &ts0_default starts
> driving it high, bringing the device out of reset. But insufficient time
> is given for the chip to come up so the I2C read fails.

Ah, that's it.

You should drop that 'output-high' from the pin config as part of this
patch to avoid toggling the reset line twice at boot.

Looks like we have the same problem on the CRD as well. There the
touchscreen still works, possibly because it has been enabled by the
boot firmware or simply because that touchscreen can handle a shorter
delay.

Where exactly did you find those delay values in the ACPI tables? I
couldn't seem to find anything in the decompiled DSDT.

> If you later try to probe again, 200ms has elapsed since the reset was
> deasserted (driven high).

Right.

Johan