On Tuesday 19 April 2011, Linus Walleij wrote: > 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. Ok, thanks for the explanation. > 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. That's something to discuss with Dave Jones and other people interested in cpufre. Right now, all cpufreq drivers, including those for other architectures are in arch/. I think it would be good to have the out of the individual platforms, in particular in order to get better reviews of new cpufreq drivers by people that are interested in them. Arnd -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
