From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
Amit Kucheria <amit.kucheria@linaro.org>,
Olof Johansson <olof@lixom.net>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Jon Medhurst <tixy@linaro.org>
Subject: Re: [PATCH v3 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
Date: Mon, 12 Aug 2013 14:59:31 +0100 [thread overview]
Message-ID: <20130812135930.GA21780@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <5204F28E.1050204@linaro.org>
On Fri, Aug 09, 2013 at 02:45:50PM +0100, Daniel Lezcano wrote:
> On 08/08/2013 06:18 PM, Lorenzo Pieralisi wrote:
> > On Thu, Aug 08, 2013 at 05:00:24PM +0100, Daniel Lezcano wrote:
> >> On 08/07/2013 01:43 PM, Lorenzo Pieralisi wrote:
> >>> The big.LITTLE architecture is composed of two clusters of cpus. One cluster
> >>> contains less powerful but more energy efficient processors and the other
> >>> cluster groups the powerful but energy-intensive cpus.
> >>>
> >>> The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
> >>> a big.LITTLE configuration) connected through a CCI interconnect that manages
> >>> coherency of their respective L2 caches and intercluster distributed
> >>> virtual memory messages (DVM).
> >>>
> >>> TC2 testchip integrates a power controller that manages cores resets, wake-up
> >>> IRQs and cluster low-power states. Power states are managed at cluster
> >>> level, which means that voltage is removed from a cluster iff all cores
> >>> in a cluster are in a wfi state. Single cores can enter a reset state
> >>> which is identical to wfi in terms of power consumption but simplifies the
> >>> way cluster states are entered.
> >>>
> >>> This patch provides a multiple driver CPU idle implementation for TC2
> >>> which paves the way for a generic big.LITTLE idle driver for all
> >>> upcoming big.LITTLE based systems on chip.
> >>>
> >>> The driver relies on the MCPM infrastructure to coordinate and manage
> >>> core power states; in particular MCPM allows to suspend specific cores
> >>> and hides the CPUs coordination required to shut-down clusters of CPUs.
> >>>
> >>> Power down sequences for the respective clusters are implemented in the
> >>> MCPM TC2 backend, with all code needed to clean caches and exit coherency.
> >>>
> >>> The multiple driver CPU idle infrastructure allows to define different
> >>> C-states for big and little cores, determined at boot by checking the
> >>> part id of the possible CPUs and initializing the respective logical
> >>> masks in the big and little drivers.
> >>>
> >>> Current big.little systems are composed of A7 and A15 clusters, as
> >>> implemented in TC2, but in the future that may change and the driver
> >>> will have evolve to retrieve what is a 'big' cpu and what is a 'little'
> >>> cpu in order to build the correct topology.
> >>>
> >>> Cc: Kevin Hilman <khilman@linaro.org>
> >>> Cc: Amit Kucheria <amit.kucheria@linaro.org>
> >>> Cc: Olof Johansson <olof@lixom.net>
> >>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> >>> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> >>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>> ---
> >>
> >> A nit below :/
> >>
> >> [ ... ]
> >>
> >>> +
> >>> +static struct cpuidle_driver bl_idle_big_driver = {
> >>> + .name = "big_idle",
> >>> + .owner = THIS_MODULE,
> >>> + .states[0] = ARM_CPUIDLE_WFI_STATE,
> >>> + .states[1] = {
> >>> + .enter = bl_enter_powerdown,
> >>> +
> >>> + .exit_latency = 500,
> >>
> >> Extra line between enter and exit_latency.
> >
> > Gah, not anymore :)
> >
> > Other than that, is it ready to go ? If nobody complains I have planned
> > to send a pull request early next week, as soon as a stable branch for
> > TC2 MCPM gets in arm-soc.
>
>
> It sounds good to me.
Ok. Olof, Kevin, I prepared a pull request based on top of:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/190067.html
we probably need to fix a simple niggle in that code,
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/191303.html
do you want me to wait for it before asking to pull, or I can send a PR
straight away and we will deal with conflicts (if any) later ?
Thanks,
Lorenzo
prev parent reply other threads:[~2013-08-12 13:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 11:43 [PATCH v3 0/3] ARM: TC2 big.LITTLE CPU idle driver Lorenzo Pieralisi
2013-08-07 11:43 ` [PATCH v3 1/3] drivers: irq-chip: irq-gic: introduce gic_cpu_if_down() Lorenzo Pieralisi
2013-08-07 11:43 ` [PATCH v3 2/3] ARM: vexpress: tc2: disable GIC CPU IF in tc2_pm_suspend Lorenzo Pieralisi
2013-08-07 11:43 ` [PATCH v3 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver Lorenzo Pieralisi
2013-08-08 16:00 ` Daniel Lezcano
2013-08-08 16:18 ` Lorenzo Pieralisi
2013-08-09 13:45 ` Daniel Lezcano
2013-08-12 13:59 ` Lorenzo Pieralisi [this message]
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=20130812135930.GA21780@e102568-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=amit.kucheria@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=olof@lixom.net \
--cc=rjw@sisk.pl \
--cc=tixy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).