RFC CPUFreq: create platform-dev for DT based cpufreq drivers
Get series with b4
b4 am 2342930.0NFoS1nEgv@wuerfelVersions newest first
- v1 RFC Latest0 of 8 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers
Quoted 41 lines · On Monday 01 December 2014 15:07:15 Sudeep Holla wrote:
Quoted 31 lines · Arnd Bergmann
Quoted 22 lines · On Monday 01 December 2014 13:35:25 Sudeep Holla wrote:
Quoted 21 lines · Viresh Kumar
Quoted 8 lines · Arnd Bergmann
Thanks a lot for working on this, we really need to figure it out one day!
Your patches seem well-implemented, so if everybody thinks the general approach is the best solution, we should do that. From my point of view, there are two things I would do differently:
Quoted 7 lines
- In the DT binding, I would strongly prefer anything but the root compatible property as the key for the new platforms. Clearly we have to keep using it for the backwards-compatibility case, as you do, but I think there are more appropriate places to put it. Sorting from most favorite to least favorite, my list would be:
1. a new property in /cpus/
2. a new property each /cpus/cpu at ... node.I did it this way earlier and named it dvfs-method but probably putting this into the /cpus/ node is far better. But then Sudeep asked to utilize compatible property only..
Quoted 7 lines
Quoted 2 lines
Are you fine with the name here? "dvfs-method"
That's right, I don't like driver specific method in the cpu node as you initially did. But if it's a property in the chosen node (where we usually put the Linux specific properties), I am fine with that as Arnd has illustrated in his patch.
Quoted 5 lines
I would prefer the /cpus node over the /chosen node because the former describes the hardware while the latter is supposed to be user-settable (on real open-firmware at least). But I think either one is better than using the / node compatible string.
Agreed, the main reason for objection was that in the initial proposal it was more a Linux configuration rather than hardware property.
Quoted 6 lines
<dvfs-method> = "cpufreq-dt";
I don't see anything hardware feature presented with that. On the other hand, we could represent the some thing like whether the cpu share clock or are they independently clocked as a hardware property in the cpu nodes.
My interpretation of the dvfs-method property is that the string states how dvfs works. In particular, it would be used to tell the difference between machines that just rely on the clocks and regulators properties of the CPU nodes as defined in bindings/cpufreq/cpufreq-dt.txt compared to those that need platform-specific properties beyond that. The value of the string should indeed not be "cpufreq-dt", as that would be a linux implementation detail and inappropriate here.
For the strings, we could use a set like
linux,dvfs-method = "generic"; /* bindings/cpufreq/cpufreq-dt.txt */ linux,dvfs-method = "arm,big-little"; /* bindings/cpufreq/arm_big_little_dt.txt */ linux,dvfs-method = "samsung,exynos4210"; /* legacy exynos, all four */ linux,dvfs-method = "samsung,exynos4212"; linux,dvfs-method = "samsung,exynos4412"; linux,dvfs-method = "samsung,exynos5250";
Note that the "linux," prefix here does not mean that the property would not be interpreted by another OS or that it doesn't describe the hardware. Instead, it means that it is defined by linux first and not specific to some other vendor. We could also drop the prefix, but that has the danger of conflicting with another property that someone already defined, while the "linux," namespace is managed through our upstream git and we know that nobody is using this property name.
Quoted 9 lines
Quoted 4 lines
How about a "linux,cpu-dvfs-method" property in the root node? Would that work better for you than a "linux,dvfs-method" in the "/cpus" node?
I will leave that to the DT maintainers for specific details though my preference is still chosen node as it's more related to Linux and it's driver choice and unlikely to be used by other OSes. IMO we just need single entry in the DT, so I am fine with either of your choice above.
Ok.
Arnd