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

[alsa-devel] [PATCH] ASoC: dt-bindings: stm32: convert spdfirx to json-schema
by Olivier Moysan 15 Jan '20

15 Jan '20

Convert the STM32 SPDIFRX bindings to DT schema format using json-schema. Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> --- .../bindings/sound/st,stm32-spdifrx.txt | 56 ------------- .../bindings/sound/st,stm32-spdifrx.yaml | 80 +++++++++++++++++++ 2 files changed, 80 insertions(+), 56 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/st,stm32-spdifrx.txt create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.txt b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.txt deleted file mode 100644 index 33826f2459fa..000000000000 --- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.txt +++ /dev/null @@ -1,56 +0,0 @@ -STMicroelectronics STM32 S/PDIF receiver (SPDIFRX). - -The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with -IEC-60958 and IEC-61937. - -Required properties: - - compatible: should be "st,stm32h7-spdifrx" - - reg: cpu DAI IP base address and size - - clocks: must contain an entry for kclk (used as S/PDIF signal reference) - - clock-names: must contain "kclk" - - interrupts: cpu DAI interrupt line - - dmas: DMA specifiers for audio data DMA and iec control flow DMA - See STM32 DMA bindings, Documentation/devicetree/bindings/dma/stm32-dma.txt - - dma-names: two dmas have to be defined, "rx" and "rx-ctrl" - -Optional properties: - - resets: Reference to a reset controller asserting the SPDIFRX - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -graph.txt. - -Example: -spdifrx: spdifrx@40004000 { - compatible = "st,stm32h7-spdifrx"; - reg = <0x40004000 0x400>; - clocks = <&rcc SPDIFRX_CK>; - clock-names = "kclk"; - interrupts = <97>; - dmas = <&dmamux1 2 93 0x400 0x0>, - <&dmamux1 3 94 0x400 0x0>; - dma-names = "rx", "rx-ctrl"; - pinctrl-0 = <&spdifrx_pins>; - pinctrl-names = "default"; - - spdifrx_port: port { - cpu_endpoint: endpoint { - remote-endpoint = <&codec_endpoint>; - }; - }; -}; - -spdif_in: spdif-in { - compatible = "linux,spdif-dir"; - - codec_port: port { - codec_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint>; - }; - }; -}; - -soundcard { - compatible = "audio-graph-card"; - dais = <&spdifrx_port>; -}; diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml new file mode 100644 index 000000000000..ab8e9d74ac3c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/st,stm32-spdifrx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 S/PDIF receiver (SPDIFRX) + +maintainers: + - Olivier Moysan <olivier.moysan(a)st.com> + +description: | + The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with + IEC-60958 and IEC-61937. + +properties: + compatible: + enum: + - st,stm32h7-spdifrx + + "#sound-dai-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: kclk + + interrupts: + maxItems: 1 + + dmas: + items: + - description: audio data capture DMA + - description: IEC status bits capture DMA + minItems: 1 + maxItems: 2 + + dma-names: + items: + - const: rx + - const: rx-ctrl + + resets: + maxItems: 1 + +required: + - compatible + - "#sound-dai-cells" + - reg + - clocks + - clock-names + - interrupts + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp1-clks.h> + spdifrx: spdifrx@40004000 { + compatible = "st,stm32h7-spdifrx"; + #sound-dai-cells = <0>; + reg = <0x40004000 0x400>; + clocks = <&rcc SPDIF_K>; + clock-names = "kclk"; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&dmamux1 2 93 0x400 0x0>, + <&dmamux1 3 94 0x400 0x0>; + dma-names = "rx", "rx-ctrl"; + pinctrl-0 = <&spdifrx_pins>; + pinctrl-names = "default"; + }; + +... -- 2.17.1

2 1

[alsa-devel] Simultaneous play/record on implicit feedback device causes 'endpoint in use' error
by Robert Giaraffa 15 Jan '20

15 Jan '20

