Commit Graph
1412087 Commits
Author SHA1 Message Date
Mark Brown 0bd4b0f583 ASoC / soc/qcom: Constify APR/GPR callback response
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>:

This constifies the response data used for APR/GPR callbacks.
2025-12-22 19:41:18 +00:00
Shuming Fan 8db50f0fa4 ASoC: rt1320: fix the warning the string may be truncated
1488 |                          "realtek/rt1320/rt1320_%s_%s_%s.dat", vendor, product, sku);
     |                                                 ^~             ~~~~~~
sound/soc/codecs/rt1320-sdw.c:1487:17: note: 'snprintf' output between 29 and 410 bytes into a destination of size 128
1487 |                 snprintf(filename, sizeof(filename),
     |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1488 |                          "realtek/rt1320/rt1320_%s_%s_%s.dat", vendor, product, sku);
     |

Fixes: da1682d5e8 ("ASoC: rt1320: support calibration and temperature/r0 loading")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512191521.RK0edKdX-lkp@intel.com/
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251222101329.558973-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-22 17:51:06 +00:00
Dan Carpenter c6bca73d69 ASoC: rt1320: Fix retry checking in rt1320_rae_load()
This loop iterates 200 times and then gives up.  The problem is that
currently the loop exits with "retry" set to -1 on the failure path but
the check for failure expects it to be 0.  Change from a post-op to a
pre-op so that it exits with "retry" set to 0.

