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.
Yes I see what you mean. On my platform the clock source is actually described
by the common clock framework, so I would want to use that. If it were a
component driver then it would most likely be a codec that is part of the
dai-link anyway. So what about having two struct clk pointers in struct
snd_soc_dai?
struct snd_soc_dai {
/* ... */
struct clk *bitclock_provider;
struct clk *frameclock_provider;
/* ... */
};
If non-NULL I could then have the ASoC core enable/disable the clocks on demand?
I would say in hw_params/hw_free, albeit that runs after set_fmt.
Having said that, I see ASoC doesn't really use the CCF much... am I way off?
I don't think it's feasible to modify every component driver to explicitly
handle this and then ignore any CBP_CFP bits set in its call to set_fmt - this
is why I want help from the ASoC core.
>
> > The other issue is that for the simple-card the DAI format is only parsed in one
> > place and applied to the whole link. Are you proposing that it be modified to
> > explicitly try and parse both ends in order to determine if both sides want to
> > be clock consumers? In that case I'd have to also introduce bitclock-consumer
> > and frameclock-consumer properties to mirror the existing bitclock-master and
> > frameclock-master properties, as an explicit absence of the *-master property on
> > both sides would have to default to the original ASoC behaviour described above.
>
> If simple-card can't be made to work that's fine, it's deprecated
> anyway.
Ah OK, I didn't know that. Right now I'm using graph-card2, that's not
deprecated, right?
Kind regards,
Alvin
