[PATCH 5/6] ARM: ux500: move PRCMU functions into the CPUidle driver

Linus Walleij linus.walleij at linaro.org
Mon Mar 25 09:44:00 EDT 2013


On Thu, Mar 21, 2013 at 1:30 PM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On 03/21/2013 01:14 PM, Rickard Andersson wrote:
>> On 03/21/2013 12:49 PM, Linus WALLEIJ wrote:
>>> From: Linus Walleij<linus.walleij at linaro.org>
>>>
>>> We are trying to decompose and decentralize the code in
>>> the DB8500 PRCMU out into subdrivers. The CPUidle code is
>>> calling down into the PRCMU driver basically just to access
>>> these registers, so let's remap them locally in the CPUidle
>>> driver and move the code there, simply. Besides, the PRCMU
>>> code was poking around in the GIC which is the responsibility
>>> of the machine.
>>>
>>> Cc: Daniel Lezcano<daniel.lezcano at linaro.org>
>>> Cc: Rickard Andersson<rickard.andersson at stericsson.com>
>>> Cc: Samuel Ortiz<sameo at linux.intel.com>
>>> Signed-off-by: Linus Walleij<linus.walleij at linaro.org>
>>> ---
>>> Sam, I'm requesting an ACK for taking this through the
>>> ARM SoC tree.
>>> ---
>> This functionality will be used by the platform suspend operation also
>> which I am currently working on. So I would prefer if you can move it to
>> a separate file instead so it can be used by suspend as well. I
>> recommend to have it the same way we have it in our internal track i.e.
>> a file called pm.c in the machine.
>
> That would be nice to move this driver to drivers/cpuidle.
>
> If you are ok with that, I can take care of moving the driver to this
> directory and then create the pm.c file in the mach-ux500 to move the
> prcmu specific code inside. Meanwhile this patch can be merged to group
> the prcmu code needed for the driver and can be easily identified.

If you write a patch like that it needs to go with this patch series
because I need this split out of the PRCMU driver to be able to
move forward with multiplatform.

I tried figuring out if I could just make this split as part of my
patch series which is simpler (then we just merge that into
ARM SoC and you can base CPUidle movement on that).

But then I get into the dilemma of where to put the header
file for these PM functions.

The goal of this series does away with <mach/*> so it can not be
any new <mach/pm.h> header.

The code will need to be called by idle code in drivers/cpuidle
and suspend code in mach-ux500. (Unless suspend/resume shall
also be moved to drivers/cpuidle? I guess not?)

Shall I put it in <linux/platform_data/arm-ux500-pm.h> or so,
with the implementation in arch/arm/mach-ux500/pm.c
or so?

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list