[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FE86361.3050603@linaro.org>
Date: Mon, 25 Jun 2012 15:10:57 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: "Shilimkar, Santosh" <santosh.shilimkar@...com>
CC: linux-acpi@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
Lists Linaro-dev <linaro-dev@...ts.linaro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kevin Hilman <khilman@...com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Amit Kucheria <amit.kucheria@...aro.org>,
linux-next@...r.kernel.org, Colin Cross <ccross@...roid.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rob Lee <rob.lee@...aro.org>
Subject: Re: [linux-pm] cpuidle future and improvements
On 06/25/2012 02:58 PM, Shilimkar, Santosh wrote:
> On Mon, Jun 18, 2012 at 7:00 PM, a0393909 <santosh.shilimkar@...com> wrote:
>> Daniel,
>>
>>
>> On 06/18/2012 02:10 PM, Daniel Lezcano wrote:
>>>
>>>
>>> Dear all,
>>>
>>> A few weeks ago, Peter De Schrijver proposed a patch [1] to allow per
>>> cpu latencies. We had a discussion about this patchset because it
>>> reverse the modifications Deepthi did some months ago [2] and we may
>>> want to provide a different implementation.
>>>
>>> The Linaro Connect [3] event bring us the opportunity to meet people
>>> involved in the power management and the cpuidle area for different SoC.
>>>
>>> With the Tegra3 and big.LITTLE architecture, making per cpu latencies
>>> for cpuidle is vital.
>>>
>>> Also, the SoC vendors would like to have the ability to tune their cpu
>>> latencies through the device tree.
>>>
>>> We agreed in the following steps:
>>>
>>> 1. factor out / cleanup the cpuidle code as much as possible
>>> 2. better sharing of code amongst SoC idle drivers by moving common bits
>>> to core code
>>> 3. make the cpuidle_state structure contain only data
>>> 4. add a API to register latencies per cpu
>>>
>>> These four steps impacts all the architecture. I began the factor out
>>> code / cleanup [4] and that has been accepted upstream and I proposed
>>> some modifications [5] but I had a very few answers.
>>>
>> Another thing which we discussed is bringing the CPU cluster/package
>> notion in the core idle code. Couple idle did bring that idea to some
>> extent but in can be further extended and abstracted. Atm, most of
>> the work is done in back-end cpuidle drivers which can be easily
>> abstracted if the "cluster idle" notion is supported in the core layer.
>>
> Are you considering the "cluster idle" as one of the topic ?
Yes, absolutely. ATM, I am looking for refactoring the cpuidle code and
cleanup whenever is possible.
--
<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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists