Arnd, On Wed, 10 Sep 2014 11:53:27 +0200, Arnd Bergmann wrote: > > Another approach would be to lift the ban on machine-specific cpufreq > > drivers, since the generic driver is not capable of handling all > > situations. > > Using platform_data works nicely if you register the cpufreq device > from the platform code, but that is a particular thing that has > been bugging me for a long time and that I really want to get rid > of: We don't want to introduce platform-specific files for ARM64, > so we have to solve this anyway by just looking at DT, and whatever > solution we end up with should work for both ARM32 and ARM64. Right. Note that there is a similar issue with cpuidle. Maybe each cpufreq/cpuidle driver should simply list of top-level compatible strings it is compatible with, so that at boot time, each cpufreq/cpuidle driver gets a chance to init itself and see whether it is matching the currently running platform. > Most of us will be at LCU next week, so I'd suggest we solve this > problem using the 'lock everyone into one room without beer until > we come up with a working approach' method. That does seem like an interesting idea. However, I initially wanted to push cpufreq support for Armada XP in 3.17, and everything was pushed *except* the cpufreq driver bits. So I was hoping to at least get things working for 3.18. If the discussion takes place next week, and then the time to finally implement something, we'll also miss 3.18. In the mean time, would it be possible to realize that the existing generic cpufreq driver simply isn't generic enough, and that we should accept machine-specific cpufreq drivers for the time being? Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
