From: khilman@baylibre•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
Date: Fri, 19 Aug 2016 13:10:32 -0500 [thread overview]
Message-ID: <m2fuq0k4tj.fsf@baylibre.com> (raw)
In-Reply-To: <5e59874c-bbb7-270a-199c-da1ff5932554@arm.com> (Sudeep Holla's message of "Wed, 10 Aug 2016 19:09:21 +0100")
Sudeep Holla <sudeep.holla@arm•com> writes:
[...]
> In general whatever binding we come up must not just address OS
> coordinated mode. Also I was thinking to have better coverage in the
> description by having a bit more complex system like:
>
> cluster0
> CLUSTER_RET(Retention)
> CLUSTER_PG(Power Gate)
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
Also, remember that a power domain may contain more than just CPUs, so
this will also need to handle things like:
device0..N
DEV_CLK_GATE
DEV_RET
DEV_PG
So, as (I think) Lina was trying to say, including CPU idle states
inside domain idles states doesn't really scale well because it would
also imply domain states would also include device idle states.
IMO, the device-specific states belong in the device nodes, and that
includes CPUs.
It's up to the domain (genpd) governor to look at *all* devices in the
domain, check their state and make a domain-wide decision.
The tricky part remains, IMO, the mapping between device/CPU states and
allowable domain states.
As was suggested earlier, a good potential starting point would be that
all devices/CPUs would need to be in their deepest state before the
domain would make any decisions. While that leaves soem power savings
on the table, it maps well to how genpd works today with only on/off
states and could be extended with more complicated governors down the
road.
Kevin
next prev parent reply other threads:[~2016-08-19 18:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 23:04 [PATCH v3 00/15] PM: SoC idle support using PM domains Lina Iyer
2016-08-04 23:04 ` [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT Lina Iyer
2016-08-04 23:04 ` [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states Lina Iyer
2016-08-09 23:55 ` Rob Herring
2016-08-10 15:14 ` Sudeep Holla
2016-08-10 16:40 ` Lina Iyer
2016-08-10 18:09 ` Sudeep Holla
2016-08-10 18:13 ` Sudeep Holla
2016-08-11 21:10 ` Lina Iyer
2016-08-12 9:47 ` Brendan Jackman
2016-08-12 10:08 ` Sudeep Holla
2016-08-15 16:08 ` Lina Iyer
2016-08-15 16:14 ` Sudeep Holla
2016-08-15 22:40 ` Lina Iyer
2016-08-16 8:34 ` Brendan Jackman
2016-08-16 8:41 ` Brendan Jackman
2016-08-16 9:19 ` Sudeep Holla
2016-08-12 12:35 ` Brendan Jackman
2016-08-15 16:06 ` Lina Iyer
2016-08-19 18:10 ` Kevin Hilman [this message]
2016-08-24 14:07 ` Sudeep Holla
2016-08-04 23:04 ` [PATCH v3 03/15] PM / Domains: Abstract genpd locking Lina Iyer
2016-08-04 23:04 ` [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains Lina Iyer
2016-08-04 23:04 ` [PATCH v3 05/15] PM / doc: Update device documentation for devices in " Lina Iyer
2016-08-04 23:04 ` [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters Lina Iyer
2016-08-04 23:04 ` [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs Lina Iyer
2016-08-04 23:04 ` [PATCH v3 08/15] timer: Export next wake up of a CPU Lina Iyer
2016-08-04 23:04 ` [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs Lina Iyer
2016-08-04 23:04 ` [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor Lina Iyer
2016-08-04 23:04 ` [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode Lina Iyer
2016-08-04 23:04 ` [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated Lina Iyer
2016-08-04 23:05 ` [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings Lina Iyer
2016-08-05 14:44 ` Lina Iyer
2016-08-04 23:05 ` [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916 Lina Iyer
2016-08-04 23:05 ` [PATCH v3 15/15] ARM64: dts: Define CPU power domain " Lina Iyer
2016-08-10 15:27 ` Sudeep Holla
2016-08-10 17:35 ` Lina Iyer
2016-08-11 9:30 ` Sudeep Holla
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=m2fuq0k4tj.fsf@baylibre.com \
--to=khilman@baylibre$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox