From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC patch 02/11] cpuidle / arm : a single cpuidle driver
Date: Mon, 25 Mar 2013 19:35:05 +0100 [thread overview]
Message-ID: <515098D9.2000107@linaro.org> (raw)
In-Reply-To: <CAHkRjk45cGSKiC003izHrLSZPb3wsmjXPTG3e0raSaXAdQRqEQ@mail.gmail.com>
On 03/25/2013 07:27 PM, Catalin Marinas wrote:
> On 15 March 2013 15:07, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> On 03/15/2013 03:47 PM, Arnd Bergmann wrote:
>>> On Friday 15 March 2013, Daniel Lezcano wrote:
>>>> The cpuidle drivers are duplicating a lot of code and in most
>>>> of the case there is a common pattern we can factor out:
>>>>
>>>> * setup the broadcast timers
>>>> * register the driver
>>>> * register the devices
>>>>
>>>> This arm driver is the common part between all the ARM cpuidle drivers,
>>>> with the code factored out.
>>>>
>>>> It does not handle the coupled idle state for now but it is the first
>>>> step to have everyone to converge to the same code pattern.
>>>>
>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>
>>> Unfortunately, I missed the session in Hong Kong, but I'd like to understand
>>> what part of this driver is actually ARM specific. I assume there is nothing
>>> in it that depends on 32 bit ARM hardware, right?
>>
>> What depends on the 32bits ARM hardware is the drivers themselves. This
>> ARM driver is the first step to consolidate all SoC cpuidle specific
>> code we find in arch/arm. The code is designated to factor out these
>> drivers, as a first step. The second step is to consolidate more this
>> driver (eg. moving the code in arch/arm/kernel/cpuidle.c in this driver).
>>
>> The last man standing algorithm we have in mach-ux500 and mach-imx is
>> the same, and will be moved in the ARM cpuidle driver.
>>
>> The more it will be consolidated, the more it will be ARM specific.
>>
>> The final step will be to use the device tree to be passed to this
>> driver and do the cpuidle driver initialization from there.
>>
>>> Would the same code be used with arch/arm64?
>>
>> I can't tell but IIUC, a single ARM driver will be used based on the
>> psci for ARM64, but it does not exist for now. It is possible some code
>> pattern could be used from the ARM32 cpuidle driver.
>
> While we recommend PSCI if EL3 (secure mode) is available, not all
> ARMv8 CPU implementations will have this and most likely we'll have to
> reuse existing cpuidle drivers. So if you can make it as generic as
> possible it would really help.
Sure, I will keep it in mind.
Thanks for the information.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2013-03-25 18:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 14:26 [RFC patch 00/11] cpuidle : ARM driver to rule them all Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 01/11] cpuidle : handle clockevent notify from the cpuidle framework Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 02/11] cpuidle / arm : a single cpuidle driver Daniel Lezcano
2013-03-15 14:47 ` Arnd Bergmann
2013-03-15 15:07 ` Daniel Lezcano
2013-03-25 18:27 ` Catalin Marinas
2013-03-25 18:35 ` Daniel Lezcano [this message]
2013-03-26 4:31 ` Santosh Shilimkar
2013-03-26 10:58 ` Daniel Lezcano
2013-03-26 11:17 ` Andrew Lunn
2013-03-26 11:44 ` Daniel Lezcano
2013-03-26 23:27 ` Rafael J. Wysocki
2013-03-15 14:27 ` [RFC patch 03/11] cpuidle / ux500 : use common ARM " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 04/11] cpuidle / omap3 " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 05/11] cpuidle / davinci : use common ARM driver Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 06/11] cpuidle / at91 : use common ARM cpuidle driver Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 07/11] cpuidle / shmobile " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 08/11] cpuidle / imx " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 09/11] cpuidle / s3c64xx " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 10/11] cpuidle / calxeda " Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 11/11] cpuidle / kirkwood " Daniel Lezcano
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=515098D9.2000107@linaro.org \
--to=daniel.lezcano@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).