On 10 September 2014 15:11, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > And with Viresh not accepting any machine specific driver, it Its not that we aren't accepting any drivers at all, but if we can reuse existing infrastructure then we better use it for long term maintainability. But there is another view here which Mike objected to, sometime back. Its also not a good idea to push everything onto a virtual-cpu-clock driver.. I had something in mind to get that fixed, but this thread hasn't allowed me to work on that as it should be finished first. Probably we can add some callbacks to the cpufreq-cpu0 driver. For example if somebody wants to do something crazy enough in their ->target() routine then they can just register their callback and we will call it instead of cpufreq-dt's target() routine.. That way we can still reuse the common part.. > 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. The platform-data solution is better than any other here :), and that will get fixed once we get all this including which driver to probe from DT.. -- 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
