CPUFreq PowerOP integration, Intro 0/3

Integrating CPUFreq and PowerOP was discussed at the Linux PM summit and in recent emails exchanges. Some say keep them separate and some say they must be integrated. There is actually a very natural point where integration makes sense - cpufreq_driver. This patchset presents that integration point and is submitted for discussion.

The patches do not change the functionality of the cpufreq core. Instead the idea is to redesign the tightly coupled interfaces of cpufreq to clearly separate the arch dependent and independent pieces layers. This enables cpufreq to become arch independent and can start to use the named operating points in all its layers.

PowerOP replaces cpufreq driver as the h/w independent interface for operating points. PM core handles the h/w specific details for defining the power parameters and setting the power parameters in h/w registers. Operating point definition/registration is now independent of cpufreq.

Please note, that all userspace/kernel governor concepts, legacy sysfs cpufreq interface remain untouched and SMP case is accounted in the resulting code as well.

Highlights:

cpufreq.c
- get rid of cpufreq driver calls. the calls are replaced be calls to arch independent freq_helpers (freq_helpers.c)
- available frequencies sysfs interface now can be handled in arch independent way
- cpufreq_sysdev_driver now serves only cpufreq core internal needs upon cpu add/remove events (since all hw related is handled by PM Core)
- cpufreq_powerop_call() is added to handle operating point registration in the kernel by an independent module at arbitrary moment

freq_table.c (now freq_helpers.c)
- get rid of cpufreq_frequency_table structures as input parameter and made the code arch independent by leveraging PowerOP interface
- routine remain the same but are no longer used by arch dependent code but by cpufreq core arch independent code instead
- all routines are arch independent; the only shared knowledge is platform power parameter names (string)
- target() method expects power parameter names "freqN", "vN" are supported by PM Core for cpu N
- setpolisy() method expects power parameter names "hfreqN", "lfreqN", "vN" are supported by PM Core for cpu N

Hi,

Just some nitpicking at the description, will cover the patches next.

Well, I don't think that cpufreq_driver is the "natural" point -- in fact, I think it is one of the worst points for the interaction. My alternative suggestion will be the last one of the many mails you'll likely receive from me today :)

cpufreq is arch independent, as can be seen that it is used by many different architectures right now.

Have you considered the drivers which do not use the frequency table helper library in cpufreq?

Also for the case where there are thousands of frequency states? Or only a range to be set, and a in-CPU-mode [longrun]? There's a reason this export is optional.

That sounds like a good step forward -- especially as sysdevs may actually be removed soon. It's orthogonal to the other changes though; i.e. we could do that with the current cpufreq core without switching to PowerOP/"PM core".

arch independent? Well, this helper library is used by different archs already...

Thanks,
Dominik