On Thu, 2020-09-03 at 11:01 +0200, Cezary Rojewski wrote:
> Hello,
>
> Till v5.4 dpcm_fe_dai_do_trigger was supporting all pcm cmds as each
> case: SND_SOC_DPCM_TRIGGER_PRE/ _POST/ _BESPOKE was simply passing
> cmd's
> value to appropriate variant of _trigger().
>
> Since the addition of:
> acbf27746ecfa96b290b54cc7f05273482ea128a
> ASoC: pcm: update FE/BE trigger order based on the command
>
> additional filters have been introduced for _PRE and _POST cases:
>
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> ret = dpcm_dai_trigger_fe_be(substream, cmd, true);
> break;
> case SNDRV_PCM_TRIGGER_STOP:
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> ret = dpcm_dai_trigger_fe_be(substream, cmd, false);
> break;
> default:
> ret = -EINVAL;
> break;
> }
>
> effectively removing support for _DRAIN command - all requests will
> yield -EINVAL. _BESPOKE was left alone so support remained there.
>
> Now, is DPCM no longer supporting _DRAIN and that's how things should
> be
> -or- DPCM still intends to support _DRAIN and mentioned change is
> unintended regression?
Hi Czarek,
Thanks for bringing this up. It does look like an unintended side-
effect of the aforementioned patch. I dont have a way to test the
support for the DRAIN command. Would you mind sending the fix for this?
Thanks,
Ranjani
