Dear Viresh Kumar,
On Wed, 10 Sep 2014 16:08:51 +0530, Viresh Kumar wrote:
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.
Sure, but when "existing infrastructure" isn't ready to support a particular use case, and there seems to be no solution on which people are agreeing?
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..
I personally don't think it would be a very good idea: in this case, you'd better do a complete cpufreq driver on its own. Doing subsystems in subsystems just for the sake of factorizing 10 lines of initialization seems a bit silly to me.
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..
Ok, I'll respin with a different solution than the flags.
Thanks,
Thomas