Hi Oleksij,

On Thu, 11 Nov 2021 at 10:16, Oleksij Rempel [off-list ref] wrote:

On Wed, Nov 10, 2021 at 11:07:31AM +0100, Michal Vokáč wrote:

quoted

On 25. 10. 21 13:06, Petr Benes wrote:

quoted

Hi Oleksij,

On Thu, 21 Oct 2021 at 19:21, Oleksij Rempel [off-list ref] wrote:

quoted

Hi Petr,

On Wed, Oct 20, 2021 at 05:53:03PM +0200, Petr Benes wrote:

quoted

On Wed, 20 Oct 2021 at 07:05, Oleksij Rempel [off-list ref] wrote:

quoted

Hi Petr and Michal,

I forgot to add you for v2 in CC. Please test/review this version.

Hi Oleksij,

It works good. with PM as well as without PM. The only minor issue I found is,
that the first temperature reading (when the driver probes) fails. That is
(val & soc_data->temp_valid_mask) == 0) holds true. How does
pm_runtime_resume_and_get() behave in imx_thermal_probe()?
Does it go through imx_thermal_runtime_resume() with usleep_range()?

How exactly did you reproduce it? Even more or less understanding how

I just placed my debug print into get_temp()

     if ((val & soc_data->temp_valid_mask) == 0) {
         dev_dbg(&tz->device, "temp measurement never finished\n");
         printk("Wrong temperature reading!!!!!!\n");
         return -EAGAIN;
     }

quoted

this can potentially happen, i never had this issue on my HW. Is it something
HW specific?

IMHO it is just product of the following sequence:

pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(data->dev);
pm_runtime_resume_and_get(data->dev);
thermal_zone_device_enable(data->tz);

With assumption imx_thermal_runtime_resume() didn't run,
hence the sensor didn't get enough time to come up.

I didn't have time to spend it on and you have better knowledge of the
area. If it is not that straightforward I can try to diagnose it better.

Hi Oleksij,
Did you manage to further debug and reproduce this problem?
Do you plan to send the v3?

Regarding your question about the HW - this problem occured once we
upgraded the SoC on our SBC from i.MX6DL to i.MX6Q/QP. With the DualLite
we never had this problem but the Quad is getting hot quite fast.
We have pretty limited cooling options so the core is operated at its
upper temperature limits when fully loaded.

Hi Michal,

Sorry, I was busy and lost this topic from my radar. I was not able to
reproduce it on my i.MX6Q and i.MX6QP died after other thermal voltage
experiments. Please, if you able to reproduce it, try to investigate
what is wrong, for example increasing wakeup time and/or and tracing
sleap/wake/get sequences.

Seems it is just as easy as calling usleep_range(20, 50) when you switch on
the sensor and enable temperature measurement in imx_thermal_probe().
So, we are sure the sensor is configured and _ready_.

You call pm_runtime_set_active(), pm_runtime_enable(), and
pm_runtime_resume_and_get(). The last one doesn't call the resume
callback (which correctly handles waiting for the sensor) as the device
is already active.

On some SoCs the timing leads to a failure of the temperature readout
in thermal_zone_device_enable() which follows. I've seen it on i.MX6DL,
but cannot reproduce it on i.MX6QP for example.

Regards,
Petr

Regards,
Oleksij
--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |