[RFC 6/8] of: add clock providers

Rob Herring robherring2 at gmail.com
Thu Nov 10 00:59:17 EST 2011


On 11/09/2011 05:23 AM, 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?

You typically only have a frequency property for fixed clocks.

However, we should think about how to set frequency for programmable
clocks. Perhaps this is just making clock-frequency an array of
values in the same order as the outputs.

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

Whether you decide to implement a blob or every single mux, divider, and
gate is independent from whether you use generic clock code or not. You
could simply define a clock controller node with lots of outputs yet
still use generic code to implement clock support in Linux. The reality
is you will probably have a mixture of generic and SOC-specific clocks.

What is our goal here? I'm skeptical we will ever get to the point that
we can fully describe the clock tree for a new SOC without any code
changes. Perhaps our goal is simply that clock differences across all
boards for an SOC can be described in DT.

Rob



More information about the devicetree-discuss mailing list