All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	andrew@lunn.ch, magnus.damm@gmail.com, ben-linux@fluff.org,
	nsekhar@ti.com, nicolas.ferre@atmel.com, rob.herring@calxeda.com,
	rjw@sisk.pl, kevin.hilman@linaro.org, horms@verge.net.au,
	kernel@pengutronix.de, kgene.kim@samsung.com,
	plagnioj@jcrosoft.com, linux@maxim.org.za, jason@lakedaemon.net,
	lenb@kernel.org
Subject: Re: [RFC patch 02/11] cpuidle / arm : a single cpuidle driver
Date: Fri, 15 Mar 2013 14:47:05 +0000	[thread overview]
Message-ID: <201303151447.06150.arnd@arndb.de> (raw)
In-Reply-To: <1363357630-22214-3-git-send-email-daniel.lezcano@linaro.org>

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?

Would the same code be used with arch/arm64?

What about other architectures that want to share a cpuidle driver
with and ARM SoC using the same hardware? We have a lot of examples
of SoC vendors that use similar components on ARM and non-ARM SoCs
based on SH, AVR32, Hexagon, C6x, MIPS or PowerPC.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC patch 02/11] cpuidle / arm : a single cpuidle driver
Date: Fri, 15 Mar 2013 14:47:05 +0000	[thread overview]
Message-ID: <201303151447.06150.arnd@arndb.de> (raw)
In-Reply-To: <1363357630-22214-3-git-send-email-daniel.lezcano@linaro.org>

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?

Would the same code be used with arch/arm64?

What about other architectures that want to share a cpuidle driver
with and ARM SoC using the same hardware? We have a lot of examples
of SoC vendors that use similar components on ARM and non-ARM SoCs
based on SH, AVR32, Hexagon, C6x, MIPS or PowerPC.

	Arnd

  reply	other threads:[~2013-03-15 14:50 UTC|newest]

Thread overview: 42+ 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:26 ` 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   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 02/11] cpuidle / arm : a single cpuidle driver Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:47   ` Arnd Bergmann [this message]
2013-03-15 14:47     ` Arnd Bergmann
2013-03-15 15:07     ` Daniel Lezcano
2013-03-15 15:07       ` Daniel Lezcano
2013-03-25 18:27       ` Catalin Marinas
2013-03-25 18:27         ` Catalin Marinas
2013-03-25 18:35         ` Daniel Lezcano
2013-03-25 18:35           ` Daniel Lezcano
2013-03-26  4:31   ` Santosh Shilimkar
2013-03-26  4:31     ` Santosh Shilimkar
2013-03-26 10:58     ` Daniel Lezcano
2013-03-26 10:58       ` Daniel Lezcano
2013-03-26 11:17       ` Andrew Lunn
2013-03-26 11:17         ` Andrew Lunn
2013-03-26 11:44         ` Daniel Lezcano
2013-03-26 11:44           ` Daniel Lezcano
2013-03-26 23:27           ` Rafael J. Wysocki
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   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 04/11] cpuidle / omap3 " Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 05/11] cpuidle / davinci : use common ARM driver Daniel Lezcano
2013-03-15 14:27   ` 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   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 07/11] cpuidle / shmobile " Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 08/11] cpuidle / imx " Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 09/11] cpuidle / s3c64xx " Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 10/11] cpuidle / calxeda " Daniel Lezcano
2013-03-15 14:27   ` Daniel Lezcano
2013-03-15 14:27 ` [RFC patch 11/11] cpuidle / kirkwood " Daniel Lezcano
2013-03-15 14:27   ` 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=201303151447.06150.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=andrew@lunn.ch \
    --cc=ben-linux@fluff.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=horms@verge.net.au \
    --cc=jason@lakedaemon.net \
    --cc=kernel@pengutronix.de \
    --cc=kevin.hilman@linaro.org \
    --cc=kgene.kim@samsung.com \
    --cc=lenb@kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@maxim.org.za \
    --cc=magnus.damm@gmail.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=nsekhar@ti.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=rjw@sisk.pl \
    --cc=rob.herring@calxeda.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.