All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.