On Fri, Jun 02, 2023 at 01:19:08PM +0100, Mark Brown wrote:
On Fri, Jun 02, 2023 at 12:12:52PM +0000, Alvin Šipraga wrote:
On Fri, Jun 02, 2023 at 12:43:51PM +0100, Mark Brown wrote:
Why would we have a property for this and not just describe whatever the actual clocking arrangement is?
Sure - let me just elaborate on my thinking and maybe you can help me with a better approach:
The clocking arrangement is encoded in the dai_fmt field of snd_soc_dai_link, but this is a single value that describes the format on both ends. The current behaviour of ASoC is to flip the clock roles encoded in dai_fmt when applying it to the CPU side of the link.
Looking from a DT perspective, if I do not specify e.g. bitclock-master on either side of the link, then the dai_fmt will describe the codec as a bitclock consumer and (after flipping) the CPU as a provider. That's the default implication of the DT bindings and I can't break compatibility there.
None of this addresses my question. To repeat why would we not just describe the actual clocking arrangement here - this property does not specify where the clock actually comes from at all, we're still going to need additional information for that and if we've described that clock then we already know it's there without having to specify any more properties.
Maybe I overcomplicated your point with my previous reply. Some questions to clarify:
1. You don't like the DT property because it should be inferrable by other means. Correct?
2. As for the flag added to snd_soc_dai_link, do you think that is an OK approach?
Just want to understand which direction you would like me to focus the effort.
Kind regards, Alvin