ASoC: simple_card_utils.h: convert not to use asoc_xxx()
ASoC is using 2 type of prefix (asoc_xxx() vs snd_soc_xxx()),
but these are unified into snd_soc_xxx().
simple_card / audio_graph drivers are historically using
asoc_xxx() prefix too. simple_card / audio_graph are not
ASoC framework, so let's use simple_card_xxx_() / audio_graph_xxx()
for global function prefix.
This patch has asoc_xxx() as define to keep compatible.
It will be removed if all drivers were switched to new style.
ASoC is using 2 type of prefix (asoc_xxx() vs snd_soc_xxx()), but there
is no particular reason about that [1].
To reduce confusing, standarding these to snd_soc_xxx() is sensible.
This patch adds asoc_xxx() macro to keep compatible for a while.
It will be removed if all drivers were switched to new style.
Mark Brown [Thu, 21 Sep 2023 16:45:30 +0000 (17:45 +0100)]
ASoC: Add rtq9128 audio amplifier
Merge series from cy_huang@richtek.com:
This patch series adds Richtek rtq9128 automotive audio amplifier
support. It can deliver up to 4x75W into 4Ohm speaker from a 25V
supply in automotive applications.
The array size is irrelevant with SNDRV_CARDS. dev_index is from
codec address and the available codec number is HDA_MAX_CODECS.
Also, hda_pvt->fw is for a temporary use, no need to add a new extra
field in hdac_hda_priv{}.
Mark Brown [Tue, 19 Sep 2023 17:22:11 +0000 (18:22 +0100)]
ASoC: SOF: ipc4/Intel: Support for firmware exception
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
When a firmware crashes it creats a panic information into a telemetry
slot. The panic format is defined by Zephyr, includes stack and
additional information to help to identify the reason for the crash.
Part of the firmware exception handling the firmware also sends an
EXCEPTION_CAUGHT notification.
This series implements the kernel side handling of the exception: print
information into the kernel log export the whole telemetry slot to user
space for tools extract additional information from the panic dump.
Mark Brown [Tue, 19 Sep 2023 17:11:02 +0000 (18:11 +0100)]
ASoC: SOF: ipc4-control: Support for Switch and Enum
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Currently IPC4 has no notion of a switch or enum type of control which
is a generic concept in ALSA.
The generic support for these control types will be as follows:
- large config is used to send the channel-value par array
- param_id of a SWITCH type is 200
- param_id of an ENUM type is 201
Each module need to support a switch or/and enum must handle these
universal param_ids. The message payload is described by struct
sof_ipc4_control_msg_payload.
Mark Brown [Tue, 19 Sep 2023 16:59:30 +0000 (17:59 +0100)]
ASoC: SOF: Use generic IPC type identifiers
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Hi,
rename the IPC type defines to be more generic and intuitive:
SOF_IPC -> SOF_IPC_TYPE_3
SOF_INTEL_IPC4 -> SOF_IPC_TYPE_4
No functional change, just renaming all around.
Regards,
Peter
---
Peter Ujfalusi (9):
ASoC: SOF: Introduce generic names for IPC types
ASoC: SOF: sof-pci-dev: Update the ipc_type module parameter
description
ASoC: SOF: Kconfig: Rename SND_SOC_SOF_INTEL_IPC4 to SND_SOC_SOF_IPC4
ASoC: SOF: Use generic names for IPC types
ASoC: SOF: amd: Use generic names for IPC types
ASoC: SOF: imx: Use generic names for IPC types
ASoC: SOF: Intel: Use generic names for IPC types
ASoC: SOF: mediatek: Use generic names for IPC types
ASoC: SOF: Drop unused IPC type defines
Charles Keepax [Tue, 19 Sep 2023 10:31:16 +0000 (11:31 +0100)]
ASoC: cs42l43: Extend timeout on bias sense timeout
For very slow removals the current bias sense timeout is sometimes too
short and unclamps the mic bias before the jack removal is properly
detected by the tip detect, causing a pop. As bias sense should be
tuned to deliver very few false positives, increase the timeout fairly
dramatically to cover all but the most exaggerated removals.
Charles Keepax [Tue, 19 Sep 2023 10:31:15 +0000 (11:31 +0100)]
ASoC: cs42l43: Move headset bias sense enable earlier in process
Currently the bias sense is enabled along with the button detect, but
this has two problems. Firstly, the detections themselves arn't covered
by the bias sense, potentially resulting in pops and secondly, the
sequence of enabling/disabling looks like:
enable bias
enable bias sense
disable bias sense
disable bias
When the bias sense is disabled but the bias is still on the clamp is
removed and a pop results. Fix both of these issues by moving the bias
sense enable/disable to be along with the bias itself. With a resulting
sequence of:
enable bias sense
enable bias
disable bias
disable bias sense
Charles Keepax [Tue, 19 Sep 2023 10:31:13 +0000 (11:31 +0100)]
ASoC: cs42l43: Lower default type detect time
The current default is a little excessive, reduce the pop on insertion
by reducing the time a little. The new value of 1000uS is still pretty
conservative.
Peter Ujfalusi [Tue, 19 Sep 2023 10:31:14 +0000 (13:31 +0300)]
ASoC: SOF: ipc4-control: Add support for ALSA switch control
Volume controls with a max value of 1 are switches.
Switch controls use generic param_id and a generic struct where the data
is passed to the firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230919103115.30783-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 19 Sep 2023 10:31:13 +0000 (13:31 +0300)]
ASoC: SOF: ipc4-topology: Add definition for generic switch/enum control
Currently IPC4 has no notion of a switch or enum type of control which is
a generic concept in ALSA.
The generic support for these control types will be as follows:
- large config is used to send the channel-value par array
- param_id of a SWITCH type is 200
- param_id of an ENUM type is 201
Each module need to support a switch or/and enum must handle these
universal param_ids.
The message payload is described by struct sof_ipc4_control_msg_payload.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230919103115.30783-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Rander Wang [Tue, 19 Sep 2023 09:24:15 +0000 (12:24 +0300)]
ASoC: SOF: Intel: hda: add ipc4 FW panic support on CAVS 2.5+ platforms
Get the FW panic information from telemetry data in memory window and
dump it to kernel log. The old platforms before CAVS 2.5+ don't support
it since there is no support in FW for them.
Rander Wang [Tue, 19 Sep 2023 09:24:14 +0000 (12:24 +0300)]
ASoC: SOF: Intel: mtl: dump dsp stack
Dump dsp stack with sof_ipc4_intel_dump_telemetry_state since dsp stack
information is included by telemetry data. This also supports lnl since
the mtl code is reused.
Rander Wang [Tue, 19 Sep 2023 09:24:11 +0000 (12:24 +0300)]
ASoC: SOF: ipc4: add definition of telemetry slot for exception handling
Core dump includes hardware platform information, cpu registers and
exception call stack. FW saves core dump to telemetry slot in shared
memory window for host in the event of FW exception. This patch creates
exception node in debugfs for user to dump telemetry data.
Rander Wang [Tue, 19 Sep 2023 09:24:10 +0000 (12:24 +0300)]
ASoC: SOF: ipc4: add a helper function to search debug slot
Currently IPC4 supports GDB slot, telemetry slot and
debug slot. This helper function will be used to get
the slot offset in debug windows for further processing.
Rander Wang [Tue, 19 Sep 2023 09:24:09 +0000 (12:24 +0300)]
ASoC: SOF: ipc4-mtrace: move debug slot related definitions to header.h
The macro definitions of debug slot can be used by gdb, telemetry
and mtrace log, so move these definitions to header.h from mtrace.
Then these macro definitions can be shared
Rander Wang [Tue, 19 Sep 2023 09:24:08 +0000 (12:24 +0300)]
ASoC: SOF: Xtensa: dump ar registers to restore call stack
On Xtensa platform ar0 is for caller address and ar1 is for stack
address. The ar register dump can be used to rebuild call stack with
FW elf file by debug tools.
We should use P/C instead of M/S for SND_SOC_DAIFMT_CBx_CFx.
We should use SND_SOC_DAIFMT_xxx instead of SND_SOC_DAI_FORMAT_xxx
This patch tidyup these.
John Watts [Mon, 18 Sep 2023 13:15:30 +0000 (23:15 +1000)]
ASoC: wm8782: Constrain maximum audio rate at runtime
The wm8782 supports up to 192kHz audio when pins are set correctly.
Instead of hardcoding which rates are supported constrain them at
runtime based on a max_rate variable.
Mark Brown [Fri, 15 Sep 2023 18:03:43 +0000 (19:03 +0100)]
ASoC: intel: sof_sdw: Remove large global CPUs array
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:
Rather than keeping a single array of CPU dai link components allocate a
smaller one for each DAI link, this reduces the amount of state that
needs to be passed back and forth in the driver.
Mark Brown [Fri, 15 Sep 2023 18:03:35 +0000 (19:03 +0100)]
ASoC: SOF: ipc4/Intel: Implement split fw library
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
This series implements support for split library loading to comply with the HDA
DMA programming sequence recommendation, which is:
1. DSP side DMA programming and GEN bit set to 1
2. host side DMA programming and RUN bit set to 1
The SOF support for library loading is based on this sequence, backwards
compatibility with older reference firmware is supported (where only the
LOAD_LIBRARY message is supported).
This configuration supports ADL boards which implement DA7219 on SSP0
and MAX98360A on SSP1. DA7219 uses PLL bypass mode to avoid WCLK
locking problem. To use this mode, MCLK frequency must be 12.288 or
24.576MHz.
Brent Lu [Fri, 15 Sep 2023 12:48:45 +0000 (20:48 +0800)]
ASoC: Intel: sof_ssp_amp: do not create amp link for nocodec board
A BE DAI link for speaker amplifier is always created even a board
quirk specifies there is no amplifier. Modify the driver to check
amplifier type before creating corresponding DAI link.
The topology (sof-tgl-rt1308-hdmi-ssp.m4) which supports HDMI-IN is
using fixed BE ID for each DAI link. Therefore we also uses fixed ID
in machine driver side.
Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Balamurugan C <balamurugan.c@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915124852.1696857-13-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
This configuration supports ADL boards which implement ALC5650 dual
I2S interface codec. Two DAI links are added: AIF1 (on codec side) for
headphone and AIF2 for speakers.
ASoC: Intel: sof_rt5682: Add support for Rex with discrete BT offload.
System firmware has included additional audio DMI string
MAX98360_ALC5682I_DISCRETE_I2S_BT for discrete BT offload
supporting devices. Same DMI string match is introduced
in sof_rt5682_quirk_table.
Brent Lu [Fri, 15 Sep 2023 12:48:37 +0000 (20:48 +0800)]
ASoC: Intel: sof_rt5682: use ssp-common module to detect codec
Use ssp-common module to detect codec and amplifier type in driver
probe function and remove all quirks about codec and amplifier type.
Due to codec detection feature, we could remove HP Dooly's DMI quirk
safely.
Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915124852.1696857-5-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Brent Lu [Fri, 15 Sep 2023 12:48:35 +0000 (20:48 +0800)]
ASoC: Intel: ssp-common: support codec detection
Create a new common module to host functions which could be shared
among SSP machine drivers. Add functions to detect headphone codec and
speaker amplifier via ACPI system at runtime in order to remove codec
type quirks in machine drivers.
Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915124852.1696857-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Brent Lu [Fri, 15 Sep 2023 12:48:34 +0000 (20:48 +0800)]
ASoC: Intel: sof_rt5682: cleanup unnecessary quirk flag
Remove SOF_RT5682_MCLK_24MHZ flag from JSL and CML/WHL board configs
since the information could be retrieved from SOF API. The macro
itself is removed as well.
Charles Keepax [Fri, 15 Sep 2023 07:56:10 +0000 (15:56 +0800)]
ASoC: intel: sof_sdw: Make create_sdw_dailink allocate link components
Now only the SoundWire part of the code uses the global cpus array,
remove it and have create_sdw_dailink allocate its own link components.
This removes a lot of state being passed around in the driver, which
simplifies things a fair bit.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915075611.1619548-4-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Fri, 15 Sep 2023 07:56:09 +0000 (15:56 +0800)]
ASoC: intel: sof_sdw: Add simple DAI link creation helper
The code contains a fair amount of state tracking and one part of that
is keeping track of which entry in the large global cpus
snd_soc_dai_link_component array is currently in use. Add a helper
function to allocate a simple DAI link, this simplifies the
code slightly and moves us in the direction of eliminating the need for
the large global cpus array. This does slightly increase the number of
allocations done, but this is probe time and the code already does a
large number of allocations so this increase is small over all.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915075611.1619548-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Fri, 15 Sep 2023 07:56:08 +0000 (15:56 +0800)]
ASoC: intel: sof_sdw: Move sdw_pin_index into private struct
Whilst it should not cause any issues as only a single instance of the
machine will be instantiated, it is still slightly better practice to
keep working data in the private data structure, rather than a global
variable. Move sdw_pin_index into the mc_private structure.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915075611.1619548-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The compile warning with -Wformat-truncation at
sdw_amd_scan_controller() is false-positive; the max loop size is
AMD_SDW_MAX_MANAGERS (= 2), hence it fits with the given size.
For suppressing the warning, replace snprintf() with scnprintf().
As stated in the above, truncation doesn't matter.
Shuming Fan [Fri, 15 Sep 2023 02:05:30 +0000 (10:05 +0800)]
ASoC: rt1015: fix the first word being cut off
This patch adds a control that there are four options to control the digital volume output.
The user could select "immediate" to make volume updates immediately.
In default, the driver selects the volume update with "zero detection + soft inc/dec change".
Peter Ujfalusi [Fri, 15 Sep 2023 11:40:18 +0000 (14:40 +0300)]
ASoC: SOF: Intel: hda-loader: Add support for split library loading
There is a certain sequence needs to be followed when configuring the HDA
DMA in host and DSP.
The firmware provides a way to handle this two stage sequencing by
splitting the library loading into two stage:
1st stage: LOAD_LIBRARY_PREPARE message
the lib_id is 0, used to configure the DMA on DSP side
2nd stage: LOAD_LIBRARY message
both dma_id and lib_id is valid, used for the actual transfer of
the library
In case a firmware without support for this two stage loading is used then
the second stage message will trigger the loading and the first stage will
return with error, which is ignored by the kernel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://lore.kernel.org/r/20230915114018.1701-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 15 Sep 2023 11:40:17 +0000 (14:40 +0300)]
ASoC: SOF: ipc4: Add new message type: SOF_IPC4_GLB_LOAD_LIBRARY_PREPARE
On Intel platforms there is a strict order requirement for the DMA
programming:
DSP side configures the buffer and sets the GEN bit
Host side sets the RUN bit.
In order to follow this flow, a new global message type has been added to
prepare the DSP side of the DMA:
host sends LOAD_LIBRARY_PREPARE with the dma_id
DSP side sets its buffer and sets the GEN bit
Host sets the RUN bit
Host sends LOAD_LIBRARY with dma_id and lib_id
DSP receives the library data.
It is up to the platform code to use the new prepare stage message and how
to handle the reply to it from the firmware, which can indicate that the
message type is not supported/handled.
In this case the kernel should proceed to the LOAD_LIBRARY stage assuming
a single stage library loading:
host sends LOAD_LIBRARY_PREPARE with the dma_id
DSP replies that the message type is not supported/handled
Host acknowledges the return code and sets the RUN bit
Host sends LOAD_LIBRARY with dma_id and lib_id
DSP receives the library data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://lore.kernel.org/r/20230915114018.1701-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 15 Sep 2023 11:40:16 +0000 (14:40 +0300)]
ASoC: SOF: Intel: hda: Add definition for SDxFIFOS.FIFOS mask
The FIFOS (FIFO Size) field is in bit 0-15 of the register.
Use the defined mask instead of a magic number for the FIFOS value
masking in hda_dsp_stream_hw_params().
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://lore.kernel.org/r/20230915114018.1701-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: ipc4-pcm: fixup dailink based on copier format
When a copier exposes a single format, we can fixup the BE dailink with
that format. This is helpful when some codec have format restrictions and
e.g. don't support a 32-bit format. In that case, the copier output
formats mirror that restriction in the topology file.
An alternate solution was suggested earlier using a dedicated topology
token. When specified, the token would be used to fix-up the dailink. The
main reason why this solution was chosen is that there is a risk of a
disconnect between token definition and copier format. With a single piece
of information as suggested in this patch, there are fewer risks of a bad
configuration.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230915093507.7242-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>