August 2021 - Alsa-devel - mailman.alsa-project.org

[PATCH 0/4] Rockchip I2S/TDM controller
by Nicolas Frattaroli 19 Aug '21

19 Aug '21

Hello, I come bearing four patches for your consideration. The first of these four patches adds a driver for the Rockchip I2S/TDM controller, used in interfacing between the AHB bus and the I2S bus on some Rockchip SoCs. This allows for audio playback with a matching codec. The controller has three different modes: I2S, I2S/TDM and PCM. It is distinct from the earlier Rockchip I2S controller, and therefore not just an extension of that driver. The driver is based on the downstream version, though various changes have been made to hopefully make it more palatable to upstream. Some needless code duplication has been refactored, and the probe function will no longer let wrong device tree values write nonsense to hardware registers. Properties have been renamed and had their semantics changed. I won't bore you with the details of what downstream did, since that's not what I'm submitting, but the changes are significant enough that I've added myself to the list of authors. The second patch adds the YAML device tree bindings for this, which have been written from scratch by yours truly. Since I didn't like having random integers mean things, I defined them as constants in a header file for the bindings. The third patch adds the i2s1 controller to the rk356x device tree. I didn't add any of the other i2s controllers on that SoC for now as I have no way of testing them; in particular, i2s0 is tied to HDMI, so needs a functioning VOP2 driver to even have a chance of working. The fourth patch makes use of the i2s1 controller to enable analog audio output on the Quartz64 Model A through its RK817 codec. I've tested this to work properly at both 44.1 kHz and 96 kHz, so both mclk_root0 and mclk_root1 are definitely functioning. This is my first kernel contribution, so I most likely did something horribly wrong. That's why I'm more than happy to receive any criticisms and concerns over how the driver is implemented, because I've run out of ideas on how to make it clearly better myself. I'd also like to extend my thanks to Peter Geis, who has been acting as somewhat of a mentor and gave me occasional feedback and ideas during the writing of this patch series. Regards, Nicolas Frattaroli Nicolas Frattaroli (4): ASoC: rockchip: add support for i2s-tdm controller dt-bindings: sound: add rockchip i2s-tdm binding arm64: dts: rockchip: add i2s1 on rk356x arm64: dts: rockchip: add analog audio on Quartz64 .../bindings/sound/rockchip,i2s-tdm.yaml | 221 ++ .../boot/dts/rockchip/rk3566-quartz64-a.dts | 36 +- arch/arm64/boot/dts/rockchip/rk356x.dtsi | 26 + include/dt-bindings/sound/rockchip,i2s-tdm.h | 9 + sound/soc/rockchip/Kconfig | 11 + sound/soc/rockchip/Makefile | 2 + sound/soc/rockchip/rockchip_i2s_tdm.c | 1804 +++++++++++++++++ sound/soc/rockchip/rockchip_i2s_tdm.h | 400 ++++ 8 files changed, 2508 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml create mode 100644 include/dt-bindings/sound/rockchip,i2s-tdm.h create mode 100644 sound/soc/rockchip/rockchip_i2s_tdm.c create mode 100644 sound/soc/rockchip/rockchip_i2s_tdm.h -- 2.32.0

5 9

[PATCH] ASoC: intel: atom: Fix breakage for PCM buffer address setup
by Takashi Iwai 19 Aug '21

19 Aug '21

The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") changed the reference of PCM buffer address to substream->runtime->dma_addr as the buffer address may change dynamically. However, I forgot that the dma_addr field is still not set up for the CONTINUOUS buffer type (that this driver uses) yet in 5.14 and earlier kernels, and it resulted in garbage I/O. The problem will be fixed in 5.15, but we need to address it quickly for now. The fix is to deduce the address again from the DMA pointer with virt_to_phys(), but from the right one, substream->runtime->dma_area. Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") Reported-and-tested-by: Hans de Goede <hdegoede(a)redhat.com> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 5db2f4865bbb..905c7965f653 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -127,7 +127,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream, snd_pcm_uframes_t period_size; ssize_t periodbytes; ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream); - u32 buffer_addr = substream->runtime->dma_addr; + u32 buffer_addr = virt_to_phys(substream->runtime->dma_area); channels = substream->runtime->channels; period_size = substream->runtime->period_size; -- 2.26.2

2 3

[PATCH] ALSA: hda/realtek: Limit mic boost on HP ProBook 445 G8
by Kai-Heng Feng 19 Aug '21

19 Aug '21

