Re: [PATCH v4 05/26] ASoC: soc-compress: Implement trigger FE-BE sequencing as with normal PCMs

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 06/10/2026 12:12, Mark Brown wrote:
> On Wed, Sep 16, 2026 at 03:02:59PM +0300, Peter Ujfalusi wrote:
>> The FE-BE trigger sequence should be dynamic, similarly how soc-pcm.c
>> dpcm_fe_dai_do_trigger() does it.
> 
>> -static int soc_compr_trigger_fe(struct snd_compr_stream *cstream, int cmd)
>> +static int soc_compr_trigger_fe_be(struct snd_compr_stream *cstream, int cmd,
>> +				   bool fe_first)
>>  {
> 
>> +	} else {
>> +		dev_dbg(fe->dev, "ASoC: post trigger FE %s cmd %d\n",
>> +			fe->dai_link->name, cmd);
>> +
>> +		ret = dpcm_be_dai_trigger(fe, cstream->direction, cmd);
>> +		if (ret < 0)
>> +			goto out;
>> +
>> +		ret = snd_soc_dai_compr_trigger(cpu_dai, cstream, cmd);
>> +		if (ret < 0)
>> +			goto out;
>> +
>> +		ret = snd_soc_component_compr_trigger(cstream, cmd);
>> +	}
> 
> Shouldn't we unwind the triggered front/back ends if a later one fails?

This mirrors dpcm_dai_trigger_fe_be() in soc-pcm.c, which does not
unwind either: it bails out on the first error and returns it. One level
down, dpcm_be_dai_trigger() only drops the be_start count of the BE that
failed and carries on with the remaining BEs, so already triggered BEs
are left as they are there as well.

The missing unwind on the FE side is not new, the code before this patch
had the same sequence (DAI trigger, then component trigger) with the
same early return.

What is new is the order: STOP/SUSPEND/PAUSE_PUSH now trigger the BEs
before the FE, so 'BEs triggered, FE trigger failed' is a case which did
not exist before this patch.

I can add the unwind, but I would rather do it for soc-pcm.c and
soc-compress.c in a separate patch so that the compressed path does not
diverge from the PCM one. It is not quite mechanical either: the command
needed to unwind depends on the failing command (STOP for a failed
START, PAUSE_PUSH for a failed PAUSE_RELEASE) and it has to deal with
the BE refcounts and the pause/stop transition handling.

Would it be OK if I send a followup series to cover both at the same time?

-- 
Péter