| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:
Add support for TAS2563 amplifier on Intel platforms.
|
|
Merge series from Zhang Yi <zhangyi@everest-semi.com>:
Add some Kcontrols for ES8326
|
|
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.
|
|
SX controls are currently broken, since the clamp introduced in
commit a0ce874cfaaa ("ASoC: ops: improve snd_soc_get_volsw") does not
handle SX controls, for example where the min value in the clamp is
greater than the max value in the clamp.
Add clamp parameter to prevent clamping in SX controls.
The nature of SX controls mean that it wraps around 0, with a variable
number of bits, therefore clamping the value becomes complicated and
prone to error.
Fixes 35 kunit tests for soc_ops_test_access.
Fixes: a0ce874cfaaa ("ASoC: ops: improve snd_soc_get_volsw")
Co-developed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20251216134938.788625-1-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: a062c8899fed ("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>
|
|
The size of the data behind scontrol->ipc_control_data is stored in
scontrol->size, use this when copying data for backup/restore.
Fixes: db38d86d0c54 ("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>
|
|
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: a382082ff74b ("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>
|
|
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: a062c8899fed ("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>
|
|
Add match for 6x CS35L63, 3x on link 2 and 3x on link 3.
This is to support 6 amps on the CDB35L63-CB8 board.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251217163227.1186373-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a match for 6x CS35L56, 3x on link 0 and 3x on link 1.
To support the CDB35L56-EIGHT-C board using 6 amps.
This is the same as the existing 8-amp configuration
mtl_cs35l56_x8_link0_link1_fb, but reduced to 6 amps.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251217163227.1186373-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 4ed357f72a0e ("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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The use of of_property_read_bool() for non-boolean properties is
deprecated in favor of of_property_present() when testing for property
presence.
Otherwise there'll be kernel warning:
[ 29.018081] OF: /sound-wm8962: Read of boolean property 'hp-det-gpios' with a value.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20251216071656.648412-1-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch updates blind write settings for VC version.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251216090601.3955252-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This driver uses multiple regmaps, which will causes name conflicts
in debugfs like:
debugfs: '30cc0000.xcvr' already exists in 'regmap'
Fix this by adding a name for the non-core regmap configurations.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://patch.msgid.link/20251216084931.553328-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Drivers does cache sync during runtime resume, setting all writable
registers. Not all writable registers are set in cache default, resulting
in the erorr message:
fsl-sai 30c30000.sai: using zero-initialized flat cache, this may cause
unexpected behavior
Fix this by adding missing writable register defaults.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://patch.msgid.link/20251216102246.676181-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The reset_control handler has the reference count for usage, as there is
reset operation in runtime suspend and resume, then reset operation in
probe() would cause the reference count of reset not balanced.
Previously add reset operation in probe and remove is to fix the compile
issue with !CONFIG_PM, as the driver has been update to use
RUNTIME_PM_OPS(), so that change can be reverted.
Fixes: 1e0dff741b0a ("ASoC: ak4458: remove "reset-gpios" property handler")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20251216070201.358477-1-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This driver registers a component for asrc. This is also used together
with easrc, both attached using the device name as component name.
Eventually debugfs directories with identical name are created in
soc_init_component_debugfs(), leading to error message:
debugfs: '30c90000.easrc' already exists in 'tqm-tlv320aic32'
Fix this by adding the debugfs_prefix.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20251216094045.623184-3-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This driver registers two components: asrc and easrc, both attached using
the device name as component name. Eventually debugfs directories with
identical name are created in soc_init_component_debugfs(), leading to
error message:
debugfs: '30c90000.easrc' already exists in 'tqm-tlv320aic32'
Fix this by adding the debugfs_prefix.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20251216094045.623184-2-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The introduction of 8bit and FLOAT formats missed to cover the
new corner cases they cause when the NHLT blobs are looked up.
The two patch in this series fixes the 8bit and FLOAT format caused
cases to be able to find the correct blob from NHLT.
|
|
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
support for NVL-S and the support using functional topology fragments for
Soundwire configurations is introduced in 6.19-rc1 in parallel.
The SOF projects plan is to not create individual topology files for NVL
as with SDCA and the functional topology support can handle most if not
all soundwire devices going forward.
However one issue have been identified with the functional topology only
support, which was masked by the presence of a single topology file:
if the device contains a dai link for which we don't have topology fragment,
then the probe will fail.
This worked with a fallback to a monolithic topology file - which made the
dai link to be ignored.
The first patch in the series adds a flag to instruct the function discovery
to make a best effort to form a card by ignoring functions without
corresponding fragment (and print this out for developers) in case there
is no fallback topology available.
The second patch removes the match entry to refer to a topology file which
will not be built by the SOF project.
|
|
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).
|
|
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>
|
|
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>
|
|
Revert "ASoC: Intel: soc-acpi-intel-nvl-match: add rt722 l3 support"
NVL should be only using functional topologies for products, no monolithic
topologies are planned to be released.
In parallel a feature has been landed [1] which allows to remove the
entries from the match table for sdca codecs to rely solely on function
fragments.
This reverts commit 41566e3de40616375e8dfe5455344558b79f9354.
Link: https://lore.kernel.org/linux-sound/20251014071335.3844631-1-yung-chuan.liao@linux.intel.com/
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251215101036.9370-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When there is no fallback possibility available for the function topology
use it is better to try to create a profile for the card in best effort
manner, leaving out non supported links for example.
As an example: some laptops present SSPx-BT link but we don't have fragment
yet to support this. If we only have support for functional topology
without monolithic fallback then we would fail the card creation.
The reason why the monolithic topology works on the same device is that it
does not have the SSPx-BT link handled, it is ignored.
In case when there is no fallback possibility we should try to create the
card with links that we support as best effort instead of failing and
leaving the user without a card.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20251215101036.9370-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
