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

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 10 September 2014 12:10:02 Thomas Petazzoni wrote:
> On Wed, 10 Sep 2014 11:53:27 +0200, Arnd Bergmann wrote:
> 
> > > 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.
> 
> Right. Note that there is a similar issue with cpuidle.
> 
> Maybe each cpufreq/cpuidle driver should simply list of top-level
> compatible strings it is compatible with, so that at boot time, each
> cpufreq/cpuidle driver gets a chance to init itself and see whether it
> is matching the currently running platform.

The main problem I see with that is that it requires updating
the driver for every new platform we want to support. It would
be better to find a way that lets you add new platforms using just
new dts files that work with the existing driver.

This is the main reason why we try to never match the root
compatible property in any driver, and I don't think cpufreq
should be an exception to this just because it can't easily be
mapped to a particular register set.

> > 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.
> 
> That does seem like an interesting idea. However, I initially wanted to
> push cpufreq support for Armada XP in 3.17, and everything was pushed
> *except* the cpufreq driver bits. So I was hoping to at least get
> things working for 3.18. If the discussion takes place next week, and
> then the time to finally implement something, we'll also miss 3.18.

I see.

> In the mean time, would it be possible to realize that the existing
> generic cpufreq driver simply isn't generic enough, and that we should
> accept machine-specific cpufreq drivers for the time being?

That would work for me, to get things going for 3.18, but it's really
up to the cpufreq maintainers. Your platform_data based patch set
seems like a better solution to me than separate drivers, but I haven't
looked at the details.

	Arnd