My company (Silicon Labs) makes a CP2615 USB audio class 1.0 device which uses implicit feedback. I saw these two issues when testing with aplay/arecord/alsabat/alsaloop: * During playback-only operation, the implicit feedback (IN) endpoint was not active. * During play/record operation, the implicit feedback values were not acted on, i.e. the host always sent 192 bytes per OUT packet even if previous IN packets had been 188 or 196 bytes. This behavior was observed on these systems: RaspberryPi2: Raspbian 9 (stretch), kernel v4.14.72 x86-64: Ubuntu 18.04, kernel v4.15.0-36 I was able to get implicit feedback working properly in playback mode by adding a device-specific quirk to 'pcm.c' that is similar to existing quirks for implicit-feedback devices, e.g. M-Audio Fast Track Ultra. (Note: The following patch applies to kernel v4.14.72. In v4.18, the set_sync_ep_implicit_fb_quirk function was changed so that there is a single call to usb_ifnum_to_if(), rather than a call for each device-dependent quirk.) $ git diff pcm.c diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index b9c9a19f..6fb5567b 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -358,6 +358,21 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x10C4, 0xEAC1): // Silicon Labs CP2615 + // Ensure CP2615 is configured in Async Mode + if (attr != USB_ENDPOINT_SYNC_ASYNC) + return 0; + + // In P16R16 async mode, AudioIN EP (IF:4 EP:0x83) used for implicit feedback + ep = 0x83; + iface = usb_ifnum_to_if(dev, 4); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; + } if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && After adding the patch, I verified that implicit feedback worked properly for playback, i.e. the OUT samples per packet tracked previous IN values. However, when attempting to perform simultaneous play and record via alsabat, alsaloop, or separate aplay/arecord, the system reports the 'endpoint already in use' error when attempting to set the format for the IN endpoint that is already in use (note that this dmesg log has customized printk messages): [Oct23 10:13] snd_usb_hw_params->set_format() [ +0.000014] set_format(): dev:b3856c00 alts:b67e8824 ifnum: 3 [ +0.001654] set_format()->usb_set_interface 3:1 [ +0.000006] Creating new playback data endpoint 03 [ +0.000004] Creating new capture data endpoint 83 <Begin Playback. SYNC endpoint also starts because feedback is implicit> [ +0.000027] snd_usb_pcm_prepare->set_format() [ +0.000005] set_format(): dev:b3856c00 alts:b67e8824 ifnum: 3 [ +0.000755] Setting params for EP 03 (type 0, 12 urbs), ret=0 [ +0.000017] Setting params for EP 83 (type 0, 12 urbs), ret=0 [ +0.000004] Starting DATA_EP 03 @b9224000 [ +0.000004] snd_usb_endpoint_implicit_feedback_sink (03) is TRUE [ +0.001495] Starting SYNC_EP 83 @b9222000 <After playing for 0.5s, start recording. Failure occurs because EP83 is already in use.> [ +0.493035] snd_usb_hw_params->set_format() [ +0.000016] set_format(): dev:b3856c00 alts:b67e88a4 ifnum: 4 [ +0.001549] set_format()->usb_set_interface 4:1 [ +0.000005] Re-using EP 83 in iface 4:1 [ +0.000028] snd_usb_pcm_prepare->set_format() [ +0.000004] set_format(): dev:b3856c00 alts:b67e88a4 ifnum: 4 *** [ +0.003196] *** snd_usb_endpoint_set_params(): EP #83: already in use [ +0.000003] configure_endpoint->endpoint_set_params: err=FFFFFFF0 I bought a used Fast Track Ultra device for comparison testing, and found that it behaved the same way as the CP2615 does with the implicit feedback quirk: in playback-only mode implicit feedback works properly, but play/record causes the 'EP already in use' error. Are there any suggestions on how I can resolve this issue? Any help would be greatly appreciated! Thanks, Bob Giaraffa

3 4

[alsa-devel] arecord: buffer-size dependency on period-size and other params
by Rajwa, Marcin 15 Jan '20

15 Jan '20

Hello, I have spotted strange behavior of alsa-lib when I try to set buffer-size in arecord. It looks like the size of the buffer is very dependent on other parameters like period-size and rate for example. At first it sounds like normal behaviour, after all buffer size smaller than period size doesn’t make much sense. However what if we go in the reverse direction and set buffer-size much larger than period size? Then I see no reason to forbid such request (at least on the user space level). So to be specific I issue such command: arecod -Dplughw:0,8 -r 16000 -c 2 -f S24_LE --buffer_size 1280000 tmp.wav -vvv. The arecord response for this is buffer size of 31992 frames, 255936 bytes. Now let me also tell the buffer size of 1280000 bytes is the maximum buffer size our driver allows, likewise max period is 268800 bytes. Now if inside our driver I double max period size limit I get buffer size accordingly bigger. Similarly, if I change the format in the command line request from S24_LE to i.e S16_LE then again I will get buffer size closer to my request (bigger). So below are my questions: 1. Why alsa-lib behaves in a way I described above? Why I can not control buffer size independently from other parameters (providing it has physical sense). 2. It looks like alsa-lib first calculates initial buffer-size base on other input params like mentioned period size or sampling rate and then ask driver to refine it according to its capabilities. Is that the case? 3. I also tried to dump hw capabilities by adding –dump-hw-param flag to my command line request and here yet another surprise – in a row dedicated for buffer size it says “BUFFER_SIZE [12 4294967294]”. Where is this “4294967294” comes from, and on what basics is it calculated? I would expect at the bare minimum it should ask driver but in the snd_pcm_hw_param_dump() function I don’t see any communication with the driver. Kind Regards, Marcin Rajwa

3 2

[alsa-devel] Applied "regulator fix for "regulator: core: Add regulator_is_equal() helper"" to the asoc tree
by Mark Brown 15 Jan '20

15 Jan '20

The patch regulator fix for "regulator: core: Add regulator_is_equal() helper" has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 0468e667a5bead9c1b7ded92861b5a98d8d78745 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell <sfr(a)canb.auug.org.au> Date: Wed, 15 Jan 2020 12:02:58 +1100 Subject: [PATCH] regulator fix for "regulator: core: Add regulator_is_equal() helper" Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Link: https://lore.kernel.org/r/20200115120258.0e535fcb@canb.auug.org.au Acked-by: Marek Vasut <marex(a)denx.de> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- include/linux/regulator/consumer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 2c89d886595c..6a92fd3105a3 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -596,7 +596,7 @@ regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers, } static inline bool -regulator_is_equal(struct regulator *reg1, struct regulator *reg2); +regulator_is_equal(struct regulator *reg1, struct regulator *reg2) { return false; } -- 2.20.1

1 0

[alsa-devel] Bug report for changes in ucm2 with chtrt5645 card on Lenovo Miix 320
by Tim Schumacher 15 Jan '20

15 Jan '20

Hi alsa devs, I'm on Arch Linux on a rather uncommon laptop (Lenovo Miix 320) and my sound stopped working on the upgrade from alsa-lib 1.1.9 to 1.2.1. wabbits on IRC helped me track down the problem to a change in the /usr/share/alsa/ucm (now /usr/share/alsa/ucm2) files. It seems like /usr/share/alsa/ucm2/chtrt5645/HiFi-dmic2.conf and a symlink at /usr/share/alsa/ucm2/chtrt5645/LENOVO-80XF-LenovoMIIX320_10ICR-LNVNB161216.conf were specifically added for this laptop but in the contrary they break the sound for me. After the upgrade to alsa-lib 1.2.1 the sound is not working. The commands play no sound: pasuspender -- speaker-test --nloops=1 --channels=2 --test=wav --device=hw:0,0 pasuspender -- speaker-test --nloops=1 --channels=2 --test=wav --device=hw:0,1 And this is the alsa-info.sh output http://alsa-project.org/db/?f=f883910a5c5101b4b1ea4202d1fe84ccd139f796 After deleting the /usr/share/alsa/ucm2/chtrt5645/LENOVO-80XF-LenovoMIIX320_10ICR-LNVNB161216.conf symlink both commands from above play sound and this is the alsa-info.sh output http://alsa-project.org/db/?f=e759eb9118a191b6c3b8c021fed58abc9cf95076 Thanks. - Tim

2 6

[alsa-devel] [PATCH] ALSA: hda/analog - Minor optimization for SPDIF mux connections
by Takashi Iwai 15 Jan '20

