Status of arch/arm in linux-next

[Linus Walleij]

2011/4/19 Arnd Bergmann <arnd at arndb.de>:
> On Tuesday 19 April 2011, Mark Brown wrote:
>> On Tue, Apr 19, 2011 at 04:16:01PM +0200, Arnd Bergmann wrote:
>>
>> > That sounds like a good idea. Same for the regulator drivers that are
>> > currently in arch/arm instead of drivers/regulator.
>>
>> We don't have any regulator drivers in arch/arm I think (unless the ST
>> one got merged, but that's actually a dual regulator/system management
>> driver rather than a proper regulator - when I reviewed it I didn't flag
>> the location due to the second interface on the side).
>
> I was thinking of arch/arm/mach-ux500/regulator-db8500.c in linux-next.
>
> I can only see regulator contents in there, what do you mean by
> system management?

I will surely put that into drivers/regulator, Mark already requested that
as part of his review.

The problem is that it is dependent on the PRCMU driver which
provides the communication mechanism to actually control these
regulators.

The PRCMU is the Power Reset and Control Management Unit,
it is a register pages where you send commands to a firmware
running on its own CPU on the other side, partly using mailboxes.
The firmware handles things like voltage and power domains
(modeled as regulators), frequency changes (using CPUfreq),
idle states (CPUidle and sleep, idling), as well as resetting
particular memory blocks AND an I2C channel to the AB8500
chip (driven from drivers/ab8500-core.c indeed) and some
GPIO configuration.

We are indeed trying to spread the stuff in there out across
the proper subsystems.

Thinking of it, is it OK to put chip CPUfreq drivers into
drivers/cpufreq/* instead of into the arch/arm/* platform
code as everyone does right now? We could probably
fix that and bring down the diffstat considerably.

Yours,
Linus Walleij