Hello, Here is a proposal to solve the cpufreq-dt issue. 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. Thomas Thomas Petazzoni (4): cpufreq: allow driver-specific flags cpufreq: cpufreq-dt: extend with platform_data ARM: mvebu: use the cpufreq-dt platform_data for independent clocks cpufreq: cpufreq-dt: remove warning about regulators arch/arm/mach-mvebu/pmsu.c | 8 +++++++- drivers/cpufreq/cpufreq-dt.c | 23 ++++++++++++++++++----- drivers/cpufreq/cpufreq.c | 15 +++++++++++++++ include/linux/cpufreq-dt.h | 22 ++++++++++++++++++++++ include/linux/cpufreq.h | 5 ++++- 5 files changed, 66 insertions(+), 7 deletions(-) create mode 100644 include/linux/cpufreq-dt.h -- 2.0.0 -- 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
