[RFC] dpcm_fe_dai_do_trigger: implicit removal of _DRAIN cmd since v5.4

[RFC] dpcm_fe_dai_do_trigger: implicit removal of _DRAIN cmd since v5.4

[Cezary Rojewski]

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?

Czarek

Re: [RFC] dpcm_fe_dai_do_trigger: implicit removal of _DRAIN cmd since v5.4

[Sridharan, Ranjani]

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