Re: [PATCH 0/4] cpufreq-dt, platform_data based proposal

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com