Fixes: 22937af75a ("ASoC: rt1320: support RAE parameters loading")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/aUZiNJ7pzuahXFYE@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-22 09:02:04 +00:00
Nathan Chancellor 9e692bb541 ASoC: rt1320: Change return type of rt1320_t0_load() to void
Clang warns (or errors with CONFIG_WERROR=y / W=e):

  sound/soc/codecs/rt1320-sdw.c:1387:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
   1387 |         if (!fw_ready) {
        |             ^~~~~~~~~
  sound/soc/codecs/rt1320-sdw.c:1421:9: note: uninitialized use occurs here
   1421 |         return ret;
        |                ^~~
  sound/soc/codecs/rt1320-sdw.c:1387:2: note: remove the 'if' if its condition is always false
   1387 |         if (!fw_ready) {
        |         ^~~~~~~~~~~~~~~~
   1388 |                 dev_warn(dev, "%s, DSP FW is NOT ready\n", __func__);
        |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1389 |                 goto _exit_;
        |                 ~~~~~~~~~~~~
   1390 |         }
        |         ~
  sound/soc/codecs/rt1320-sdw.c:1366:9: note: initialize the variable 'ret' to silence this warning
   1366 |         int ret;
        |                ^
        |                 = 0

The return value of rt1320_t0_load() is never actually used, so it can
just be eliminated altogether by returning void, clearing up the
warning.

Fixes: da1682d5e8 ("ASoC: rt1320: support calibration and temperature/r0 loading")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512191711.wY6XU796-lkp@intel.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251219-rt1320-sdw-avoid-uninit-ret-v1-1-faa3e250ebc4@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-22 09:02:03 +00:00
Krzysztof Kozlowski a2a631830d ASoC: qcom: Constify APR/GPR result structs
APR and GPR callbacks receive pointer to const response packet which
holds the response result.  That result should not be modified by
callback, so make it pointer to const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-4-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-19 21:29:31 +00:00
Krzysztof Kozlowski f3a86870c5 ASoC: qcom: Constify GPR callback response data
GPR bus driver calls each GPR client callback with pointer to the GPR
response packet.  The callbacks are not suppose to modify that response
packet, so make it a pointer to const to document that expectation
explicitly.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-3-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-19 21:29:30 +00:00
Krzysztof Kozlowski c66cea195d soc: qcom: apr: Use typedef for GPR callback member
There is already a typedef for GPR callback used in 'struct
pkt_router_svc', so use it also in 'struct apr_driver', because it is
the same type - one is assigned to another in apr_device_probe().

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-2-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-19 21:29:29 +00:00
Krzysztof Kozlowski 86af3c2292 ASoC: qcom: Constify APR callback response data
APR bus driver calls each APR client callback with pointer to the APR
response packet.  The callbacks are not suppose to modify that response
packet, so make it a pointer to const to document that expectation
explicitly.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-1-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-19 21:29:28 +00:00
Mark Brown dc8d1ba537 ASoC: Intel: add support for TAS2563 amplifier
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:

Add support for TAS2563 amplifier on Intel platforms.
2025-12-19 13:13:57 +00:00
Mark Brown 20c24c1b28 ASoC: codecs: ES8326 : Add Kcontrol
Merge series from Zhang Yi <zhangyi@everest-semi.com>:

Add some Kcontrols for ES8326
2025-12-19 13:13:53 +00:00
Mark Brown 10929de75e ASoC: SOF: ipoc4: Support for generic bytes
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

We support bytes control type for set and get, but these are module specific
controls and there is no way to handle notifications from them in a generic way.
Each control have module specific param_id and this param_id is only valid in
the module's scope, other modules might use the same id for different functions
for example.

This series will add a new generic control type, similar to the existing ones
for ENUM and SWITCH, which can be used to create bytes controls which can send
notifications from firmware on change.

The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to
describe bytes payload also.

On set, the payload must include the sof_ipc4_control_msg_payload struct with
the control's ID and data size, followed by the data.

On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along
with the LARGE_CONFIG_GET message as payload with the ID of the control that
needs to be retrieved. The raw data is received back without additional header.

A notification might contain data, in this case the num_elems reflects the size
in bytes, or without data. If no data is received then the control is marked as
dirty and on read the kernel will refresh the data from firmware.

The series includes mandatory fixes for existing code and adds support for
sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM,
SWITCH or BYTES control.
2025-12-19 13:13:48 +00:00
Johan Hovold 7a8447fc71 ASoC: codecs: wcd939x-sdw: use devres for regmap allocation
Components are bound inside a new devres group so that any resources
allocated can be released on bind failure and on unbind without
affecting anything else.

Switch to using device managed regmap allocation for consistency while
dropping the misleading comment claiming that devres cannot be used.

Cc: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251201092259.11761-1-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 15:32:43 +00:00
HariKrishna Sagala 3622dc47a4 ASoC: codec: rt286: Use devm_request_threaded_irq to manage IRQ lifetime and fix smatch warning
Replace manual "request_threaded_irq()" with the device managed
"devm_request_threaded_irq" to manage the IRQ lifetime and also
it removes the smatch reported warning.
Remove the manual "free_irq()" in the "remove" function as free_irq
is tied to device teardown.

Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com>
Link: https://patch.msgid.link/20251217054458.38257-2-hariconscious@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:52 +00:00
Niranjan H Y 961f20faa4 ASoC: tas2783A: read slave properties from acpi table
Currently device is using hardcoded slave properties
using the .read_prop callback from "struct sdw_slave_ops".
This patch removes this and uses the sdw_slave_read_prop API
to read the data directly from the ACPI table.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251215153219.810-8-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:51 +00:00
Niranjan H Y ca8f3611dc ASoC: tas2783A: use acpi initialisation table
This patch adds support for parsing the initilisation
data from ACPI table. This table is required to configure
each device correctly so that correct channel's data is
selected during playback.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251215153219.810-7-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:50 +00:00
Niranjan H Y a6b5629e13 ASoc: tas2783A: acpi match for 4 channel for mtl
Add changes to support 4 tas2783A devices on mtl platform.
The supported unique IDs are updated to 9, a, c, d, where
c and d are configured to play left channels and 9 and a
are configured to play right channel.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-6-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:49 +00:00
Niranjan H Y 2bc4b4f77c ASoc: tas2783A: fw name based on system details
The firmware file for tas2783A contains the device
and algorithm settings. So the firmware files are unique
for a system and driver should have the ability to
distinctly identify and pick the right firmware.

This commit adds the method to uniquely identify the
firmware for a system based on the below format.
 <Subsystem>-<Link>-<Unique>.bin

* Subsystem is the PCI device subsystem-id
* Link is the SoundWire link id on which the device recides.
* Unique is the SoundWire slave unique id in the system.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-5-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:48 +00:00
Niranjan H Y ce65a90222 ASoC: tas2783A: fix error log for calibration data
Currently when the calibration is not found, it is wrongly
logged as device is not found. Fix this error message to
indicate that calibration data is not valid instead.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-4-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:47 +00:00
Niranjan H Y f8f1f0d8f0 ASoC: tas2783A: update default init writes
Remove unwanted initialistaion writes to the
device which will now be part of the either firmware
or acpi table.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-3-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:46 +00:00
Niranjan H Y a3b0cd63f2 ASoC: tas2783A: use custom firmware
Use the firmware version same as in Windows
projects. The firmware contains algorithm
parameters and some device configuration
writes which are part of the same firmware file.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-2-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:45 +00:00
Niranjan H Y 5965df0670 ASoC: tas2783A: sdw_utils: support ch 3 & 4
Currently the machine driver for tas2783A can only
support 2 channels. This patch adds support for
2 channel playback with 4 device setup.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-1-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18 08:21:44 +00:00
Peter Ujfalusi 2a28b5240f ASoC: SOF: ipc4-control: Add support for generic bytes control
The generic byte control can be used in cases when the bytes data can be
changed by the firmware and it sends a notification about the change,
similarly to the enum and switch controls.

The generic control support is needed as from the param_id itself it is
not possible to know which control has changed. The needed information
is only available via generic control change notification.

Generic bytes controls use param_id 202 and their change notification can
contain payload with the change embedded or just the header message as
notification.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-9-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:51 +00:00
Peter Ujfalusi 7fd8c216c4 ASoC: SOF: ipc4: Add definition for generic bytes control
Currently IPC4 only supports module specific custom bytes controls, where
each control's param_id is module specific.
These bytes controls cannot be handled in a generic way, there is no clean
way to support for example notifications from firmware when their data
has been changed.

Add definition for generic bytes control which should be handled in a
similar way as the enum/switch controls.

The generic param id for BYTES is selected to be 202

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-8-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:50 +00:00
Peter Ujfalusi d96cb0b86d ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET
There are message types when we would need to send a payload along with
the LARGE_CONFIG_GET message to provide information to the firmware on
what data is requested.
Such cases are the ALSA Kcontrol related messages when the high level
param_id tells only the type of the control, but the ID/index of the exact
control is specified in the payload area.

The caller must place the payload for TX before calling the set_get_data()
and this payload will be sent alongside with the message to the firmware.

The data area will be overwritten by the received data from firmware.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:49 +00:00
Peter Ujfalusi 2fdde18a2c ASoC: SOF: ipc4-topology: Set initial param_id for bytes control type
Set the param_id in extension based on the information we got from the
topology.
If the payload did not present then the param_id will remain 0.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:48 +00:00
Peter Ujfalusi ebcfdbe4ad ASoC: SOF: ipc4-control: Keep the payload size up to date
When the bytes data is read from the firmware, the size of the payload
can be different than what it was previously.
For example when the topology did not contained payload data at all for the
control, the data size was 0.
For get operation allow maximum size of payload to be read and then update
the sizes according to the completed message.

Similarly, keep the size in sync when updating the data in firmware.

With the change we will be able to read data from firmware for bytes
controls which did not had initial payload defined in topology.

Fixes: a062c8899f ("ASoC: SOF: ipc4-control: Add support for bytes control get and put")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:47 +00:00
Peter Ujfalusi c1876fc33c ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data
The size of the data behind scontrol->ipc_control_data is stored in
scontrol->size, use this when copying data for backup/restore.

Fixes: db38d86d0c ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:46 +00:00
Peter Ujfalusi a653820700 ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls
The size of the data behind of scontrol->ipc_control_data for bytes
controls is:
[1] sizeof(struct sof_ipc4_control_data) + // kernel only struct
[2] sizeof(struct sof_abi_hdr)) + payload

