[RFC] cpufreq: Add bindings for CPU clock sharing topology

[Viresh Kumar]

On 21 July 2014 22:30, Rob Herring <rob.herring at linaro.org> wrote:

> To me, but every time I suggest adding things to the topology the ARM
> folks object... I really think we should have built the topology into
> the /cpus hierarchy. Then we could add properties at the correct place
> in the hierarchy where they are common.
>
> I don't really like the proposal here. It just doesn't look like a
> clean description of the h/w.

I knew it wouldn't be easy to get these bindings correctly in the first
attempt atleast, but I still went for it so that this thread can progress:

https://lkml.org/lkml/2014/7/18/3

There are changes waiting to get some kind of intermediate solution
in, so that other platforms can reuse cpufreq-cpu0 driver. Also, so that
cpufreq-cpu0 can be converted to cpufreq-generic, so that it can support
almost any platform.

Can you please reply to that thread to suggest some intermediate
solution that we can get fixed in 3.17? Mvebu and Krait are waiting for
these patches to get in..

The solution can be simple enough as right now we have only two kinds
of platforms:
- All CPUs share clock
- All CPUs have separate clocks

The most simple solution of that could have been a Kconfig entry, but that
would be a problem for multi-arch builds if these platforms do want to get
build with multi-arch config. Otherwise we have to get some binding in
place for 3.17..

Please see if you can get that thread going :)

> Ignoring compatibility, I would like to see something like
> operating-points and/or the clock properties be moved up to /cpus if
> they are shared and be per cpu node when they are not. This of course
> does not work if you have independent OPPs for each cluster with a
> shared clock within cluster.

Yeah, that had always been the issue. People probably tried to get a
cluster {} block as well to simplify that but there were some objections
to it as well, though not sure what happened to that stuff..