On Thu, May 31, 2018 at 3:03 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
> On Thursday, May 31, 2018 07:02 PM, Rob Herring wrote:
>>
>> On Tue, May 29, 2018 at 10:23:48PM +0200, Daniel Mack wrote:
>
>
>>> If that's the case, could you depict how the DT bindings should look like
>>> by
>>> example?
>>
>>
>> In clock providers, you just add #clock-cells. Then the consumer side
>> defines 'clocks'. Which clock(s) comes from the dai is defined by the
>> index in the 'clocks' property for that node.
>>
>> Both ends can be providers, but who is active is determined by defining
>> the actual connections with 'clocks'. Or perhaps you have both
>> directions shown and there is some other means to select which one is
>> active such as solving for who can provide the desired freq.
>
>
> How about entities that are a clock producer and consume their clocks
> themselves? That's a rather typical thing for DAIs. Is that expressible in
> DT?
And I assume something else consumes those clocks, too? If not, you
can just handle all that within the driver and don't need the clock
binding or clock framework.
But yes, you can do something like this:
myclk: clock-controller {
#clock-cells = <1>;
clocks = <&myclk 123>, <&otherclk 1>;
};
You'll have to handle clk registration and clk_get in the right order
to avoid deferring probe on yourself.
Rob
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
