[REGRESSION] Re: [PATCH v1] ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Detlev,

On Fri Jan 17, 2025 at 5:31 PM CET, Detlev Casanova wrote:
> In commit
> 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"),
> the set_sysclk callback was removed as considered unused as the mclk rate
> can be set in the hw_params callback.
> The difference between hw_params and set_sysclk is that the former is
> called with the audio sampling rate set in the params (e.g.: 48000 Hz)
> while the latter is called with a clock rate already computed with
>   sampling_rate * mclk-fs (e.g.: 48000 * 256)
>
> For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must
> be set to 128 instead of the default 256, and that value is set in the
> device tree at the machine driver level (like a simple-audio-card
> compatible node).
> Therefore, the i2s_tdm driver has no idea that another mclk-fs value can
> be configured and simply computes the mclk rate in the hw_params callback
> with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI
> audio.
>
> Re-add the set_sysclk callback so that the mclk rate is computed by the
> machine driver which has the correct mclk-fs value set in its device tree
> node.

I'm afraid I just found this commit breaks audio capture on the RK3308.

Using 'arecord -Vmono -d 2 -c 8 -f S16_LE -r 96000 /dev/null' I get:

  rockchip-i2s-tdm ff320000.i2s: ASoC error (-22): at snd_soc_dai_hw_params() on ff320000.i2s
   ff320000.i2s-rk3308-hifi: ASoC error (-22): at __soc_pcm_hw_params() on ff320000.i2s-rk3308-hifi

Tested on:

 * Radxa Rock Pi S
 * Upstream kernel
 * arm64 defconfig

Tested kernel versions:

 * v6.12 works
 * 5323186e2e8d (this commit) fails
 * 5323186e2e8d^ works
 * 21cfbeae7d7c (same patch on stable/linux-6.12.y) fails
 * 21cfbeae7d7c^ works
 * v6.19 fails
 * v6.19 + 'git revert 5323186e2e8d' works

I don't have more information at the moment.

> Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates")

I'm the author of commit 9e2ab4b18ebd mentioned in the 'Fixes:' tag, so it
would have been good to Cc me. I would have had the option of testing your
patch and this regression could have been solved before getting in
mainline. I think b4 does it automatically (and perhaps get_maintainers
with appropriate flags).

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com