15 Jan '20

AD HD-audio codec driver has a few code lines invoking snd_get_num_conns() and using its return value as the array index without checking. This is basically safe in all those places; at the second and later calls snd_get_num_conns() returns the value cached from the first invocation, hence the value is always consistent. However, it looks a bit confusing as if a lack of the proper check. This patch introduces a new field num_smux_conns in ad198x_spec for simplifying the code. Now we store and refer to the value more locally without invoking the extra function at each time. Reported-by: Colin King <colin.king(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_analog.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 88c46b051d14..2132b2acec4d 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -28,6 +28,7 @@ struct ad198x_spec { hda_nid_t eapd_nid; unsigned int beep_amp; /* beep amp value, set via set_beep_amp() */ + int num_smux_conns; }; @@ -453,8 +454,7 @@ static int ad1983_auto_smux_enum_info(struct snd_kcontrol *kcontrol, struct ad198x_spec *spec = codec->spec; static const char * const texts2[] = { "PCM", "ADC" }; static const char * const texts3[] = { "PCM", "ADC1", "ADC2" }; - hda_nid_t dig_out = spec->gen.multiout.dig_out_nid; - int num_conns = snd_hda_get_num_conns(codec, dig_out); + int num_conns = spec->num_smux_conns; if (num_conns == 2) return snd_hda_enum_helper_info(kcontrol, uinfo, 2, texts2); @@ -481,7 +481,7 @@ static int ad1983_auto_smux_enum_put(struct snd_kcontrol *kcontrol, struct ad198x_spec *spec = codec->spec; unsigned int val = ucontrol->value.enumerated.item[0]; hda_nid_t dig_out = spec->gen.multiout.dig_out_nid; - int num_conns = snd_hda_get_num_conns(codec, dig_out); + int num_conns = spec->num_smux_conns; if (val >= num_conns) return -EINVAL; @@ -512,6 +512,7 @@ static int ad1983_add_spdif_mux_ctl(struct hda_codec *codec) num_conns = snd_hda_get_num_conns(codec, dig_out); if (num_conns != 2 && num_conns != 3) return 0; + spec->num_smux_conns = num_conns; if (!snd_hda_gen_add_kctl(&spec->gen, NULL, &ad1983_auto_smux_mixer)) return -ENOMEM; return 0; @@ -730,10 +731,12 @@ static int ad1988_auto_smux_enum_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct ad198x_spec *spec = codec->spec; static const char * const texts[] = { "PCM", "ADC1", "ADC2", "ADC3", }; - int num_conns = snd_hda_get_num_conns(codec, 0x0b) + 1; + int num_conns = spec->num_smux_conns; + if (num_conns > 4) num_conns = 4; return snd_hda_enum_helper_info(kcontrol, uinfo, num_conns, texts); @@ -756,7 +759,7 @@ static int ad1988_auto_smux_enum_put(struct snd_kcontrol *kcontrol, struct ad198x_spec *spec = codec->spec; unsigned int val = ucontrol->value.enumerated.item[0]; struct nid_path *path; - int num_conns = snd_hda_get_num_conns(codec, 0x0b) + 1; + int num_conns = spec->num_smux_conns; if (val >= num_conns) return -EINVAL; @@ -847,6 +850,7 @@ static int ad1988_add_spdif_mux_ctl(struct hda_codec *codec) num_conns = snd_hda_get_num_conns(codec, 0x0b) + 1; if (num_conns != 3 && num_conns != 4) return 0; + spec->num_smux_conns = num_conns; for (i = 0; i < num_conns; i++) { struct nid_path *path = snd_array_new(&spec->gen.paths); -- 2.16.4

1 0

[alsa-devel] ABI breakage in alsa-lib 1.2
by Jordi Mallach 15 Jan '20

15 Jan '20

[Please Cc me on replies, I'm not currently subscribed to alsa-devel] Hello, I'm one of the ALSA Debian maintainers, and some weeks ago I looked into updating our ALSA packages to 1.2.1. I quickly noticed there's been some fundamental change to libasound2, one that appears to break ABI and should have warranted an soname bump at least. With the split of the snd_tplg API to the new libatopology2, libasound2 has been left missing that part of the API that was part of the asound.h header, etc. This could have been a somewhat lesser issue if libasound2 linked to libatopology, but unfortunately this goes in the other direction, so the ABI and API breakage is not avoided. I cannot update alsa-lib in this state. I could hack around and patch it to reinstate the missing api in libasound, but this sounds like pain and suffering for everyone involved. How should we move forward with this? I am sorry I only come up with this 2 months after the release when I had identified the problem many weeks ago, I've been extremely busy. Thanks, Jordi -- Jordi Mallach <jordi(a)debian.org> Debian Project

2 1

[alsa-devel] [PATCH RFC 0/3] ASoC: Add Multi CPU DAI support
by Bard liao 15 Jan '20

15 Jan '20

From: Bard Liao <yung-chuan.liao(a)linux.intel.com> As discussed in [1], ASoC core supports multi codec DAIs on a DAI link. However it does not do so for CPU DAIs. So, add support for multi CPU DAIs on a DAI Link by adding multi CPU DAI in Card instantiation, suspend and resume functions, PCM ops, stream handling functions and DAPM. [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html Shreyas NC (3): ASoC: Add initial support for multiple CPU DAIs ASoC: Add multiple CPU DAI support for PCM ops ASoC: Add multiple CPU DAI support in DAPM include/sound/soc.h | 15 ++ sound/soc/soc-core.c | 183 ++++++++++-------- sound/soc/soc-dapm.c | 131 +++++++------ sound/soc/soc-pcm.c | 432 ++++++++++++++++++++++++++++--------------- 4 files changed, 483 insertions(+), 278 deletions(-) -- 2.17.1

4 7

[alsa-devel] [PATCH] ALSA: hda - fix out of bounds read on spec->smux_paths
by Colin King 14 Jan '20

14 Jan '20

From: Colin Ian King <colin.king(a)canonical.com> It is possible for the call to snd_hda_get_num_conns to fail and return a negative error code that gets assigned to num_conns. In that specific case, the check of very large values of val against num_conns will not fail the -EINVAL check and later on an out of bounds array read on spec->smux_paths will occur. Fix this by sanity checking for an error return from the call to snd_hda_get_num_conns. Addresses-Coverity: ("Out-of-bounds read") Fixes: 272f3ea31776 ("ALSA: hda - Add SPDIF mux control to AD codec auto-parser") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/pci/hda/patch_analog.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 88c46b051d14..399561369495 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -756,9 +756,11 @@ static int ad1988_auto_smux_enum_put(struct snd_kcontrol *kcontrol, struct ad198x_spec *spec = codec->spec; unsigned int val = ucontrol->value.enumerated.item[0]; struct nid_path *path; - int num_conns = snd_hda_get_num_conns(codec, 0x0b) + 1; + int num_conns = snd_hda_get_num_conns(codec, 0x0b); - if (val >= num_conns) + if (num_conns < 0) + return num_conns; + if (val >= num_conns + 1) return -EINVAL; if (spec->cur_smux == val) return 0; -- 2.24.0

3 2

[alsa-devel] [PATCH 0/5] soundwire: intel: add DAI callbacks
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

The existing mainline code is missing most of the DAI callbacks needed for a functional implementation, and the existing ones need to be modified to provide the relevant information to SOF drivers. As suggested by Vinod, these patches are shared first - with the risk that they are separated from the actual DAI enablement, so reviewers might wonder why they are needed in the first place. For reference, the complete set of 100+ patches required for SoundWire on Intel platforms is available here: https://github.com/thesofproject/linux/pull/1692 Pierre-Louis Bossart (2): soundwire: intel: rename res field as link_res soundwire: intel: free all resources on hw_free() Rander Wang (3): soundwire: intel: add prepare support in sdw dai driver soundwire: intel: add trigger support in sdw dai driver soundwire: intel: add sdw_stream_setup helper for .startup callback drivers/soundwire/intel.c | 198 ++++++++++++++++++++++++++++++++++---- 1 file changed, 178 insertions(+), 20 deletions(-) base-commit: b637124800a157c4df3699d1137d8533394f7678 -- 2.20.1

2 7