[RFC 6/8] of: add clock providers

[Cousson, Benoit]

On 11/9/2011 12:49 PM, Sascha Hauer wrote:
> On Wed, Nov 09, 2011 at 12:23:25PM +0100, Cousson, Benoit wrote:
>> On 11/9/2011 10:13 AM, Sascha Hauer wrote:
>>> On Tue, Nov 08, 2011 at 06:19:41PM -0700, Grant Likely wrote:
>>
>> [...]
>>
>>>> +Sources of clock signal can be represented by any node in the device
>>>> +tree.  Those nodes are designated as clock providers.  Clock consumer
>>>> +nodes use a phandle and clock specifier pair to connect clock provider
>>>> +outputs to clock inputs.  Similar to the gpio specifiers, a clock
>>>> +specifier is an array of one more more cells identifying the clock
>>>> +output on a device.  The length of a clock specifier is defined by the
>>>> +value of a #clock-cells property in the clock provider node.
>>>> +
>>>> +[1] http://patchwork.ozlabs.org/patch/31551/
>>>> +
>>>> +==Clock providers==
>>>> +
>>>> +Required properties:
>>>> +#clock-cells:	   Number of cells in a clock specifier; typically will be
>>>> +		   set to 1
>>>> +
>>>> +Optional properties:
>>>> +clock-output-name: Recommended to be a list of strings of clock output signal
>>>> +		   names indexed by the first cell in the clock specifier.
>>>> +		   However, the meaning of clock-output-names is domain
>>>> +		   specific to the clock provider, and is only provided to
>>>> +		   encourage using the same meaning for the majority of clock
>>>> +		   providers.  This format may not work for clock providers
>>>> +		   using a complex clock specifier format.  In those cases it
>>>> +		   is recommended to omit this property and create a binding
>>>> +		   specific names property.
>>>
>>> If the clock-output-name property is omitted, does this mean a clock
>>> provider only has a single output or does it mean that it's not known
>>> how many clock outputs a provider actually has?
>>
>> Allowing several outputs for a single clock node might lead to a lot
>> of confusion. What will be the meaning of a clock rate if you have
>> several outputs at different frequency?
>> I think it will be better to define a clock node as a single source
>> of clock. If several outputs are needed, then we should define
>> several clock nodes.
>> If we let a clock node be any kind of big clock blob, we will never
>> be able to define some generic reusable clock node API. Everybody
>> will define its own custom clock blobs.
>
> Generally +1. I asked myself the same question whether it's a good thing
> to allow a node to have multiple clocks. For i.MX I can say that I don't
> need this and that I do not intend to use this feature. Grants concerns
> about this are that the clock part of the device tree might explode when
> we put each and every clock into the devicetree, so he wants to allow
> bigger blobs of multiple clocks.

I can clearly understand this concern, because in the case of OMAP4, we 
will have to add ~250 nodes if we want to define the current clock tree.

> My impression gets more and more that we either put the clock tree in the
> devicetree or we do not do it, but there's not much room in between.

If we are not ready to accept 4k lines of clock data inside the 
devicetree, which is indeed huge and mostly useless, then I think we 
should just expose the leaf clocks. But then they will depend on parent 
that will not be in DT but in static files, which might be weird.

I'm not sure what the right answer is :-(

Regards,
Benoit