Re: [PATCH V5] Docs/sound: Update codec-to-codec documentation

[anish kumar]

On Tue, Dec 10, 2024 at 3:06 AM Charles Keepax
<ckeepax@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Dec 07, 2024 at 11:34:41AM -0800, anish kumar wrote:
> > +Boot-up logs will display message similar to:
> > +
> > +.. code-block:: text
> > +
> > +   ASoC: registered pcm #0 codec2codec(Playback Codec)
> > +
> > +To trigger this DAI link, a control interface is established by the
> > +DAPM core during internal DAI creation. This interface links to
> > +the ``snd_soc_dai_link_event`` function, which is invoked when a
> > +path connects in the DAPM core. A mixer must be created to trigger
> > +the connection, prompting the DAPM core to evaluate path
> > +connections and call the ``snd_soc_dai_link_event`` callback with
> > +SND_SOC_DAPM_*_PMU and SND_SOC_DAPM_*_PMD events.
> > +
>
> I am still not really following this, what are we trying to
> convey in this paragraph?
>
> What do we mean by a "control interface" here, is that referring
> to the kcontrol that is created to select the rate in the case
> of multiple rates? Or is it simply refering to the fact we call
> snd_soc_dapm_new_control_unlocked? But really that function is
> adding widgets, as I noted in my last email.

I mean snd_soc_dapm_new_control_unlocked gets called to
create the widget which gets triggered as part of DAPM path
enablement.

>
> Also what do we mean by a "A mixer must be created", I am not
> aware of any requirement for a mixer? The DAI link needs to be on
> a valid DAPM path, but I don't see any requirements other than
> that.

In my case, I was implementing a mixer widget that users could
trigger to enable the entire DAPM path. However, I believe it's
sufficient to simply state that there should be a mechanism to
trigger the codec-to-codec widget, enabling the full DAPM path.
>
> Thanks,
> Charles