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
