Re: [PATCH RFC v2] ASoC: cs43130: Take the frame layout from set_tdm_slot()

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Fri, Oct 23, 2026 at 06:32:06PM +0200, Olivier Louvignes wrote:
> hw_params() derives the slot width from the frequency given to the DAI's
> set_sysclk(), which it takes for SCLK. Generic cards pass MCLK there: the
> simple-audio-card of a HiBy R1 (Ingenic X1600 as I2S master, 64 bit
> clocks per frame, mclk-fs = 512) hands over 22.5792 MHz, so the driver
> sets up 256-bit slots for a 44.1 kHz stream and the CS43131 plays white
> noise. The card cannot simply leave mclk-fs out: simple-audio-card then
> sets no clock on the I2S controller either, and the codec, as clock
> slave, fails hw_params() with "SCLK freq is not set".
> 
> Add a set_tdm_slot() callback so the card can give the layout instead.
> The two channels go to the first and second slots set in tx_mask, within
> frames of 16 to 64 bits, the sizes the serial port clock tables cover.
> When set, the layout takes precedence over the one derived from
> set_sysclk(); zero slots go back to deriving it.
> 
> Tested on a HiBy R1, on v7.3, with dai-tdm-slot-num = <2> and
> dai-tdm-slot-width = <32> on the codec node.
> 
> Signed-off-by: Olivier Louvignes <olivier@mgcrea.io>
> ---
> +static int cs43130_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask,
> +				unsigned int rx_mask, int slots, int slot_width)
> +{
> +	struct snd_soc_component *component = dai->component;
> +	struct cs43130_private *cs43130 = snd_soc_component_get_drvdata(component);
> +	struct cs43130_dai *cs_dai = &cs43130->dais[dai->id];
> +	unsigned int frm_size = slots * slot_width;
> +
> +	if (!slots) {
> +		cs_dai->slots = 0;
> +		cs_dai->slot_width = 0;
> +		return 0;
> +	}
> +	if (slots < 0 || slot_width < 16 || slot_width > 32 ||
> +	    frm_size > 64 || frm_size % 16)
> +		return -EINVAL;
> +	if (!tx_mask || hweight32(tx_mask) > 2 || tx_mask >= BIT(slots))
> +		return -EINVAL;

Should we not be using rx_mask here? I think set_tdm is usually
centric to the device.

Otherwise, I think this looks good to me.

Thanks,
Charles