[PATCH v2 1/2] ASoC: fsl_sai: add bitcount and timestamp controls

[Shengjiu Wang]

On Tue, Mar 3, 2026 at 8:25 AM Mark Brown <broonie at kernel.org> wrote:
>
> On Thu, Feb 12, 2026 at 03:22:28PM +0800, Shengjiu Wang wrote:
> > The transmitter and receiver implement separate timestamp counters and
> > bit counters. The bit counter increments at the end of each bit in a
> > frame whenever the transmitter or receiver is enabled. The bit counter
> > can be reset by software. The timestamp counter increments on the bus
> > interface clock whenever it is enabled. The current value of the
> > timestamp counter is latched whenever the bit counter increments.
> > Reading the bit counter register will cause the latched timestamp
> > value to be saved in the bit counter timestamp register. The timestamp
> > counter can be reset by software, this also resets the latched timestamp
> > value and the bit counter timestamp register.
>
> It seems this makes mixer-test deeply unhappy, spamming lots of:
>
> [   56.466460] fsl-sai 30c10000.sai: ASoC error (-16): at soc_component_read_no_lock() on 30c10000.sai for register: [0x000000fc]
> [   56.466469] fsl-sai 30c10000.sai: ASoC error (-16): at snd_soc_component_update_bits() on 30c10000.sai for register: [0x000000fc]
>

Thanks for pointing it out.

The registers are volatile, at pm suspend state, the cache_only is enabled.
Then regmap will return -EBUSY error when amixer tries to access these
registers.

Looks like for this case, I can't not use the common functions
snd_soc_put_xr_sx(),
snd_soc_get_enum_double(), soc_get_volsw().

I need to define my own functions to check the pm runtime status, to
avoid accessing
these registers when at pm suspend state.

best regards
Shengjiu Wang

> into dmesg on the Toradax Verdin:
>
>   https://lava.sirena.org.uk/scheduler/job/2518775#L2238
>
> I don't have results for i.MX8MP-EVK since I didn't test it with the
> fixes from:
>
>   https://patch.msgid.link/20260205-asoc-fsl-easrc-fix-events-v1-2-39d4c766918b@kernel.org
>
> applied so the test ran out of time due to the time taken to log those
> issues but I'm guessing this new issue should be reproducible there too.