This RFC series updates the Tegra186 ASRC driver control handling.

The main RFC point is the userspace-visible ALSA mixer control ABI
change in patch 2. The existing per-stream controls expose the software
ratio as separate integer and fractional mixer controls. This series
replaces each pair with one two-value mixer control so userspace updates
the integer and fractional parts together. That avoids programming a
transient mixed ratio to hardware, but it does require userspace that
sets ASRC software ratios to switch to the new paired controls.

Patch 1 fixes the Stream6 input-threshold control, which was using the
same stream index as Stream5 and therefore addressed the wrong lane.

Patch 2 replaces the separate integer and fractional software ratio
ALSA mixer controls with a paired two-value control per stream. This
keeps the integer/fractional ratio update atomic from userspace,
validates both values before programming hardware, serializes
ratio-source and ratio updates, refreshes the hardware lock for large
ratio jumps, and rolls back partial hardware updates on failure.

ALSA exposes one min and max range for all values in an integer-array
control, so the paired ratio controls advertise the fractional field's
full 32-bit range. The put callback validates the integer part separately
against the hardware field width.

Patch 3 caches software ratio updates while the target stream is not
active or the ASRC device is runtime suspended. Cached ratios are applied
when streams are configured and restored after runtime resume, avoiding
unsafe volatile register accesses while suspended.

Sheetal (3):
  ASoC: tegra: Fix ASRC Stream6 input threshold control
  ASoC: tegra: Update ASRC ratio controls
  ASoC: tegra: Cache ASRC ratios until streams are active

 sound/soc/tegra/tegra186_asrc.c | 513 +++++++++++++++++++++-----------
 sound/soc/tegra/tegra186_asrc.h |   5 +
 2 files changed, 347 insertions(+), 171 deletions(-)

-- 
2.43.0

On Mon, Sep 21, 2026 at 08:57:01AM +0000, Sheetal wrote:
> This RFC series updates the Tegra186 ASRC driver control handling.
> 
> The main RFC point is the userspace-visible ALSA mixer control ABI
> change in patch 2. The existing per-stream controls expose the software
> ratio as separate integer and fractional mixer controls. This series
> replaces each pair with one two-value mixer control so userspace updates
> the integer and fractional parts together. That avoids programming a
> transient mixed ratio to hardware, but it does require userspace that
> sets ASRC software ratios to switch to the new paired controls.

Given the ABI change, do we have a good understanding of who might be
using these features? My understanding is that these are used for the
setup of hardware pipelines involving sample rate conversions. So these
are likely not your regular users that just want to change the volume
for headphones and such. This is for highly specific use-cases. Do we
know if people use extra userspace software on top of ALSA to set these
up, or are they typically dealing with fixed configuration files for
specifying these values?

So essentially to be able to better understand how to proceed it'd be
good to know what the upgrade path is for this. How easy or difficult
will it be for people to transition to this? Can we transition them
automatically by keeping write-only backwards-compatibility controls
that mirror the old ABI and maybe provide a hint that people should be
upgrading to the new controls?

Since we expect this to also fix the occasional glitch caused by
mismatched ratios, I think we really want this, but we need to make sure
users aren't left in the dark about such changes and have a reasonable
upgrade path.

Mark, Liam, do you have any guidelines on how to handle such ABI
changes?

Thierry

On Mon, Sep 21, 2026 at 02:07:19PM +0200, Thierry Reding wrote:

> Given the ABI change, do we have a good understanding of who might be
> using these features? My understanding is that these are used for the
> setup of hardware pipelines involving sample rate conversions. So these
> are likely not your regular users that just want to change the volume
> for headphones and such. This is for highly specific use-cases. Do we
> know if people use extra userspace software on top of ALSA to set these
> up, or are they typically dealing with fixed configuration files for
> specifying these values?

...

> Mark, Liam, do you have any guidelines on how to handle such ABI
> changes?

I don't really, beyond your already very good summary.  It depends a lot
on knowledge of the users for the device, their level of expertise and
how likely anyone is to be using the individual feature in the first
place.  Obviously it's an ABI break so we shouldn't really be doing it
if we can avoid it, but if everyone involved is happy and has a good way
to deal with the changes then it's not really a problem.