From: Kevin Hilman <khilman@baylibre.com> To: Ulf Hansson <ulf.hansson@linaro.org> Cc: Lina Iyer <lina.iyer@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Andy Gross <andy.gross@linaro.org>, Stephen Boyd <sboyd@codeaurora.org>, "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>, Brendan Jackman <brendan.jackman@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Juri Lelli <Juri.Lelli@arm.com> Subject: Re: [PATCH V5 3/9] kernel/cpu_pm: Add runtime PM support for CPUs Date: Wed, 29 Mar 2017 16:54:53 -0700 [thread overview] Message-ID: <m2tw6b4p0y.fsf@baylibre.com> (raw) In-Reply-To: <CAPDyKFqXLzuge6+pQV-UzotENTV2gxZUCT6eU4CLtckdNZoYSw@mail.gmail.com> (Ulf Hansson's message of "Tue, 14 Mar 2017 08:45:00 +0100") Ulf Hansson <ulf.hansson@linaro.org> writes: > On 3 March 2017 at 21:41, Lina Iyer <lina.iyer@linaro.org> wrote: >> Notify runtime PM when the CPU is going to be powered off in the idle >> state. This allows for runtime PM suspend/resume of the CPU as well as >> its PM domain. >> >> Cc: Kevin Hilman <khilman@kernel.org> >> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org> [...] >> @@ -99,6 +102,7 @@ int cpu_pm_enter(void) >> { >> int nr_calls; >> int ret = 0; >> + struct device *dev = get_cpu_device(smp_processor_id()); >> >> read_lock(&cpu_pm_notifier_lock); >> ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls); >> @@ -110,6 +114,10 @@ int cpu_pm_enter(void) >> cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL); >> read_unlock(&cpu_pm_notifier_lock); >> >> + /* Notify Runtime PM that we are suspending the CPU */ >> + if (!ret && dev) >> + RCU_NONIDLE(pm_runtime_put_sync_suspend(dev)); >> + > > I am trying to understand how the runtime PM usage count becomes > properly balanced. > > I believe you could you end up first calling a > pm_runtime_put_sync_suspend(), without earlier having called > pm_runtime_get*(). I am not sure though, but perhaps you can > elaborate. > > Anyway, in patch2/9, where you enable runtime PM there is only a call > to pm_runtime_set_active(), which doesn't increase the usage count. To > me, it seems like that change also needs a pm_runtime_get_noresume(). IIUC, the CPU hotplug callback below (cpu_pm_cpu_starting) will do the first _get_sync(), and I'm assuming that will happen before any of the CPU PM notifiers get called, so I think the usecount will always be at least 1 by the time any CPU PM callbacks happen. [...] >> +#ifdef CONFIG_HOTPLUG_CPU >> +static int cpu_pm_cpu_dying(unsigned int cpu) >> +{ >> + struct device *dev = get_cpu_device(cpu); >> + >> + if (dev) >> + pm_runtime_put_sync_suspend(dev); >> + >> + return 0; >> +} >> + >> +static int cpu_pm_cpu_starting(unsigned int cpu) >> +{ >> + struct device *dev = get_cpu_device(cpu); >> + >> + if (dev) >> + pm_runtime_get_sync(dev); > > I assume that according to my comment above, you somehow need to > compensate for either of the cases when CONFIG_HOTPLUG_CPU is set or > unset. Right? Right, if for some reason CONFIG_HOTPLUG_CPU=n, we'll have a problem where there is never an initial _get() so the usecount will be zero when CPU PM notifiers get called the first time. Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@baylibre.com (Kevin Hilman) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V5 3/9] kernel/cpu_pm: Add runtime PM support for CPUs Date: Wed, 29 Mar 2017 16:54:53 -0700 [thread overview] Message-ID: <m2tw6b4p0y.fsf@baylibre.com> (raw) In-Reply-To: <CAPDyKFqXLzuge6+pQV-UzotENTV2gxZUCT6eU4CLtckdNZoYSw@mail.gmail.com> (Ulf Hansson's message of "Tue, 14 Mar 2017 08:45:00 +0100") Ulf Hansson <ulf.hansson@linaro.org> writes: > On 3 March 2017 at 21:41, Lina Iyer <lina.iyer@linaro.org> wrote: >> Notify runtime PM when the CPU is going to be powered off in the idle >> state. This allows for runtime PM suspend/resume of the CPU as well as >> its PM domain. >> >> Cc: Kevin Hilman <khilman@kernel.org> >> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org> [...] >> @@ -99,6 +102,7 @@ int cpu_pm_enter(void) >> { >> int nr_calls; >> int ret = 0; >> + struct device *dev = get_cpu_device(smp_processor_id()); >> >> read_lock(&cpu_pm_notifier_lock); >> ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls); >> @@ -110,6 +114,10 @@ int cpu_pm_enter(void) >> cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL); >> read_unlock(&cpu_pm_notifier_lock); >> >> + /* Notify Runtime PM that we are suspending the CPU */ >> + if (!ret && dev) >> + RCU_NONIDLE(pm_runtime_put_sync_suspend(dev)); >> + > > I am trying to understand how the runtime PM usage count becomes > properly balanced. > > I believe you could you end up first calling a > pm_runtime_put_sync_suspend(), without earlier having called > pm_runtime_get*(). I am not sure though, but perhaps you can > elaborate. > > Anyway, in patch2/9, where you enable runtime PM there is only a call > to pm_runtime_set_active(), which doesn't increase the usage count. To > me, it seems like that change also needs a pm_runtime_get_noresume(). IIUC, the CPU hotplug callback below (cpu_pm_cpu_starting) will do the first _get_sync(), and I'm assuming that will happen before any of the CPU PM notifiers get called, so I think the usecount will always be at least 1 by the time any CPU PM callbacks happen. [...] >> +#ifdef CONFIG_HOTPLUG_CPU >> +static int cpu_pm_cpu_dying(unsigned int cpu) >> +{ >> + struct device *dev = get_cpu_device(cpu); >> + >> + if (dev) >> + pm_runtime_put_sync_suspend(dev); >> + >> + return 0; >> +} >> + >> +static int cpu_pm_cpu_starting(unsigned int cpu) >> +{ >> + struct device *dev = get_cpu_device(cpu); >> + >> + if (dev) >> + pm_runtime_get_sync(dev); > > I assume that according to my comment above, you somehow need to > compensate for either of the cases when CONFIG_HOTPLUG_CPU is set or > unset. Right? Right, if for some reason CONFIG_HOTPLUG_CPU=n, we'll have a problem where there is never an initial _get() so the usecount will be zero when CPU PM notifiers get called the first time. Kevin
next prev parent reply other threads:[~2017-03-29 23:54 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-03 20:41 [PATCH V5 0/9] CPU PM domains Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-03 20:41 ` [PATCH V5 1/9] PM / Domains: Ignore domain-idle-states that are not compatible Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-12 14:35 ` Rob Herring 2017-03-12 14:35 ` Rob Herring 2017-03-13 15:56 ` Ulf Hansson 2017-03-13 15:56 ` Ulf Hansson 2017-03-03 20:41 ` [PATCH V5 2/9] drivers: cpu: Setup CPU devices to do runtime PM Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-13 15:55 ` Ulf Hansson 2017-03-13 15:55 ` Ulf Hansson 2017-03-03 20:41 ` [PATCH V5 3/9] kernel/cpu_pm: Add runtime PM support for CPUs Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-14 7:45 ` Ulf Hansson 2017-03-14 7:45 ` Ulf Hansson 2017-03-29 23:54 ` Kevin Hilman [this message] 2017-03-29 23:54 ` Kevin Hilman 2017-03-03 20:41 ` [PATCH V5 4/9] PM / cpu_domains: Setup PM domains for CPUs/clusters Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-14 9:24 ` Ulf Hansson 2017-03-14 9:24 ` Ulf Hansson 2017-03-14 11:36 ` Ulf Hansson 2017-03-14 11:36 ` Ulf Hansson 2017-03-03 20:41 ` [PATCH V5 5/9] timer: Export next wake up of a CPU Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-03 20:41 ` [PATCH V5 6/9] PM / cpu_domains: Add PM Domain governor for CPUs Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-03 20:41 ` [PATCH V5 7/9] PM / Domains: allow platform specific data for genpd states Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-03 20:41 ` [PATCH V5 8/9] PM / cpu_domains: Initialize CPU PM domains from DT Lina Iyer 2017-03-03 20:41 ` Lina Iyer 2017-03-03 20:41 ` [PATCH V5 9/9] doc / cpu_domains: Describe CPU PM domains setup and governor Lina Iyer 2017-03-03 20:41 ` Lina Iyer
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=m2tw6b4p0y.fsf@baylibre.com \ --to=khilman@baylibre.com \ --cc=Juri.Lelli@arm.com \ --cc=andy.gross@linaro.org \ --cc=brendan.jackman@arm.com \ --cc=lina.iyer@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=rjw@rjwysocki.net \ --cc=sboyd@codeaurora.org \ --cc=sudeep.holla@arm.com \ --cc=ulf.hansson@linaro.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: 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.