Hi Mark Rutland
Thank you for your feedback
> > It means "if system doesn't support common clock".
> > I will fix it
>
> When you say "doesn't support common clock", you mean the code for that
> platform is incompatible with the common clock framework? It seems very
> messy to allow a Linux-internal implementation detail (which is expected
> to change) to leak into a binding...
Some CPU doesn't support common clock, like PowerPC (?)
This is Mark (Brown) comment
--------------------
So, ideally. However we have to consider the fact that the clock API
isn't reliably available makes this harder than it should be. Even
among the DT using platforms at least PowerPC still uses a custom clock
API. We could just use this as a carrot to push people to convert
though.
---------------------
> > > > + of_property_read_u32(np,
> > > > + "system-clock-frequency",
> > > > + &dai->sysclk);
> > >
> > > What it this isn't present?
> >
> > If sysclk doesn't have common clock support
>
> Huh? That's not what I asked.
>
> What if the dt has neither a clock or a system-clock-frequency property?
OK, sorry for my English
This happen if cpu/codec was slave, not strange things.
Please check "Example". in there, "simple-audio,codec" has clocks
but, "simple-audio,cpu" doesn't have it, and "simple-audio,codec" has
"bitclock-master" and "frame-master";
This case, codec chip creates audio play/capture clock from system clock,
and "cpu" use it.
This is the reason why the name is "system-clock-frequency" instead of "clock-frequency"
The image is like this
clocks / +- simple card --+
system clock | |-> playback
-------------+-[codec]--[cpu] |
| |<- capture
+----------------+
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
