On Wednesday 10 September 2014 11:41:48 Thomas Petazzoni wrote: > We don't seem to be anywhere near reaching an agreement on a DT > binding to represent the topology of CPU clocks in a system, because > it's a complicated matter. Mike doesn't want to add a clock API that > would allow the generic cpufreq driver to find out which CPUs share > clocks, as he believes this is part of the hardware description and > should therefore be described in the DT rather than "guessed" > dynamically at boot time by looking at the clocks referenced by each > CPU. And with Viresh not accepting any machine specific driver, it > results in platforms like Armada XP having no solution to support > cpufreq... > > So this proposal consists in adding a platform_data flag for the > cpufreq-dt driver, which allows platform code to tell whether CPU > clocks are shared or are independent. > > If you don't like platform_data, we can also register two different > platform_driver for the two different cases, simply with different > names. > > 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. 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. Arnd -- 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
