[PATCH 2/2] ASoC: meson: aiu-formatter: remove pipeline reset from prepare

Valerio Setti vsetti at baylibre.com
Thu Jul 2 13:44:51 PDT 2026



On 7/2/26 1:14 PM, sashiko-bot at kernel.org wrote:

>> diff --git a/sound/soc/meson/aiu-formatter-i2s.c b/sound/soc/meson/aiu-formatter-i2s.c
>> index b4604734fe88d..cb554c2e7ce4a 100644
>> --- a/sound/soc/meson/aiu-formatter-i2s.c
>> +++ b/sound/soc/meson/aiu-formatter-i2s.c
> [ ... ]
>> @@ -55,11 +54,11 @@ static int aiu_formatter_i2s_prepare(struct regmap *map,
>>   {
>>   	/* Always operate in split (classic interleaved) mode */
>>   	unsigned int desc = 0;
>> -	unsigned int tmp;
>>   
>> -	/* Reset required to update the pipeline */
>> -	regmap_write(map, AIU_RST_SOFT, AIU_RST_SOFT_I2S_FAST);
>> -	regmap_read(map, AIU_I2S_SYNC, &tmp);
>> +	/*
>> +	 * Pipeline reset is already implemented in aiu_fifo_i2s_trigger() at
>> +	 * trigger time.
>> +	 */
> 
> [Severity: High]
> Does removing this reset break dynamic DAPM routing (DPCM)?
> 
> When a backend is dynamically connected to an already-running frontend via
> DPCM, the frontend's trigger() callback is not invoked again.
> 
> For example, if the I2S FIFO frontend is started (e.g., routed to the SPDIF
> backend) and then the I2S backend is dynamically connected while the stream is
> running, the "I2S Formatter" DAPM widget powers up and calls
> aiu_formatter_i2s_prepare().
> 
> Without the reset pulse here, will the hardware fail to latch new
> configurations (like AIU_I2S_SOURCE_DESC), potentially resulting in corrupted
> or no audio output from the I2S backend?
> 

I'm not sure about this. The reason I removed the pipeline reset was 
that having it happening after the one on the FIFO side caused the 
stream at 24-bits to be corrupted.
In the scenario described by Sashiko we would have had the pipeline 
reset again after the one from the FIFO (which is continuouly running). 
Moreover I think that this would have happened also before my series 
that was recently merged, i.e. c7852d2dcf66
("ASoC: meson: aiu: align I2S design to the AXG one"), so I have some 
doubt that this could have worked seamlessly also before recent changes.

-- 
Valerio




More information about the linux-amlogic mailing list