[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <267eb29d-b506-43df-9380-3d79798c772c@joelselvaraj.com>
Date: Fri, 17 Oct 2025 07:13:15 +0000
From: Joel Selvaraj <foss@...lselvaraj.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sdm845-shift-axolotl: fix touchscreen properties
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@...lselvaraj.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
>
Powered by blists - more mailing lists