ASoC: codecs: add Qualcomm Tambora (WCD9378) SDCA codec

Add support for the Qualcomm Tambora (WCD9378) headset codec in SDCA
mode over SoundWire. On ARM/DT platforms without ACPI/DisCo firmware
the

ASoC: codecs: add Qualcomm Tambora (WCD9378) SDCA codec

Add support for the Qualcomm Tambora (WCD9378) headset codec in SDCA
mode over SoundWire. On ARM/DT platforms without ACPI/DisCo firmware
the SDCA topology and SoundWire port properties are supplied as static
data through the codec driver.

The codec exposes a single SimpleJack SDCA Function providing:
- Headphone playback via FU 6 (mute + Q7.8 volume) and OT 43/45.
- Headset mic capture via IT 33 with MICB2 bias at 2.75V.
- MBHC-based headset jack detection.

The driver enables the codec supplies, releases the reset GPIO, and
uses:
- sdw_slave_ops.read_prop to publish SoundWire slave properties and
dpn caps for the compute-mode dataports.
- sdca_class_ops.populate_function to hand the SDCA Function data
(entities, clusters, init_table) to the class driver from static
tables.

Binds SoundWire slave id 0x0217:0x0110 when qcom,sdca-compliant is
set on the DT node.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260925161049.758913-8-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: es9039q2m: add ESS Technology ES9039Q2M codec driver

The ES9039Q2M is a 32-bit two-channel audio DAC with an asynchronous
sample rate converter. It selects between two control personalities wi

ASoC: es9039q2m: add ESS Technology ES9039Q2M codec driver

The ES9039Q2M is a 32-bit two-channel audio DAC with an asynchronous
sample rate converter. It selects between two control personalities with
its MODE pin: hardware mode, strapped by HW0/HW1/HW2 with no control bus
at all, and software mode over I2C or SPI. This driver implements
software mode over I2C, which MODE = GND selects.

Three properties of the part shape the driver:

- The ASRC in front of the DAC means MCLK need not be synchronous with
BCLK or LRCK, so a board can feed it a fixed oscillator and never
touch the clock again. The driver derives which case it is in rather
than assuming one: the part runs synchronously when it drives the bus
clocks itself, or when the MCLK it was given can be set to a
multiple of the sample rate, and asynchronously only when a fixed
oscillator feeds it as a clock consumer. The datasheet's MCLK floor
differs between the two - 128 x Fs synchronous, 130 x Fs asynchronous
- and where the clock is fixed a startup constraint derives the
maximum rate from the MCLK actually present rather than advertising
rates the hardware cannot honour.

- Selecting an input format takes two registers, not one. Register 57
INPUT_SEL chooses which port to listen to; register 1 SYS MODE CONFIG
enables the corresponding decoder, and at reset only ENABLE_TDM_DECODE
is set. Selecting DoP without also enabling ENABLE_DOP_DECODE leaves
the part hunting for a marker with the marker decoder switched off, so
it finds no valid DoP and mutes. The driver sets both.

- Several registers have non-zero reserved defaults - register 88 reads
0xb8 at reset - so every write is read-modify-write.

The part has four supply inputs and the datasheet asks for them in a set
order: AVDD, then VCCA about 200us later, then the two output-stage
references AVCC_DAC1 and AVCC_DAC2, with power-down exactly reversed. The
driver enables them one at a time for that reason rather than calling
regulator_bulk_enable(), which makes no ordering guarantee; the bulk API
still acquires them, where order does not matter. DVDD is not among them:
the part's 1.2V digital rail is generated on chip and that pin takes only
a decoupling capacitor. No settling time is inserted before the first
register access because the datasheet specifies none.

The datapath is off at reset and the driver turns it on at component
probe. SYSTEM_CONFIG[1] is clear when the part comes out of reset, so in
software mode nothing enables it at power-up and the analogue output
stays dead until the driver writes that bit. It is written after the mute
and never before it: bringing the datapath up into an unmuted part whose
volume registers still sit at their 0 dB reset value is the thump the
mute is there to prevent. Note when testing that a warm reboot does not
reset this part - registers and coefficient RAM both survive one, and
only removing power clears them - so the previous boot's value can hide
whether the write happened at all.