The mic has lots of noises if mic boost is enabled. So disable mic boost to get crystal clear audio capture. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8b72064f83211..cdd87917dd8cf 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6645,6 +6645,7 @@ enum { ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP, ALC623_FIXUP_LENOVO_THINKSTATION_P340, ALC255_FIXUP_ACER_HEADPHONE_AND_MIC, + ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST, }; static const struct hda_fixup alc269_fixups[] = { @@ -8229,6 +8230,12 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC255_FIXUP_XIAOMI_HEADSET_MIC }, + [ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_limit_int_mic_boost, + .chained = true, + .chain_id = ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -8425,8 +8432,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8847, "HP EliteBook x360 830 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x884b, "HP EliteBook 840 Aero G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x884c, "HP EliteBook 840 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), - SND_PCI_QUIRK(0x103c, 0x8862, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), - SND_PCI_QUIRK(0x103c, 0x8863, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8862, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x103c, 0x8863, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x103c, 0x886d, "HP ZBook Fury 17.3 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), SND_PCI_QUIRK(0x103c, 0x8870, "HP ZBook Fury 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), SND_PCI_QUIRK(0x103c, 0x8873, "HP ZBook Studio 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), -- 2.32.0

2 1

[5.14 regression] "ASoC: intel: atom: Fix reference to PCM buffer address" breaks Intel SST audio
by Hans de Goede 19 Aug '21

19 Aug '21

Hi All, After rebasing a set of bytcr_rt5640 patches, on top of asoc/for-next I noticed that playing back audio would only generate random-noise / buzzing (I did not try recording any audio). After poking at this for a while I've found the culprit: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") If I revert that single commit then audio on Intel Bay Trail and Cherry Trail devices works fine again with 5.14. This is with a Fedora 34 userspace using pipewire as audiodaemon I'm not sure what is going on here, but since the old code changed by the broken commit has worked fine for ages and given where we are in the devel-cycle I think it might be best to just revert 2e6b836312a4 again. Regards, Hans

2 4

huge mixers
by Philippe Bekaert 19 Aug '21

19 Aug '21

Dear all, I am working on a new driver for the RME HDSPe cards, which eventually could replace the hdspm driver. These cards have a hardware mixer / matrox router, freely mixing tens of hardware inputs and software playbacks into tens of outputs (8192 mixer controls on the HDSPe MADI). Right now, mixer state (cached by the driver) can be read efficiently in one ad-hoc ioctl call, and individual channels modified through a HWDEP ALSA control element with 3 parameters (input/playback index, output index, gain value). I understand there is a desire to get rid of ad hoc ioctls and am therefore looking for a more generic way to read and write huge mixer state. Has anyone been facing similar issues? How have you been solving it? Is there any “common practice” or “habits” in this community concerning this topic? Would it make sense to define a kind of generic huge mixer interface? Then, has anyone an idea or preference how it should look like? Looking forward to your feedback. Best regards and thanks in advance, Philippe.

2 1

PCM channel names
by Philippe Bekaert 19 Aug '21

19 Aug '21

Same context as my previous mail … The RME HDSPe cards have a large number of input and outputs for which the standard ALSA channels names and mappings make little sense. Names depend on the card, e.g. Analog.L, Analog.R, AES.1/1 … AES.1/8, ADAT.1 … ADAT.8 etc… Right now, the hdspm driver provides a ad-hoc virtual file in /proc/asound/card<n> containing these names. Isn’t there a more generic interface to communicate PCM channel names from driver to user space Same questions as before: Has anyone been facing similar issues? How have you been solving it? Is there any “common practice” or “habits” in this community concerning this topic? Would it make sense to define a kind of generic interface for PCM naming? Then, has anyone an idea or preference how it should look like? Again looking forward to your feedback. Best regards and thanks in advance, Philippe.

2 1

[RFC PATCH 0/2] driver core: kick deferred probe from delayed context
by Pierre-Louis Bossart 18 Aug '21

18 Aug '21

