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

[PATCH] sound/pci/asihpi: fix spellint typo in comments
by Wang Qing 21 Sep '20

21 Sep '20

Change the comment typo: "ununsed" -> "unused". Signed-off-by: Wang Qing <wangqing(a)vivo.com> --- sound/pci/asihpi/hpios.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/asihpi/hpios.h b/sound/pci/asihpi/hpios.h index 26f7cf4..9e551bc --- a/sound/pci/asihpi/hpios.h +++ b/sound/pci/asihpi/hpios.h @@ -67,7 +67,7 @@ struct hpi_ioctl_linux { }; /* Conflict?: H is already used by a number of drivers hid, bluetooth hci, - and some sound drivers sb16, hdsp, emu10k. AFAIK 0xFC is ununsed command + and some sound drivers sb16, hdsp, emu10k. AFAIK 0xFC is unused command */ #define HPI_IOCTL_LINUX _IOWR('H', 0xFC, struct hpi_ioctl_linux) -- 2.7.4

2 1

[PATCH] ALSA: hda/realtek: Enable front panel headset LED on Lenovo ThinkStation P520
by Kai-Heng Feng 21 Sep '20

21 Sep '20

On Lenovo P520, the front panel headset LED isn't lit up right now. Realtek states that the LED needs to be enabled by ALC233's GPIO2, so let's do it accordingly to light the LED up. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index c521a1f17096..ba941bd0b792 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6017,6 +6017,7 @@ static void alc_fixup_thinkpad_acpi(struct hda_codec *codec, #include "hp_x360_helper.c" enum { + ALC269_FIXUP_GPIO2, ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, ALC269_FIXUP_DELL_M101Z, @@ -6194,6 +6195,10 @@ enum { }; static const struct hda_fixup alc269_fixups[] = { + [ALC269_FIXUP_GPIO2] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_gpio2, + }, [ALC269_FIXUP_SONY_VAIO] = { .type = HDA_FIXUP_PINCTLS, .v.pins = (const struct hda_pintbl[]) { @@ -7013,6 +7018,8 @@ static const struct hda_fixup alc269_fixups[] = { [ALC233_FIXUP_LENOVO_MULTI_CODECS] = { .type = HDA_FIXUP_FUNC, .v.func = alc233_alc662_fixup_lenovo_dual_codecs, + .chained = true, + .chain_id = ALC269_FIXUP_GPIO2 }, [ALC233_FIXUP_ACER_HEADSET_MIC] = { .type = HDA_FIXUP_VERBS, -- 2.17.1

3 5

[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