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>
Tegra238 platforms use different clock rates for plla and
plla_out0 clocks. Add Tegra238 support in the Tegra
sound card driver to apply specific clock configurations.
Signed-off-by: Aditya Bavanari <abavanari@nvidia.com>
Signed-off-by: Sheetal <sheetal@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260303100249.3214529-3-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Wolfson Microelectronics WM8962 codec support to the Tegra ASoC
machine driver. The WM8962 codec is found on devices like Microsoft
Surface RT and Microsoft Surface 2 Windows RT based tablets.
Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Link: https://patch.msgid.link/20260223065051.13070-5-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add CPCAP codec support to the Tegra ASoC machine driver. This codec is
found in Motorola T20 devices like Atrix 4G and Droid X2.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20260223065051.13070-3-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set reg_default_cb so REGCACHE_FLAT can supply zero defaults without
large reg_defaults tables, simplifying cache initialization for
zero-reset registers.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-4-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add writeable_reg callbacks for Tegra210/186 AHUB RX registers so the
flat cache only treats valid RX locations as writable, avoiding holes
in the register map.
Fixes: 16e1bcc2ca ("ASoC: tegra: Add Tegra210 based AHUB driver")
Signed-off-by: Sheetal <sheetal@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-2-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4d4021b0bb ("ASoC: tegra: Fix uninitialized flat cache warning
in tegra210_ahub") attempted to fix the uninitialized flat cache warning
that is observed for the Tegra210 AHUB driver. However, the change broke
various audio tests because an -EBUSY error is returned when accessing
registers from cache before they are read from hardware. Revert this
change for now, until a proper fix is available.
Fixes: 4d4021b0bb ("ASoC: tegra: Fix uninitialized flat cache warning in tegra210_ahub")
Signed-off-by: sheetal <sheetal@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20251217132524.2844499-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The tegra210_ahub driver started triggering a warning after commit
e062bdfdd6 ("regmap: warn users about uninitialized flat cache"),
which flags drivers using REGCACHE_FLAT without register defaults.
Since the driver omits default definitions because its registers are
zero initialized, the following warning is shown:
WARNING KERN tegra210-ahub 2900800.ahub: using zero-initialized flat cache, this may cause unexpected behavior
Switch to REGCACHE_FLAT_S which is the recommended cache type for
sparse register maps without defaults. This cache type initializes
entries on-demand from hardware, eliminating the warning while using
memory efficiently.
Signed-off-by: sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20251208052040.4025612-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ALSA SoC driver for Tegra runs also on SoCs without the Tegra20 APB DMA
controller (e.g. Tegra234).
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Link: https://patch.msgid.link/20251126112926.4126757-1-flavra@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We have very similar name functions (A)(B). Both gets component from
snd_kcontrol, but (A) is used in callback functions which is registered
through snd_soc_add_component_controls(), (B) is used through
snd_soc_dapm_new_widgets().
(A) snd_soc_kcontrol_component()
(B) snd_soc_dapm_kcontrol_component()
(B) is using very picky way to get component but using it is necessary in
ASoC. But (A) is just wrapper function to snd_kcontrol_chip(), and directly
using it without wrapper is very common way on ALSA.
To reduce confusions of similar function, let's use common way on (A).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ecr6m7jn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
