Date:   Fri, 2 Jun 2023 12:42:49 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Mark Brown <broonie@...nel.org>
CC:     Alvin Šipraga <alvin@...s.dk>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] ASoC: dt-bindings: document new symmetric-clock-role
 flag

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

Powered by blists - more mailing lists