The SAI and XCVR have the timestamp counters and bit counters, which can
be used by software to track the progress of the transmitter and receiver.
They can also be used to calculate the relative frequency of the bit clock
against the bus interface clock.

changes in v3:
- define own functions which check the pm status before accessing the
  registers to avoid -EBUSY error reported by mixer-test.

Changes in v2:
- remove arrays of enums, define transmit_tstmp_enum and receive_tstmp_enum
  separately.
- remove __bf_shf(), define the XXX_SHIFT macros.

Shengjiu Wang (3):
  ASoC: fsl_utils: Add snd_kcontrol functions for specific cases
  ASoC: fsl_sai: add bitcount and timestamp controls
  ASoC: fsl_xcvr: add bitcount and timestamp controls

 sound/soc/fsl/fsl_sai.c   | 62 +++++++++++++++++++++++++++
 sound/soc/fsl/fsl_sai.h   |  4 ++
 sound/soc/fsl/fsl_utils.c | 89 +++++++++++++++++++++++++++++++++++++++
 sound/soc/fsl/fsl_utils.h | 30 +++++++++++++
 sound/soc/fsl/fsl_xcvr.c  | 64 ++++++++++++++++++++++++++++
 sound/soc/fsl/fsl_xcvr.h  | 18 ++++++++
 6 files changed, 267 insertions(+)

-- 
2.34.1

On Thu, 05 Mar 2026 11:10:28 +0800, Shengjiu Wang wrote:
> The SAI and XCVR have the timestamp counters and bit counters, which can
> be used by software to track the progress of the transmitter and receiver.
> They can also be used to calculate the relative frequency of the bit clock
> against the bus interface clock.
> 
> changes in v3:
> - define own functions which check the pm status before accessing the
>   registers to avoid -EBUSY error reported by mixer-test.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/3] ASoC: fsl_utils: Add snd_kcontrol functions for specific cases
      commit: 819cf1dc01ce66b6906d403a6925c4bd754a7a1d
[2/3] ASoC: fsl_sai: add bitcount and timestamp controls
      commit: 8e27987a208029c39da7a787bd9f1217d42011a5
[3/3] ASoC: fsl_xcvr: add bitcount and timestamp controls
      commit: 7b3f8db159f710d432c4edc024fcefa9e62e8b4b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark