linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Tue, 26 Mar 2013 11:58:36 +0100	[thread overview]
Message-ID: <51517F5C.3090505@linaro.org> (raw)
In-Reply-To: <5151249D.4000602@ti.com>

On 03/26/2013 05:31 AM, Santosh Shilimkar wrote:
> On Friday 15 March 2013 07:57 PM, 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>
>> ---
> While I appreciate the effort behind code consolidation, $subject is
> bit confusing. You are just abstracting the registration code to one
> common place and I don't know why it has to be limited to arm-idle
> since it is very generic code. That is true even for the broad-cast
> notifier setup which is same across all arch's including ARM, X86.

[ ... ]


Ok, I should have put a subject:

"cpuidle / arm : a single cpuidle driver : step 1"

As I mentioned earlier, these init functions will be modified. This is
why I prefer ATM to keep these initialization in this file.

When the consolidation reach an acceptable state, then all the arch will
be consolidated in the generic framework for the common parts.

>> +
>> +	if (use_broadcast_timer)
>> +		arm_idle_timer_broadcast(false);
>> +}
>> +EXPORT_SYMBOL_GPL(arm_idle_exit);
>>
> All above code is completly generic and I would rather create
> some thing like "drivers/cpuidle/generic-idle.c" where it can
> handle all the registration stuff for all arch's rather than
> just ARM. There is nothing ARM specific in above code IMHO.

Yes, it seems generic but it won't be.

There is my tree at

http://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=shortlog;h=refs/heads/linux-pm-next

So you can see a part of the evolution of the patchset.

-- 
 <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

  reply	other threads:[~2013-03-26 10:58 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
2013-03-26  4:31   ` Santosh Shilimkar
2013-03-26 10:58     ` Daniel Lezcano [this message]
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=51517F5C.3090505@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).