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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, Jul 17, 2014 at 11:40 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> On 18 July 2014 11:47, Olof Johansson <olof@xxxxxxxxx> wrote:
>> Why complicate it by using two properties?
>>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>>
>> if there is a clock-master = <phandle> property, then that points at
>> the cpu that is the main one controlling clock for the group.
>>
>> There's really no need to label the master -- it will be the only one
>> with incoming links but nothing outgoing. And a master without slaves
>> is an independently controlled cpu so you should be fine in that
>> aspect too.
>
> I thought so earlier, but then I remembered something I read long back.
> Don't remember which thread now, but I *might* be wrong..
>
> "Bindings are like APIs and new bindings shouldn't break existing stuff.."
>
> And:
>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>
> seems to break the existing API.

What is the current API that is being broken, in your opinion?

> 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?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux