The Stream6 Input Threshold control points at stream index 4, which is
already used by Stream5. The threshold get and put callbacks derive the
lane ID from the register offset, so the duplicate index makes Stream6
operate on lane 4 and leaves lane 5 inaccessible from userspace.
Use stream index 5 for Stream6.
Fixes: a2df8c2d5b ("ASoC: tegra: Add Tegra186 based ASRC driver")
Signed-off-by: Sheetal <sheetal@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260921085704.1248920-2-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue with the Tegra MBDRC driver and
now the following warning is observed:
tegra210-ope 2908000.processing-engine: Driver needs fixing: Unsorted
reg_defaults, sorting the copy
This warning occurs because register defaults in the structure
tegra210_mbdrc_reg_defaults are not specified in ascending order which
is required by regmap. Fix this by sorting the register defaults
according to their address. Note that in order to do this it is
necessary to replace the macro MBDRC_FILTER_REG_DEFAULTS with a per
register macro MBDRC_FILTER_PARAM_REG_DEFAULTS.
Fixes: 7358a803c7 ("ASoC: tegra: Add Tegra210 based OPE driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-5-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra ADMAIF driver and now
the following warning is observed:
tegra210-admaif 290f000.admaif: Driver needs fixing: Unsorted
reg_defaults, sorting the copy
This warning occurs because register defaults in the structures
tegra186_admaif_reg_defaults and tegra264_admaif_reg_defaults are not
specified in ascending order which is required by regmap. Fix this by
sorting the register defaults according to their address. Note that in
order to do this it is necessary to split the macro ADMAIF_REG_DEFAULTS
into separate RX and TX macros to the RX and TX registers.
Fixes: f74028e159 ("ASoC: tegra: Add Tegra210 based ADMAIF driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-4-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra MIXER driver where
the register default for the TEGRA210_MIXER_ENABLE is specified as 1,
but the hardware default is actually 0. After this commit was added the
MIXER driver is no longer working and so fix this by correcting the
default value for this register and explicitly configuring the
MIXER_ENABLE register when runtime resuming the MIXER device.
Fixes: 05bb3d5ec6 ("ASoC: tegra: Add Tegra210 based Mixer driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-3-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra I2S driver where the
register default for the TEGRA210_I2S_ENABLE is specified as 1, but the
hardware default is actually 0. After this commit was added the I2S
driver is no longer working and so fix this by correcting the default
value for this register and explicitly configuring the I2S_ENABLE
register when runtime resuming the I2S device.
The I2S_ENABLE register offset is different on Tegra264 devices than
other Tegra devices and so add a 'enable_reg' variable to the SoC data
structure to specify the offset for different SoC devices.
Fixes: c0bfa98349 ("ASoC: tegra: Add Tegra210 based I2S driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-2-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch(). See commit
fd80df352b ("regcache: Add support for sorting defaults arrays").
TEGRA210_MIXER_ENABLE (0x400) is the last entry of the table, after
TEGRA210_MIXER_PEAKM_RAM_CTRL (0x434), which makes it unreachable.
regcache_reg_needs_sync() then cannot compare it against its default and
reports that a sync is needed, so it is written to the device on every
regcache_sync() even when it was never touched.
Sort the table by register address.
Fixes: 05bb3d5ec6 ("ASoC: tegra: Add Tegra210 based Mixer driver")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260805122748.13090-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch(). See commit
fd80df352b ("regcache: Add support for sorting defaults arrays").
TEGRA264_I2S_ENABLE (0x100), TEGRA264_I2S_RX_FIFO_WR_ACCESS_MODE (0x30)
and TEGRA264_I2S_TX_FIFO_RD_ACCESS_MODE (0xb0) are listed at the end of
the table, after TEGRA264_I2S_TIMING (0x130), which leaves 4 of the 9
entries unreachable. regcache_reg_needs_sync() then cannot compare them
against their default and reports that a sync is needed, so they are
written to the device on every regcache_sync() even when they were never
touched.
Sort the table by register address.
Fixes: b3354438d8 ("ASoC: tegra: I2S: Add Tegra264 support")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260805122748.13090-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch(). See commit
fd80df352b ("regcache: Add support for sorting defaults arrays").
TEGRA210_I2S_ENABLE (0x80) is listed after TEGRA210_I2S_CG (0x88) and
TEGRA210_I2S_TIMING (0xa4), so both it and TEGRA210_I2S_TIMING are
unreachable. regcache_reg_needs_sync() then cannot compare them against
their default and reports that a sync is needed, so they are written to
the device on every regcache_sync() even when they were never touched.
Sort the table by register address.
Fixes: c0bfa98349 ("ASoC: tegra: Add Tegra210 based I2S driver")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260805122748.13090-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The existing comment states that the sync_input clock is only needed
when another I/O is configured to use the current I2S instance as its
input clock, and the current code does not treat its absence as an
error.
Use devm_clk_get_optional() to match the existing behaviour while still
reporting real failures via dev_err_probe(). Update the comment to
describe the optional nature of the clock rather than the previous error
handling.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260715051115.17385-5-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_add_component_controls() already reports failures internally.
Return its error code directly instead of logging the error again in the
component probe callback. Also remove the now unnecessary local error
variable.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260715051115.17385-4-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_add_component_controls() already reports failures internally.
Return its error code directly instead of logging the error again in the
component probe callback. Also remove the now unnecessary local error
variable.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260715051115.17385-3-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace the existing dev_err() and PTR_ERR() sequence with
dev_err_probe(), preserving the original error code while simplifying
the error handling.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260715051115.17385-2-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
HyeongJun An <sammiee5311@gmail.com> says:
Some custom ASoC kcontrol put() handlers use the written enum value
(ucontrol->value.enumerated.item[0]) to index a table or compute a bit
shift before validating that the value is within the control's enum range.
An out-of-range value written from userspace is therefore consumed before
it is rejected.
This is the same class addressed for the Meson codecs in commit
1e00120680 ("ASoC: meson: g12a-tohdmitx: Validate written enum values")
and commit 3150b70e94 ("ASoC: meson: g12a-toacodec: Validate written
enum values").
Fix four more instances:
- hdac_hdmi reads e->texts[item] before validation.
- aiu converts the item before validating it.
- fsl_audmix converts the item and uses the result before validation.
- tegra210_ahub reads e->values[item] before validation.
Link: https://patch.msgid.link/20260609124317.38046-1-sammiee5311@gmail.com
tegra_ahub_put_value_enum() reads e->values[item[0]] before
checking whether item[0] is within the enum item range. The existing
check therefore happens too late to prevent an out-of-range read of the
values array.
Move the check before the array access.
Fixes: 16e1bcc2ca ("ASoC: tegra: Add Tegra210 based AHUB driver")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260609124317.38046-5-sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DURATION_INV_N3 is computed from BIT_ULL(31 + prescalar) divided
by the configured duration, and then written as a 32-bit RAM value.
Durations of 32 samples or less overflow that value, so reject them
and advertise the valid range through the fade duration control.
Validate the ALSA integer control value as a long before storing it in
the driver's u32 duration field. Use a u32 temporary for duration RAM
writes because the largest valid inverse value can still exceed INT_MAX.
Fixes: 36645381b8 ("ASoC: tegra: Add per-stream Mixer Fade controls")
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260519094858.1426057-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A MIPS allmodconfig build with LLVM fails during modpost:
ERROR: modpost: "__udivdi3"
[sound/soc/tegra/snd-soc-tegra210-mixer.ko] undefined!
tegra210_mixer_configure_gain() divides a 64-bit BIT_ULL() value by the
fade duration. On 32-bit MIPS, clang emits a call to __udivdi3 for that
plain C division, but that compiler helper is not exported to modules.
Use div_u64() for the inverse duration calculation so the driver uses the
kernel's 64-bit division helper instead of emitting a compiler runtime
call.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260507232131.438589-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add per-stream fade controls for the Tegra mixer to allow
independently configuring target gain and fade duration for each of
the 10 input streams (RX1 through RX10).
The following controls are added per stream:
"RXn Fade Duration" - fade duration in samples (N3 parameter)
"RXn Fade Gain" - target gain level for fade
A strobe control commits all pending fade configurations:
"Fade Switch" - 1 = apply staged gain/duration and start fades
0 = disable sample count for all fading streams
A read-only status control reports per-stream fade state:
"Fade Status" - per-stream state for all 10 RX inputs
0 = idle, 1 = active
Usage example (fade 2 streams simultaneously):
amixer -c <card> cset name="RX1 Fade Duration" 1024
amixer -c <card> cset name="RX1 Fade Gain" 12000
amixer -c <card> cset name="RX2 Fade Duration" 2048
amixer -c <card> cset name="RX2 Fade Gain" 15000
amixer -c <card> cset name="Fade Switch" 1
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260506102032.1644851-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260505102803.183455-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
phucduc.bui@gmail.com <phucduc.bui@gmail.com> says:
This series converts spin lock handling in UniPhier AIO drivers
to use guard() helpers.
The changes are purely code cleanups with no functional impact.
Consolidate the allocations for capture_dma_data and playback_dma_data
into a single kzalloc by using a flexible array member at the end of
the tegra_admaif struct. This reduces the number of allocations from
three to one, simplifies error handling, and improves memory locality.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260503003037.11942-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add handling for SNDRV_PCM_FORMAT_S8 in the MVC audio CIF
configuration. This allows 8-bit PCM streams to be processed
by setting the appropriate TEGRA_ACIF_BITS_8 format in the
CIF configuration.
Signed-off-by: Anupama Kunkulagunta <akunkulagunt@nvidia.com>
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260428051216.2746030-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The byte-map controls ("Byte Map N") already expose a value range of
[0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
"disabled" sentinel. The driver stored this state as a byte-packed
u32 map[] array plus a separate byte_mask[] bitmap tracking which
slots were enabled, because 256 does not fit in a byte. As a result
get_byte_map() had to consult byte_mask[] to decide whether to
report the stored byte or 256, and put_byte_map() had to keep the
two arrays in sync on every write.
Store each slot as a u16 holding the control value directly
(0..255 enabled, 256 disabled). This is the native representation
for what userspace already sees, so get_byte_map() becomes a direct
return and put_byte_map() becomes a compare-and-store. The
hardware-facing packed RAM word and the OUT_BYTE_EN mask are now
derived on the fly inside tegra210_amx_write_map_ram() from the
slot array, which is the only place that needs to know about the
hardware layout.
The byte_mask buffer is allocated in probe() using devm_kcalloc()
with soc_data->byte_mask_size, so it scales to any SoC variant
without depending on chip-specific constants. It is zeroed and
recomputed each time write_map_ram() is called.
A new TEGRA_AMX_SLOTS_PER_WORD constant replaces the literal '4'
used for byte slots per RAM word, and BITS_PER_BYTE /
BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and
'32' shifts.
Slots are initialised to 256 in probe() so the default reported
value stays "disabled", matching previous behaviour. Values written
from userspace that fall outside [0, 255] are clamped to 256
("disabled") exactly as before -- no userspace-visible change.
As a side effect this also fixes a latent bug in the previous
put_byte_map(): because it compared the enable mask rather than the
stored byte, changing a slot from one enabled value to another
enabled value (e.g. 42 -> 99) would early-return without persisting
the new value, and the next CFG_RAM flush would still program the
old byte. The new implementation compares the stored value itself,
so this case is now handled correctly.
Addresses TODO left in tegra210_amx_get_byte_map().
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Link: https://patch.msgid.link/20260410200530.171323-3-piyushpatle228@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The byte-map controls ("Byte Map N") already expose a value range of
[0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
"disabled" sentinel. The driver stored this state as a byte-packed
u32 map[] array plus a separate byte_mask[] bitmap tracking which
slots were enabled, because 256 does not fit in a byte. As a result
get_byte_map() had to consult byte_mask[] to decide whether to
report the stored byte or 256, and put_byte_map() had to keep the
two arrays in sync on every write.
Store each slot as a u16 holding the control value directly
(0..255 enabled, 256 disabled). This is the native representation
for what userspace already sees, so get_byte_map() becomes a direct
return and put_byte_map() becomes a compare-and-store. The
hardware-facing packed RAM word and the IN_BYTE_EN mask are now
derived on the fly inside tegra210_adx_write_map_ram() from the
slot array, which is the only place that needs to know about the
hardware layout.
The byte_mask buffer is allocated in probe() using devm_kcalloc()
with soc_data->byte_mask_size, so it scales to any SoC variant
without depending on chip-specific constants. It is zeroed and
recomputed each time write_map_ram() is called.
A new TEGRA_ADX_SLOTS_PER_WORD constant replaces the literal '4'
used for byte slots per RAM word, and BITS_PER_BYTE /
BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and
'32' shifts.
Slots are initialised to 256 in probe() so the default reported
value stays "disabled", matching previous behaviour. Values written
from userspace that fall outside [0, 255] are clamped to 256
("disabled") exactly as before -- no userspace-visible change.
As a side effect this also fixes a latent bug in the previous
put_byte_map(): because it compared the enable mask rather than the
stored byte, changing a slot from one enabled value to another
enabled value (e.g. 42 -> 99) would early-return without persisting
the new value, and the next CFG_RAM flush would still program the
old byte. The new implementation compares the stored value itself,
so this case is now handled correctly.
Addresses TODO left in tegra210_adx_get_byte_map().
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Link: https://patch.msgid.link/20260410200530.171323-2-piyushpatle228@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
kconfiglint reports two warnings for sound/soc/tegra/Makefile:
M002: composite module 'snd-soc-tegra-utils' defined but not in any obj-*
M008: composite module 'snd-soc-tegra-utils': tegra_asoc_utils.o has no
source file
The composite module definition
`snd-soc-tegra-utils-y += tegra_asoc_utils.o` references a source file that
no longer exists and defines a module that is never included in any obj-*
target.
The tegra_asoc_utils module was originally introduced in commit
a3cd50deef ("ASoC: Tegra: Move utilities to separate module") by Stephen
Warren in 2011 to provide shared clock/rate utility functions for Tegra
machine drivers. At that time, the Makefile had both the composite
definition (`snd-soc-tegra-utils-objs`) and the build target
(`obj-$(CONFIG_SND_TEGRA_SOC) += snd-soc-tegra-utils.o`).
In 2021,
commit 8c1b3b1593 ("ASoC: tegra: Squash utils into common machine
driver")
by Dmitry Osipenko merged tegra_asoc_utils.c into tegra_asoc_machine.c,
deleting both the .c and .h files. That commit correctly removed the obj-*
build target line but overlooked the composite module definition line
(`snd-soc-tegra-utils-objs += tegra_asoc_utils.o`).
The orphaned line persisted unnoticed and was even mechanically updated in
2024 by
commit 51a50d6ad7 ("ASoC: tegra: Use *-y instead of *-objs in
Makefile")
by Takashi Iwai, which converted it from `-objs` to `-y` syntax as part of
a treewide cleanup — inadvertently refreshing a stale definition.
Remove the orphaned composite module definition since it serves no purpose:
the source file was deleted, the obj-* target was already removed, and the
functionality now lives in tegra_asoc_machine.c.
Assisted-by: Claude:claude-opus-4-6 kconfiglint
Signed-off-by: Sasha Levin <sashal@kernel.org>
Link: https://patch.msgid.link/20260426000249.54799-1-sashal@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Log errors in the Tegra210 OPE, PEQ and MBDRC probe paths using
dev_err_probe(). Drop redundant dev_err() at tegra210_peq_regmap_init()
and tegra210_mbdrc_regmap_init() call sites in ope_probe() since
these functions already log errors internally.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260401112500.4076861-3-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Log errors in the Tegra210 ADMAIF probe and runtime callback paths.
Drop redundant dev_err() at tegra_isomgr_adma_register() call site
since it already logs errors internally.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260401112500.4076861-2-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
component has component->val_bytes which is set via
snd_soc_component_setup_regmap(). But it can be calculated via
component->regmap. No need to keep it as component->val_bytes.
This patchset adds new snd_soc_component_regmap_val_bytes(),
and remove component->val_bytes / snd_soc_component_setup_regmap().
Link: https://patch.msgid.link/87a4wdzyxf.wl-kuninori.morimoto.gx@renesas.com
component has component->val_bytes which is set via
snd_soc_component_setup_regmap(). But it can be calculated via
component->regmap. No need to keep it as component->val_bytes.
Use snd_soc_component_regmap_val_bytes().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/877brhzywd.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We have been used pcm_new()/pcm_free(), but switched to
pcm_construct()/pcm_destruct() to use extra parameters [1].
pcm_new()/free() had been removed [2], but each drivers are still
using such function naming. Let's name back to pcm_new()/pcm_free()
again.
[1] commit c64bfc9066 ("ASoC: soc-core: add new pcm_construct/pcmdestruct")
[2] commit e9067bb502 ("ASoC: soc-component: remove snd_pcm_ops from component driver")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87bjgojyoy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