The deferred probe mechanism uses a successful driver probe/attach as a trigger to revisit the list of deferred probe devices. This works in most cases, except when the probe success is not a valid indicator of resources being available. In that case, a race condition may occur, where the device/driver core framework will attempt to probe a device that depends on resources before those resources are available, resulting in a -EPROBE_DEFER error and a deferred probe device that will never be initialized. The example provided in this RFC relies on the probe workqueue used for the HDaudio support where we simultaneously: a) need to use request_module() b) cannot use an async probe due to the use of request_module() c) cannot block the probe of other drivers In this example, the deferred probe can be kicked when the workqueue completes. The use of request_firmware_nowait() is another conceptual example, where a domain-specific callback can enable resources *after* the probe returns, for example by downloading the firmware, booting a processor and waiting for the processor to be ready for interaction with the Linux host. In this second example, the deferred probe could be kicked when the 'cont' callback completes. This patchset suggests a 7-line change to solve race conditions in these examples with delayed work. Discussion: a) During Intel internal reviews, Andy Shevchenko pointed out another known issue with deferred probe [1]. This patchset is unrelated and does not claim to solve the problem raised by Andy. b) one possible objection is that this patchset does not suppress a possibly unnecessary round of evaluation of deferred probe devices. It did not feel necessary to any of us to minimize the occurrences of EPROBE_DEFER but instead to make sure the device waiting for resources successfully probes in the end. c) another objection might be that the driver core should know about such dependencies. It would be desirable but in the cases we've encountered such dependencies are highly domain-specific and not necessarily straightforward to describe. There's been multiple endeavors to improve the description of dependencies, this patchset only focuses on the deferred probe framework, with an improvement when the provider of resources makes these resources available after its probe returns. [1] https://lore.kernel.org/lkml/20200324175719.62496-1-andriy.shevchenko@linux… Pierre-Louis Bossart (2): driver core: export driver_deferred_probe_trigger() ASoC: SOF: trigger re-probing of deferred devices from workqueue drivers/base/dd.c | 3 ++- include/linux/device/driver.h | 1 + sound/soc/sof/core.c | 3 +++ 3 files changed, 6 insertions(+), 1 deletion(-) base-commit: 8d1998893cd5e3488cd95529f60a187e3009d14b -- 2.25.1

4 16

[PATCH] ASoC: fsl_rpmsg: Check -EPROBE_DEFER for getting clocks
by Shengjiu Wang 18 Aug '21

18 Aug '21

The devm_clk_get() may return -EPROBE_DEFER, then clocks will be assigned to NULL wrongly. As the clocks are optional so we can use devm_clk_get_optional() instead of devm_clk_get(). Fixes: b73d9e6225e8 ("ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg") Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl_rpmsg.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c index ea5c973e2e84..d60f4dac6c1b 100644 --- a/sound/soc/fsl/fsl_rpmsg.c +++ b/sound/soc/fsl/fsl_rpmsg.c @@ -165,25 +165,25 @@ static int fsl_rpmsg_probe(struct platform_device *pdev) } /* Get the optional clocks */ - rpmsg->ipg = devm_clk_get(&pdev->dev, "ipg"); + rpmsg->ipg = devm_clk_get_optional(&pdev->dev, "ipg"); if (IS_ERR(rpmsg->ipg)) - rpmsg->ipg = NULL; + return PTR_ERR(rpmsg->ipg); - rpmsg->mclk = devm_clk_get(&pdev->dev, "mclk"); + rpmsg->mclk = devm_clk_get_optional(&pdev->dev, "mclk"); if (IS_ERR(rpmsg->mclk)) - rpmsg->mclk = NULL; + return PTR_ERR(rpmsg->mclk); - rpmsg->dma = devm_clk_get(&pdev->dev, "dma"); + rpmsg->dma = devm_clk_get_optional(&pdev->dev, "dma"); if (IS_ERR(rpmsg->dma)) - rpmsg->dma = NULL; + return PTR_ERR(rpmsg->dma); - rpmsg->pll8k = devm_clk_get(&pdev->dev, "pll8k"); + rpmsg->pll8k = devm_clk_get_optional(&pdev->dev, "pll8k"); if (IS_ERR(rpmsg->pll8k)) - rpmsg->pll8k = NULL; + return PTR_ERR(rpmsg->pll8k); - rpmsg->pll11k = devm_clk_get(&pdev->dev, "pll11k"); + rpmsg->pll11k = devm_clk_get_optional(&pdev->dev, "pll11k"); if (IS_ERR(rpmsg->pll11k)) - rpmsg->pll11k = NULL; + return PTR_ERR(rpmsg->pll11k); platform_set_drvdata(pdev, rpmsg); pm_runtime_enable(&pdev->dev); -- 2.27.0

2 1

[PATCH v4 00/11] ASoC: mediatek: Add support for MT8195 SoC
by Trevor Wu 18 Aug '21

18 Aug '21