DoP is detected by the part rather than announced by the host:
AUTO_INPUT_SEL is enabled and both the TDM and DoP decoders run, so a
player can simply send DoP-encoded PCM. That is the only way DoP works in
practice, because no player can select a DAC mode through a kcontrol
first, and material sent to a part that is not looking for the marker
renders as the near-silent hiss the DoP design deliberately degrades to.

The programmable FIR coefficient controls are write-only by design. The
part has a PROG_COEFF_OUT register described as "Programmable FIR
coefficient readback", but it is not a RAM read port: it returns the last
coefficient written, whatever address is selected in PROG_COEFF_ADDR.
Measured by writing two different coefficients to addresses 0 and 1 and
reading them back five ways - plain, with a settle delay, with
PROG_COEFF_EN set, with the address written twice, and with a
write-enable pulse after the address. All ten reads returned the value
written to address 1. A get() built on that register would return
something with the shape of data and none of its meaning, so there is
none.

Every control was verified against the silicon rather than against the
driver's own read-back: written through ALSA, then read from the chip
over raw I2C. That covers the eight filter shapes, the modulator
bandwidth, the IIR bandwidth, the four signed 16-bit THD compensation
coefficients at both extremes of their range, and the automute enable,
time, level and off-level fields including the neighbouring
MUTE_RAMP_TO_GND bit that shares a register with the 11-bit time field.
The coefficient upload, whose RAM cannot be read back, was verified from
the I2C bus itself.

System suspend gates the part's internal clock tree. Where the part is
clocked from the SoC, system suspend stops its clock as a side effect and
there is nothing for a driver to do; where the board feeds it a
free-running oscillator - which the ASRC makes an attractive design,
since MCLK then need not track BCLK or LRCK - nothing in the system can
gate that clock and the part stays fully clocked for the whole of
suspend. Clearing ENABLE_DAC_CLK is the only part of its consumption
software can reach; the analogue supplies are the board's business.
Measured on an RK3588 board with a fixed 24.576 MHz oscillator, system
suspend power fell from 1.98 W to 1.95 W and followed the register in
both directions across an A/B.

Resume mutes the part before regcache_sync(), because the sync walks
registers in ascending address order. A board that keeps the supplies up
needs nothing, but one that removes them brings the part back at reset
defaults - DAC_MODE clear, both channels unmuted, both volume registers
at 0 dB - and the sync would set DAC_MODE in register 0 and only restore
the real mute in register 86, lighting the datapath up at full scale in
between.

Resume also re-uploads the programmable FIR coefficient RAM.
regcache_sync() cannot restore it - the RAM is write-only, so nothing
caches it - but the sync does restore the filter selection, so a board
that removed the supplies would come back with the programmable filter
selected and the RAM holding whatever it powered up with. The driver
keeps a shadow of each stage it uploaded and replays it after the sync.
Stages never written have no shadow and keep the part's own defaults.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Asseily <karl@asseily.com>
Link: https://patch.msgid.link/20260918182317.143223-4-karl@asseily.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: add Senary SN624x SoundWire SDCA support

Qianghua Wang <qianghua.wang@senarytech.com> says:

