[PATCH v2] ASoC: meson: aiu-formatter-i2s: remove pipeline reset from prepare
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Thu Jul 2 14:42:39 PDT 2026
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] The formatter is configured in the ALSA `.trigger` callback rather than `.prepare`, causing it to be updated after the FIFO has already been enabled and is actively streaming data.
--
commit 8c488e8a8134ef43be2df030518f521b015aa61c
Author: Valerio Setti <vsetti at baylibre.com>
ASoC: meson: aiu-formatter-i2s: remove pipeline reset from prepare
This commit removes a pipeline reset from the AIU I2S formatter prepare
callback. The reset is already handled by the DAI frontend during trigger,
and duplicating it here corrupts playback in 24-bit mode since the FIFO
has already been started.
> 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: Medium]
This is a pre-existing issue, but does the formatter configuration happen too
late in the sequence?
The commit notes that the frontend starts the FIFO before this formatter
gets configured. Looking at the call chain, aiu_formatter_i2s_prepare() in
sound/soc/meson/aiu-formatter-i2s.c is executed during the ALSA trigger
phase instead of the prepare phase:
sound/soc/meson/aiu-encoder-i2s.c:aiu_encoder_i2s_trigger()
ret = gx_stream_start(ts);
sound/soc/meson/gx-formatter.c:gx_formatter_enable()
ret = formatter->drv->ops->prepare(formatter->map,
formatter->drv->quirks,
formatter->stream);
Modifying hardware data path configuration like bit width and channel count
while the DMA FIFO is already feeding data to it can cause audio glitches,
dropped samples, or corruption at the start of playback.
Could the formatter configuration be moved to the actual ALSA prepare
callback rather than being deferred to the trigger callback?
>
> switch (ts->physical_width) {
> case 16: /* Nothing to do */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-fix-24-bit-i2s-playback-v2-1-9c008ff0b211@baylibre.com?part=1
More information about the linux-amlogic
mailing list