Re: [PATCH] ASoC: core: Support INPUT and OUTPUT DAPM widgets in DT

[Ivaylo Dimitrov]

On 5.08.26 г. 20:23 ч., Mark Brown wrote:
> On Wed, Aug 05, 2026 at 08:16:10PM +0300, Ivaylo Dimitrov wrote:
>
> > I have an out-of-tree audio-graph-card2 based machine description for
> > Motorola OMAP4 devices using the CPCAP codec together with an external modem
> > codec. Without modelling the remote endpoint as a DAPM INPUT/OUTPUT widget,
> > the DAPM graph is incomplete and one side of the codec-to-codec link does
> > not become active as expected, so runtime PM does not resume one of the
> > devices in the link during a call.
>
> Why is it appropriate that the remote endpoint be a raw widget of this
> non-specific type?
>
> > I used INPUT/OUTPUT because they appear to be the generic DAPM endpoint
> > widgets for this type of digital connection. If there is a more appropriate
> > existing widget type for modelling such a remote DAI endpoint, I'd be happy
> > to use that instead.
>
> If it's a DAI to DAI link you need a custom machine driver, we don't
> have anything like the infrastructure to put DAI<->DAI links in DT.
> These should be using AIF widgets.

Ok, that discussion helped me remember the original reason for the patch.

The issue was not the codec-to-codec DAI link itself. The modem codec 
has playback and capture streams which both need to stay active during a 
voice call, but there was no DAPM path coupling them, so one side of the 
link was not getting activated and runtime PM did not resume the 
corresponding device.

I dropped the DT INPUT/OUTPUT widget addition and the corresponding DT 
routing, and instead added a small DAPM graph fragment in the modem 
codec driver:

SND_SOC_DAPM_MIXER("Voice Call", SND_SOC_NOPM, 0, 0, NULL, 0)

{
	"Voice Call", NULL, "Voice Call Playback",
},
{
	"Voice Call Capture", NULL, "Voice Call",
},

This represents the internal hostless voice-call path in the modem codec 
and makes the codec2codec voice call work.

This may not be the final form I want to use, but it seems to be the 
right place for this piece of topology since it is a property of the 
modem codec rather than of the board routing. I will revisit the 
representation when I prepare the modem codec driver for upstream 
submission.

Thanks for the clarification.

Ivo