From: khilman@kernel•org (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 5/9] ARM: common: Introduce PM domains for CPUs/clusters
Date: Fri, 14 Aug 2015 12:11:30 -0700 [thread overview]
Message-ID: <7h1tf5it25.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20150814154947.GC24806@red-moon> (Lorenzo Pieralisi's message of "Fri, 14 Aug 2015 16:49:47 +0100")
Lorenzo Pieralisi <lorenzo.pieralisi@arm•com> writes:
> On Fri, Aug 14, 2015 at 04:51:15AM +0100, Kevin Hilman wrote:
[...]
>> However, you can think of CPU PM notifiers as the equivalent of runtime
>> PM hooks. They're called when the "devices" are about to be powered off
>> (runtime suspended) or powered on (runtime resumed.)
>>
>> However the CPU PM framework and notifiers are rather dumb compared to
>> runtime PM. For example, runtime PM gives you usecounting, autosuspend,
>> control from userspace, statistics, etc. etc. Also, IMO, CPU PM will
>> not scale well for multiple clusters.
>>
>> What if instead, we used runtime PM for the things that the CPU PM
>> notifiers manager (GIC, VFP, Coresight, etc.), and those drivers used
>> runtime PM callbacks to replace their CPU PM notifiers? We'd then be in
>> a beautiful land where CPU "devices" (and the other connected logic) can
>> be modeled as devices using runtime PM just like every other device in
>> the system.
>
> I would agree with that (even though I do not see how we can make
> eg GIC, VFP and arch timers behave like devices from a runtime PM
> standpoint),
Sure, that might be a stretch due the implementation details, but
conceptully it models the hardware well and I'd like to explore runtime
PM for all of these "devices", though it's not the highest priority.
> still I do not see why we need a virtual power domain for
> that, the CPU "devices" should be attached to the HW CPU power domain.
>
> More below for systems relying on FW interfaces to handle CPU power
> management.
>
>> Then take it up a level... what if we then could use genpd to model the
>> "cluster", made of of the CPUs and "connected" devices (GIC, VFP, etc.)
>> but also modeled the shared L2$ as a device which was using runtime PM.
>
> I have to understand what "modeled" means (do we create a struct device
> on purpose for that ? Same goes for GIC and VFP).
Not necessarily a struct device for the cluster, but for the CPUs (which
already have one) and and possibly GIC, VFP, timers. etc. With that in
place, cluster would just be modleled by a genpd (which is what Lina's
series is doing.)
> But overall I get the gist of what you are saying, we just have to see
> how this can be implemented within the genPD framework.
>
> I suspect the "virtual" power domain you are introducing is there for
> systems where the power controller is hidden from the kernel (ie PSCI),
> where basically the CPU "devices" can't be attached to a power domain
> simply because that power domain is not managed in the kernel but
> by firmware.
The main idea behind a "virtual" power domain was to collect the common
parts of cluster management, possibly governors etc. However, maybe
it's better just have a set of functions that the "real" hw power domain
drivers could use for the common parts. That might get rid of the need
to describe this in DT, which I think is what Rob is suggesting also.
>> Now we're in a place where we can use all the benefits of runtime PM,
>> plus the governor features of genpd to start doing a real, multi-CPU,
>> multi-cluster CPUidle that's flexible enough to model the various
>> dependencies in an SoC independent way, but generic enough to be able to
>> use common governors for last-man standing, cache flushing, etc. etc.
>
> I do not disagree (even though I think that last man standing is pushing
> this concept a bit over the top), I am just concerned about the points
> raised above, most of them should be reasonably simple to solve.
Good, hopefully we can have a good discussion about this at Plumbers
next week as the issues above and proposed in Lina's series are the main
issues I want to raise in my part of the EAS/PM track[1].
See you there!
Kevin
[1] https://linuxplumbersconf.org/2015/ocw/events/LPC2015/tracks/501
next prev parent reply other threads:[~2015-08-14 19:11 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 23:35 [PATCH 0/9] ARM: PM / Domains: Generic PM domains for CPUs/Clusters Lina Iyer
2015-08-04 23:35 ` [PATCH 1/9] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-08-12 19:47 ` Kevin Hilman
2015-09-01 12:40 ` Ulf Hansson
2015-08-04 23:35 ` [PATCH 2/9] PM / Domains: Remove dev->driver check for runtime PM Lina Iyer
2015-08-12 19:50 ` Kevin Hilman
2015-08-13 8:57 ` Geert Uytterhoeven
2015-08-14 3:40 ` Kevin Hilman
2015-08-14 7:24 ` Geert Uytterhoeven
2015-08-14 17:19 ` Kevin Hilman
2015-08-16 9:24 ` Geert Uytterhoeven
2015-08-21 21:04 ` Kevin Hilman
2015-08-24 19:50 ` Lina Iyer
2015-08-25 9:24 ` Geert Uytterhoeven
2015-09-01 13:28 ` Ulf Hansson
2015-08-04 23:35 ` [PATCH 3/9] PM / Domains: Support IRQ safe PM domains Lina Iyer
2015-08-12 20:12 ` Kevin Hilman
2015-08-12 20:47 ` Lina Iyer
2015-08-12 23:03 ` Stephen Boyd
2015-08-04 23:35 ` [PATCH 4/9] kernel/cpu_pm: fix cpu_cluster_pm_exit comment Lina Iyer
2015-08-12 20:13 ` Kevin Hilman
2015-08-04 23:35 ` [PATCH 5/9] ARM: common: Introduce PM domains for CPUs/clusters Lina Iyer
2015-08-06 3:14 ` Rob Herring
2015-08-07 23:45 ` Kevin Hilman
2015-08-11 13:07 ` Geert Uytterhoeven
2015-08-11 15:58 ` Lina Iyer
2015-08-11 20:12 ` Rob Herring
2015-08-11 22:29 ` Lina Iyer
2015-08-12 19:00 ` [PATCH v2 1/2] " Lina Iyer
2015-08-12 19:00 ` [PATCH v2 2/2] ARM: domain: Add platform handlers for CPU PM domains Lina Iyer
2015-08-13 17:29 ` [PATCH v2 1/2] ARM: common: Introduce PM domains for CPUs/clusters Rob Herring
2015-08-13 20:12 ` Lina Iyer
2015-08-13 22:01 ` Rob Herring
2015-08-14 14:38 ` Lina Iyer
2015-08-13 15:01 ` [PATCH 5/9] " Lorenzo Pieralisi
2015-08-13 15:45 ` Lina Iyer
2015-08-13 15:52 ` Lorenzo Pieralisi
2015-08-13 16:22 ` Lina Iyer
2015-08-14 3:51 ` Kevin Hilman
2015-08-14 4:02 ` Lina Iyer
2015-08-14 15:49 ` Lorenzo Pieralisi
2015-08-14 19:11 ` Kevin Hilman [this message]
2015-08-13 17:26 ` Sudeep Holla
2015-08-13 19:27 ` Lina Iyer
2015-08-14 9:52 ` Sudeep Holla
2015-08-04 23:35 ` [PATCH 6/9] ARM: domain: Add platform handlers for CPU PM domains Lina Iyer
2015-08-05 14:45 ` Rob Herring
2015-08-05 16:38 ` Lina Iyer
2015-08-05 19:23 ` Lina Iyer
2015-08-06 3:01 ` Rob Herring
2015-08-10 15:36 ` Lina Iyer
2015-08-04 23:35 ` [PATCH 7/9] ARM: cpuidle: Add runtime PM support for CPU idle Lina Iyer
2015-08-04 23:35 ` [PATCH 8/9] ARM64: smp: Add runtime PM support for CPU hotplug Lina Iyer
2015-08-04 23:35 ` [PATCH 9/9] ARM: " Lina Iyer
2015-08-12 20:28 ` Kevin Hilman
2015-08-12 20:43 ` Lina Iyer
2015-08-14 18:59 ` Kevin Hilman
2015-08-12 23:47 ` Stephen Boyd
2015-08-13 16:00 ` Lina Iyer
2015-08-13 19:18 ` Stephen Boyd
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=7h1tf5it25.fsf@deeprootsystems.com \
--to=khilman@kernel$(echo .)org \
--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