November 2023 - Alsa-devel - mailman.alsa-project.org

[PATCH v2 1/3] ASoC: qcom: audioreach: Commonize setting channel mappings
by Krzysztof Kozlowski 11 Dec '23

11 Dec '23

Move code assigning channel mapping values to a common helper function. This simplifies three out of four cases, with the last case using incompatible type (uint16_t array instead of uint8_t array). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Changes in v2: 1. New patch --- sound/soc/qcom/qdsp6/audioreach.c | 35 ++++++++++++++----------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/sound/soc/qcom/qdsp6/audioreach.c b/sound/soc/qcom/qdsp6/audioreach.c index 5974c7929dd3..3db5ff367a29 100644 --- a/sound/soc/qcom/qdsp6/audioreach.c +++ b/sound/soc/qcom/qdsp6/audioreach.c @@ -267,6 +267,16 @@ void *audioreach_alloc_apm_cmd_pkt(int pkt_size, uint32_t opcode, uint32_t token } EXPORT_SYMBOL_GPL(audioreach_alloc_apm_cmd_pkt); +static void audioreach_set_channel_mapping(u8 *ch_map, int num_channels) +{ + if (num_channels == 1) { + ch_map[0] = PCM_CHANNEL_L; + } else if (num_channels == 2) { + ch_map[0] = PCM_CHANNEL_L; + ch_map[1] = PCM_CHANNEL_R; + } +} + static void apm_populate_container_config(struct apm_container_obj *cfg, struct audioreach_container *cont) { @@ -864,12 +874,8 @@ static int audioreach_set_compr_media_format(struct media_format *media_fmt_hdr, mp3_cfg->endianness = PCM_LITTLE_ENDIAN; mp3_cfg->num_channels = mcfg->num_channels; - if (mcfg->num_channels == 1) { - mp3_cfg->channel_mapping[0] = PCM_CHANNEL_L; - } else if (mcfg->num_channels == 2) { - mp3_cfg->channel_mapping[0] = PCM_CHANNEL_L; - mp3_cfg->channel_mapping[1] = PCM_CHANNEL_R; - } + audioreach_set_channel_mapping(mp3_cfg->channel_mapping, + mcfg->num_channels); break; case SND_AUDIOCODEC_AAC: media_fmt_hdr->data_format = DATA_FORMAT_RAW_COMPRESSED; @@ -1089,13 +1095,8 @@ static int audioreach_pcm_set_media_format(struct q6apm_graph *graph, media_cfg->q_factor = mcfg->bit_width - 1; media_cfg->bits_per_sample = mcfg->bit_width; - if (num_channels == 1) { - media_cfg->channel_mapping[0] = PCM_CHANNEL_L; - } else if (num_channels == 2) { - media_cfg->channel_mapping[0] = PCM_CHANNEL_L; - media_cfg->channel_mapping[1] = PCM_CHANNEL_R; - - } + audioreach_set_channel_mapping(media_cfg->channel_mapping, + num_channels); rc = q6apm_send_cmd_sync(graph->apm, pkt, 0); @@ -1153,12 +1154,8 @@ static int audioreach_shmem_set_media_format(struct q6apm_graph *graph, cfg->endianness = PCM_LITTLE_ENDIAN; cfg->num_channels = mcfg->num_channels; - if (mcfg->num_channels == 1) - cfg->channel_mapping[0] = PCM_CHANNEL_L; - else if (num_channels == 2) { - cfg->channel_mapping[0] = PCM_CHANNEL_L; - cfg->channel_mapping[1] = PCM_CHANNEL_R; - } + audioreach_set_channel_mapping(cfg->channel_mapping, + num_channels); } else { rc = audioreach_set_compr_media_format(header, p, mcfg); if (rc) { -- 2.34.1

2 3

[PATCH 1/4] ASoC: dt-bindings: qcom,lpass-rx-macro: Add SM8650 LPASS RX
by Krzysztof Kozlowski 11 Dec '23

11 Dec '23

Add bindings for Qualcomm SM8650 Low Power Audio SubSystem (LPASS) RX macro codec, which looks like compatible with earlier SM8550. Cc: Neil Armstrong <neil.armstrong(a)linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- .../bindings/sound/qcom,lpass-rx-macro.yaml | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index ec4b0ac8ad68..cbc36646100f 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -11,12 +11,16 @@ maintainers: properties: compatible: - enum: - - qcom,sc7280-lpass-rx-macro - - qcom,sm8250-lpass-rx-macro - - qcom,sm8450-lpass-rx-macro - - qcom,sm8550-lpass-rx-macro - - qcom,sc8280xp-lpass-rx-macro + oneOf: + - enum: + - qcom,sc7280-lpass-rx-macro + - qcom,sm8250-lpass-rx-macro + - qcom,sm8450-lpass-rx-macro + - qcom,sm8550-lpass-rx-macro + - qcom,sc8280xp-lpass-rx-macro + - items: + - const: qcom,sm8650-lpass-rx-macro + - const: qcom,sm8550-lpass-rx-macro reg: maxItems: 1 @@ -96,8 +100,9 @@ allOf: - if: properties: compatible: - enum: - - qcom,sm8550-lpass-rx-macro + contains: + enum: + - qcom,sm8550-lpass-rx-macro then: properties: clocks: -- 2.34.1

3 7

Bass speaker fixup for Lenovo Yoga Pro 7 14APH8
by Yevhen Hrubiian 07 Dec '23

07 Dec '23

Hello ! I've seen a few patches fixing bass speaker problem for new Lenovo (written by Philipp Jungkamp and later by Pascal Gross), for example this line in linux/sound/pci/hda/patch_realtek.c: SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN) Could you please add this line for a similar model with the same Problem? SND_PCI_QUIRK(0x17aa, 0x3882, "Lenovo Yoga Pro 7 14APH8", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), I do not have experience in writing kernel patches so I hope I will not irritate you with this letter. Thanks! Yevhen Hrubiian

2 1

BUG hda/cs8904: Headphones not detected and no speaker sound after system suspend
by Andrés Pedraza 05 Dec '23

05 Dec '23

Hello my dudes. I've been having this bug for a few months now. Sound on my laptop works just fine until the system suspends or I close the lid. If my headphones are connected when I suspend the system, then there's no sound on headphones or speakers on wake and PulseAudio claims there's never any headphones connected. If my headphones aren't connected on suspend, then speakers work just fine, but headphones are still never detected and make no sound. Additionally, I recently found out that after waking from suspend, if I run `sudo dmesg | grep snd` I find two timeout warnings that weren't there before, and more showing up as I keep running the command. They go: > snd_hda_codec_cs8409 hdaudioC1D0: Timeout waiting for PDN_DONE for > CS42L42 I'm on a Dell Vostro 3405 laptop, which I know has a Cirrus sound card. I recently compiled and tested this bug on the Linux 6.6.2 stable kernel. No dice. I attach the outputs of `pactl list sinks`, `sudo dmesg | grep snd` and `sudo lspci -v | grep snd -B 10`. Please do tell if the issue might be caused by some other module or BIOS configuration, or if you need more data.

3 2

[PATCH 00/17] dt-bindings: samsung: add specific compatibles for existing SoC
by Krzysztof Kozlowski 05 Dec '23

05 Dec '23

Hi, Merging ======= I propose to take entire patchset through my tree (Samsung SoC), because: 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so they will touch the same lines in some of the DT bindings (not all, though). It is reasonable for me to take the bindings for the new SoCs, to have clean `make dtbs_check` on the new DTS. 2. Having it together helps me to have clean `make dtbs_check` within my tree on the existing DTS. 3. No drivers are affected by this change. 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect follow up patchsets. If folks agree, please kindly Ack the patches. Description =========== Samsung Exynos SoCs reuse several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Future ====== If reasonable, I will do similar work for Tesla FSD and ARMv7/ARM32 Exynos bindings and DTS. Best regards, Krzysztof Krzysztof Kozlowski (17): dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for existing SoC dt-bindings: i2c: exynos5: add specific compatibles for existing SoC dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for existing SoC dt-bindings: pinctrl: samsung: add specific compatibles for existing SoC dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC dt-bindings: serial: samsung: add specific compatibles for existing SoC dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoC dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing Exynos SoC dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC dt-bindings: pwm: samsung: add specific compatibles for existing SoC arm64: dts: exynos5433: add specific compatibles to several blocks arm64: dts: exynos7: add specific compatibles to several blocks arm64: dts: exynos7885: add specific compatibles to several blocks arm64: dts: exynos850: add specific compatibles to several blocks arm64: dts: exynosautov9: add specific compatibles to several blocks .../bindings/gpu/arm,mali-midgard.yaml | 5 ++ .../hwinfo/samsung,exynos-chipid.yaml | 17 +++++- .../devicetree/bindings/i2c/i2c-exynos5.yaml | 10 +++- .../bindings/i2c/samsung,s3c2410-i2c.yaml | 22 ++++--- .../bindings/iio/adc/samsung,exynos-adc.yaml | 29 +++++---- .../mfd/samsung,exynos5433-lpass.yaml | 2 +- .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 25 +++++--- .../samsung,pinctrl-wakeup-interrupt.yaml | 24 +++++--- .../bindings/pinctrl/samsung,pinctrl.yaml | 3 +- .../devicetree/bindings/pwm/pwm-samsung.yaml | 2 + .../devicetree/bindings/rtc/s3c-rtc.yaml | 5 ++ .../bindings/serial/samsung_uart.yaml | 14 ++++- .../bindings/soc/samsung/exynos-pmu.yaml | 6 ++ .../bindings/soc/samsung/exynos-usi.yaml | 2 +- .../bindings/sound/samsung-i2s.yaml | 19 +++--- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 60 ++++++++++++------- arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 +++--- arch/arm64/boot/dts/exynos/exynos7885.dtsi | 45 +++++++++----- arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 ++++++----- arch/arm64/boot/dts/exynos/exynosautov9.dtsi | 6 +- 20 files changed, 233 insertions(+), 115 deletions(-) -- 2.34.1

13 65

Regression apparently caused by commit 088a40980efbc2c449b72f0f2c7ebd82f71d08e2 "ASoC: amd: acp: add pm ops support for acp pci driver"
by Marian Postevca 05 Dec '23

05 Dec '23

I'm trying to develop a sound machine driver based on the acp legacy driver. The first version of the driver was sent for review on the alsa mailing list this spring: https://lore.kernel.org/all/20230320203519.20137-1-posteuca@mutex.one I'm trying to fix some of the issues that were brought up during the review back then, but when I ported the patches to the latest commit on the for-next branch, I noticed a regression where I couldn't hear any sound at all. So I started a bisect session and found that the first bad commit is: ASoC: amd: acp: add pm ops support for acp pci driver commit 088a40980efbc2c449b72f0f2c7ebd82f71d08e2 https://lore.kernel.org/lkml/20230622152406.3709231-11-Syed.SabaKareem@amd.… If I revert this commit sound works as expected. So I started tinkering a little bit with it and I believe that what happens is that the acp pci driver enters the autosuspend state and never leaves this state at all. I noticed this because if I increase the autosuspend delay to a much larger value, then the sound works until that delay passes. I added traces and I can see that when the delay expires the suspend callback snd_acp_suspend() gets called, but the resume callback snd_acp_resume() never gets called. I'm no expert in runtime power management (though I did read a bit on it), so I don't understand all the things that happen underneath, but one thing that is not clear to me is who's supposed to mark activity on this device and keep it from entering autosuspend if the user wants to play some sound? Shouldn't there be some counterpart that calls pm_runtime_mark_last_busy() ? I looked through the code and can't find who's calling pm_runtime_mark_last_busy(). Some help here would be welcome. Is there something missing in my machine driver code, or is the runtime pm handling in acp pci driver wrong?

5 12

[PATCH] soundwire: amd: drop bus freq calculation and set 'max_clk_freq'
by Vinod Koul 02 Dec '23

02 Dec '23

max_dr_freq and curr_dr_freq is calculated and set in sdw_bus_master_add(). Setting in the driver is reduanant, so drop that. Set max_clk_freq instead. Signed-off-by: Vinod Koul <vkoul(a)kernel.org> --- drivers/soundwire/amd_manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c index a3b1f4e6f0f9..f54bb4dd2d10 100644 --- a/drivers/soundwire/amd_manager.c +++ b/drivers/soundwire/amd_manager.c @@ -950,13 +950,13 @@ static int amd_sdw_manager_probe(struct platform_device *pdev) amd_manager->reg_mask = &sdw_manager_reg_mask_array[amd_manager->instance]; params = &amd_manager->bus.params; - params->max_dr_freq = AMD_SDW_DEFAULT_CLK_FREQ * 2; - params->curr_dr_freq = AMD_SDW_DEFAULT_CLK_FREQ * 2; + params->col = AMD_SDW_DEFAULT_COLUMNS; params->row = AMD_SDW_DEFAULT_ROWS; prop = &amd_manager->bus.prop; prop->clk_freq = &amd_sdw_freq_tbl[0]; prop->mclk_freq = AMD_SDW_BUS_BASE_FREQ; + prop->max_clk_freq = AMD_SDW_DEFAULT_CLK_FREQ; ret = sdw_bus_master_add(&amd_manager->bus, dev, dev->fwnode); if (ret) { -- 2.41.0

2 3

[PATCH 0/7] ASoC: Intel: Soundwire related board and match updates
by Peter Ujfalusi 01 Dec '23

01 Dec '23

Hi, A small update for SDW machine support: Small fixes for sof_sdw machine driver Support for rt722 New TGL/MTL and LNL match for new configurations Regards, Peter --- Bard Liao (1): ASoC: Intel: soc-acpi-intel-tgl-match: add cs42l43 and cs56l56 support Chao Song (4): ASoC: Intel: sof_sdw: remove unused function declaration ASoC: Intel: sof_sdw: Add rt722 support ASoC: Intel: soc-acpi: add Gen4.1 SDCA board support for LNL RVP ASoC: Intel: soc-acpi-intel-mtl-match: Add rt722 support Mac Chiang (1): ASoC: Intel: soc-acpi: rt713+rt1316, no sdw-dmic config Peter Ujfalusi (1): ASoC: Intel: sof_sdw: Make use of dev_err_probe() sound/soc/intel/boards/Kconfig | 1 + sound/soc/intel/boards/Makefile | 3 +- sound/soc/intel/boards/sof_sdw.c | 32 +++++- sound/soc/intel/boards/sof_sdw_common.h | 18 ++-- sound/soc/intel/boards/sof_sdw_rt722_sdca.c | 97 +++++++++++++++++++ .../boards/sof_sdw_rt_sdca_jack_common.c | 8 ++ .../intel/common/soc-acpi-intel-lnl-match.c | 71 ++++++++++++++ .../intel/common/soc-acpi-intel-mtl-match.c | 74 ++++++++++++++ .../intel/common/soc-acpi-intel-tgl-match.c | 78 +++++++++++++++ 9 files changed, 374 insertions(+), 8 deletions(-) create mode 100644 sound/soc/intel/boards/sof_sdw_rt722_sdca.c -- 2.43.0

4 17

[PATCH 00/17] Prepare the PowerQUICC QMC and TSA for the HDLC QMC driver
by Herve Codina 01 Dec '23

01 Dec '23

Hi, This series updates PowerQUICC QMC and TSA drivers to prepare the support for the QMC HDLC driver. Patches were previously sent as part of a full feature series: "Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1] The full feature series reached the v9 iteration. The v1 was sent the 07/25/2023 followed by the other iterations (07/26/2023, 08/09/2023, 08/18/2023, 09/12/2023, 09/22/2023, 09/28/2023, 10/11/23, 11/15/2023) and was ready to be merged in its v8. https://lore.kernel.org/linux-kernel/20231025123215.5caca7d4@kernel.org/ The lack of feedback from the Freescale SoC and the Quicc Engine maintainers (i.e. drivers/soc/fsl/qe/ to which the QMC and TSA drivers belong) blocks the entire full feature series. These patches are fixes and improvements to TSA and QMC drivers. These drivers were previously acked by Li Yang but without any feedback from Li Yang nor Qiang Zhao the series cannot move forward. In order to ease the review/merge, the full feature series has been split and this series contains patches related to the PowerQUICC SoC part (QMC and TSA). - Perform some fixes (patches 1 to 5) - Add support for child devices (patch 6) - Add QMC dynamic timeslot support (patches 7 to 17) From the original full feature series, a patches extraction without any modification was done. Best regards, Hervé [1]: https://lore.kernel.org/linux-kernel/20231115144007.478111-1-herve.codina@b… Patches extracted: - Patch 1..6 : full feature series patch 1..6 - Patch 7..17 : full feature series patch 9..19 Herve Codina (17): soc: fsl: cpm1: tsa: Fix __iomem addresses declaration soc: fsl: cpm1: qmc: Fix __iomem addresses declaration soc: fsl: cpm1: qmc: Fix rx channel reset soc: fsl: cpm1: qmc: Extend the API to provide Rx status soc: fsl: cpm1: qmc: Remove inline function specifiers soc: fsl: cpm1: qmc: Add support for child devices soc: fsl: cpm1: qmc: Introduce available timeslots masks soc: fsl: cpm1: qmc: Rename qmc_setup_tsa* to qmc_init_tsa* soc: fsl: cpm1: qmc: Introduce qmc_chan_setup_tsa* soc: fsl: cpm1: qmc: Remove no more needed checks from qmc_check_chans() soc: fsl: cpm1: qmc: Check available timeslots in qmc_check_chans() soc: fsl: cpm1: qmc: Add support for disabling channel TSA entries soc: fsl: cpm1: qmc: Split Tx and Rx TSA entries setup soc: fsl: cpm1: qmc: Introduce is_tsa_64rxtx flag soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and stop() soc: fsl: cpm1: qmc: Remove timeslots handling from setup_chan() soc: fsl: cpm1: qmc: Introduce functions to change timeslots at runtime drivers/soc/fsl/qe/qmc.c | 592 +++++++++++++++++++++++++++------- drivers/soc/fsl/qe/tsa.c | 22 +- include/soc/fsl/qe/qmc.h | 27 +- sound/soc/fsl/fsl_qmc_audio.c | 2 +- 4 files changed, 506 insertions(+), 137 deletions(-) -- 2.42.0

2 20

[PATCH 00/13] ASoC: SOF: IPC path handling and fallback support
by Peter Ujfalusi 30 Nov '23

30 Nov '23

Hi, The main aim of the series is to provide a mechanism to fallback to 'older' IPC versions in case the desired one is missing either a firmware or topology file. It is going to make the life of users and distributions if we are going to start transition existing IPC3 platforms to IPC4 (CAVS2.5) and we might have missed some topology file to convert for example. In that case the kernel will fallback to IPC3 without audio regression. To be able to support this we needed to change the probe sequence to know the topology filename earlier and check if it is present in the filesystem. No functional changes for now, the default IPC versions have not been changed. Regards, Peter --- Peter Ujfalusi (13): ASoC: SOF: Move sof_of_machine_select() to sof-of-dev.c from sof-audio.c ASoC: SOF: Move sof_machine_* functions from sof-audio.c to core.c ASoC: SOF: Add placeholder for platform IPC type and path overrides ASoC: SOF: sof-acpi-dev: Save the default IPC type and path overrides ASoC: SOF: sof-of-dev: Save the default IPC type and path overrides ASoC: SOF: sof-pci-dev: Save the default IPC type and path overrides ASoC: SOF: core: Implement firmware, topology path setup in core ASoC: SOF: sof-acpi-dev: Rely on core to create the file paths ASoC: SOF: sof-of-dev: Rely on core to create the file paths ASoC: SOF: sof-pci-dev: Rely on core to create the file paths ASoC: SOF: core: Add helper for initialization of paths, ops ASoC: SOF: Intel: Do not use resource managed allocation for ipc4_data ASoC: SOF: core: Implement IPC version fallback if firmware files are missing include/sound/sof.h | 15 ++ sound/soc/sof/Kconfig | 11 ++ sound/soc/sof/Makefile | 3 +- sound/soc/sof/core.c | 289 +++++++++++++++++++++++----- sound/soc/sof/fw-file-profile.c | 322 ++++++++++++++++++++++++++++++++ sound/soc/sof/intel/apl.c | 2 +- sound/soc/sof/intel/cnl.c | 2 +- sound/soc/sof/intel/hda-dai.c | 3 + sound/soc/sof/intel/icl.c | 2 +- sound/soc/sof/intel/lnl.c | 2 +- sound/soc/sof/intel/mtl.c | 2 +- sound/soc/sof/intel/skl.c | 2 +- sound/soc/sof/intel/tgl.c | 2 +- sound/soc/sof/sof-acpi-dev.c | 16 +- sound/soc/sof/sof-audio.c | 120 ------------ sound/soc/sof/sof-of-dev.c | 36 +++- sound/soc/sof/sof-of-dev.h | 9 + sound/soc/sof/sof-pci-dev.c | 102 ++-------- sound/soc/sof/sof-priv.h | 9 +- 19 files changed, 671 insertions(+), 278 deletions(-) create mode 100644 sound/soc/sof/fw-file-profile.c -- 2.43.0

2 14