On 15/01/2021 15:20, Mark Brown wrote:
On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
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.
So you're trying to describe a crystal on the board? Why would this be
a subnode of the CODEC then? Surely it's just a standard fixed clock
which provides some input to the CODEC in the same way you'd describe
any other input to the CODEC. The above doesn't look anything like the
hardware. But if that's what you're doing how is that related to
configuring the FLL except possibly as the input clock you'd reference?
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.
As far as I can tell you are trying to configure the FLL in the CODEC,
telling it to take an input clock and produce a fixed output clock rate
from that. The FLL is a fairly basic clock, there are examples for both
that and choosing a configuration for a clock in the clock bindings.
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:
I'm pretty sure I understand you perfectly; again, what makes you say
that a description of a clock in the device tree has any requirement
for a separate compatible string?
If I do:
sound {
clocks = <&clock>;
};
clock: clock {
compatible = "fixed-clock";
clock-frequency = <98304000>;
};
I can clk_bulk_get_all().
But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
will return -EPROBE_DEFER and log:
/sound: Failed to get clk index: 0 ret: -517
from the error case in _clk_bulk_get() in clk/clk-bulk.c.
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.
When we say to use the clock binding what we are saying is to use the
actual clock bindings to describe the clocks, not make a custom binding
that looks kind of like them - making a custom binding doesn't address
the problem.
But I don't know what you mean by "use the actual clock bindings to
describe the clocks".
What is not clear to me is how you want me to use a clock binding to
describe something that isn't a clk-framework clk. If you know what you
want, then please.. an example would help explain.
