On Thu, Jun 18, 2020 at 10:45:45AM -0500, Pierre-Louis Bossart wrote:
> 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.
>
If we end up simplifying those flags, and eventually removing
dpcm_playback/capture entirely, wouldn't it be the easiest solution to
just relax the error checks for 5.8? (Like the diff I suggested?)
Pierre's diff to set dpcm_playback/capture correctly for
simple-audio-card etc would work too, but I'm not sure if this is worth
it if we end up removing those anyway.
Thanks,
Stephan
