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

[PATCH v2] ASoC: Intel: Fix platform ID matching for kbl_da7219_max98373
by Lukasz Majczak 19 Aug '21

19 Aug '21

Sparse warnings triggered truncating the IDs of some platform device tables. Unfortunately kbl_da7219_max98373 was also truncated. This patch is reverting the original ID. Tested on Atlas chromebook. Fixes: 94efd726b947 ("ASoC: Intel: kbl_da7219_max98357a: shrink platform_id below 20 characters") Cc: <stable(a)vger.kernel.org> # 5.4+ Tested-by: Lukasz Majczak <lma(a)semihalf.com> Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> Suggested-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/common/soc-acpi-intel-kbl-match.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/common/soc-acpi-intel-kbl-match.c b/sound/soc/intel/common/soc-acpi-intel-kbl-match.c index 741bf2f9e081..8cab91a00b1a 100644 --- a/sound/soc/intel/common/soc-acpi-intel-kbl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-kbl-match.c @@ -113,7 +113,7 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_kbl_machines[] = { }, { .id = "DLGS7219", - .drv_name = "kbl_da7219_mx98373", + .drv_name = "kbl_da7219_max98373", .fw_filename = "intel/dsp_fw_kbl.bin", .machine_quirk = snd_soc_acpi_codec_list, .quirk_data = &kbl_7219_98373_codecs, -- 2.33.0.rc2.250.ged5fa647cd-goog

4 4

[PATCH v3] ASoC: sh: rz-ssi: Improve error handling in rz_ssi_dma_request function
by Biju Das 19 Aug '21

19 Aug '21

dma_request_chan() returns error pointer in case of failures, but the rz_ssi_dma_request() checked for NULL pointer instead. This patch fixes the issue by checking for ERR_PTR() instead of NULL and sets the DMA pointers to NULL in error case so that ssi can fallback to PIO mode. Fixes: 26ac471c5354 ("ASoC: sh: rz-ssi: Add SSI DMAC support") Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> --- v2->v3: * Added Fixes tag * For SSI with with full-duplex transmission and reception, Add support for fallback to PIO mode, if both channels are not available. v1->v2: * Replaced IS_ERR_OR_NULL with IS_ERR for error pointer check, as the dma_request_chan function never returns NULL pointer for error case. --- sound/soc/sh/rz-ssi.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/rz-ssi.c b/sound/soc/sh/rz-ssi.c index f097c773d413..fa0cc08f70ec 100644 --- a/sound/soc/sh/rz-ssi.c +++ b/sound/soc/sh/rz-ssi.c @@ -185,7 +185,7 @@ rz_ssi_stream_get(struct rz_ssi_priv *ssi, struct snd_pcm_substream *substream) static inline bool rz_ssi_is_dma_enabled(struct rz_ssi_priv *ssi) { - return (ssi->playback.dma_ch || ssi->capture.dma_ch); + return (ssi->playback.dma_ch && (ssi->dma_rt || ssi->capture.dma_ch)); } static int rz_ssi_stream_is_valid(struct rz_ssi_priv *ssi, @@ -676,15 +676,26 @@ 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; } + if (!rz_ssi_is_dma_enabled(ssi)) + goto no_dma; + if (ssi->playback.dma_ch && (rz_ssi_dma_slave_config(ssi, ssi->playback.dma_ch, true) < 0)) goto no_dma; -- 2.17.1

2 1

[PATCH] ASoC: uniphier: make arrays mul and div static const, makes object smaller
by Colin King 19 Aug '21

19 Aug '21

From: Colin Ian King <colin.king(a)canonical.com> Don't populate the arrays mul and div on the stack but instead make them static const. Makes the object code smaller by 4 bytes. Before: text data bss dec hex filename 16226 4984 64 21274 531a ./sound/soc/uniphier/aio-cpu.o After: text data bss dec hex filename 16062 5144 64 21270 5316 ./sound/soc/uniphier/aio-cpu.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/uniphier/aio-cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c index cf9814130067..4e8d5f7532ba 100644 --- a/sound/soc/uniphier/aio-cpu.c +++ b/sound/soc/uniphier/aio-cpu.c @@ -128,8 +128,8 @@ static const struct uniphier_aio_spec *find_spec(struct uniphier_aio *aio, static int find_divider(struct uniphier_aio *aio, int pll_id, unsigned int freq) { struct uniphier_aio_pll *pll; - int mul[] = { 1, 1, 1, 2, }; - int div[] = { 2, 3, 1, 3, }; + static const int mul[] = { 1, 1, 1, 2, }; + static const int div[] = { 2, 3, 1, 3, }; int i; if (!is_valid_pll(aio->chip, pll_id)) -- 2.32.0

3 2

[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