Re: [PATCH] arm64: dts: qcom: sdm845-shift-axolotl: fix touchscreen properties

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/17/25 9:13 AM, Joel Selvaraj wrote:
> Hi Konrad Dybcio,
> 
> On 10/6/25 9:49 AM, Konrad Dybcio wrote:
>> On 9/19/25 11:02 AM, Joel Selvaraj via B4 Relay wrote:
>>> From: Joel Selvaraj <foss@joelselvaraj.com>
>>> ---
>>>   arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts | 17 ++++++++---------
>>>   1 file changed, 8 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts b/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
>>> index 89260fce6513937224f76a94e1833a5a8d59faa4..d4062844234e33b0d501bcb7d0b6d5386c822937 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
>>> @@ -434,20 +434,19 @@ &i2c5 {
>>>   	status = "okay";
>>>
>>>   	touchscreen@38 {
>>> -		compatible = "focaltech,fts8719";
>>> +		compatible = "focaltech,ft5452";
>>>   		reg = <0x38>;
>>> -		wakeup-source;
>>
>> All the changes look good given your commit message, but you dropped
>> this wakeup-source property without explanation. It's fine to do so
>> if it's intended, but please mention it if so
> 
> In reference to the touchscreen/edt-ft5x06.c driver which is used here, 
> I am bit confused how wakeup-source works. Does specifying wakeup-source 
> in dts automatically makes "device_may_wakeup(dev)" return true, even if 
> device_init_wakeup is NOT configured in the driver? I noticed some 
> drivers do:
> 
> device_init_wakeup(dev,device_property_read_bool(dev, "wakeup-source"));
> 
> but the edt-ft5x06 driver doesnt do the init, but directly checks for 
> may_wakeup in suspend/resume.
> 
> Few scenarios based on the driver code and my understanding:
> 1. if device_may_wakeup will return true when wakeup-source is 
> specified, I probably want to just remove it, because irq and regulator 
> is not disabled during suspend and this will likely cause power drain.

I think this may be the case

> 2. The driver has an option to specify wake-gpio. In which case, the 
> touchscreen is put in some low power hibernate mode with irq and 
> regulators still enabled. But the touchscreen controller used in this 
> device doesn't seem to have support for a wake-gpio (atleast based on 
> downstream code). So that is not an option.

IIRC Shift was pretty open about development collaboration.. maybe you
could reach out to them to confirm on schematics that the GPIO is
absent?

> 3. if device_may_wakeup will always return false since 
> device_init_wakeup is not configured and since no wake-gpio is 
> available, the irq and regulators will be disabled during suspend. 
> Therefore, the device will not wake up from sleep even if wakeup-source 
> is specified as the irq is not going to be triggered.
> 
> So probably no point in specifying wakeup-source either way I think? But 
> I am not sure which of these explanation is correct and thus not sure 
> what to mention in the v2 patch commit message. Also, there is a 
> possibility I am not understanding something. A little help from someone 
> will be very nice and sorry if I am obviously missing something.

I think this is intended for things like double-tap-to-wake, which
obviously need some hw backing if you don't want to just keep the
touchscreen online at "full power" 24/7

Konrad