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

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

[Joel Selvaraj via B4 Relay]

From: Joel Selvaraj <foss@joelselvaraj.com>

The touchscreen properties previously upstreamed was based on downstream
touchscreen driver. We ended up adapting upstream edt_ft5x06 driver to
support the FocalTech FT5452 touchscreen controller used in this device.
Update the touchscreen properties to match with the upstream edt_ft5x06
driver. Also, as mentioned, the touchscreen controller used in this
device is ft5452 and not fts8719. Fix it.

Signed-off-by: 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;
-		interrupt-parent = <&tlmm>;
-		interrupts = <125 IRQ_TYPE_EDGE_FALLING>;
-		vdd-supply = <&vreg_l28a_3p0>;
-		vcc-i2c-supply = <&vreg_l14a_1p88>;
 
-		pinctrl-names = "default", "suspend";
+		interrupts-extended = <&tlmm 125 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
+
+		vcc-supply = <&vreg_l28a_3p0>;
+		iovcc-supply = <&vreg_l14a_1p88>;
+
 		pinctrl-0 = <&ts_int_active &ts_reset_active>;
 		pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>;
+		pinctrl-names = "default", "suspend";
 
-		reset-gpio = <&tlmm 99 GPIO_ACTIVE_HIGH>;
-		irq-gpio = <&tlmm 125 GPIO_TRANSITORY>;
 		touchscreen-size-x = <1080>;
 		touchscreen-size-y = <2160>;
 	};

---
base-commit: 8f7f8b1b3f4c613dd886f53f768f82816b41eaa3
change-id: 20250919-shift-axolotl-fix-touchscreen-dts-afa274c233de

Best regards,
-- 
Joel Selvaraj <foss@joelselvaraj.com>

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

[Konrad Dybcio]

On 9/19/25 11:02 AM, Joel Selvaraj via B4 Relay wrote:
> From: Joel Selvaraj <foss@joelselvaraj.com>
> 
> The touchscreen properties previously upstreamed was based on downstream
> touchscreen driver. We ended up adapting upstream edt_ft5x06 driver to
> support the FocalTech FT5452 touchscreen controller used in this device.
> Update the touchscreen properties to match with the upstream edt_ft5x06
> driver. Also, as mentioned, the touchscreen controller used in this
> device is ft5452 and not fts8719. Fix it.

This is a little difficult to read, breaking the paragraph somewhere
would help.

> 
> Signed-off-by: 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

Konrad

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

[Joel Selvaraj]

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.

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.

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.

Thanks,
Joel Selvaraj


> 
> Konrad
> 

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

[Konrad Dybcio]

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

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

[Joel Selvaraj]

Hi Konrad Dybcio,

On 10/17/25 4:57 AM, Konrad Dybcio wrote:
>>> 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
> 

Yeah. I think I will remove the wakeup-source for now to avoid potential 
battery drain. Once I get more info on wake-gpio/low-power mode and test 
with users that tap-to-wake work as expected, it will be added. For now, 
this is not something expected to be working. Will send a v2 with 
updated commit message.

Thank you,
Joel Selvaraj

> Konrad