On 03/07/2024 16:42, neil.armstrong@xxxxxxxxxx wrote:
On 03/07/2024 16:00, Daniel Lezcano wrote:
On 03/07/2024 14:43, neil.armstrong@xxxxxxxxxx wrote:
Hi,
On 03/07/2024 14:25, Daniel Lezcano wrote:
Hi Neil,
it seems there is something wrong with the driver actually.
There can be a moment where the sensor is not yet initialized for
different reason, so reading the temperature fails. The routine will
just retry until the sensor gets ready.
Having these errors seem to me that the sensor for this specific
thermal zone is never ready which may be the root cause of your
issue. The change is spotting this problem IMO.
Probably, but it gets printed every second until system shutdown, but
only for a single thermal_zone.
Using v1 of Rafael's patch makes the message disappear completely.
Yes, because you have probably the thermal zone polling delay set to
zero, thus it fails the first time and does no longer try to set it up
again. The V1 is an incomplete fix.
Very likely the problem is in the sensor platform driver, or in the
thermal zone description in the device tree which describes a non
functional thermal zone.
It was at 0 but the delay was removed recently:
https://lore.kernel.org/all/20240510-topic-msm-polling-cleanup-v2-0-436ca4218da2@xxxxxxxxxx/
Yes, these changes are because another change did:
commit 488164006a281986d95abbc4b26e340c19c4c85b
Author: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
thermal/of: Assume polling-delay(-passive) 0 when absent
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
That doesn't explain it because only the last platforms have this error
message printed.
Let me recap.
It has been reported if a thermal-zone with zero delay fails to
initialize because the sensor returns an error, then there is no more
attempt to initialize it and the thermal zone won't be functional.
The provided fix will periodically read the sensor temperature until
there is a valid temperature. When there is a valid temperature, then
the interrupts are set for the previous and the next temperature
thresholds. That leads to the end of the routine of initializing the
thermal zone and cancels the timer.
The platforms you reported, the delay is zero (before and after the
'polling cleanup').
My hypothesis is the following:
The thermal-zone29 describes a sensor which does not operate.
Before the patch:
First attempt to initialize it, the temperature is invalid, then because
the delay is zero, the routine stops, and there is no more attempts to
initialize it. Nothing will happen to this thermal zone and it will stay
stuck silently. So at this point, the thermal zone is broken and you
don't notice it.
After the patch:
The initialization routine is constantly retrying to init the thermal zone.
-------------------
If you revert the fix and you try to read the thermal zone 29, it should
always fail to return an error.
If I'm correct, then I suggest to identify what thermal zone is 29 (type
file), identify the node name in the DT, find the tsens channel and
double check if it really describes an existing sensor
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