The max_size specifies the size of [2] and it is coming from topology.

Change the function to take this into account and allocate adequate amount
of memory behind scontrol->ipc_control_data.

With the change we will allocate [1] amount more memory to be able to hold
the full size of data.

Fixes: a382082ff7 ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BYTES")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:45 +00:00
Peter Ujfalusi 2fa7471374 ASoC: SOF: ipc4-control: If there is no data do not send bytes update
When the bytes control have no data (payload) then there is no need to send
an IPC message as there is nothing to send.

Fixes: a062c8899f ("ASoC: SOF: ipc4-control: Add support for bytes control get and put")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 16:35:44 +00:00
Kuninori Morimoto f764645cb8 ASoC: codecs: tas2780: tidyup format check in tas2780_set_fmt()
Current code is using messy code to check format. Let's cleanup
it by using switch().

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87h5trrljz.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:39 +00:00
Krzysztof Kozlowski 3e43a8c033 ASoC: qcom: audioreach: Add support for VI Sense module
VI Sense module in ADSP is responsible for feedback loop for measuring
current and voltage of amplifiers, necessary for proper calibration of
Speaker Protection algorightms.  Implement parsing
MODULE_ID_SPEAKER_PROTECTION_VI from Audioreach topology and sending it
as command to the ADSP.

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251217094602.55117-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:38 +00:00
Krzysztof Kozlowski 0db76f5b22 ASoC: qcom: audioreach: Add support for Speaker Protection module
Speaker Protection is capability of ADSP to adjust the gain during
playback to different speakers and their temperature.  This allows good
playback without blowing the speakers up.

