From: b.zolnierkie@samsung.com (Bartlomiej Zolnierkiewicz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
Date: Fri, 30 May 2014 15:53:09 +0200 [thread overview]
Message-ID: <2110279.TVBlLBzQV3@amdc1032> (raw)
In-Reply-To: <53886CD5.8010301@gmail.com>
Hi,
On Friday, May 30, 2014 01:34:45 PM Tomasz Figa wrote:
> Hi Daniel,
>
> On 30.05.2014 11:30, Daniel Lezcano wrote:
> > On 04/24/2014 07:42 PM, Tomasz Figa wrote:
> >> Hi Daniel,
> >>
> >> Please see my comments inline.
> >>
> >> Btw. Please fix your e-mail composer to properly wrap your messages
> >> around 7xth column, as otherwise they're hard to read.
> >>
> >> On 04.04.2014 11:48, Daniel Lezcano wrote:
> >>> The following driver is for exynos4210. I did not yet finished the
> >>> other boards, so
> >>> I created a specific driver for 4210 which could be merged later.
> >>>
> >>> The driver is based on Colin Cross's driver found at:
> >>>
> >>> https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
> >>>
> >>>
> >>>
> >>> This one was based on a 3.4 kernel and an old API.
> >>>
> >>> It has been refreshed, simplified and based on the recent code cleanup
> >>> I sent
> >>> today.
> >>>
> >>> The AFTR could be entered when all the cpus (except cpu0) are down. In
> >>> order to
> >>> reach this situation, the couple idle states are used.
> >>>
> >>> There is a sync barrier at the entry and the exit of the low power
> >>> function. So
> >>> all cpus will enter and exit the function at the same time.
> >>>
> >>> At this point, CPU0 knows the other cpu will power down itself. CPU0
> >>> waits for
> >>> the CPU1 to be powered down and then initiate the AFTR power down
> >>> sequence.
> >>>
> >>> No interrupts are handled by CPU1, this is why we switch to the timer
> >>> broadcast
> >>> even if the local timer is not impacted by the idle state.
> >>>
> >>> When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then
> >>> they both
> >>> exit the idle function.
> >>>
> >>> This driver allows the exynos4210 to have the same power consumption
> >>> at idle
> >>> time than the one when we have to unplug CPU1 in order to let CPU0 to
> >>> reach
> >>> the AFTR state.
> >>>
> >>> This patch is a RFC because, we have to find a way to remove the macros
> >>> definitions and cpu powerdown function without pulling the arch
> >>> dependent
> >>> headers.
> >>>
> >>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>> ---
> >>> arch/arm/mach-exynos/common.c | 11 +-
> >>> drivers/cpuidle/Kconfig.arm | 8 ++
> >>> drivers/cpuidle/Makefile | 1 +
> >>> drivers/cpuidle/cpuidle-exynos4210.c | 226
> >>> ++++++++++++++++++++++++++++++++++
> >
> > [ ... ]
> >
> >
> >> Otherwise, I quite like the whole idea. I need to play a bit with CPU
> >> hotplug and PMU to verify that things couldn't really be simplified a
> >> bit, but in general this looks reasonably.
> >
> > Hi Tomasz,
> >
> > did you have time to look at this simplification ?
>
> Unfortunately I got preempted with other things to do and now I'm on
> vacation. I worked a bit with Bart (added on CC) on this and generally
> the conclusion was that all the things are necessary. He was also
> working to extend the driver to support Exynos4x12.
>
> Bart, has anything interesting showed up since we talked about this last
> time?
Since we last looked into this I have fixed the "standard" AFTR support
for Exynos3250 and started to work on adding Exynos3250 support to this
driver (as Exynos3250 support has bigger priority than Exynos4x12 one).
Unfortunately I also got preempted with other things so it is still
unfinished and doesn't work yet. Moreover I had no possibility to test
the new driver on Exynos4210 based Origen yet (I hope to do this next
week).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
next prev parent reply other threads:[~2014-05-30 13:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 9:48 [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state Daniel Lezcano
2014-04-04 14:25 ` Lorenzo Pieralisi
2014-04-15 6:37 ` Lukasz Majewski
2014-04-15 15:23 ` Daniel Lezcano
2014-04-15 15:54 ` Lukasz Majewski
2014-04-15 16:38 ` Daniel Lezcano
2014-04-15 22:19 ` Lukasz Majewski
2014-04-24 17:42 ` Tomasz Figa
2014-04-25 7:52 ` Daniel Lezcano
2014-05-30 9:30 ` Daniel Lezcano
2014-05-30 11:34 ` Tomasz Figa
2014-05-30 13:53 ` Bartlomiej Zolnierkiewicz [this message]
2014-07-16 17:34 ` Bartlomiej Zolnierkiewicz
2014-07-21 11:06 ` Daniel Lezcano
2014-08-14 10:55 ` Bartlomiej Zolnierkiewicz
2014-08-14 23:57 ` Daniel Lezcano
2014-06-11 8:50 ` Krzysztof Kozlowski
2014-06-13 22:43 ` Daniel Lezcano
2014-06-25 7:36 ` Krzysztof Kozlowski
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=2110279.TVBlLBzQV3@amdc1032 \
--to=b.zolnierkie@samsung.com \
--cc=linux-arm-kernel@lists.infradead.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