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
