[PATCH 1/4] ASoC: soc-pcm: dpcm: fix playback/capture checks

[Pierre-Louis Bossart]

On 6/18/20 10:01 AM, Mark Brown wrote:
> On Wed, Jun 17, 2020 at 07:46:35PM +0200, Stephan Gerhold wrote:
> 
>> At the end the question is if those machine drivers that have
>> dpcm_playback/capture hardcoded just set it because it was required to
>> make DPCM work, or if they actually use it to restrict the direction of
>> a DAI link.

I think those flags are absolutely not DPCM specific, the only use I see 
for the flags is to set:

	if (rtd->dai_link->no_pcm || rtd->dai_link->params) {
		if (playback)
			pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream->private_data = rtd;
		if (capture)
			pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream->private_data = rtd;
		goto out;
	}

and that's why I highlighted some time back that they are probably 
redundant with capture_only and playback_only. We don't need 4 flags to 
specify 2 directions.

In all cases the use for those flags seems to be to restrict the 
direction of a DAI link.

Note that people can screw-up the configurations without DPCM, e.g. by 
not setting capture_only for a microphone, I found last week a WoV DAI 
link on Broadwell where the capture_only flag was not set... DPCM does 
not have a monopoly on brokenness...

> The other question would be if they are restricting it to limit the
> direction of a DAI link beyond the limits that the hardware has why are
> they doing that?  I'm not sure that'd be a sensible thing to do.

I don't see any such case. When both directions are not set, it's only 
because the hardware is only capable of one, e.g. dmic, HDMI or SoundWire.

There's one set of cases where we have amplifiers on an SSP link (which 
is bidirectional), but the amplifier itself does not provide any 
capture/feedback. That part is probably borderline incorrect, but 
harmless since the topology does not try to use those links for capture.