[RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers

[Sudeep Holla]

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 <arnd at 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 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..
>>>>>
>>>>> 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