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

[PATCH] ALSA: hda/realtek - Couldn't detect Mic if booting with headset plugged
by Hui Wang 21 Sep '20

21 Sep '20

We found a Mic detection issue on many Lenovo laptops, those laptops belong to differnt models and they have different audio design like internal mic connects to the codec or PCH, they all have this problem, the problem is if plugging a headset before powerup/reboot the machine, after booting up, the headphone could be detected but Mic couldn't. If we plug out and plug in the headset, both headphone and Mic could be detected then. Through debugging we found the codec on those laptops are same, it is alc257, and if we don't disable the 3k pulldown in alc256_shutup(), the issue will be fixed. So far there is no pop noise or power consumption regression on those laptops after this change. Cc: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 85e207173f5d..b6dc47da1d7b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3428,7 +3428,11 @@ static void alc256_shutup(struct hda_codec *codec) /* 3k pull low control for Headset jack. */ /* NOTE: call this before clearing the pin, otherwise codec stalls */ - alc_update_coef_idx(codec, 0x46, 0, 3 << 12); + /* If disable 3k pulldown control for alc257, the Mic detection will not work correctly + * when booting with headset plugged. So skip setting it for the codec alc257 + */ + if (codec->core.vendor_id != 0x10ec0257) + alc_update_coef_idx(codec, 0x46, 0, 3 << 12); if (!spec->no_shutup_pins) snd_hda_codec_write(codec, hp_pin, 0, -- 2.17.1

3 2

[PATCH] ALSA: asihpi: fix iounmap in error handler
by trix＠redhat.com 21 Sep '20

21 Sep '20

From: Tom Rix <trix(a)redhat.com> clang static analysis flags this problem hpioctl.c:513:7: warning: Branch condition evaluates to a garbage value if (pci.ap_mem_base[idx]) { ^~~~~~~~~~~~~~~~~~~~ If there is a failure in the middle of the memory space loop, only some of the memory spaces need to be cleaned up. At the error handler, idx holds the number of successful memory spaces mapped. So rework the handler loop to use the old idx. There is a second problem, the memory space loop conditionally iomaps()/sets the mem_base so it is necessay to initize pci. Fixes: 719f82d3987a ("ALSA: Add support of AudioScience ASI boards") Signed-off-by: Tom Rix <trix(a)redhat.com> --- sound/pci/asihpi/hpioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/asihpi/hpioctl.c b/sound/pci/asihpi/hpioctl.c index 6cc2b6964bb5..bb31b7fe867d 100644 --- a/sound/pci/asihpi/hpioctl.c +++ b/sound/pci/asihpi/hpioctl.c @@ -352,7 +352,7 @@ int asihpi_adapter_probe(struct pci_dev *pci_dev, struct hpi_message hm; struct hpi_response hr; struct hpi_adapter adapter; - struct hpi_pci pci; + struct hpi_pci pci = { 0 }; memset(&adapter, 0, sizeof(adapter)); @@ -509,7 +509,7 @@ int asihpi_adapter_probe(struct pci_dev *pci_dev, return 0; err: - for (idx = 0; idx < HPI_MAX_ADAPTER_MEM_SPACES; idx++) { + while (--idx >= 0) { if (pci.ap_mem_base[idx]) { iounmap(pci.ap_mem_base[idx]); pci.ap_mem_base[idx] = NULL; -- 2.18.1

2 1

[PATCH v3 00/19] Add Allwinner H3/H5/H6/A64 HDMI audio
by Clément Péron 20 Sep '20

20 Sep '20

Hi, New test done by Maxime using TDM show that's LRCK is indeed inverted so I drop the patch reverted in v2. And HDMI requires an inverted LRCK so let's readd the frame-inversion in the device-tree. I have also added a patch to change set_chan_cfg. Please note that I can't test TDM and only have a Allwinner H6. So test and comment on other Allwinner chips are welcome! Regards, Clement Change since v2: - rebase on next-20200918 - drop revert LRCK polarity patch - readd simple-audio-card,frame-inversion in dts - Add patch for changing set_chan_cfg params Change since v1: - rebase on next-20200828 - add revert LRCK polarity - remove all simple-audio-card,frame-inversion in dts - add Ondrej patches for Orange Pi board - Add arm64 defconfig patch Clément Péron (4): ASoC: sun4i-i2s: Change set_chan_cfg params ASoC: sun4i-i2s: Fix sun8i volatile regs arm64: dts: allwinner: h6: Enable HDMI sound for Beelink GS1 arm64: defconfig: Enable Allwinner i2s driver Jernej Skrabec (3): ASoC: sun4i-i2s: Add support for H6 I2S dt-bindings: ASoC: sun4i-i2s: Add H6 compatible arm64: dts: allwinner: h6: Add HDMI audio node Marcus Cooper (9): ASoC: sun4i-i2s: Set sign extend sample ASoc: sun4i-i2s: Add 20 and 24 bit support arm: dts: sunxi: h3/h5: Add DAI node for HDMI arm: dts: sunxi: h3/h5: Add HDMI audio arm64: dts: allwinner: a64: Add DAI node for HDMI arm64: dts: allwinner: a64: Add HDMI audio arm: sun8i: h3: Add HDMI audio to Orange Pi 2 arm: sun8i: h3: Add HDMI audio to Beelink X2 arm64: dts: allwinner: a64: Add HDMI audio to Pine64 Ondrej Jirman (3): arm64: dts: allwinner: Enable HDMI audio on Orange Pi PC 2 ARM: dts: sun8i-h3: Enable HDMI audio on Orange Pi PC/One arm64: dts: sun50i-h6-orangepi-3: Enable HDMI audio .../sound/allwinner,sun4i-a10-i2s.yaml | 2 + arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 + arch/arm/boot/dts/sunxi-h3-h5.dtsi | 33 +++ .../boot/dts/allwinner/sun50i-a64-pine64.dts | 8 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 34 +++ .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 8 + .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 8 + .../dts/allwinner/sun50i-h6-orangepi-3.dts | 8 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 +++ arch/arm64/configs/defconfig | 1 + sound/soc/sunxi/sun4i-i2s.c | 280 ++++++++++++++++-- 14 files changed, 427 insertions(+), 20 deletions(-) -- 2.25.1

2 25

Re: [PATCH v3 3/7] ASoC: sun4i-i2s: Add support for H6 I2S
by Samuel Holland 20 Sep '20

20 Sep '20

Maxime, On 9/10/20 9:33 AM, Maxime Ripard wrote: > On Thu, Sep 03, 2020 at 09:54:39PM -0500, Samuel Holland wrote: >> On 9/3/20 3:58 PM, Maxime Ripard wrote: >>> On Thu, Sep 03, 2020 at 10:02:31PM +0200, Clément Péron wrote: >>>> Hi Maxime, >>>> >>>> On Wed, 29 Jul 2020 at 17:16, Mark Brown <broonie(a)kernel.org> wrote: >>>>> >>>>> On Wed, Jul 29, 2020 at 04:39:27PM +0200, Maxime Ripard wrote: >>>>> >>>>>> It really looks like the polarity of LRCK is fine though. The first word >>>>>> is sent with LRCK low, and then high, so we have channel 0 and then >>>>>> channel 1 which seems to be the proper ordering? >> >> Which image file is this in reference to? >> >>>>> Yes, that's normal. >>>> >>>> Thank you very much for this test. >>>> >>>> So I will revert the following commit: >>>> >>>> ASoC: sun4i-i2s: Fix the LRCK polarity >>>> >>>> https://github.com/clementperon/linux/commit/dd657eae8164f7e4bafe8b875031a7… >>> >>> Like I said, the current code is working as expected with regard to the >>> LRCK polarity. The issue is that the samples are delayed and start to be >>> transmitted on the wrong phase of the signal. >> >> Since an I2S LRCK frame is radially symmetric, "wrong phase" and "inverted >> polarity" look the same. The only way to definitively distinguish them is by >> looking at the sample data. >> >> In "i2s-h6.png", the samples are all zeroes, so you're assuming that the first >> sample transmitted (that is, when the bit clock starts transitioning) was a >> "left" sample. >> >> However, in "h6-i2s-start-data.png", there are pairs of samples we can look at. >> I'm still assuming that similar samples are a left/right pair, but that's >> probably a safe assumption. Here we see the first sample in each pair is >> transmitted with LRCK *high*, and the second sample in the pair is transmitted >> with LRCK *low*. This is the opposite of your claim above. >> >> An ideal test would put left/right markers and frame numbers in the data >> channel. The Python script below can generate such a file. Then you would know >> how much startup delay there is, which channel the "first sample" came from, and >> how each channel maps to the LRCK level. >> >> It would also be helpful to test DSP_A mode, where the LRCK signal is >> asymmetric and an inversion would be obvious. > > I had no idea that there was a wave module in Python, that's a great > suggestion, thanks! > > You'll find attached the screenshots for both the I2S and DSP_A formats. > I zoomed out a bit to be able to have the first valid samples, but it > should be readable. > > The code I used is there: > https://github.com/mripard/linux/tree/sunxi/h6-i2s-test > > It's basically the v3, plus the DT bits. > > As you can see, in the i2s case, LRCK starts low and then goes up, with > the first channel (0x2*** samples) transmitted first, so everything > looks right here. > > On the DSP_A screenshot, LRCK will be low with small bursts high, and > once again with the first channel being transmitted first, so it looks > right to me too. Indeed, for H6 i2s0 with LRCK inversion in software, everything looks correct on the wire. It's still concerning to me that the BSP has no evidence of this inversion, either for i2s0 or i2s1[1]. And the inversion seems not to be required for HDMI audio on mainline either (but there could be an inversion on the HDMI side or on the interconnect). Even so, your research is sufficient justification for me that the code is correct as-is (with the inversion). Thank you very much for collecting the data! Cheers, Samuel [1]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/e634a960316dddd1eb… where 1 == SND_SOC_DAIFMT_NB_NF, and there's no inversion in sunxi_daudio_init_fmt().

3 4

USB-Audio.conf patch for ASUS Xonar SE IEC958
by Brian McCarter 20 Sep '20

20 Sep '20

Hello, I recently purchased an ASUS Xonar SE sound card and found that the IEC958 output did not work under ALSA. The attached patch to alsa-lib enables the output. I can see that the SE is among several other Xonar models which require special treatment to enable the S/PDIF output, but this one appears to be the only one which puts the digital output on PCM #2. Brian McCarter

1 0

[PATCH 1/2] ASoC: tas2770: Fix calling reset in probe
by Dan Murphy 18 Sep '20

18 Sep '20

tas2770_reset is called during i2c probe. The reset calls the snd_soc_component_write which depends on the tas2770->component being available. The component pointer is not set until codec_probe so move the reset to the codec_probe after the pointer is set. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- sound/soc/codecs/tas2770.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c index c09851834395..03d7ad1885b8 100644 --- a/sound/soc/codecs/tas2770.c +++ b/sound/soc/codecs/tas2770.c @@ -575,6 +575,8 @@ static int tas2770_codec_probe(struct snd_soc_component *component) tas2770->component = component; + tas2770_reset(tas2770); + return 0; } @@ -771,8 +773,6 @@ static int tas2770_i2c_probe(struct i2c_client *client, tas2770->channel_size = 0; tas2770->slot_width = 0; - tas2770_reset(tas2770); - result = tas2770_register_codec(tas2770); if (result) dev_err(tas2770->dev, "Register codec failed.\n"); -- 2.28.0

1 2

[PATCH 0/2] DAI driver for new XCVR IP
by Viorel Suman (OSS) 18 Sep '20

18 Sep '20

From: Viorel Suman <viorel.suman(a)nxp.com> DAI driver for new XCVR IP found in i.MX8MP. Viorel Suman (2): ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver ASoC: dt-bindings: fsl_xcvr: Add document for XCVR .../devicetree/bindings/sound/fsl,xcvr.yaml | 104 ++ sound/soc/fsl/Kconfig | 10 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_xcvr.c | 1352 ++++++++++++++++++++ sound/soc/fsl/fsl_xcvr.h | 266 ++++ 5 files changed, 1734 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml create mode 100644 sound/soc/fsl/fsl_xcvr.c create mode 100644 sound/soc/fsl/fsl_xcvr.h -- 2.7.4

5 10

[PATCH 0/7] SOF fixes and updates
by Ranjani Sridharan 18 Sep '20

18 Sep '20

This series includes fixes for error reporting, topology parsing and runtime PM issues along with updates for DMIC support and IMX platforms. Iulian Olaru (2): ASoC: SOF: imx: Replace sdev->private with sdev->pdata->hw_pdata ASoC: SOF: sof-of-dev: Add .arch_ops field Jaska Uimonen (1): ASoC: SOF: intel: hda: support also devices with 1 and 3 dmics Keyon Jie (1): ASoC: SOF: topology: fix the ipc_size calculation for process component Rander Wang (1): ASoC: SOF: fix a runtime pm issue in SOF when HDMI codec doesn't work Ranjani Sridharan (2): ASoC: SOF: Intel: hda: report error only for the last ROM init iteration ASoC: SOF: Intel: hda: add extended rom status dump to error log sound/soc/sof/imx/Kconfig | 2 ++ sound/soc/sof/imx/imx8.c | 17 +++++++++---- sound/soc/sof/imx/imx8m.c | 10 +++++--- sound/soc/sof/intel/hda-codec.c | 4 +-- sound/soc/sof/intel/hda-loader.c | 42 +++++++++++++++++++------------- sound/soc/sof/intel/hda.c | 26 +++++++++++++++++++- sound/soc/sof/topology.c | 4 +-- 7 files changed, 74 insertions(+), 31 deletions(-) -- 2.25.1

3 10

[PATCH v2] ALSA: HDA: Early Forbid of runtime PM
by Harsha Priya 18 Sep '20

18 Sep '20

For certain codecs (like Realtek), pm_runtime_forbid() is invoked in the probe function after build_controls(). In a stress test, its observed occasionally that runtime PM calls are invoked before controls are built. This causes the codec to be runtime suspended before probe completes. Because of this, not all controls are enumerated correctly, and audio does not work until system is rebooted. This issue being common across all codecs, pm_runtime_forbid() is called when the codec object is created to fix this issue. A codec enables or disables runtime pm in its own probe function. Multiple stress tests of 2000+ cycles has been done to test the fix. Signed-off-by: Harsha Priya <harshapriya.n(a)intel.com> Signed-off-by: Emmanuel Jillela <emmanuel.jillela(a)intel.com> Reviewed-by: Kailang Yang <kailang(a)realtek.com> --- sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index e96a87f1b611..a356c21edb90 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1000,6 +1000,9 @@ int snd_hda_codec_device_new(struct hda_bus *bus, struct snd_card *card, if (err < 0) goto error; + /* PM runtime needs to be enabled later after binding codec */ + pm_runtime_forbid(&codec->core.dev); + return 0; error: -- 2.17.1

3 3

[PATCH] ASoC: fix kconfig dependency warnings for SND_SOC_WM8731
by Necip Fazil Yildiran 18 Sep '20

18 Sep '20

SND_SOC_WM8731 was made visible and dependent on other symbols with commit 1291e14175e6 ("ASoC: codecs: Make OF supported CODECs visible in Kconfig"). To this respect, the symbols selecting SND_SOC_WM8731 turned out to be overlooking its dependencies. For example, enabling SND_SOC_DB1200 and disabling SND_SOC_I2C_AND_SPI results in the following Kconfig warning since SND_SOC_DB1200 selects SND_SOC_WM8731 but does not account for its dependencies: WARNING: unmet direct dependencies detected for SND_SOC_WM8731 Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_I2C_AND_SPI [=n] Selected by [y]: - SND_SOC_DB1200 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AU1XPSC [=y] Switch reverse dependencies on SND_SOC_WM8731 to normal dependencies. Fixes: 1291e14175e6 ("ASoC: codecs: Make OF supported CODECs visible in Kconfig") Signed-off-by: Necip Fazil Yildiran <fazilyildiran(a)gmail.com> --- sound/soc/atmel/Kconfig | 7 +++---- sound/soc/au1x/Kconfig | 3 +-- sound/soc/pxa/Kconfig | 4 ++-- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig index 71f2d42188c4..abb1284835c0 100644 --- a/sound/soc/atmel/Kconfig +++ b/sound/soc/atmel/Kconfig @@ -44,8 +44,8 @@ config SND_AT91_SOC_SAM9G20_WM8731 tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation board" depends on ARCH_AT91 || COMPILE_TEST depends on ATMEL_SSC && SND_SOC_I2C_AND_SPI + depends on SND_SOC_WM8731 select SND_ATMEL_SOC_SSC_PDC - select SND_SOC_WM8731 help Say Y if you want to add support for SoC audio on WM8731-based AT91sam9g20 evaluation board. @@ -64,8 +64,8 @@ config SND_AT91_SOC_SAM9X5_WM8731 tristate "SoC Audio support for WM8731-based at91sam9x5 board" depends on ARCH_AT91 || COMPILE_TEST depends on ATMEL_SSC && SND_SOC_I2C_AND_SPI + depends on SND_SOC_WM8731 select SND_ATMEL_SOC_SSC_DMA - select SND_SOC_WM8731 help Say Y if you want to add support for audio SoC on an at91sam9x5 based board that is using WM8731 codec. @@ -110,8 +110,7 @@ config SND_ATMEL_SOC_I2S config SND_SOC_MIKROE_PROTO tristate "Support for Mikroe-PROTO board" depends on OF - depends on SND_SOC_I2C_AND_SPI - select SND_SOC_WM8731 + depends on SND_SOC_I2C_AND_SPI && SND_SOC_WM8731 help Say Y or M if you want to add support for MikroElektronika PROTO Audio Board. This board contains the WM8731 codec, which can be configured diff --git a/sound/soc/au1x/Kconfig b/sound/soc/au1x/Kconfig index 38de7c0efbc7..749e59fddfcd 100644 --- a/sound/soc/au1x/Kconfig +++ b/sound/soc/au1x/Kconfig @@ -53,12 +53,11 @@ config SND_SOC_DB1000 config SND_SOC_DB1200 tristate "DB1200/DB1300/DB1550 Audio support" - depends on SND_SOC_AU1XPSC + depends on SND_SOC_AU1XPSC && SND_SOC_WM8731 select SND_SOC_AU1XPSC_AC97 select SND_SOC_AC97_CODEC select SND_SOC_WM9712 select SND_SOC_AU1XPSC_I2S - select SND_SOC_WM8731 help Select this option to enable audio (AC97 and I2S) on the Alchemy/AMD/RMI/NetLogic Db1200, Db1550 and Db1300 evaluation boards. diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 0ac85eada75c..eeb1dde59468 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -44,8 +44,8 @@ config SND_MMP_SOC_SSPA config SND_PXA2XX_SOC_CORGI tristate "SoC Audio support for Sharp Zaurus SL-C7x0" depends on SND_PXA2XX_SOC && PXA_SHARP_C7xx && I2C + depends on SND_SOC_WM8731 select SND_PXA2XX_SOC_I2S - select SND_SOC_WM8731 help Say Y if you want to add support for SoC audio on Sharp Zaurus SL-C7x0 models (Corgi, Shepherd, Husky). @@ -70,8 +70,8 @@ config SND_PXA2XX_SOC_Z2 config SND_PXA2XX_SOC_POODLE tristate "SoC Audio support for Poodle" depends on SND_PXA2XX_SOC && MACH_POODLE && I2C + depends on SND_SOC_WM8731 select SND_PXA2XX_SOC_I2S - select SND_SOC_WM8731 help Say Y if you want to add support for SoC audio on Sharp Zaurus SL-5600 model (Poodle). -- 2.25.1

2 1