On Tue, Mar 3, 2026 at 8:25 AM Mark Brown <[email protected]> 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/[email protected] > > 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.
