Re: [RFC v2 4/9] of: add clock providers

[Grant Likely]

On Tue, Jan 17, 2012 at 1:44 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Grant Likely wrote at Monday, December 12, 2011 3:02 PM:
>> +This DT fragment defines three devices: an external oscillator to provide a
>> +low-frequency reference clock, a PLL device to generate a higher frequency
>> +clock signal, and a UART.
>> +
>> +* The oscillator is fixed-frequency, and provides one clock output, named "osc".
>> +* The PLL is both a clock provider and a clock consumer. It uses the clock
>> +  signal generated by the external oscillator, and provides two output signals
>> +  ("pll" and "pll-switched").
>> +* The UART has its baud clock connected the external oscillator and its
>> +  register clock connected to the PLL clock (the "pll-switched" signal)
>
> In the example above, the UART's register clock's parent is the PLL, and
> the PLL's parent is the OSC. Is the intention to have this parenting set
> up automatically by the core OF clock code, or is this something that each
> individual driver needs to set up itself.
>
> In other words, does the UART driver need to do something like:
>
> clk_reg = clk_get(dev, "register");
> clk_parent = of_clk_get_by_name(np, "register);
> clk_set_parent(clk_reg, clk_parent);
>
> Or will that all happen transparently within just the of_clk_get_by_name
> call?
>
> (I suppose this question makes slightly more sense for the PLL itself,
> since both the upstream and downstream clocks are represented in the PLL
> node, whereas the UART's node only represents the clock consumer side,
> so the above code isn't really possible automatically).

The intent is that device only interacts with the leaf device.  If the
clocks are arranged into a hierarchy, then the clock driver is
responsible for any interactions with the parent clock.  Requiring the
driver to manipulate parent clocks directly defeats the purpose of
having a clock abstraction.

> Somewhat related to this: How does dynamic reparenting interact with
> the DT clock binding; is the DT just the default/initial clock setup,
> and anything beyond that needs a custom binding and code in the consumer?

As far as the clock binding goes, it only describes provider/consumer
relationships.  The fact that such relationships may resolve to a
hierarchy is beyond what the binding describes.  If a clock has
multiple possible parents, then that specific clock binding should
document how the multiple parent clocks are described and the clock
driver is responsible for implementing the correct behaviour.

Similarly, the DT clock binding provides no generic mechanism for
walking up the clock tree.  That behaviour must also be implemented by
each specific clock driver.

> I'm thinking of say a system with 1 I2S controller, and both an internal
> and external I2S clock source, where perhaps the internal source needs
> to be used to capture from an I2S interface on one set of pins (e.g.
> analog mic) but the other clock source needs to be used to capture from
> I2S on another set of pins (e.g. digital baseband unit connection).
> (This example is theoretical, but I'm sure there are other dynamic clock
> cases in practice).

That is a reasonable example.  In this case, the i2c controller would
include both in its clocks property, and the binding would document
when and why each clock source is used.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/