On 01/12/14 16:03, Arnd Bergmann wrote:
On Monday 01 December 2014 15:07:15 Sudeep Holla wrote:
On 01/12/14 14:11, Arnd Bergmann wrote:
On Monday 01 December 2014 13:35:25 Sudeep Holla wrote:
On 01/12/14 13:29, Viresh Kumar wrote:
On 1 December 2014 at 18:24, Arnd Bergmann <a...@arndb.de> wrote:
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:
- 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@... 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..
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.
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.
<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.
May be I misunderstood, but from Viresh's initial proposal my
understanding was that the value of the property would indicate that it
should use the cpufreq-dt driver and that sounded like Linux specific.
If it's not going to be used in that manner and is what have explained
above, I am fine with that as that's exactly what I am trying to convey
in this thread(though I now realize that I have not been so clear :( )
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
