From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Lina Iyer <lina.iyer@linaro.org>
Cc: rjw@rjwysocki.net, ulf.hansson@linaro.org, khilman@linaro.org,
mathieu.poirier@linaro.org, linux-pm@vger.kernel.org,
galak@codeaurora.org, msivasub@codeaurora.org,
agross@codeaurora.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain
Date: Thu, 11 Jun 2015 09:27:34 +0900 [thread overview]
Message-ID: <5578D5F6.8000000@samsung.com> (raw)
In-Reply-To: <20150610165742.GB4497@linaro.org>
On 11.06.2015 01:57, Lina Iyer wrote:
> On Sun, Jun 07 2015 at 03:43 -0600, Krzysztof Kozlowski wrote:
>> W dniu 05.06.2015 o 07:29, Lina Iyer pisze:
>>> Generally cpus are grouped under a power domain in a SoC. When all cpus
>>> in the domain are in their power off state,
>>
>> What do you exactly mean here by "CPU in power off state"? How does it
>> map to kernel understanding of CPU device (hotplug? cpuidle?)?
>>
> Both cpuidle and hotplug could end with with core being powered down at
> the platform driver or at PSCI (on V8). It does not matter which of
> these two frameworks resulted in the cpu being powered off. But, if all
> cpus in the domain are powered off, then the domain could be powered off
> as well. This is the premise of this change. It is probably easier to
> power off the domain when the cores in that domain/cluster have been
> hotplugged off. It saves power to turn off the domain at that time, but
> more power savings can be achieved if the domain could also be powered
> off during cpuidle. Hotplug is not a common occurance, while cpuidle is.
OK, it answers my questions, thanks.
>
>>> the cpu domain can also be
>>> powered off. Genpd provides the framework for defining cpus as devices
>>> that are part of a cpu domain.
>>
>> The problem which is solved looks to me like the same problem which
>> coupled cpuidle tried to solve: a certain deep sleep mode (e.g. power
>> off) can be entered when whole cluster is idle or other CPUs in cluster
>> are powered off completely.
>>
>> It seems a little like duplicating the effort around coupled cpuidle.
>>
> I see where are you are going with this, but genpd solution is not
> exactly a duplicate of the solution.
>
> Couple state is used to put the cpus in a deeper sleep state, which
> could also result in powering off the domain. Coupled cpuidle is a
> cpuidle mechanism for choosing a deeper sleep mode on certain hardware
> that can only enter such a mode when all cpus cooperate.
>
> This patch attempts to describe the backend of a cpu domain. CPUs are
> responsible for individual cpuidle states, cpus do enter their
> recommended deepest idle state at the time of no activity. A cpu-domain
> could be comprised of cpus, and other devices like GIC, busses etc, that
> all need to idle before the domain can be powered off. This patch does
> not dictate which idle state any those devices should enter, or
> coordinate the idle states between devices. But, if cpus, choose to
> power down, then this patch recognizes that and reduces the reference
> usage count on the domain. Only when all devices in the domain remove
> their usage count, will the domain be powered off.
It would be nice to see the usage of this patch in cpuidle driver or
platform code but I think I get the idea.
Actually I like the approach.
I am thinking how to utilize it to replace coupled cpuidle for our case.
In our case we use coupled cpuidle because the SoC can be put in low
power mode only if non-boot CPUs are powered down.
However in our case:
1. Some other devices (buses, clocks) also should be idle. This would
perfectly match with this patch and with runtime PM.
2. Some non-boot idle CPU could power itself down but it cannot wake up.
Only the alive CPU can wake others. This probably means that we cannot
provide a cpuidle driver which will power off unused cores and then, if
boot CPU is idle, disable the CPU power domain by entering to low power
mode.
Anyway, as I said, I like the approach.
> There are two things this patch provides -
>
> i. A generic way to initialize a genpd specifically for cpus. (The
> platform specifies the relation between a cpu and its domain in the DT
> and provides the memory for the genpd structure)
>
> ii. On behalf of a platform, we track when the cpus power up and down
> and use runtime_get and runtime_put on the genpd.
>
> Unlike coupled cpuidle, individual cpu idle state is not manipulated.
> Coupled cpuidle does not care if the domain is powered off, it is used
> to allow a certain C-state for the cpu, based on the idleness of other
> cpus in that cluster. The focus of the series is powering down the
> domain when the devices (cpus included) are powered off. You could see
> this patch as a cpu-pm and runtime-pm interface layer.
>
> Hope that helps.
>
> Thanks,
> Lina
>
Best regards,
Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain
Date: Thu, 11 Jun 2015 09:27:34 +0900 [thread overview]
Message-ID: <5578D5F6.8000000@samsung.com> (raw)
In-Reply-To: <20150610165742.GB4497@linaro.org>
On 11.06.2015 01:57, Lina Iyer wrote:
> On Sun, Jun 07 2015 at 03:43 -0600, Krzysztof Kozlowski wrote:
>> W dniu 05.06.2015 o 07:29, Lina Iyer pisze:
>>> Generally cpus are grouped under a power domain in a SoC. When all cpus
>>> in the domain are in their power off state,
>>
>> What do you exactly mean here by "CPU in power off state"? How does it
>> map to kernel understanding of CPU device (hotplug? cpuidle?)?
>>
> Both cpuidle and hotplug could end with with core being powered down at
> the platform driver or at PSCI (on V8). It does not matter which of
> these two frameworks resulted in the cpu being powered off. But, if all
> cpus in the domain are powered off, then the domain could be powered off
> as well. This is the premise of this change. It is probably easier to
> power off the domain when the cores in that domain/cluster have been
> hotplugged off. It saves power to turn off the domain at that time, but
> more power savings can be achieved if the domain could also be powered
> off during cpuidle. Hotplug is not a common occurance, while cpuidle is.
OK, it answers my questions, thanks.
>
>>> the cpu domain can also be
>>> powered off. Genpd provides the framework for defining cpus as devices
>>> that are part of a cpu domain.
>>
>> The problem which is solved looks to me like the same problem which
>> coupled cpuidle tried to solve: a certain deep sleep mode (e.g. power
>> off) can be entered when whole cluster is idle or other CPUs in cluster
>> are powered off completely.
>>
>> It seems a little like duplicating the effort around coupled cpuidle.
>>
> I see where are you are going with this, but genpd solution is not
> exactly a duplicate of the solution.
>
> Couple state is used to put the cpus in a deeper sleep state, which
> could also result in powering off the domain. Coupled cpuidle is a
> cpuidle mechanism for choosing a deeper sleep mode on certain hardware
> that can only enter such a mode when all cpus cooperate.
>
> This patch attempts to describe the backend of a cpu domain. CPUs are
> responsible for individual cpuidle states, cpus do enter their
> recommended deepest idle state at the time of no activity. A cpu-domain
> could be comprised of cpus, and other devices like GIC, busses etc, that
> all need to idle before the domain can be powered off. This patch does
> not dictate which idle state any those devices should enter, or
> coordinate the idle states between devices. But, if cpus, choose to
> power down, then this patch recognizes that and reduces the reference
> usage count on the domain. Only when all devices in the domain remove
> their usage count, will the domain be powered off.
It would be nice to see the usage of this patch in cpuidle driver or
platform code but I think I get the idea.
Actually I like the approach.
I am thinking how to utilize it to replace coupled cpuidle for our case.
In our case we use coupled cpuidle because the SoC can be put in low
power mode only if non-boot CPUs are powered down.
However in our case:
1. Some other devices (buses, clocks) also should be idle. This would
perfectly match with this patch and with runtime PM.
2. Some non-boot idle CPU could power itself down but it cannot wake up.
Only the alive CPU can wake others. This probably means that we cannot
provide a cpuidle driver which will power off unused cores and then, if
boot CPU is idle, disable the CPU power domain by entering to low power
mode.
Anyway, as I said, I like the approach.
> There are two things this patch provides -
>
> i. A generic way to initialize a genpd specifically for cpus. (The
> platform specifies the relation between a cpu and its domain in the DT
> and provides the memory for the genpd structure)
>
> ii. On behalf of a platform, we track when the cpus power up and down
> and use runtime_get and runtime_put on the genpd.
>
> Unlike coupled cpuidle, individual cpu idle state is not manipulated.
> Coupled cpuidle does not care if the domain is powered off, it is used
> to allow a certain C-state for the cpu, based on the idleness of other
> cpus in that cluster. The focus of the series is powering down the
> domain when the devices (cpus included) are powered off. You could see
> this patch as a cpu-pm and runtime-pm interface layer.
>
> Hope that helps.
>
> Thanks,
> Lina
>
Best regards,
Krzysztof
next prev parent reply other threads:[~2015-06-11 0:27 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 15:53 [PATCH RFC 0/3] PM / Domains: Generic PM domains for cpus Lina Iyer
2015-06-04 22:29 ` Lina Iyer
2015-06-03 15:53 ` [PATCH RFC 2/3] PM / Domains: Support atomic PM domains Lina Iyer
2015-06-04 22:29 ` Lina Iyer
2015-06-07 9:21 ` Krzysztof Kozlowski
2015-06-07 9:21 ` Krzysztof Kozlowski
2015-06-10 16:13 ` Lina Iyer
2015-06-10 16:13 ` Lina Iyer
2015-06-11 0:13 ` Krzysztof Kozlowski
2015-06-11 0:13 ` Krzysztof Kozlowski
2015-06-11 14:33 ` Lina Iyer
2015-06-11 14:33 ` Lina Iyer
2015-06-10 18:04 ` Kevin Hilman
2015-06-10 18:04 ` Kevin Hilman
2015-06-10 20:35 ` Lina Iyer
2015-06-10 20:35 ` Lina Iyer
2015-06-11 9:41 ` Ulf Hansson
2015-06-11 9:41 ` Ulf Hansson
2015-06-11 19:47 ` Lina Iyer
2015-06-11 19:47 ` Lina Iyer
2015-06-11 21:13 ` Ulf Hansson
2015-06-11 21:13 ` Ulf Hansson
2015-06-03 15:53 ` [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain Lina Iyer
2015-06-04 22:29 ` Lina Iyer
2015-06-07 9:42 ` Krzysztof Kozlowski
2015-06-07 9:42 ` Krzysztof Kozlowski
2015-06-10 16:57 ` Lina Iyer
2015-06-10 16:57 ` Lina Iyer
2015-06-11 0:27 ` Krzysztof Kozlowski [this message]
2015-06-11 0:27 ` Krzysztof Kozlowski
2015-06-11 14:42 ` Lina Iyer
2015-06-11 14:42 ` Lina Iyer
2015-06-10 17:01 ` Kevin Hilman
2015-06-10 17:01 ` Kevin Hilman
2015-06-11 0:35 ` Krzysztof Kozlowski
2015-06-11 0:35 ` Krzysztof Kozlowski
2015-06-10 21:37 ` Kevin Hilman
2015-06-10 21:37 ` Kevin Hilman
2015-06-11 14:56 ` Lina Iyer
2015-06-11 14:56 ` Lina Iyer
2015-06-15 18:43 ` Kevin Hilman
2015-06-15 18:43 ` Kevin Hilman
2015-06-15 19:14 ` Lina Iyer
2015-06-15 19:14 ` Lina Iyer
2015-06-16 15:50 ` Kevin Hilman
2015-06-16 15:50 ` Kevin Hilman
2015-06-03 15:54 ` [PATCH RFC 1/3] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-06-04 22:29 ` Lina Iyer
2015-06-07 8:35 ` Krzysztof Kozlowski
2015-06-07 8:35 ` Krzysztof Kozlowski
2015-06-09 22:45 ` Lina Iyer
2015-06-09 22:45 ` Lina Iyer
2015-06-10 17:33 ` Kevin Hilman
2015-06-10 17:33 ` Kevin Hilman
2015-06-03 15:55 ` [PATCH RFC 2/3] PM / Domains: Support atomic PM domains Lina Iyer
2015-06-03 15:55 ` [PATCH RFC 1/3] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-06-03 15:55 ` [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain Lina Iyer
2015-06-10 17:24 ` [PATCH RFC 0/3] PM / Domains: Generic PM domains for cpus Kevin Hilman
2015-06-10 17:24 ` Kevin Hilman
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=5578D5F6.8000000@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=agross@codeaurora.org \
--cc=galak@codeaurora.org \
--cc=khilman@linaro.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=msivasub@codeaurora.org \
--cc=rjw@rjwysocki.net \
--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.