This series of patches adds support for Mediatek AFE of MT8195 SoC. Patches are based on broonie tree "for-next" branch. Changes since v3: - fixed warnings found by kernel test robot - removed unused critical section - corrected the lock protected sections on etdm driver - added DPTX and HDMITX audio support Changes since v2: - added audio clock gate control - added 'mediatek' prefix to private dts properties - added consumed clocks to dt-bindins and adopted suggestions from Rob - refined clock usage and remove unused clock and control code - fixed typos Changes since v1: - fixed some problems related to dt-bindings - added some missing properties to dt-bindings - added depency declaration on dt-bindings - fixed some warnings found by kernel test robot Trevor Wu (11): ASoC: mediatek: mt8195: update mediatek common driver ASoC: mediatek: mt8195: support audsys clock control ASoC: mediatek: mt8195: support etdm in platform driver ASoC: mediatek: mt8195: support adda in platform driver ASoC: mediatek: mt8195: support pcm in platform driver ASoC: mediatek: mt8195: add platform driver dt-bindings: mediatek: mt8195: add audio afe document ASoC: mediatek: mt8195: add machine driver with mt6359, rt1019 and rt5682 ASoC: mediatek: mt8195: add DPTX audio support ASoC: mediatek: mt8195: add HDMITX audio support dt-bindings: mediatek: mt8195: add mt8195-mt6359-rt1019-rt5682 document .../bindings/sound/mt8195-afe-pcm.yaml | 184 + .../sound/mt8195-mt6359-rt1019-rt5682.yaml | 47 + sound/soc/mediatek/Kconfig | 24 + sound/soc/mediatek/Makefile | 1 + sound/soc/mediatek/common/mtk-afe-fe-dai.c | 22 +- sound/soc/mediatek/common/mtk-base-afe.h | 10 +- sound/soc/mediatek/mt8195/Makefile | 15 + sound/soc/mediatek/mt8195/mt8195-afe-clk.c | 441 +++ sound/soc/mediatek/mt8195/mt8195-afe-clk.h | 109 + sound/soc/mediatek/mt8195/mt8195-afe-common.h | 158 + sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 3281 +++++++++++++++++ sound/soc/mediatek/mt8195/mt8195-audsys-clk.c | 214 ++ sound/soc/mediatek/mt8195/mt8195-audsys-clk.h | 15 + .../soc/mediatek/mt8195/mt8195-audsys-clkid.h | 93 + sound/soc/mediatek/mt8195/mt8195-dai-adda.c | 830 +++++ sound/soc/mediatek/mt8195/mt8195-dai-etdm.c | 2639 +++++++++++++ sound/soc/mediatek/mt8195/mt8195-dai-pcm.c | 389 ++ .../mt8195/mt8195-mt6359-rt1019-rt5682.c | 1093 ++++++ sound/soc/mediatek/mt8195/mt8195-reg.h | 2796 ++++++++++++++ 19 files changed, 12356 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml create mode 100644 sound/soc/mediatek/mt8195/Makefile create mode 100644 sound/soc/mediatek/mt8195/mt8195-afe-clk.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-afe-clk.h create mode 100644 sound/soc/mediatek/mt8195/mt8195-afe-common.h create mode 100644 sound/soc/mediatek/mt8195/mt8195-afe-pcm.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-audsys-clk.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-audsys-clk.h create mode 100644 sound/soc/mediatek/mt8195/mt8195-audsys-clkid.h create mode 100644 sound/soc/mediatek/mt8195/mt8195-dai-adda.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-dai-etdm.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-dai-pcm.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c create mode 100644 sound/soc/mediatek/mt8195/mt8195-reg.h -- 2.18.0

1 11

[PATCH -next] ASoC: sh: rz-ssi: Fix return value check in rz_ssi_dma_request()
by Yang Yingliang 18 Aug '21

18 Aug '21

In case of error, the function dma_request_chan() returns ERR_PTR() and never returns NULL. Set 'dma_ch' to NULL, if dma_request_chan() returns error, so the code using 'dma_ch' can work correctly. Fixes: 26ac471c5354 ("ASoC: sh: rz-ssi: Add SSI DMAC support") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- sound/soc/sh/rz-ssi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/sh/rz-ssi.c b/sound/soc/sh/rz-ssi.c index ea8d33ede5d2..5ec78fd94d94 100644 --- a/sound/soc/sh/rz-ssi.c +++ b/sound/soc/sh/rz-ssi.c @@ -676,11 +676,17 @@ static void rz_ssi_release_dma_channels(struct rz_ssi_priv *ssi) static int rz_ssi_dma_request(struct rz_ssi_priv *ssi, struct device *dev) { ssi->playback.dma_ch = dma_request_chan(dev, "tx"); + if (IS_ERR(ssi->playback.dma_ch)) + ssi->playback.dma_ch = NULL; ssi->capture.dma_ch = dma_request_chan(dev, "rx"); + if (IS_ERR(ssi->capture.dma_ch)) + ssi->capture.dma_ch = NULL; if (!ssi->playback.dma_ch && !ssi->capture.dma_ch) { ssi->playback.dma_ch = dma_request_chan(dev, "rt"); - if (!ssi->playback.dma_ch) + if (IS_ERR(ssi->playback.dma_ch)) { + ssi->playback.dma_ch = NULL; goto no_dma; + } ssi->dma_rt = true; } -- 2.25.1

2 2