Implement parsing MODULE_ID_SPEAKER_PROTECTION from Audioreach topology
and sending it as command to the ADSP.

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251217094602.55117-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:37 +00:00
Richard Fitzgerald 9a123f222e ASoC: cs-amp-lib: Replace __free(kfree) with normal kfree() cleanup
Replace the use of __free(kfree) in _cs_amp_set_efi_calibration_data()
with normal kfree() at the end of the function.

Krzysztof Kozlowski pointed out that __free() can be dangerous.
It can introduce new cleanup bugs. These are more subtle and difficult to
spot than a missing goto in traditional cleanup, because they are triggered
by writing regular idiomatic C code instead of using C++ conventions. As
it's regular C style it's more likely to be missed because the code is as
would be expected for C. The traditional goto also more obviously flags
to anyone changing the code in the future that they must be careful about
the cleanup.

Arguably the traditional approach is more readable, and it avoids the
manipulation of __free() pointers when the buffer is reallocated for
resizing.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251201123906.86876-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:37 +00:00
Shuming Fan 22937af75a ASoC: rt1320: support RAE parameters loading
This patch supports the RAE parameters loading.
The RAE parameters is related to EQ/DRC parameters for each endpoint.
The driver could load these parameters from the binary file.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251216090630.3955323-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:36 +00:00
Simon Trimmer 87783532d3 ASoC: SDCA: Allow sample width wild cards in set_usage()
The SDCA spec allows the sample rate and width to be wild cards, but the
current implementation of set_usage() only checked for a wild card of
the sample rate.

Fixes: 4ed357f72a ("ASoC: SDCA: Add hw_params() helper function")
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251216142204.183958-1-simont@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:35 +00:00
Shuming Fan da1682d5e8 ASoC: rt1320: support calibration and temperature/r0 loading
This patch adds the functions/controls to support the calibration.
The mixer controls could trigger a calibration and load temperature/r0 value.

Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251216090616.3955293-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:34 +00:00
HariKrishna Sagala 3a4e4e0003 ASoC: codec: rt298: Use devm_request_threaded_irq to manage IRQ lifetime and fix smatch warning
Replace manual "request_threaded_irq()" with the device managed
"devm_request_threaded_irq" to manage the IRQ lifetime and also
it removes the smatch reported warning.
Remove the manual "free_irq()" in the "remove" function as free_irq
is tied to device teardown.

Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com>
Link: https://patch.msgid.link/20251217104356.60839-3-hariconscious@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:33 +00:00
David Lin 02e7af5b64 ASoC: Intel: sof_rt5682: add tas2563 speaker amp support
This patch adds tas2563 which supports the RT5682 headset codec
and TAS2563 speaker amplifier combination on PantherLake platform.

Signed-off-by: David Lin <david.lin@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251217110433.3558136-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:27 +00:00
David Lin 331786db1b ASoC: Intel: ti-common: support tas2563 amplifier
Implement tas2563 support code in this common module so it could be
shared between multiple SOF machine drivers.

Signed-off-by: David Lin <david.lin@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251217110433.3558136-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:04:27 +00:00
Zhang Yi 9a6bc0a406 ASoC: codecs: ES8326: Add kcontrol for DRE
Set up a kcontrol to control DRE

Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20251216064721.4622-3-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:01:25 +00:00
Zhang Yi 68970b5389 ASoC: codecs: ES8326: Add a kcontrol for PGAGAIN
set a kcontrol to control bit 7 of ES8326_PGAGAIN
instead of setting a fixed value in the driver

Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20251216064721.4622-2-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-17 12:01:24 +00:00
Mark Brown dab6b6f5fc ASoC: SOF: Support for on-demand DSP boot
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

On system suspend / resume we always power up the DSP and boot the
firmware, which is not strictly needed as right after the firmware booted
up we power the DSP down again on suspend and we also power it down after
resume after some inactivity.

Similarly, on jack insert/removal we needlesly boot up the firmware to check
the jack status, which needs no DSP/firmware communication.

The on-demand DSP boot will make sure that we boot the DSP firmware up only
when it is needed - for audio activity, in other cases the firmware will be
not booted up, which saves time.

