Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties

[Richard Fitzgerald <rf@opensource.cirrus.com>]

On 15/01/2021 13:11, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>> On 13/01/2021 16:09, Mark Brown wrote:
>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> some_codec {
>> 	pll: pll {
>> 		compatible = "fixed-clock";
>> 		clocks = <&audio_mclk>;
>> 		clock-frequency = <98304000>;
>> 	}
> 
> A PLL is not a fixed clock, why would you define a fixed clock here?

It's a fixed clock if you are only setting one configuration. Call it
compatible="any-other-dummy-clock-type" if you like, it doesn't matter
what it is for the purposes of what I was describing.

This isn't a clk driver for a pll, it's just a setting to be passed to
snd_soc_component_set_pll() using a clock binding to specify it.

> Are you confusing the selection of rates on existing clocks with the use
> of the assigned-* properties that the clock binding provides?
> 

I'm not at all sure what you and Rob have in mind here. Perhaps you
could give an example of what you are thinking the .dts would look like
to define some pll/sysclk settings for audio-graph-card to apply. An
example is worth a thousand emails.

>> For this to work the clock binding must be a real clock object (so needs
>> a valid compatible=). But I need to somehow specify the PLL ID and
> 
> That seems like a *very* surprising requirement - why would the clock
> binding have that requirement?  It would seem to create issues for a
> single device providing multiple clocks which should be a pretty common
> coase.
> 

You misunderstand me. What I'm saying is that to do this:

	sound {
		clocks = <&pll>;
	}

The node 'pll' must correspond to a clock provider driver. It can't be
just a bare node with some properties pick-n-mixed from the clock
binding, like this:

	pll1 : pll1 {
		clock-frequency = <98304000>;
	};

which doesn't define a compatible= to match it to a clk driver. An
attempt to bulk_get the machine driver clocks here will fail.

To use a bare node with pick-n-mixed useful clock binding properties,
that doesn't represent a real clk provider driver, it would have to be
pointed to by a custom property that is not treated as a clk framework
object, e.g.:

	sound {
		audio-graph-card,plls = <&pll>;
	}

In this case pll is a node parsed by audio-graph-card that just happens
to use properties from the clock binding.

So the question I'm trying to ask is: when you and Rob said use
the clock binding, did you mean pointing to that binding from
clocks=<...>, or from a custom property like my audio-graph-card,plls
example above.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel