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

[PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding
by Maxime Ripard 03 Sep '21

03 Sep '21

Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing. Cc: alsa-devel(a)alsa-project.org Cc: devicetree(a)vger.kernel.org Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: patches(a)opensource.cirrus.com Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- Changes from v1: - Changed the maintainers of the bindings --- .../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml new file mode 100644 index 000000000000..944e5859c962 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8978 Codec Device Tree Bindings + +maintainers: + - patches(a)opensource.cirrus.com + +properties: + '#sound-dai-cells': + const: 0 + + compatible: + const: wlf,wm8978 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 526000 + +required: + - '#sound-dai-cells' + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + codec@0 { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0>; + spi-max-frequency = <500000>; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@0 { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0>; + }; + }; + +... -- 2.31.1

3 4

[PATCH v2 0/3] Convert name-prefix doc to json-schema
by Sameer Pujar 03 Sep '21

03 Sep '21

Following are the changes: - Add json-schema for 'sound-name-prefix' documentation under 'name-perfix.yaml' - Use schema references wherever needed. - Remove txt based doc Changelog ========= v1 -> v2 -------- * Provide top reference to name-prefix.yaml as suggested by Rob for patch 2/3 * Dropped couple of unreachable email ids from Cc list in commit message of patch 2/3 * No changes in remaining patches Sameer Pujar (3): ASoC: Add json-schema documentation for sound-name-prefix ASoC: Use schema reference for sound-name-prefix ASoC: Remove name-prefix.txt .../devicetree/bindings/sound/name-prefix.txt | 24 --------------- .../devicetree/bindings/sound/name-prefix.yaml | 35 ++++++++++++++++++++++ .../bindings/sound/nvidia,tegra186-dspk.yaml | 9 ++---- .../bindings/sound/nvidia,tegra210-dmic.yaml | 9 ++---- .../bindings/sound/nvidia,tegra210-i2s.yaml | 9 ++---- .../devicetree/bindings/sound/nxp,tfa989x.yaml | 9 ++---- Documentation/devicetree/bindings/sound/rt5659.txt | 2 +- .../bindings/sound/simple-audio-mux.yaml | 9 ++---- 8 files changed, 51 insertions(+), 55 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/name-prefix.txt create mode 100644 Documentation/devicetree/bindings/sound/name-prefix.yaml -- 2.7.4

3 11

Re: linux-next: Tree for Sep 1 [sound/soc/mediatek/mt8195/snd-soc-mt8195-afe.ko]
by Randy Dunlap 03 Sep '21

03 Sep '21

On 9/1/21 1:17 AM, Stephen Rothwell wrote: > Hi all, > > Please do not add any v5.16 related code to your linux-next included > branches until after v5.15-rc1 has been released. > > Changes since 20210831: > on x86_64: ERROR: modpost: "clkdev_add" [sound/soc/mediatek/mt8195/snd-soc-mt8195-afe.ko] undefined! ERROR: modpost: "clkdev_drop" [sound/soc/mediatek/mt8195/snd-soc-mt8195-afe.ko] undefined! ERROR: modpost: "clk_unregister_gate" [sound/soc/mediatek/mt8195/snd-soc-mt8195-afe.ko] undefined! ERROR: modpost: "clk_register_gate" [sound/soc/mediatek/mt8195/snd-soc-mt8195-afe.ko] undefined! Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap <rdunlap(a)infradead.org>

4 6

[PATCH] ASoC: dt-bindings: fsl_rpmsg: Add compatible string for i.MX8ULP
by Shengjiu Wang 02 Sep '21

02 Sep '21

Add compatible string for i.MX8ULP platform which support audio function through rpmsg audio channel on M core. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml index 61802a11baf4..d370c98a62c7 100644 --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -21,6 +21,7 @@ properties: - fsl,imx8mn-rpmsg-audio - fsl,imx8mm-rpmsg-audio - fsl,imx8mp-rpmsg-audio + - fsl,imx8ulp-rpmsg-audio model: $ref: /schemas/types.yaml#/definitions/string -- 2.17.1

2 1

config issue with SoundWire mockup device support
by Fabio Aiuto 02 Sep '21

02 Sep '21

Dear Pierre and all sound developers, I work for some tests on a Lenovo ideapad Miix 300-10IBY, with fedora 34 workstation intalled on. After having pulled the last changes from staging tree I get the following issue by typing: $ make olddefconfig WARNING: unmet direct dependencies detected for SND_SOC_SDW_MOCKUP Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && EXPERT [=n] && SOUNDWIRE [=y] Selected by [m]: - SND_SOC_INTEL_SOUNDWIRE_SOF_MACH [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_MACH [=y] && SND_SOC_SOF_INTEL_SOUNDWIRE [=m] && I2C [=y] && ACPI [=y] && GPIOLIB [=y] && (MFD_INTEL_LPSS [=y] || COMPILE_TEST [=n]) && (SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES [=y] || COMPILE_TEST [=n]) && SOUNDWIRE [=y] && SND_HDA_CODEC_HDMI [=m] && SND_SOC_SOF_HDA_AUDIO_CODEC [=y] WARNING: unmet direct dependencies detected for SND_SOC_SDW_MOCKUP Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && EXPERT [=n] && SOUNDWIRE [=y] Selected by [m]: - SND_SOC_INTEL_SOUNDWIRE_SOF_MACH [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_MACH [=y] && SND_SOC_SOF_INTEL_SOUNDWIRE [=m] && I2C [=y] && ACPI [=y] && GPIOLIB [=y] && (MFD_INTEL_LPSS [=y] || COMPILE_TEST [=n]) && (SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES [=y] || COMPILE_TEST [=n]) && SOUNDWIRE [=y] && SND_HDA_CODEC_HDMI [=m] && SND_SOC_SOF_HDA_AUDIO_CODEC [=y] # # No change to .config <--- this one gets written the first time # this is an n-th run output Attached the config file I took from my own fedora distribution (just lockdep was enabled). Please tell me if you need more information on this issue. Thank you, fabio

2 2

[PATCH RESEND 0/2] Add reset-gpios handling for max98927
by Alejandro Tafalla 02 Sep '21

02 Sep '21

The max98927 codec on some devices (i.e. Xiaomi Mi A2 Lite phone) require hardware-resetting the codec by driving a reset-gpio. This series add support for it through an optional reset-gpios property. Alejandro Tafalla (2): ASoC: max98927: Handle reset gpio when probing i2c dt-bindings: sound: max98927: Add reset-gpios optional property .../devicetree/bindings/sound/max9892x.txt | 3 +++ sound/soc/codecs/max98927.c | 16 ++++++++++++++++ sound/soc/codecs/max98927.h | 1 + 3 files changed, 20 insertions(+) -- 2.32.0

4 6

Changes in ALSA firewire stack at Linux kernel v5.14 release
by Takashi Sakamoto 02 Sep '21

02 Sep '21

Dear all, I'm a maintainer of ALSA firewire stack. Linux kernel v5.14 was out a few days ago[1], including some changes in ALSA firewire stack. The changes bring improvement for usage of including drivers by solving some issues. I appreciate the users cooperating for it[2]. This message includes two topics about solved issues in the release: 1. get rid of playback noise by recovering media clock 2. allow some applications to run without periodical hardware interrupts and another topic: 3. device aggregation Let me describe the two topics first. 1. get rid of playback noise by recovering media clock Many users had been reporting playback noise since the initial version of each driver in ALSA firewire stack. The cause of the issue is complicated to explain, but let me roughly summarize it to a point below: * mismatch between audio sample count in playback stream and the one expected by hardware Since the initial stage of ALSA firewire stack, included drivers transfer audio data frames per second the exact count as sampling frequency, which is configured via ALSA PCM interface; e.g. 44.1 kHz. But it is figured out that it is not suitable for many models. For recent years, I've measured actual packets from/to various models with Windows and OS X drivers[3], and realized the below phenomena. Here, the configured frequency is called 'nominal', and the measured frequency is called 'effective'. * the effective frequency is not the same as the nominal frequency, less or greater by several audio data frames (<= 10 frames) * the effective frequency is not even in successive seconds for some models The phenomena mean that it is not achieved to transfer samples for playback sound by nominal frequency, and computation for even number of samples per second for some models. Additionally, in isochronous communication of IEEE 1394, part of models support time stamp per isochronous packet[4]. When parsing the sequence of time stamp and compare it to frequency of samples included in the packets, I realize the phenomena below: * the phase of sample based on computed time stamp shifts during long packet streaming * before and after configuring source of sampling clock to external signal input such as S/PDIF, neither the effective frequency of samples in packets nor the sequence of time stamp in packets have difference. The phenomena give us some insights. At least, the phase of samples is not deterministic somehow in driver side. It is required to recover the timing to put audio data frame into packet according to packets transferred by the hardware. This is called 'media clock recovery'[5]. In engineering field, many method of media clock recovery has been invented for each type of media. The way which ALSA firewire stack in v5.14 uses is the simplest one. It is to replay the sequence in transferred packets[6][7][8]. The result looks better. As long as I tested, it can cover all of models supported by ALSA firewire stack. 2. allow applications to run independently of periodical hardware interrupts ALSA PCM interface has hardware parameter for runtime of PCM substream to process audio data frame without scheduling periodical hardware interrupts[9]. PulseAudio and PipeWire use the function. All of drivers[10] in ALSA firewire stack now support it. Linux FireWire subsystem has function to flush queued packet till the most recent isochronous cycle. The function is available in process context without waiting for scheduled hardware interrupts, and allows drivers to achieve the topic. In most cases, it's done by calling ioctl(2) with SNDRV_PCM_IOCTL_HWSYNC. The call is the part of routine in usual ALSA PCM application, thus users do not need to take extra care of it. I think these improvements and configurable size of PCM buffer added in Linux kernel v5.5 brings better experience to users. The rest of topic comes from comparison to what existent userspace driver, libffado2[11], does. 3. device aggregation Some user pointed that it is not available with drivers in ALSA firewire stack to aggregate several audio data stream into one stream. It is what libffado2 does. Let me describe my opinion about it. At first, let me start with fundamental attribute of audio data frame. In my understanding about ALSA PCM interface, audio data frame is a unit for audio data transmission. The audio data frame includes the specific number of audio data depending on hardware; e.g. 2 samples for usual sound device. The fundamental attribute of audio data frame is to include the set of audio data sampled at the same time. The goal of aggregating audio data stream is to construct an audio data frame from some audio data frames for several devices. It means that one audio data frame consists of audio data sampled at different time. As I describe the phenomena about nominal and effective frequency, each hardware seems to run own unique effective frequency time to time[12], at least over IEEE 1394 bus. Additionally, we have the experience that the hardware is not aware of sequence of packet with nominal frequency for sample synchronization. It might be legitimate that we can not pick up audio data frame which consists of audio data sampled at the same time even if they are transferred at the same isochronous cycle[13]. When achieving the aggregation, we would need to loosen up the fundamental attribute of audio data frame, by accepting the range of sampling time for audio data in the frame, or need to implement one of resampling methods to adjust phase of audio data to the frame. Although the aggregation is itself superficially useful, it seems not to be a requirement to device driver in hardware abstraction layer of general purpose operating system. It may be over engineering. [1] Linux 5.14 https://lore.kernel.org/lkml/CAHk-=wh75ELUu99yPkPNt+R166CK=-M4eoV+F62tW3TVg… [2] The cooperation is done in my public repository in github.com: https://github.com/takaswie/snd-firewire-improve [3] The method is described in the message: [alsa-devel] IEEE 1394 isoc library, libhinoko v0.1.0 release https://lore.kernel.org/alsa-devel/20190415153053.GA32090@workstation/ [4] The resolution of time stamp is 24.576 MHz, which is the same as specification of cycle time in IEEE 1394. The method to compute time stamp of packet for samples in the packet is defined by IEC 61883-6. We can see integrated document for it published by industry group: https://web.archive.org/web/20210216003054/http://1394ta.org/wp-content/upl… [5] I borrow the expression from IEEE 1722. We can see specific term, sampling transmission frequency (STF) in IEC 61883-6 to express similar idea of the media clock. [6] [PATCH 0/3] ALSA: firewire: media clock recovery for syt-aware devices https://lore.kernel.org/alsa-devel/20210601081753.9191-1-o-takashi@sakamocc… [7] [PATCH 0/6] ALSA: firewire: media clock recovery for syt-unaware devices https://lore.kernel.org/alsa-devel/20210531025103.17880-1-o-takashi@sakamoc… [8] [PATCH 0/3] ALSA: firewire-motu: media clock recovery for sph-aware devices https://lore.kernel.org/alsa-devel/20210602013406.26442-1-o-takashi@sakamoc… [9] SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP. When the PCM substream has a flag of SNDRV_PCM_INFO_NO_PERIOD_WAKEUP, it's available. [10] Precisely except for snd-isight. [11] http://www.ffado.org/ [12] Precisely the hardware looks to run own unique media clock over IEEE 1394 bus. [13] For precise discussion, the knowledge about IEC 61883-6 and vendor specific method for packetization is required. Regards Takashi Sakamoto

4 3

[PATCH] ALSA: usb-audio: Add registration quirk for JBL Quantum 800
by Alexander Tsoy 01 Sep '21

01 Sep '21

Add another device ID for JBL Quantum 800. It requires the same quirk as other JBL Quantum devices. Signed-off-by: Alexander Tsoy <alexander(a)tsoy.me> --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 4479a590194f..6ee6d24c847f 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1743,6 +1743,7 @@ static const struct registration_quirk registration_quirks[] = { REG_QUIRK_ENTRY(0x0951, 0x16ed, 2), /* Kingston HyperX Cloud Alpha S */ REG_QUIRK_ENTRY(0x0951, 0x16ea, 2), /* Kingston HyperX Cloud Flight S */ REG_QUIRK_ENTRY(0x0ecb, 0x1f46, 2), /* JBL Quantum 600 */ + REG_QUIRK_ENTRY(0x0ecb, 0x1f47, 2), /* JBL Quantum 800 */ REG_QUIRK_ENTRY(0x0ecb, 0x2039, 2), /* JBL Quantum 400 */ REG_QUIRK_ENTRY(0x0ecb, 0x203c, 2), /* JBL Quantum 600 */ REG_QUIRK_ENTRY(0x0ecb, 0x203e, 2), /* JBL Quantum 800 */ -- 2.31.1

2 1

[PATCH] ASoC: mediatek: mt8195: add MTK_PMIC_WRAP dependency
by Trevor Wu 01 Sep '21

01 Sep '21

randconfig builds show the warning below, WARNING: unmet direct dependencies detected for SND_SOC_MT6359 Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && MTK_PMIC_WRAP [=n] Selected by [y]: - SND_SOC_MT8195_MT6359_RT1019_RT5682 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && I2C [=y] && SND_SOC_MT8195 [=y] Add a dependency to avoid it. Signed-off-by: Trevor Wu <trevor.wu(a)mediatek.com> Reported-by: Randy Dunlap <rdunlap(a)infradead.org> --- sound/soc/mediatek/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig index cf567a89f421..f6bf0f9c91e3 100644 --- a/sound/soc/mediatek/Kconfig +++ b/sound/soc/mediatek/Kconfig @@ -197,7 +197,7 @@ config SND_SOC_MT8195 config SND_SOC_MT8195_MT6359_RT1019_RT5682 tristate "ASoC Audio driver for MT8195 with MT6359 RT1019 RT5682 codec" depends on I2C - depends on SND_SOC_MT8195 + depends on SND_SOC_MT8195 && MTK_PMIC_WRAP select SND_SOC_MT6359 select SND_SOC_RT1015P select SND_SOC_RT5682_I2C -- 2.18.0

3 2

[PATCH] ASoC: audio-graph: respawn Platform Support
by Kuninori Morimoto 01 Sep '21

01 Sep '21

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 63f2f9cceb09f8 ("ASoC: audio-graph: remove Platform support") removed Platform support from audio-graph, because it doesn't have "plat" support on DT (simple-card has). But, Platform support is needed if user is using snd_dmaengine_pcm_register() which adds generic DMA as Platform. And this Platform dev is using CPU dev. Without this patch, at least STM32MP15 audio sound card is no more functional (v5.13 or later). This patch respawn Platform Support on audio-graph again. Reported-by: Olivier MOYSAN <olivier.moysan(a)foss.st.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- This patch needs Olivier's Tested-by sound/soc/generic/audio-graph-card.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c index 5e71382467e8..546f6fd0609e 100644 --- a/sound/soc/generic/audio-graph-card.c +++ b/sound/soc/generic/audio-graph-card.c @@ -285,6 +285,7 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv *priv, if (li->cpu) { struct snd_soc_card *card = simple_priv_to_card(priv); struct snd_soc_dai_link_component *cpus = asoc_link_to_cpu(dai_link, 0); + struct snd_soc_dai_link_component *platforms = asoc_link_to_platform(dai_link, 0); int is_single_links = 0; /* Codec is dummy */ @@ -313,6 +314,7 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv *priv, dai_link->no_pcm = 1; asoc_simple_canonicalize_cpu(cpus, is_single_links); + asoc_simple_canonicalize_platform(platforms, cpus); } else { struct snd_soc_codec_conf *cconf = simple_props_to_codec_conf(dai_props, 0); struct snd_soc_dai_link_component *codecs = asoc_link_to_codec(dai_link, 0); @@ -366,6 +368,7 @@ static int graph_dai_link_of(struct asoc_simple_priv *priv, struct snd_soc_dai_link *dai_link = simple_priv_to_link(priv, li->link); struct snd_soc_dai_link_component *cpus = asoc_link_to_cpu(dai_link, 0); struct snd_soc_dai_link_component *codecs = asoc_link_to_codec(dai_link, 0); + struct snd_soc_dai_link_component *platforms = asoc_link_to_platform(dai_link, 0); char dai_name[64]; int ret, is_single_links = 0; @@ -383,6 +386,7 @@ static int graph_dai_link_of(struct asoc_simple_priv *priv, "%s-%s", cpus->dai_name, codecs->dai_name); asoc_simple_canonicalize_cpu(cpus, is_single_links); + asoc_simple_canonicalize_platform(platforms, cpus); ret = graph_link_init(priv, cpu_ep, codec_ep, li, dai_name); if (ret < 0) @@ -608,6 +612,7 @@ static int graph_count_noml(struct asoc_simple_priv *priv, li->num[li->link].cpus = 1; li->num[li->link].codecs = 1; + li->num[li->link].platforms = 1; li->link += 1; /* 1xCPU-Codec */ @@ -630,6 +635,7 @@ static int graph_count_dpcm(struct asoc_simple_priv *priv, if (li->cpu) { li->num[li->link].cpus = 1; + li->num[li->link].platforms = 1; li->link++; /* 1xCPU-dummy */ } else { -- 2.25.1

3 2