Out of caution, add a new platform descriptor flag to enable on-demand
DSP boot since this might not work without changes to platform code on
certain platforms.

With the on-demand dsp boot enabled we will not boot the DSP and firmware
up on system or rpm resume, just enable audio subsystem since audio IPs,
like HDA and SoundWire might be needed (codecs suspend/resume operation).
Only boot up the DSP during the first hw_params() call when the DSP is
really going to be needed.

In this way we can handle the audio related use cases:
normal audio use (rpm suspend/resume)
system suspend/resume without active audio
system suspend/resume with active audio
system suspend/resume without active audio, and audio start before the rpm
suspend timeout

Add module option to force the on-demand DSP boot to allow it to be
disabled or enabled without kernel change for testing.

The on-demand boot has been tested in our CI for more than half a year
and so far no issues have been seen on supported platforms since it's
introduction to our development tree (sof-dev).
2025-12-16 19:12:22 +00:00
Peter Ujfalusi 524ee55994 ASoC: SOF: Intel: hda: Only check SSP MCLK mask in case of IPC3
IPC4 is using the NHLT blob itself and sends the SSP blob from it directly
to the firmware, there is no need for the MCLK quirk based on the SSP blob
since the SSP blob is in use.

At the same time reword the error, info and debug messages for clarity.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Balamurugan C <balamurugan.c@intel.com>
Link: https://patch.msgid.link/20251215130819.31218-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:08:48 +09:00
Andy Shevchenko a1bcb66209 ASoC: Fix acronym for Intel Gemini Lake
While the used GML is consistent with the pattern for other Intel * Lake
SoCs, the de facto use is GLK. Update the acronym and users accordingly.

Note, a handful of the drivers for Gemini Lake in the Linux kernel use
GLK already (LPC, MEI, pin control, SDHCI, ...) and even some in ASoC.
The only ones in this patch used the inconsistent one.

Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20251212181742.3944789-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:08:47 +09:00
Peter Ujfalusi f25c7d709b ASoC: SOF: Intel: pci-nvl: Set on_demand_dsp_boot for NVL-S
NVL-S can be used with on-demand DSP booting, set the flag to enable it.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20251215132946.2155-9-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:46 +09:00
Peter Ujfalusi aabcb01353 ASoC: SOF: Intel: pci-ptl: Set on_demand_dsp_boot for PTL and WCL
PTL and WCL can be used with on-demand DSP booting, set the flag to
enable it.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-8-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:45 +09:00
Peter Ujfalusi 6780fb864d ASoC: SOF: Intel: pci-lnl: Set on_demand_dsp_boot for LNL
LNL can be used with on-demand DSP booting, set the flag to enable it.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:44 +09:00
Peter Ujfalusi d4e34f4ef8 ASoC: SOF: Intel: hda-sdw-bpt: Add support for on-demand DSP boot
If on-demand DSP boot is used we need to make sure that the DSP is booted
up - which might not be the case - since we need ChainDMA in normal, non
DSPless mode for the BRA to work.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:43 +09:00
Peter Ujfalusi 2cf7a9ced3 ASoC: SOF: sof-client: Add support for on-demand DSP boot
With the introduction of on-demand DSP boot the rpm status not necessary
tells that the DSP firmware is booted up.

Introduce the sof_client_boot_dsp() which can be used to make sure that
the DSP is booted and it can handle IPCs.

Update the client drivers to use the new function where it is expected that
the DSP is booted up.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:42 +09:00
Peter Ujfalusi c3e1549811 ASoC: SOF: Add support for on-demand DSP boot
On system suspend / resume we always power up the DSP and boot the
firmware, which is not strictly needed as right after the firmware booted
up we power the DSP down again on suspend and we also power it down after
resume after some inactivity.

Out of caution, add a new platform descriptor flag to enable on-demand
DSP boot since this might not work without changes to platform code on
certain platforms.

With the on-demand dsp boot enabled we will not boot the DSP and firmware
up on system or rpm resume, just enable audio subsystem since audio IPs,
like HDA and SoundWire might be needed (codecs suspend/resume operation).
Only boot up the DSP during the first hw_params() call when the DSP is
really going to be needed.

In this way we can handle the audio related use cases:
normal audio use (rpm suspend/resume)
system suspend/resume without active audio
system suspend/resume with active audio
system suspend/resume without active audio, and audio start before the rpm
suspend timeout

Add module option to force the on-demand DSP boot to allow it to be
disabled or enabled without kernel change for testing.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15 23:07:41 +09:00