ASoC: Additional v6.16 updates
A couple more updates on top of the last set I sent you, a new driver
for the ES8375 and a fix for the Cirrus KUnit tests from Jaroslav.
ASoC: Updates for v6.16
The changes in this release are quite large, mainly in drivers rather
than the core. This is partly due to cleanups that touch a lot of
drivers and partly due to several relatively large new drivers.
- Support for automatically enumerating DAIs from standards conforming
SoundWire SDCA devices, further work is required for these to be
useful in an actual card.
- Conversion of quite a few drivers to newer GPIO APIs.
- More helpers and cleanups from Mormimoto-san.
- Support for a wider range of AVS platforms.
- Support for AMD ACP 7.x platforms, Cirrus Logic CS35L63 and CS48L32,
Everest Semiconductor ES8389, Longsoon-1 AC'97 controllers, nVidia
Tegra264, Richtek ALC203 and RT9123 and Rockchip SAI controllers.
In commit d69d804845 ("driver core: have match() callback in struct
bus_type take a const *"), the match bus callback was changed to have
the driver be a const pointer. Unfortunately that const attribute was
thrown away when container_of() is called, which is not correct and was
not caught by the compiler due to how container_of() is implemented.
Fix this up by correctly preserving the const attribute of the driver
passed to the bus match function which requires the hdac_driver match
function to also take a const pointer for the driver structure.
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Fixes: d69d804845 ("driver core: have match() callback in struct bus_type take a const *")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2025052204-hyphen-thermal-3e72@gregkh
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from "Sheetal ." <sheetal@nvidia.com>:
The patch series includes the necessary changes to enable
support for the Tegra264 platforms in AHUB drivers.
Add Tegra264 AHUB support with following changes:
- Update Tegra264 IP instances: DMIC(2), DSPK(1), AMX(6), ADX(6), I2S(8).
- Update register offsets for Tegra264.
- Add soc_data for Tegra264 chip-specific variations.
- Increase channels_max to 32 for Tegra264 DAIs.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-11-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Tegra264 ADX support with following changes:
- Add soc_data for Tegra264-specific variations
- Tegra264 ADX supports 32 input channels, hence update the playback DAI
channels_max parameter and CIF configuration API.
- Register offsets and default values are updated to align with Tegra264.
- Add 128 byte map controls for Tegra264 to accommodate each byte per
channel (32channels x 32bits).
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-10-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Tegra264 AMX support with following changes:
- Add soc_data for Tegra264-specific variations
- Tegra264 AMX supports 32 output channels, hence update the capture DAI
channels_max parameter and CIF configuration API.
- Register offsets and default values are updated to align with Tegra264.
- Add 128 byte map controls for Tegra264 to accommodate each byte per
channel (32channels x 32bits).
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-9-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Tegra264 I2S support with following changes:
- Add soc_data for Tegra264-specific variations
- Tegra264 I2S supports 32 audio channels, hence update the TDM config,
CIF configuration API and DAI channel_max parameter.
- Register offsets and default values are updated to align with Tegra264.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-8-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PLLs should be set with a VCO frequency in the 900MHz – 1GHz range
to minimize jitter and ppm error for Tegra264. Add the PLLA rate
accordingly.
Therefore, use 983040000 frequency is for multiple of 8K frequencies
and 993484800 frequency is for multiple of 11.025K frequencies.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-7-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Tegra264 I2S support with following changes:
- Add soc_data for Tegra264-specific variations
- Tegra264 supports 32 RX and 32 TX ADMAIF channels and each ADMAIF
stream supports max 32 channels. To accommodate the change dais, CIF
configuration API and driver components are updated.
- Register offsets and default values are updated to align with Tegra264.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250512051747.1026770-5-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Tegra264 compatible strings to APE subsystem device bindings:
- audio-graph-card: Due to different PLL clock rate.
- admaif: Due to 32 channels supported and register offset changes.
- i2s: Due to 32 channels supported and register offset changes.
- amx/adx: Due to 32 channels supported and register offset changes.
- asrc: Due to different ARAM address.
- ahub: Due to AHUB IPs number of instances updates.
- for future proofing the T264 compatibility is added for other device
nodes.
These bindings enable the enhanced audio features of Tegra264
while maintaining compatibility with existing platforms.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250512051747.1026770-3-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add optional interconnect and iommu properties to admaif yaml. These
properties are supported from Tegra186 SoC onwards.
This fixes below dtbs_check error for Tegra194 and Tegra234:
'interconnect-names', 'interconnects', 'iommus' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Sheetal <sheetal@nvidia.com>
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://patch.msgid.link/20250512051747.1026770-2-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Calibration data getting function for SPI and I2C HDA drivers are almost
same, which read the calibration data from UEFI. To put them into
tas2781_hda lib for code cleanup is more reasonable than to still keep
them in the codec driver. For tas2781 codec driver, there're two different
sources for calibrated data, one is from bin file, generated in factory
test, requested and read in codec driver side; the other is from user
space during device bootup.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://patch.msgid.link/20250522014347.1163-1-shenghao-ding@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some systems expose HD-Audio controllers via objects in the ACPI tables
which encapsulate the controller's interrupt and the base address for the
HDA registers in an ACPI _CRS object, for example, as listed in this ACPI
table dump excerpt:
Device (HDA0)
{
Name (_HID, "NVDA2014") // _HID: Hardware ID
...
Name (_CRS, ResourceTemplate ()
// _CRS: Current Resource Settings
{
Memory32Fixed (ReadWrite,
0x36078000, // Address Base
0x00008000, // Address Length
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,
,, )
{
0x0000021E,
}
})
}
Add support for HDA controllers discovered through ACPI, including support
for some platforms which expose such HDA controllers on NVIDIA SoCs. This
is done with a new driver which uses existing infrastructure for extracting
resource information from _CRS objects and plumbs the parsed resource
information through to the existing HDA infrastructure to enable HD-Audio
functionality on such devices.
Although this driver is in the sound/pci/hda/ directory, it targets devices
which are not actually enumerated on the PCI bus. This is because it
depends upon the Intel "Azalia" infrastructure which has traditionally been
usedvfor PCI-based devices.
Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
Link: https://patch.msgid.link/aC3ksXJUM9DlKiz6@ddadap-lakeline.nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
Add helper functions to add DAPM widgets, routes, ALSA controls,
and DAI drivers, these will be used to create SDCA function device
drivers.
This series should provide most of the core functionality needed to
get a device registered and have a working DAPM graph within the
device. There are some features that still need additional work, these
are marked with FIXMEs in the code. The two main things are SDCA
Clock Muxes (not used in our devices and needs some ASoC core work),
and better support for more complex SDCA volume control definitions
(our parts have fairly simple volumes, and SDCA has a large amount of
flexibility in how the volume control is specified).
The next steps in the process are to add helpers for the DAI ops
themselves, some IRQ handling, and firmware download. And finally we
should be able to actually add the SDCA class driver itself.
Merge series from Stefan Binding <sbinding@opensource.cirrus.com>:
This adds support to the Intel machine drivers for CS35L63 codecs using
soundwire, and also adds match entries for the CDB35L63-CB2 on MTL
systems.
When compile-testing this driver, the missing FW_CS_DSP module
causes a link failure:
aarch64-linux-ld: sound/pci/hda/cs35l41_hda.o: in function `cs35l41_shutdown_dsp':
cs35l41_hda.c:(.text+0x7e4): undefined reference to `cs_dsp_stop'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x7ec): undefined reference to `cs_dsp_power_down'
aarch64-linux-ld: sound/pci/hda/cs35l41_hda.o: in function `cs35l41_hda_remove':
cs35l41_hda.c:(.text+0x14b4): undefined reference to `cs_dsp_remove'
aarch64-linux-ld: sound/pci/hda/cs35l41_hda.o: in function `cs35l41_smart_amp.isra.0':
cs35l41_hda.c:(.text+0x189c): undefined reference to `cs_dsp_halo_init'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1bd4): undefined reference to `cs_dsp_power_up'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1c38): undefined reference to `cs_dsp_run'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1c80): undefined reference to `cs_dsp_get_ctl'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1c90): undefined reference to `cs_dsp_coeff_read_ctrl'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1cd4): undefined reference to `cs_dsp_get_ctl'
aarch64-linux-ld: cs35l41_hda.c:(.text+0x1ce4): undefined reference to `cs_dsp_coeff_read_ctrl'
Fixes: bdd9ea9187 ("ALSA: hda/hda_cs_dsp_ctl: Delete hda_cs_dsp_ctl module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250520162101.3929551-1-arnd@kernel.org
Use the previously parsed DisCo information from ACPI to create the DAI
drivers required to connect an SDCA Function into an ASoC soundcard.
Create DAI driver structures and populate the supported sample rates
and sample widths into them based on the Input/Output Terminal and any
attach Clock Source entities. More complex relationships with channels
etc. will be added later as constraints as part of the DAI startup.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the previously parsed DisCo information from ACPI to create the
ALSA controls required by an SDCA Function. This maps all User and
Application level SDCA Controls to ALSA controls. Typically controls
marked with those access levels are just volumes and mutes.
SDCA defines volume controls as an integer in 1/256ths of a dB and
then provides a mechanism to specify what values are valid (range
templates). Currently only a simple case of a single linear volume
range with a power of 2 step size is supported. This allows the code
to expose the volume control using a simple shift. This will need
expanded in the future, to support more complex ranges and probably
also some additional control types but this should be sufficient to
for a first pass.
For non-dataport terminal widgets also add a pin switch to allow
that endpoint to be turned on/off.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the previously parsed DisCo information from ACPI to create DAPM
widgets and routes representing a SDCA Function. For the most part SDCA
maps well to the DAPM abstractions.
The primary point of interest is the SDCA Power Domain Entities
(PDEs), which actually control the power status of the device. Whilst
these PDEs are the primary widgets the other parts of the SDCA graph
are added to maintain a consistency with the hardware abstract,
and allow routing to take effect. As for the PDEs themselves the
code currently only handle PS0 and PS3 (basically on and off),
the two intermediate power states are not commonly used and don't
map well to ASoC/DAPM.
Other minor points of slightly complexity include, the Group Entities
(GEs) these set the value of several other controls, typically
Selector Units (SUs) for enabling a cetain jack configuration. Multiple
SUs being controlled by a GE are easily modelled creating a single
control and sharing it among the controlled muxes.
SDCA also has a slight habit of having fully connected paths, relying
more on activating the PDEs to enable functionality. This doesn't
map quite so perfectly to DAPM which considers the path a reason to
power the PDE. Whilst in the current specification Mixer Units are
defined as fixed-function, in DAPM we create a virtual control for
each input (which defaults to connected). This allows paths to be
connected/disconnected, providing a more ASoC style approach to
managing the power. PIN_SWITCHs will also be added for non-dataport
terminal entities in a later patch along with the other ALSA controls,
providing greater flexibility in power management.
A top level helper sdca_asoc_populate_component() is exported that
counts and allocates everything, however, the intermediate counting and
population functions are also exported. This will allow end drivers to
do allocation and add custom handling, which is probably fairly likely
for the early SDCA devices.
Clock muxes are currently not fully supported, so some future work will
also be required there.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>:
This patchset adds support for sound card on Qualcomm QCS9100 and
QCS9075 boards.
The function sdm845_slim_snd_hw_params() calls the functuion
snd_soc_dai_set_channel_map() but does not check its return
value. A proper implementation can be found in msm_snd_hw_params().
Add error handling for snd_soc_dai_set_channel_map(). If the
function fails and it is not a unsupported error, return the
error code immediately.
Fixes: 5caf64c633 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga")
Cc: stable@vger.kernel.org # v5.6
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519075739.1458-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