This series adds SoundWire SDCA support for Senary SN624x
multi-function codecs (jack, speaker amp,

ASoC: add Senary SN624x SoundWire SDCA support

Qianghua Wang <qianghua.wang@senarytech.com> says:

This series adds SoundWire SDCA support for Senary SN624x
multi-function codecs (jack, speaker amp, DMIC) on Intel ARL,
LNL, MTL, and PTL.

Based on current sound.git tip (249bfb5d8897 — Merge branch 'for-next').

Validated previously on LG / Positivo Wildcat Lake (PTL) with
part_id 0x6244 (MODALIAS sdw:m0496p6244v03c01).

Link: https://patch.msgid.link/cover.1788230065.git.qianghua.wang@senarytech.com

show more ...

ASoC: codecs: add SN624x SDCA SoundWire driver

Add a SoundWire SDCA driver for Senary SN624x multi-function codecs
(jack, speaker amp, and DMIC). Program SDCA SampleFreqIndex in
hw_params, keep SDCA

ASoC: codecs: add SN624x SDCA SoundWire driver

Add a SoundWire SDCA driver for Senary SN624x multi-function codecs
(jack, speaker amp, and DMIC). Program SDCA SampleFreqIndex in
hw_params, keep SDCA jack IRQs masked with poll-based detection, and
extend the Senary MAINTAINERS entry for the new codec files only.

Signed-off-by: Qianghua Wang <qianghua.wang@senarytech.com>
Link: https://patch.msgid.link/0aa5fde4e0213362322fd9d0d50ed9c28c40fc09.1788230065.git.qianghua.wang@senarytech.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: codecs: nau8360: Add support for NAU83G60 amplifier

Add support for the Nuvoton NAU83G60 audio codec. The NAU83G60 is a
stereo 30W+30W smart amplifier with an integrated low-latency
Advanced A

ASoC: codecs: nau8360: Add support for NAU83G60 amplifier

Add support for the Nuvoton NAU83G60 audio codec. The NAU83G60 is a
stereo 30W+30W smart amplifier with an integrated low-latency
Advanced Audio DSP.

Signed-off-by: Neo Chang <YLCHANG2@nuvoton.com>
Link: https://patch.msgid.link/20260825021644.1203076-3-YLCHANG2@nuvoton.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: rt766: add RT766/RT767 SDCA driver

This patch adds the initial SDCA multi-function codec driver for the RT766 and RT767.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Reviewed-by: Charles

ASoC: rt766: add RT766/RT767 SDCA driver

This patch adds the initial SDCA multi-function codec driver for the RT766 and RT767.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260804104828.557228-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: Add support for the Qualcomm WSA885X Stereo smart speaker amplifier

Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:

The series first documents the WSA885X devicetree binding,
includi

ASoC: Add support for the Qualcomm WSA885X Stereo smart speaker amplifier

Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:

The series first documents the WSA885X devicetree binding,
including supplies, GPIOs, Interrupt and battery configuration.

It then adds the ASoC codec driver with register programming, serial
interface setup, clock handling, mute and gain control, reset handling,
interrupt support, runtime TDM slot-count configuration, and stream-time
power-state sequencing.

validated speaker playback on Shikra and Hawi platforms.

Link: https://patch.msgid.link/20260715115220.3093799-1-prasad.kumpatla@oss.qualcomm.com

show more ...

ASoC: codecs: add Qualcomm WSA885X codec driver

Add an ASoC codec driver for the Qualcomm WSA885X stereo smart speaker
amplifier.

The driver programs the register map, handles reset and interrupt s

ASoC: codecs: add Qualcomm WSA885X codec driver

Add an ASoC codec driver for the Qualcomm WSA885X stereo smart speaker
amplifier.

The driver programs the register map, handles reset and interrupt support,
exposes DAI operations for PCM/TDM playback, and provides mixer controls
for usage mode, speaker volume and RX slot mask.

Keep stream-time power-state sequencing in the DAI callbacks and use regmap
for the control path.

Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715115220.3093799-3-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: aw88399: extract shared device library

Extract the device-level functions from aw88399.c into a new shared
library module (aw88399-lib.c) with a shared header at
include/sound/aw88399.h, follo

ASoC: aw88399: extract shared device library

Extract the device-level functions from aw88399.c into a new shared
library module (aw88399-lib.c) with a shared header at
include/sound/aw88399.h, following the pattern established by CS35L41
(cs35l41-lib.c / include/sound/cs35l41.h) for chips that need both
ASoC and HDA drivers.

The shared header at include/sound/aw88399.h contains the register
definitions, bit-field masks, hardware constants, device enums, the
struct aw88399 definition, and the library function declarations.
The ASoC-private header at sound/soc/codecs/aw88399.h is reduced to
ASoC-specific definitions (PCM formats/rates, ALSA kcontrol helpers,
calibration constants) and includes the shared header.

The library contains the chip initialization, firmware loading,
playback start/stop sequences, and all their internal dependencies
(PLL checks, DSP management, volume control, calibration, CRC
verification, etc.). The ASoC codec driver retains the ALSA controls,
DAPM widgets, codec probe/remove, calibration service, and I2C bus
driver registration.

A new Kconfig symbol SND_SOC_AW88399_LIB is introduced.
SND_SOC_AW88399 (the existing ASoC codec) selects it, ensuring no
change for current users. The HDA side codec driver (introduced
later in this series) selects the library without pulling in the
full ASoC codec module. This avoids a build-time dependency on the
full ASoC driver and follows the established pattern used by CS35L41
(SND_SOC_CS35L41_LIB) for chips with both ASoC and HDA drivers.

Some library functions (DSP control, volume setting, mute,
calibration updates, profile management, and status helpers) are
used internally by the library's start/stop sequences but are also
called directly by the ASoC driver's remaining code.
These are exported from the library so the ASoC module can access them.

This is a pure code movement with no functional changes. The moved
functions are identical to their originals in aw88399.c.

Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB772415C485FAF74297673FD7FCC62@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: cs42xx8: Add SPI bus support for CS42448/CS42888 codec

Chancel Liu <chancel.liu@nxp.com> says:

The existing cs42xx8 driver only supported I2C control interface.
Add SPI bus support for the Ci

ASoC: cs42xx8: Add SPI bus support for CS42448/CS42888 codec

Chancel Liu <chancel.liu@nxp.com> says:

The existing cs42xx8 driver only supported I2C control interface.
Add SPI bus support for the Cirrus Logic CS42448/CS42888 Audio CODEC.

Link: https://patch.msgid.link/20260603095041.3906558-1-chancel.liu@oss.nxp.com

show more ...

ASoC: cs42xx8: Add SPI bus support for CS42448/CS42888 codec

The existing cs42xx8 driver only supported I2C control interface.
Add SPI bus support for the Cirrus Logic CS42448/CS42888 Audio CODEC.

ASoC: cs42xx8: Add SPI bus support for CS42448/CS42888 codec

The existing cs42xx8 driver only supported I2C control interface.
Add SPI bus support for the Cirrus Logic CS42448/CS42888 Audio CODEC.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260603095041.3906558-3-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: es9356-sdca: Add ES9356 SDCA driver

This is the codec driver for es9356-sdca.

Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20260514075206.3483-4-zhangyi@e

ASoC: es9356-sdca: Add ES9356 SDCA driver

This is the codec driver for es9356-sdca.

Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20260514075206.3483-4-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: tac5xx2-sdw: add soundwire based codec driver

Add codec driver for tac5xx2 family of devices.
This includes the support for
1. tac5572 - DAC, PDM, UAJ and HID
2. tas2883 - Amplifier with D

ASoC: tac5xx2-sdw: add soundwire based codec driver

Add codec driver for tac5xx2 family of devices.
This includes the support for
1. tac5572 - DAC, PDM, UAJ and HID
2. tas2883 - Amplifier with DSP
3. tac5672 - Similar to tac5572 with feedback
4. tac5682 - Similar to tac5672 with Amplifier DSP.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260505111806.2280-3-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver

The TAS675x (TAS6754, TAS67524) are quad-channel, digital-input
Class-D amplifiers with an integrated DSP, controlled over I2C.
They su

ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver

The TAS675x (TAS6754, TAS67524) are quad-channel, digital-input
Class-D amplifiers with an integrated DSP, controlled over I2C.
They support I2S and TDM serial audio interfaces.

Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260416232640.3084132-3-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: wm_adsp: Add kunit test for firmware file search

Add KUnit testing of the wm_adsp code that searches for firmware files.
Also make the SND_SOC_WM_ADSP Kconfig symbol visible if KUNIT is enable

ASoC: wm_adsp: Add kunit test for firmware file search

Add KUnit testing of the wm_adsp code that searches for firmware files.
Also make the SND_SOC_WM_ADSP Kconfig symbol visible if KUNIT is enabled
so that wm_adsp can be manually included for KUnit testing.

The firmware filename is composed of several fields, some of which are
optional, and there is a search algorithm to fallback from specific to
generic versions of firmware for a device. This KUnit test verifies that
wm_adsp is searching for the correct sequence of filenames.

The are two ways of testing this, and both are used in this KUnit test.

1. Trap the calls to firmware_request_nowarn() and test that the sequence
of filenames request is correct.

This is the most thorough test because it proves that exactly the
expected filenames are requested, in the correct order.

But it doesn't fully cover regression testing. If a change to the search
algorithm changes the expected sequence of requested files, the test
must also be changed to expect that new sequence. If the expectation is
wrong, the tests can pass (because the search order is as expected)
while picking a different file in some cases from what it did before the
change.

2. Test which file is picked from a simulated directory of files.

This is better for regression testing because it is independent of the
search algorithm. It does not need to change if the search algorithm
changes. It is not testing exactly which files the algorithm searches
for, only which file it eventually picks from a given set of available
files.

In other words, the regression test is: does it still pick the same file
from the same directory of files?

But it is impractical for thorough testing. It doesn't prove that
exactly the correct files were searched for, unless it was to test with
every possible combination of file names and directory content that
could ever exist. Clearly this is impossible to implement, since the
number of combations of possible valid filenames in a directory and
number of files in a directory is astronomically large.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: cs35l56-shared: KUnit tests for onchip speaker ID gpios

Add KUnit testing of:
cs35l56_check_and_save_onchip_spkid_gpios()
cs35l56_configure_onchip_spkid_pads()
cs35l56_read_onchip_spkid()

ASoC: cs35l56-shared: KUnit tests for onchip speaker ID gpios

Add KUnit testing of:
cs35l56_check_and_save_onchip_spkid_gpios()
cs35l56_configure_onchip_spkid_pads()
cs35l56_read_onchip_spkid()

The test consists of:

- A mock regmap that simulates the pad and pin config registers.

- Parameterization of the pin list, pulls list, a simulated value for
each pin and the speaker ID value that this should produce.

- A self-test of the simulated pin and GPIO registers.

- A test that the value returned by cs35l56_read_onchip_spkid() is
correct.

- A test that the pin pull-up/down are set correctly by
cs35l56_configure_onchip_spkid_pads()

- A test that cs35l56_configure_onchip_spkid_pads() and
cs35l56_read_onchip_spkid(0 return the expected values if
cs35l56_base->num_onchip_spkid_gpios == 0.

- A test that cs35l56_check_and_save_onchip_spkid_gpios() saves
the configuration.

- A test that cs35l56_check_and_save_onchip_spkid_gpios() rejects
illegal GPIO numbers.

- A test that cs35l56_check_and_save_onchip_spkid_gpios() rejects
illegal pull types.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260205164838.1611295-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: codec: Remove ak4641/pxa2xx-ac97 and convert to

Merge series from "Peng Fan (OSS)" <peng.fan@oss.nxp.com>:

The main goal is to convert drivers to use GPIO descriptors. While reading
the code,

ASoC: codec: Remove ak4641/pxa2xx-ac97 and convert to

Merge series from "Peng Fan (OSS)" <peng.fan@oss.nxp.com>:

The main goal is to convert drivers to use GPIO descriptors. While reading
the code, I think it is time to remove ak4641 and pxa2xx-ac97 driver,
more info could be found in commit log of each patch.
Then only need to convert sound/arm/pxa2xx-ac97-lib.c to use GPIO
descriptors. Not have hardware to test the pxa2xx ac97.

show more ...

ASoC: codec: Remove ak4641

Since commit d6df7df7ae5a0 ("ARM: pxa: remove unused board files"), there
has been no in-tree user of the AK4641 codec driver. The last user
(HP iPAQ hx4700) was a non-DT

ASoC: codec: Remove ak4641

Since commit d6df7df7ae5a0 ("ARM: pxa: remove unused board files"), there
has been no in-tree user of the AK4641 codec driver. The last user
(HP iPAQ hx4700) was a non-DT PXA board file that instantiated the device
via I2C board data; that code was removed as part of the PXA board-file
purge.

The AK4641 driver was introduced ~2011 and still probes only via the I2C
device-ID table ('.id_table'), without an 'of_match_table', so there are
no upstream Devicetree users to retain. With no in-tree users left, remove
the driver.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260122-sound-cleanup-v1-1-0a91901609b8@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: cs35l56: Add KUnit testing of cs35l56_set_fw_suffix()

Add a new KUnit test for testing the creation of firmware name
qualifiers in the cs35l56 driver. The initial set of test cases
are for cs3

ASoC: cs35l56: Add KUnit testing of cs35l56_set_fw_suffix()

Add a new KUnit test for testing the creation of firmware name
qualifiers in the cs35l56 driver. The initial set of test cases
are for cs35l56_set_fw_suffix().

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: rt5575: Add the codec driver for the ALC5575

The ALC5575 integrates an audio DSP that typically loads its firmware
from an external flash via its own SPI host interface. In certain
hardware co

ASoC: rt5575: Add the codec driver for the ALC5575

The ALC5575 integrates an audio DSP that typically loads its firmware
from an external flash via its own SPI host interface. In certain
hardware configurations, the firmware can alternatively be loaded
through the SPI client interface. The driver provides basic mute and
volume control functions. When the SPI client interface is enabled,
firmware loading is handled by the SPI driver.

Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/17c36d07af44ffb1d600977955da95852f8d60f3.1767148150.git.oder_chiou@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: codecs: Modify awinic amplifier dsp read and write functions

Modify the dsp read and write functions of the chip and normalize
the dsp read and write functions of all awinic amplifier

Signed-

ASoC: codecs: Modify awinic amplifier dsp read and write functions

Modify the dsp read and write functions of the chip and normalize
the dsp read and write functions of all awinic amplifier

Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Link: https://patch.msgid.link/20251128130323.628091-1-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: nau8325: add missing build config

This configuration was missing from the initial commit.

Found by Jiri Benc <jbenc@redhat.com>

Fixes: c0a3873b9938 ("ASoC: nau8325: new driver")
Cc: Seven Le

ASoC: nau8325: add missing build config

This configuration was missing from the initial commit.

Found by Jiri Benc <jbenc@redhat.com>

Fixes: c0a3873b9938 ("ASoC: nau8325: new driver")
Cc: Seven Lee <wtli@nuvoton.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://patch.msgid.link/20251126091759.2490019-3-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: cs530x: Add SPI bus support for cs530x parts

Cirrus Logic cs530x device family has 2 control buses I2C and SPI.
This patch adds SPI support.

Signed-off-by: Vitaly Rodionov <vitalyr@opensource

ASoC: cs530x: Add SPI bus support for cs530x parts

Cirrus Logic cs530x device family has 2 control buses I2C and SPI.
This patch adds SPI support.

Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://patch.msgid.link/20251023090327.58275-13-vitalyr@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoc: tas2783A: Add soundwire based codec driver

TAS2783 is mono digital input class-D Smart Amplifier
based on MIPI Alliance Soundwire interface. The driver
supports loading the algorithm coefficie

ASoc: tas2783A: Add soundwire based codec driver

TAS2783 is mono digital input class-D Smart Amplifier
based on MIPI Alliance Soundwire interface. The driver
supports loading the algorithm coefficients for one
or more tas2783 chips.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20250912083624.804-2-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: codecs: wcd93xxx: remove code duplication

Merge series from Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>:

All the Qualcomm WCD codecs and WCD based codecs have lots of code in
c

ASoC: codecs: wcd93xxx: remove code duplication

Merge series from Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>:

All the Qualcomm WCD codecs and WCD based codecs have lots of code in
common, resulting in lot of duplicate code.
This series is an attempt to clean some of this by moving the common
code to wcd-common library or to soundwire helper functions.

Currently I have done cleanups for 4 codecs wcd934x, wcd937x, wcd938x
and wcd939x, however any new Qualcomm codecs can avoid this duplication
by using the wcd-common library.

I have also added two helpers of_sdw_find_device_by_node() and
sdw_slave_get_current_bank() in soundwire layer for the codecs to use them,
this series was already acked by Soundwire maintainer Vinod.

As original cleanup series was depending on the new soundwire interfaces
I have combined both the series as they are cleaning up code
duplications.

As am touching the same codec drivers, 2 bug fixes are also added at the
start of the series.

There is still lot of code that is duplicate, but this is just a
starting point for such cleanups.

I have tested this on T14s, any testing is appreciated.

show more ...