From: Ulf Hansson <ulf.hansson@linaro.org> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>, "Zhang Rui" <rui.zhang@intel.com>, "Eduardo Valentin" <edubezval@gmail.com>, Linux-SH <linux-sh@vger.kernel.org>, Linux-Kernel <linux-kernel@vger.kernel.org>, "Linux PM list" <linux-pm@vger.kernel.org>, "Cao Minh Hiep" <cm-hiep@jinso.co.jp>, Dung:人ソ <nv-dung@jinso.co.jp> Subject: Re: [PATCH 2/2] thermal: rcar_thermal: use pm_runtime_put_sync() Date: Tue, 10 Nov 2015 09:57:26 +0000 [thread overview] Message-ID: <CAPDyKFqW=PEiijHN8cPaLK8oPRn9WdAYsLug1dbMpitKmNNKjw@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdWSMsVZYF2jswCoRB217n_3OR8uikNtBYOfQHkQs3oWSA@mail.gmail.com> On 10 November 2015 at 09:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Morimoto-san, Ulf, > > On Tue, Nov 10, 2015 at 3:12 AM, Kuninori Morimoto > <kuninori.morimoto.gx@renesas.com> wrote: >> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> >> >> It is using pm_runtime_get_sync() on probe(). Let's use >> pm_runtime_put_sync() instead of pm_runtime_put(). Otherwise thermal >> sensor doesn't work after unbind/re-bind >> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> >> --- >> drivers/thermal/rcar_thermal.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c >> index 13d01ed..f7cf2d7 100644 >> --- a/drivers/thermal/rcar_thermal.c >> +++ b/drivers/thermal/rcar_thermal.c >> @@ -373,7 +373,7 @@ static int rcar_thermal_remove(struct platform_device *pdev) >> thermal_zone_device_unregister(priv->zone); >> } >> >> - pm_runtime_put(dev); >> + pm_runtime_put_sync(dev); >> pm_runtime_disable(dev); For the reasons explained by Geert, this is to me also a "workaround". I would replace pm_runtime_put() and pm_runtime_disable() with a call to pm_runtime_force_suspend(). In that way, you will make sure you device get runtime suspended (clock domain will gate the clock). Additionally, the runtime PM status will properly reflect the status of the device. >> >> return 0; > > While I can confirm this fixes the issue, I think this is a bug in the PM > core, and thus your patch is merely a workaround. > > Morimoto-san: I assume this is a recent regression. Have you tried to bisect? > > With a bit more debugging info, this is the difference between the failing > and the "fixed" cases: > > unbind: > > +rcar_thermal e61f0000.thermal: pm_clk_suspend() > +renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal OFF > rcar_thermal e61f0000.thermal: removing from PM domain clock-controller > pm_genpd_remove_device: Remove e61f0000.thermal from clock-controller > -renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal OFF > > bind: > > rcar_thermal e61f0000.thermal: adding to PM domain clock-controller > __pm_genpd_add_device: Add e61f0000.thermal to clock-controller > rcar_thermal e61f0000.thermal: Clock thermal con_id (null) managed by > runtime PM. > -rcar_thermal e61f0000.thermal: thermal sensor was broken > +rcar_thermal e61f0000.thermal: pm_clk_resume() > +renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal ON > rcar_thermal e61f0000.thermal: 1 sensor probed > > In the failing case, pm_clk_suspend() is not called, and turning off the > module clock is thus delayed until removal of the device from the clock > domain. > But as pm_clk_suspend() wasn't called, the device isn't correctly resumed on > rebind, and the module clock is never re-enabled, leading to a failure. > > Ulf, what do you think? I totally agree on your analyse. The problem is that the runtime PM status of the device isn't correctly updated at ->remove(). The effect is that the the pm_runtime_get_sync() in ->probe() at re-bind will *not* trigger the ->runtime_resume() callbacks to be invoked, as the runtime PM core believes the device is already runtime resumed. Kind regards Uffe
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>, "Zhang Rui" <rui.zhang@intel.com>, "Eduardo Valentin" <edubezval@gmail.com>, Linux-SH <linux-sh@vger.kernel.org>, Linux-Kernel <linux-kernel@vger.kernel.org>, "Linux PM list" <linux-pm@vger.kernel.org>, "Cao Minh Hiep" <cm-hiep@jinso.co.jp>, Dung:人ソ <nv-dung@jinso.co.jp> Subject: Re: [PATCH 2/2] thermal: rcar_thermal: use pm_runtime_put_sync() Date: Tue, 10 Nov 2015 10:57:26 +0100 [thread overview] Message-ID: <CAPDyKFqW=PEiijHN8cPaLK8oPRn9WdAYsLug1dbMpitKmNNKjw@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdWSMsVZYF2jswCoRB217n_3OR8uikNtBYOfQHkQs3oWSA@mail.gmail.com> On 10 November 2015 at 09:18, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Morimoto-san, Ulf, > > On Tue, Nov 10, 2015 at 3:12 AM, Kuninori Morimoto > <kuninori.morimoto.gx@renesas.com> wrote: >> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> >> >> It is using pm_runtime_get_sync() on probe(). Let's use >> pm_runtime_put_sync() instead of pm_runtime_put(). Otherwise thermal >> sensor doesn't work after unbind/re-bind >> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> >> --- >> drivers/thermal/rcar_thermal.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c >> index 13d01ed..f7cf2d7 100644 >> --- a/drivers/thermal/rcar_thermal.c >> +++ b/drivers/thermal/rcar_thermal.c >> @@ -373,7 +373,7 @@ static int rcar_thermal_remove(struct platform_device *pdev) >> thermal_zone_device_unregister(priv->zone); >> } >> >> - pm_runtime_put(dev); >> + pm_runtime_put_sync(dev); >> pm_runtime_disable(dev); For the reasons explained by Geert, this is to me also a "workaround". I would replace pm_runtime_put() and pm_runtime_disable() with a call to pm_runtime_force_suspend(). In that way, you will make sure you device get runtime suspended (clock domain will gate the clock). Additionally, the runtime PM status will properly reflect the status of the device. >> >> return 0; > > While I can confirm this fixes the issue, I think this is a bug in the PM > core, and thus your patch is merely a workaround. > > Morimoto-san: I assume this is a recent regression. Have you tried to bisect? > > With a bit more debugging info, this is the difference between the failing > and the "fixed" cases: > > unbind: > > +rcar_thermal e61f0000.thermal: pm_clk_suspend() > +renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal OFF > rcar_thermal e61f0000.thermal: removing from PM domain clock-controller > pm_genpd_remove_device: Remove e61f0000.thermal from clock-controller > -renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal OFF > > bind: > > rcar_thermal e61f0000.thermal: adding to PM domain clock-controller > __pm_genpd_add_device: Add e61f0000.thermal to clock-controller > rcar_thermal e61f0000.thermal: Clock thermal con_id (null) managed by > runtime PM. > -rcar_thermal e61f0000.thermal: thermal sensor was broken > +rcar_thermal e61f0000.thermal: pm_clk_resume() > +renesas-cpg-mssr e6150000.clock-controller: MSTP 522/thermal ON > rcar_thermal e61f0000.thermal: 1 sensor probed > > In the failing case, pm_clk_suspend() is not called, and turning off the > module clock is thus delayed until removal of the device from the clock > domain. > But as pm_clk_suspend() wasn't called, the device isn't correctly resumed on > rebind, and the module clock is never re-enabled, leading to a failure. > > Ulf, what do you think? I totally agree on your analyse. The problem is that the runtime PM status of the device isn't correctly updated at ->remove(). The effect is that the the pm_runtime_get_sync() in ->probe() at re-bind will *not* trigger the ->runtime_resume() callbacks to be invoked, as the runtime PM core believes the device is already runtime resumed. Kind regards Uffe
next prev parent reply other threads:[~2015-11-10 9:57 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <87h9kulkfg.wl%kuninori.morimoto.gx@renesas.com> 2015-11-10 2:11 ` [PATCH 0/2] thermal: rcar_thermal: tidyup rebind issue Kuninori Morimoto 2015-11-10 2:11 ` Kuninori Morimoto 2015-11-10 2:12 ` [PATCH 1/2] thermal: rcar_thermal: remove redundant operation Kuninori Morimoto 2015-11-10 2:12 ` Kuninori Morimoto 2015-11-13 14:50 ` Ulf Hansson 2015-11-13 14:50 ` Ulf Hansson 2015-11-16 18:42 ` Eduardo Valentin 2015-11-16 18:42 ` Eduardo Valentin 2015-11-10 2:12 ` [PATCH 2/2] thermal: rcar_thermal: use pm_runtime_put_sync() Kuninori Morimoto 2015-11-10 2:12 ` Kuninori Morimoto 2015-11-10 8:18 ` Geert Uytterhoeven 2015-11-10 8:18 ` Geert Uytterhoeven 2015-11-10 9:57 ` Ulf Hansson [this message] 2015-11-10 9:57 ` Ulf Hansson 2015-11-10 10:10 ` Geert Uytterhoeven 2015-11-10 10:10 ` Geert Uytterhoeven 2015-11-10 13:00 ` Ulf Hansson 2015-11-10 13:00 ` Ulf Hansson 2015-11-10 18:30 ` Eduardo Valentin 2015-11-10 18:30 ` Eduardo Valentin 2015-11-10 23:42 ` Rafael J. Wysocki 2015-11-11 0:11 ` Rafael J. Wysocki 2015-11-10 23:57 ` Rafael J. Wysocki 2015-11-10 23:57 ` Rafael J. Wysocki 2015-11-11 11:03 ` Ulf Hansson 2015-11-11 11:03 ` Ulf Hansson 2015-11-12 0:37 ` Rafael J. Wysocki 2015-11-12 1:06 ` Rafael J. Wysocki 2015-11-12 8:04 ` Ulf Hansson 2015-11-12 8:04 ` Ulf Hansson 2015-11-12 18:43 ` Eduardo Valentin 2015-11-12 18:43 ` Eduardo Valentin 2015-11-13 15:06 ` Ulf Hansson 2015-11-13 15:06 ` Ulf Hansson 2015-11-11 2:41 ` Kuninori Morimoto 2015-11-10 2:18 ` [PATCH 0/2] thermal: rcar_thermal: tidyup rebind issue Kuninori Morimoto 2015-11-10 2:18 ` Kuninori Morimoto 2015-11-10 2:27 ` Nguyen Viet Dung 2015-11-10 2:27 ` Nguyen Viet Dung 2015-11-10 5:15 ` Nguyen Viet Dung 2015-11-10 5:15 ` Nguyen Viet Dung [not found] ` <56499E53.2050905@jinso.co.jp> 2015-11-16 21:12 ` PM: after suspend/resume the system,can not suspends again Ulf Hansson 2015-11-16 21:12 ` Ulf Hansson 2015-11-17 1:35 ` Cao Minh Hiep 2015-11-17 1:35 ` Cao Minh Hiep
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='CAPDyKFqW=PEiijHN8cPaLK8oPRn9WdAYsLug1dbMpitKmNNKjw@mail.gmail.com' \ --to=ulf.hansson@linaro.org \ --cc=cm-hiep@jinso.co.jp \ --cc=edubezval@gmail.com \ --cc=geert@linux-m68k.org \ --cc=kuninori.morimoto.gx@renesas.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=nv-dung@jinso.co.jp \ --cc=rui.zhang@intel.com \ /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: linkBe 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.