All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Heiner Kallweit <heiner.kallweit@web.de>
Cc: linux-pm@vger.kernel.org
Subject: Re: [PATCH v3] imx: thermal: imx_get_temp might be called before sensor clock is prepared
Date: Fri, 7 Nov 2014 19:47:10 -0400	[thread overview]
Message-ID: <20141107234707.GB27665@developer> (raw)
In-Reply-To: <545D4B03.6080400@web.de>

[-- Attachment #1: Type: text/plain, Size: 5408 bytes --]

Heiner,

On Fri, Nov 07, 2014 at 11:43:15PM +0100, Heiner Kallweit wrote:
> Am 07.11.2014 um 19:18 schrieb Eduardo Valentin:
> > 
> > Hello Heiner,
> > 
> > On Mon, Oct 13, 2014 at 10:51:23PM +0200, Heiner Kallweit wrote:
> >> imx_get_temp might be called before the sensor clock is prepared
> >> thus resulting in a timeout of the first attempt to read temp:
> >> thermal thermal_zone0: failed to read out thermal zone 0
> >> Happened to me on a Utilite Standard with IMX6 Dual SoC.
> >>
> >> Reason is that in imx_thermal_probe thermal_zone_device_register
> >> is called before the sensor clock is prepared.
> >> thermal_zone_device_register however calls
> >> thermal_zone_device_update which eventually calls imx_get_temp.
> >>
> >> Fix this by preparing the clock before calling
> >> thermal_zone_device_register.
> >>
> >> Signed-off-by: Heiner Kallweit <heiner.kallweit@web.de>
> >> ---
> >> v2: revised error path. Bail out and tidy up properly if we can't
> >>     get the clock or fail to enable it
> >> v3: don't print error message if getting clock returns EPROBE_DEFER
> >> ---
> >>  drivers/thermal/imx_thermal.c | 41 +++++++++++++++++++++++++----------------
> >>  1 file changed, 25 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> >> index 461bf3d..0e8ef55 100644
> >> --- a/drivers/thermal/imx_thermal.c
> >> +++ b/drivers/thermal/imx_thermal.c
> >> @@ -521,6 +521,30 @@ static int imx_thermal_probe(struct platform_device *pdev)
> >>                 return ret;
> >>         }
> >>
> >> +       data->thermal_clk = devm_clk_get(&pdev->dev, NULL);
> >> +       if (IS_ERR(data->thermal_clk)) {
> >> +               ret = PTR_ERR(data->thermal_clk);
> >> +               if (ret != -EPROBE_DEFER)
> >> +                       dev_err(&pdev->dev,
> >> +                               "failed to get thermal clk: %d\n", ret);
> >> +               cpufreq_cooling_unregister(data->cdev);
> >> +               return ret;
> >> +       }
> >> +
> >> +       /*
> >> +        * Thermal sensor needs clk on to get correct value, normally
> >> +        * we should enable its clk before taking measurement and disable
> >> +        * clk after measurement is done, but if alarm function is enabled,
> >> +        * hardware will auto measure the temperature periodically, so we
> >> +        * need to keep the clk always on for alarm function.
> >> +        */
> >> +       ret = clk_prepare_enable(data->thermal_clk);
> >> +       if (ret) {
> >> +               dev_err(&pdev->dev, "failed to enable thermal clk: %d\n", ret);
> >> +               cpufreq_cooling_unregister(data->cdev);
> >> +               return ret;
> >> +       }
> >> +
> >>         data->tz = thermal_zone_device_register("imx_thermal_zone",
> >>                                                 IMX_TRIP_NUM,
> >>                                                 BIT(IMX_TRIP_PASSIVE), data,
> >> @@ -531,26 +555,11 @@ static int imx_thermal_probe(struct platform_device *pdev)
> >>                 ret = PTR_ERR(data->tz);
> >>                 dev_err(&pdev->dev,
> >>                         "failed to register thermal zone device %d\n", ret);
> >> +               clk_disable_unprepare(data->thermal_clk);
> >>                 cpufreq_cooling_unregister(data->cdev);
> >>                 return ret;
> >>         }
> >>
> >> -       data->thermal_clk = devm_clk_get(&pdev->dev, NULL);
> >> -       if (IS_ERR(data->thermal_clk)) {
> >> -               dev_warn(&pdev->dev, "failed to get thermal clk!\n");
> >> -       } else {
> >> -               /*
> >> -                * Thermal sensor needs clk on to get correct value, normally
> >> -                * we should enable its clk before taking measurement and disable
> >> -                * clk after measurement is done, but if alarm function is enabled,
> >> -                * hardware will auto measure the temperature periodically, so we
> >> -                * need to keep the clk always on for alarm function.
> >> -                */
> >> -               ret = clk_prepare_enable(data->thermal_clk);
> >> -               if (ret)
> >> -                       dev_warn(&pdev->dev, "failed to enable thermal clk: %d\n", ret);
> >> -       }
> >> -
> >>         /* Enable measurements at ~ 10 Hz */
> >>         regmap_write(map, TEMPSENSE1 + REG_CLR, TEMPSENSE1_MEASURE_FREQ);
> >>         measure_freq = DIV_ROUND_UP(32768, 10); /* 10 Hz */
> > 
> > 
> > While here, do you need to move up also the configuration of the
> > measurements at ~ 10 Hz? Or would still the first readings be correct
> > while at the reset value?
> When imx_get_temp is called from thermal_zone_device_register data->mode still is
> THERMAL_DEVICE_DISABLED. imx_get_temp therefore will power on the sensor and
> trigger a single measurement.
> IMHO this is fully ok and I don't think we have to relocate the setup of the
> scheduled measurements.


OK. I see. 

In this case, can you please re-post this patch on top of my -fixes
patches? I am planing to send it in the -rc cycles.

I've just merged another fix on imx driver and looks like your
patch needs refreshing now. 


Thanks,

Eduardo Valentin

> > 
> > Cheers,
> > 
> > Eduardo Valentin
> >> --
> >> 2.1.2
> Rgds, Heiner
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2014-11-07 23:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-13 20:51 [PATCH v3] imx: thermal: imx_get_temp might be called before sensor clock is prepared Heiner Kallweit
2014-11-07 18:18 ` Eduardo Valentin
2014-11-07 22:43   ` Heiner Kallweit
2014-11-07 23:47     ` Eduardo Valentin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-08 17:17 Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141107234707.GB27665@developer \
    --to=edubezval@gmail.com \
    --cc=heiner.kallweit@web.de \
    --cc=linux-pm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.