On Sat, Jul 19, 2014 at 10:24 AM, Santosh Shilimkar santosh.shilimkar@ti.com wrote:
Viresh,
On Saturday 19 July 2014 10:46 AM, Viresh Kumar wrote:
On 19 July 2014 03:22, Olof Johansson olof@lixom.net wrote:
What is the current API that is being broken, in your opinion?
So, currently the nodes doesn't have any such property. And drivers consider all of them as sharing clocks, for eg: cpufreq-cpu0.
Now, if we use those older DT's after the new changes, drivers would consider CPUs as having separate clocks. And that would be opposite of what currently happens.
Not sure if this counts as broken.
But if that isn't the case, the bindings are very simple & clear to handle. Diff for new bindings:
It's somewhat confusing to see a diff to the patch instead of a new version. It seems to remove the cpu 0 entry now?
Not really, I removed an unwanted example. This is how it looks:
- Generic CPUFreq clock bindings
Clock lines may or may not be shared among different CPUs on a platform.
Possible configurations: 1.) All CPUs share a single clock line 2.) All CPUs have independent clock lines 3.) CPUs within a group/cluster share clock line but each group/cluster have a separate line for itself
Optional Properties:
clock-master: Contains phandle of the master cpu controlling clocks.
Ideally there is nothing like a "master" CPU as any CPU can play with DVFS settings. But we have to choose one cpu out of a group, so that others can point to it.
If there is no "clock-master" property for a cpu node, it is considered as master. It may or may not have other slave CPUs pointing towards it.
Sorry for jumping late, but one of the point I was raising as part of your other series was to extend the CPU topology bindings to cover the voltage domain information which is probably what is really needed to let the CPUfreq extract the information. Not sure if it was already discussed.
After all the CPU clocks, cluster, clock-gating, power domains are pretty much related. So instead of having new binding for CPUFreq, I was wondering whether we can extend the CPU topology binding information to include missing information. Scheduler work anyway needs that information.
Ref: Documentation/devicetree/bindings/arm/topology.txt
Does that make sense ?
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.
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.
The operating-points binding has obvious shortcomings and this is another example. Someone needs to step up with a new binding that addresses this and all other issues (e.g. turbo modes, extra per OPP data, etc.). I don't really want to see halfway fixes to the binding that ignore the other issues (unless there is a really simple solution).
Rob