summaryrefslogtreecommitdiffstats
path: root/sound
Commit message (Collapse)AuthorAgeFilesLines
* ASoC: meson: axg-fifo: take continuous ratesJerome Brunet2024-02-263-6/+12
| | | | | | | | | | | | | | | The rate of the stream does not matter for the fifos of the axg family. Fifos will just push or pull data to/from the DDR according to consumption or production of the downstream element, which is the DPCM backend. Drop the rate list and allow continuous rates. The lower and upper rate are set according what is known to work with the different backends This allows the PDM input backend to also use continuous rates. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://msgid.link/r/20240223175116.2005407-6-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: meson: axg-spdifin: use max width for rate detectionJerome Brunet2024-02-261-3/+3
| | | | | | | | | | | | | | Use maximum width between 2 edges to setup spdifin thresholds and detect the input sample rate. This comes from Amlogic SDK and seems to be marginally more reliable than minimum width. This is done to align with a future eARC support. No issue was reported with minimum width so far, this is considered to be an update so no Fixes tag is set. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://msgid.link/r/20240223175116.2005407-5-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: meson: axg-tdm-interface: update error format error tracesJerome Brunet2024-02-261-1/+1
| | | | | | | | | | | ASoC stopped using CBS_CFS and CBM_CFM a few years ago but the traces in the amlogic tdm interface driver did not follow. Update this to match the new format names Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://msgid.link/r/20240223175116.2005407-4-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: meson: axg-tdm-interface: add frame rate constraintJerome Brunet2024-02-261-7/+18
| | | | | | | | | | | | | | | | | | | | | | | According to Amlogic datasheets for the SoCs supported by this driver, the maximum bit clock rate is 100MHz. The tdm interface allows the rates listed by the DAI driver, regardless of the number slots or their width. However, these will impact the bit clock rate. Hitting the 100MHz limit is very unlikely for most use cases but it is possible. For example with 32 slots / 32 bits wide, the maximum rate is no longer 384kHz but ~96kHz. Add the constraint accordingly if the component is not already active. If it is active, the rate is already constrained by the first stream rate. Fixes: d60e4f1e4be5 ("ASoC: meson: add tdm interface driver") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://msgid.link/r/20240223175116.2005407-3-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: meson: axg-tdm-interface: fix mclk setup without mclk-fsJerome Brunet2024-02-261-2/+2
| | | | | | | | | | | | | | | | | | | | By default, when mclk-fs is not provided, the tdm-interface driver requests an MCLK that is 4x the bit clock, SCLK. However there is no justification for this: * If the codec needs MCLK for its operation, mclk-fs is expected to be set according to the codec requirements. * If the codec does not need MCLK the minimum is 2 * SCLK, because this is minimum the divider between SCLK and MCLK can do. Multiplying by 4 may cause problems because the PLL limit may be reached sooner than it should, so use 2x instead. Fixes: d60e4f1e4be5 ("ASoC: meson: add tdm interface driver") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://msgid.link/r/20240223175116.2005407-2-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ALSA: cs35l56: Apply calibration from EFIMark Brown2024-02-2410-19/+467
|\ | | | | | | | | | | | | | | | | | | | | | | Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>: Factory calibration of the speakers stores the calibration information into an EFI variable. This set of patches adds support for applying speaker calibration data from that EFI variable. The HDA patch (#5) depends on the ASoC patches #2 and #3
| * ALSA: hda: cs35l56: Apply amp calibration from EFI dataRichard Fitzgerald2024-02-232-7/+34
| | | | | | | | | | | | | | | | | | If there are factory calibration settings in EFI, extract the settings and write them to the firmware calibration controls. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240223153910.2063698-6-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * ASoC: cs35l56: Apply amp calibration from EFI dataRichard Fitzgerald2024-02-232-3/+61
| | | | | | | | | | | | | | | | | | | | | | | | If there are factory calibration settings in EFI, extract the settings and write them to the firmware calibration controls. This must be done after any firmware or coefficients have been downloaded to the amp. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240223153910.2063698-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * ASoC: cs35l56: Add helper functions for amp calibrationRichard Fitzgerald2024-02-232-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds some helper functions and data for applying amp calibration. 1. cs35l56_read_silicon_uid() to get the silicon ID that is used to search for the correct calibration data entry. 2. Add the registers for the silicon ID to the readable registers. 3. cs35l56_get_calibration() wrapper around cs_amp_get_efi_calibration_data() 4. cs35l56_calibration_controls() table of the firmware controls for calibration data. 5. Added members to struct cs35l56_base to store the calibration data. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240223153910.2063698-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * ASoC: cs-amp-lib: Add helpers for factory calibration dataRichard Fitzgerald2024-02-233-0/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new library for code that is used by multiple Cirrus Logic amps. This initially implements extracting amp calibration data from EFI and writing it to firmware controls. During factory calibration of built-in speakers the firmware calibration constants are stored in an EFI file. The file contains an array of calibration constants for each of the speakers. cs_amp_get_calibration_data() searches for an entry matching the requested UID stamp, otherwise by array index. If the data is found in EFI the constants for that speaker are copied back to the caller. If EFI is not enabled, the cs_amp_get_calibration_data() implementation will compile to simply return -ENOENT and the linker can drop the code. The code to write calibration controls uses cs_dsp. Building of cs_dsp is not forced. Instead, the code will compile away the calls to cs_dsp if cs_dsp is not reachable. This strategy of conditional code allows cs-amp-lib to be shared by multiple drivers without forcing inclusion of other modules that might be unnecessary. The calls to efi.get_variable() and cs_dsp are in small wrapper functions. This is so that a KUNIT_STATIC_STUB_REDIRECT can be added in a future patch to redirect these calls to replacement functions for KUnit testing. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240223153910.2063698-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * ASoC: wm_adsp: Add wm_adsp_start() and wm_adsp_stop()Richard Fitzgerald2024-02-232-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | Separate the functionality of wm_adsp_event() into two exported functions wm_adsp_start() and wm_adsp_stop(). This allows the codec driver to start and stop the DSP outside of a DAPM widget. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240223153910.2063698-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: soc-core: tidyup strcmp() param on snd_soc_is_matching_dai()Kuninori Morimoto2024-02-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | snd_soc_is_matching_dai() checks DAI name, which is paired function with snd_soc_dai_name_get(). It checks dlc->dai_name and dai->name (A) or dai->driver_name (B) or dai->component->name (C) static int snd_soc_is_matching_dai(...) { ... if (strcmp(dlc->dai_name, dai->name) == 0) ~~~~~~~~~~~~~ ^^^^^^^^^(A) if (... strcmp(dai->driver->name, dlc->dai_name) == 0) (B)^^^^^^^^^^^^^^^^ ~~~~~~~~~~~~~ if (... strcmp(dlc->dai_name, dai->component->name) == 0) ~~~~~~~~~~~~~ ^^^^^^^^^^^^^^^^^^(C) ... } But (B) part order is different with (A) and (C) (= ^^^^ and ~~~~). This is not a big deal, but confusable to read. Fixup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://msgid.link/r/87wmqxjbcg.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: amd: ps: modify ACP register end address macroVijendar Mukunda2024-02-221-1/+1
| | | | | | | | | | | | | | | | Modify ACP63_REG_END macro to access all ACP registers. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240222102656.631144-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: amd: ps: update licenseVijendar Mukunda2024-02-225-5/+5
| | | | | | | | | | | | | | | | | | | | To align with AMD SoundWire manager driver license, update license as GPL-2.0-only for Pink Sardine ACP PCI driver and corresponding child drivers. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240222102656.631144-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: codecs: wsa884x: Allow sharing reset GPIOKrzysztof Kozlowski2024-02-211-10/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some boards with multiple WSA8840/WSA8845 speakers, the reset (shutdown) GPIO is shared between two speakers. Use the reset controller framework and its "reset-gpio" driver to handle this case. This allows bring-up and proper handling of all WSA884x speakers on X1E80100-CRD board. Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://msgid.link/r/20240129115216.96479-7-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: Intel: avs: Fixes and new platforms supportMark Brown2024-02-2160-470/+1765
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge series from Cezary Rojewski <cezary.rojewski@intel.com>: The avs-driver continues to be utilized on more recent Intel machines. As TGL-based (cAVS 2.5) e.g.: RPL, inherit most of the functionality from previous platforms: SKL <- APL <- CNL <- ICL <- TGL rather than putting everything into a single file, the platform-specific bits are split into cnl/icl/tgl.c files instead. Makes the division clear and code easier to maintain. Layout of the patchset: First are two changes combined together address the sound-clipping problem, present when only one stream is running - specifically one CAPTURE stream. Follow up is naming-scheme adjustment for some of the existing functions what improves code incohesiveness. As existing IPC/IRQ code operates solely on cAVS 1.5 architecture, it needs no abstraction. The situation changes when newer platforms come into the picture. Thus the next two patches abstract the existing IPC/IRQ handlers so that majority of the common code can be re-used. The ICCMAX change stands out a bit - the AudioDSP firmware loading procedure differs on ICL-based platforms (and onwards) and having a separate commit makes the situation clear to the developers who are going to support the solution from LTS perspective. For that reason I decided not to merge it into the commit introducing the icl.c file.
| * | ASoC: Intel: avs: Populate board selection with new I2S entriesCezary Rojewski2024-02-201-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update board selection with tables specifying supported I2S configurations. DMIC/HDAudio board selection require no update as dmic/hdaudio machine boards are generic and not tied to any specific codec. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-11-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: ICCMAX recommendations for ICL+ platformsCezary Rojewski2024-02-203-2/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For ICL+ platforms to avoid DMI/OPIO L1 entry during the base firmware load procedure, HW recommends to set LTRP_GB to 95us and start an additional CAPTURE stream in the background. Once the load completes, original LTRP_GB value is restored and the additional stream is released. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-10-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: TGL-based platforms supportCezary Rojewski2024-02-204-1/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define handlers specific to cAVS 2.5 platforms, that is TGL, ADL, RPL and all other variants based on this very version of AudioDSP architecture. Most operations are inherited from their predecessors with the major difference being AudioDSP cores management - firmware handlers that on its own so there is no need to interfere. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: ICL-based platforms supportCezary Rojewski2024-02-206-1/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define handlers specific to cAVS 2.0 platforms, that is ICL, JSL and all other variants based on this very version of AudioDSP architecture. Most operations are inherited from their predecessors with the major difference being firmware-logging functionality - IPC request as well as debug memory windows layout have changed. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: CNL-based platforms supportCezary Rojewski2024-02-206-8/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define handlers specific to cAVS 1.8 platforms, that is CNL, CFL, CML and all other variants based on this very version of AudioDSP architecture. Most operations are inherited from their predecessors. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: Abstract IRQ handlingCezary Rojewski2024-02-205-37/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Servicing IPCs on CNL platforms and onward differs from the existing one. To make room for these, relocate SKL-based platforms specific code into the skl.c file leaving only the genering irq_handler in the common code. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: Abstract IPC handlingCezary Rojewski2024-02-205-41/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Servicing IPCs on CNL platforms and onward differs from the existing one. To make room for these, enrich platform descriptor with fields representing crucial IPC registers and utilize them throughout the code. While cleaning up device descriptors, reduce the number of code lines by assigning 'min_fw_version' within a single line. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: Prefix SKL/APL-specific membersCezary Rojewski2024-02-205-57/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prefix members that are platform-specific with 'avs_' to improve code cohesiveness and reduce the chance for naming-conflics with other drivers. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: Fix sound clipping in single capture scenarioCezary Rojewski2024-02-201-2/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid sound clipping when there just one, single CAPTURE stream ongoing, disable L1SEN before it is started. Any PLAYBACK stream or additional CAPTURE allows L1SEN to be re-enabled. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Intel: avs: L1SEN reference countedCezary Rojewski2024-02-202-3/+9
| |/ | | | | | | | | | | | | | | | | | | | | Code loading is not the only procedure that manipulates L1SEN. Update existing mechanism so the stream starting procedure can interfere with L1SEN without causing any trouble to its other users. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://msgid.link/r/20240220115035.770402-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * ALSA: usb-audio: More relaxed check of MIDI jack namesTakashi Iwai2024-02-151-48/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB audio driver tries to retrieve MIDI jack name strings that can be used for rawmidi substream names and sequencer port names, but its checking is too strict: often the firmware provides the jack info for unexpected directions, and then we miss the info although it's present. In this patch, the code to extract the jack info is changed to allow both in and out directions in a single loop. That is, the former two functions to obtain the descriptor pointers for jack in and out are changed to a single function that returns iJack of the corresponding jack ID, no matter which direction is used. It's a code simplification at the same time as well as the fix. Fixes: eb596e0fd13c ("ALSA: usb-audio: generate midi streaming substream names from jack names") Link: https://lore.kernel.org/r/20240215153144.26047-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: hda/realtek: fix mute/micmute LED For HP mt645Eniac Zhang2024-02-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HP mt645 G7 Thin Client uses an ALC236 codec and needs the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and micmute LEDs work. There are two variants of the USB-C PD chip on this device. Each uses a different BIOS and board ID, hence the two entries. Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com> Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240215154922.778394-1-alexandru.gagniuc@hp.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * Merge tag 'asoc-fix-v6.8-rc4' of ↵Takashi Iwai2024-02-1527-163/+377
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.8 A relatively large set of fixes and quirk additions here but they're all driver specific, people seem to be back into the swing of things after the holidays. This is all driver specific and much of it fairly minor.
| | * ASoC: cs35l56: Workaround for ACPI with broken spk-id-gpios propertyRichard Fitzgerald2024-02-131-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI in some SoundWire laptops has a spk-id-gpios property but it points to the wrong Device node. This patch adds a workaround to try to get the GPIO directly from the correct Device node. If the attempt to get the GPIOs from the property fails, the workaround looks for the SDCA node "AF01", which is where the GpioIo resource is defined. If this exists, a spk-id-gpios mapping is added to that node and then the GPIO is got from that node using the property. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240209111840.1543630-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: SOF: Intel: pci-tgl/lnl: Change default pathsMark Brown2024-02-132-33/+33
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: Hi, Align the IPC4 firmware path/name and the topology path to the documentation: default_fw_path: intel/sof-ipc4/{platform_name} default_lib_path: intel/sof-ipc4-lib/{platform_name} default_tplg_path: intel/sof-ipc4-tplg default_fw_filename: sof-{platform_name}.ri Tiger Lake and Lunar Lake support is not yet available via the official firmware release, the paths can be changed now to avoid misalignment in the future. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: Intel: pci-tgl: Change the default paths and firmware names ASoC: SOF: Intel: pci-lnl: Change the topology path to intel/sof-ipc4-tplg sound/soc/sof/intel/pci-lnl.c | 2 +- sound/soc/sof/intel/pci-tgl.c | 64 +++++++++++++++++------------------ 2 files changed, 33 insertions(+), 33 deletions(-) -- 2.43.0
| | | * ASoC: SOF: Intel: pci-lnl: Change the topology path to intel/sof-ipc4-tplgPeter Ujfalusi2024-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware release which going to introduce support for Lunar Lake will use the documented default topology directory for IPC4: intel/sof-ipc4-tplg Change the default path accordingly before sof-bin (sof-firmware) release includes Lunar Lake firmware and topologies. Link: https://github.com/thesofproject/sof-docs/blob/master/getting_started/intel_debug/introduction.rst#2-topology-file Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Mengdong Lin <mengdong.lin@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://msgid.link/r/20240213080418.21256-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * ASoC: SOF: Intel: pci-tgl: Change the default paths and firmware namesPeter Ujfalusi2024-02-131-32/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The currently used paths and firmware name reflects the reference firmware convention: default_fw_path: intel/avs/{platform_name} default_lib_path: intel/avs-lib/{platform_name} default_tplg_path: intel/avs-tplg default_fw_filename: dsp_basefw.bin The SOF supports building the firmware for cAVS2.5 platforms using IPC4 and it is the preferred IPC4 implementation to be used on these devices. Change the paths and firmware names to reflect this: default_fw_path: intel/sof-ipc4/{platform_name} default_lib_path: intel/sof-ipc4-lib/{platform_name} default_tplg_path: intel/sof-ipc4-tplg default_fw_filename: sof-{platform_name}.ri 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: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240213080418.21256-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | ASoC: SOF: IPC3: fix message bounds on ipc opsCurtis Malainey2024-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops") introduced a new allocation before the upper bounds check in do_rx_work. As a result A DSP can cause bad allocations if spewing garbage. Fixes: 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops") Reported-by: Tim Van Patten <timvp@google.com> Cc: stable@vger.kernel.org Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213123834.4827-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspendPeter Ujfalusi2024-02-131-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot. Link: https://github.com/thesofproject/sof/issues/8721 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://msgid.link/r/20240213115233.15716-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | ASoC: q6dsp: fix event handler prototypeArnd Bergmann2024-02-131-4/+4
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang-16 points out a mismatch in function types that was hidden by a typecast: sound/soc/qcom/qdsp6/q6apm-dai.c:355:38: error: cast from 'void (*)(uint32_t, uint32_t, uint32_t *, void *)' (aka 'void (*)(unsigned int, unsigned int, unsigned int *, void *)') to 'q6apm_cb' (aka 'void (*)(unsigned int, unsigned int, void *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 355 | prtd->graph = q6apm_graph_open(dev, (q6apm_cb)event_handler, prtd, graph_id); sound/soc/qcom/qdsp6/q6apm-dai.c:499:38: error: cast from 'void (*)(uint32_t, uint32_t, uint32_t *, void *)' (aka 'void (*)(unsigned int, unsigned int, unsigned int *, void *)') to 'q6apm_cb' (aka 'void (*)(unsigned int, unsigned int, void *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 499 | prtd->graph = q6apm_graph_open(dev, (q6apm_cb)event_handler_compr, prtd, graph_id); The only difference here is the 'payload' argument, which is not even used in this function, so just fix its type and remove the cast. Fixes: 88b60bf047fd ("ASoC: q6dsp: q6apm-dai: Add open/free compress DAI callbacks") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://msgid.link/r/20240213101105.459402-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: amd: yc: Fix non-functional mic on Lenovo 82UUAttila Tőkés2024-02-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Like many other models, the Lenovo 82UU (Yoga Slim 7 Pro 14ARH7) needs a quirk entry for the internal microphone to function. Signed-off-by: Attila Tőkés <attitokes@gmail.com> Link: https://msgid.link/r/20240210193638.144028-1-attitokes@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: rt5645: Add DMI quirk for inverted jack-detect on MeeGoPad T8Hans de Goede2024-02-121-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MeeGoPad T8 uses the standard rt5645 jd_mode=3 setting for jack-detect, but the used jack connector outputs an inverted jack-detect signal. Add a DMI quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://msgid.link/r/20240211212736.179605-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: rt5645: Make LattePanda board DMI match more preciseHans de Goede2024-02-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DMI strings used for the LattePanda board DMI quirks are very generic. Using the dmidecode database from https://linux-hardware.org/ shows that the chosen DMI strings also match the following 2 laptops which also have a rt5645 codec: Insignia NS-P11W7100 https://linux-hardware.org/?computer=E092FFF8BA04 Insignia NS-P10W8100 https://linux-hardware.org/?computer=AFB6C0BF7934 All 4 hw revisions of the LattePanda board have "S70CR" in their BIOS version DMI strings: DF-BI-7-S70CR100-* DF-BI-7-S70CR110-* DF-BI-7-S70CR200-* LP-BS-7-S70CR700-* See e.g. https://linux-hardware.org/?computer=D98250A817C0 Add a partial (non exact) DMI match on this string to make the LattePanda board DMI match more precise to avoid false-positive matches. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://msgid.link/r/20240211212736.179605-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHTMark Brown2024-02-128-11/+17
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge series from Hans de Goede <hdegoede@redhat.com>: While testing 6.8 on a Bay Trail device with a ALC5640 codec I noticed a regression in 6.8 which causes a NULL pointer deref in probe(). All BYT/CHT Intel machine drivers are affected. Patch 1/2 of this series fixes all of them. Patch 2/2 adds some small cleanups to cht_bsw_rt5645.c for issues which I noticed while working on 1/2.
| | | * ASoC: Intel: cht_bsw_rt5645: Cleanup codec_name handlingHans de Goede2024-02-111-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4 fixes / cleanups to the rt5645 mc driver's codec_name handling: 1. In the for loop looking for the dai_index for the codec, replace card->dai_link[i] with cht_dailink[i]. The for loop already uses ARRAY_SIZE(cht_dailink) as bound and card->dai_link is just a pointer to cht_dailink using card->dai_link only obfuscates that cht_dailink is being modified directly rather then say a copy of cht_dailink. Using cht_dailink[i] also makes the code consistent with other machine drivers. 2. Don't set cht_dailink[dai_index].codecs->name in the for loop, this immediately gets overridden using acpi_dev_name(adev) directly below the loop. 3. Add a missing break to the loop. 4. Remove the now no longer used (only set, never read) codec_name field from struct cht_mc_private. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240210134400.24913-3-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | | * ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boardsHans de Goede2024-02-118-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") dummy snd_soc_dai_link.codecs entries no longer have a name set. This means that when looking for the codec dai_link the machine driver can no longer unconditionally run strcmp() on snd_soc_dai_link.codecs[0].name since this may now be NULL. Add a check for snd_soc_dai_link.codecs[0].name being NULL to all BYT/CHT machine drivers to avoid NULL pointer dereferences in their probe() methods. Fixes: 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240210134400.24913-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | ASoC: SOF: amd: Fix locking in ACP IRQ handlerCristian Ciocaltea2024-02-112-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent change in acp_irq_thread() was meant to address a potential race condition while trying to acquire the hardware semaphore responsible for the synchronization between firmware and host IPC interrupts. This resulted in an improper use of the IPC spinlock, causing normal kernel memory allocations (which may sleep) inside atomic contexts: 1707255557.133976 kernel: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:315 ... 1707255557.134757 kernel: sof_ipc3_rx_msg+0x70/0x130 [snd_sof] 1707255557.134793 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp] 1707255557.134855 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp] 1707255557.134904 kernel: ? irq_thread+0xb5/0x1e0 1707255557.134947 kernel: ? __pfx_irq_thread_fn+0x10/0x10 1707255557.134985 kernel: irq_thread_fn+0x23/0x60 Moreover, there are attempts to lock a mutex from the same atomic context: 1707255557.136357 kernel: ============================= 1707255557.136393 kernel: [ BUG: Invalid wait context ] 1707255557.136413 kernel: 6.8.0-rc3-next-20240206-audio-next #9 Tainted: G W 1707255557.136432 kernel: ----------------------------- 1707255557.136451 kernel: irq/66-AudioDSP/502 is trying to lock: 1707255557.136470 kernel: ffff965152f26af8 (&sb->s_type->i_mutex_key#2){+.+.}-{3:3}, at: start_creating.part.0+0x5f/0x180 ... 1707255557.137429 kernel: start_creating.part.0+0x5f/0x180 1707255557.137457 kernel: __debugfs_create_file+0x61/0x210 1707255557.137475 kernel: snd_sof_debugfs_io_item+0x75/0xc0 [snd_sof] 1707255557.137494 kernel: sof_ipc3_do_rx_work+0x7cf/0x9f0 [snd_sof] 1707255557.137513 kernel: sof_ipc3_rx_msg+0xb3/0x130 [snd_sof] 1707255557.137532 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp] 1707255557.137551 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp] Fix the issues by reducing the lock scope in acp_irq_thread(), so that it guards only the hardware semaphore acquiring attempt. Additionally, restore the initial locking in acp_sof_ipc_irq_thread() to synchronize the handling of immediate replies from DSP core. Fixes: 802134c8c2c8 ("ASoC: SOF: amd: Refactor spinlock_irq(&sdev->ipc_lock) sequence in irq_handler") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240208234315.2182048-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()Alexey Khoroshilov2024-02-111-0/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: cdba4301adda ("ASoC: rt5650: add mutex to avoid the jack detection failure") Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Link: https://lore.kernel.org/r/1707645514-21196-1-git-send-email-khoroshilov@ispras.ru Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: cs35l56: Remove default from IRQ1_CFG registerRichard Fitzgerald2024-02-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver never uses the IRQ1_CFG register so there's no need to provide a default value. It's set as a readable register only for debugging through the regmap registers file. A system-specific firmware could overwrite this register with a non-default value. Therefore the driver can't hardcode what the initial value actually is. As the register is only for debugging the value can be left unknown until someone wants to read it through debugfs. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240209145700.1555950-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: SOF: ipc3-topology: Fix pipeline tear down logicRanjani Sridharan2024-02-081-14/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the change in the widget free logic to power down the cores only when the scheduler widgets are freed, we need to ensure that the scheduler widget is freed only after all the widgets associated with the scheduler are freed. This is to ensure that the secondary core that the scheduler is scheduled to run on is kept powered on until all widgets that need them are in use. While this works well for dynamic pipelines, in the case of static pipelines the current logic does not take this into account and frees all widgets in the order they occur in the widget_list. So, modify this to ensure that the scheduler widgets are freed only after all other types of widgets in the widget_list are freed. Link: https://github.com/thesofproject/linux/issues/4807 Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores") Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20240208133432.1688-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: cs35l56: Fix deadlock in ASP1 mixer register initializationRichard Fitzgerald2024-02-082-82/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the handling of ASP1 TX mixer mux initialization to prevent a deadlock during component_remove(). The firmware can overwrite the ASP1 TX mixer registers with system-specific settings. This is mainly for hardware that uses the ASP as a chip-to-chip link controlled by the firmware. Because of this the driver cannot know the starting state of the ASP1 mixer muxes until the firmware has been downloaded and rebooted. The original workaround for this was to queue a work function from the dsp_work() job. This work then read the register values (populating the regmap cache the first time around) and then called snd_soc_dapm_mux_update_power(). The problem with this is that it was ultimately triggered by cs35l56_component_probe() queueing dsp_work, which meant that it would be running in parallel with the rest of the ASoC component and card initialization. To prevent accessing DAPM before it was fully initialized the work function took the card mutex. But this would deadlock if cs35l56_component_remove() was called before the work job had completed, because ASoC calls component_remove() with the card mutex held. This new version removes the work function. Instead the regmap cache and DAPM mux widgets are initialized the first time any of the associated ALSA controls is read or written. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 07f7d6e7a124 ("ASoC: cs35l56: Fix for initializing ASP1 mixer registers") Link: https://lore.kernel.org/r/20240208123742.1278104-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: Intel: avs: Fix dynamic port assignment when TDM is setAmadeusz Sławiński2024-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case TDM is set in topology on SSP0, parser will overwrite vindex value, because it only checks if port is set. Fix this by checking whole field value. Fixes: e6d50e474e45 ("ASoC: Intel: avs: Improve topology parsing of dynamic strings") Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20240207112624.2132821-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: cs42l43: Add system suspend ops to disable IRQCharles Keepax2024-02-071-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | The IRQ should be disabled whilst entering and exiting system suspend to avoid the IRQ handler being called whilst the PM runtime is disabled. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240206113850.719888-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * ASoC: cs42l43: Handle error from devm_pm_runtime_enableCharles Keepax2024-02-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | As devm_pm_runtime_enable can fail due to memory allocations, it is best to handle the error. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240206113850.719888-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>