On Wednesday 10 September 2014 12:10:02 Thomas Petazzoni wrote:

On Wed, 10 Sep 2014 11:53:27 +0200, Arnd Bergmann wrote:

quoted

quoted

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.

quoted

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