Hi, Just some nitpicking at the description, will cover the patches next. On Thu, Sep 14, 2006 at 06:42:26PM +0400, Eugeny S. Mints wrote: > 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. 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 :) > 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. cpufreq is arch independent, as can be seen that it is used by many different architectures right now. > cpufreq.c > - get rid of cpufreq driver calls. the calls are replaced be calls to arch > independent freq_helpers (freq_helpers.c) Have you considered the drivers which do not use the frequency table helper library in cpufreq? > - available frequencies sysfs interface now can be handled in arch > independent way 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. > - cpufreq_sysdev_driver now serves only cpufreq core internal needs upon cpu > add/remove events (since all hw related is handled by PM Core) 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". > 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 arch independent? Well, this helper library is used by different archs already... Thanks, Dominik
