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

[PATCH] ASoC: dt-bindings: Convert dmic-codec to DT schema
by Rob Herring 24 Oct '22

24 Oct '22

Convert the dmic-codec binding to DT schema format. The '#sound-dai-cells' and 'sound-name-prefix' properties were not documented, but are in use, so add them. Signed-off-by: Rob Herring <robh(a)kernel.org> --- .../devicetree/bindings/sound/dmic-codec.yaml | 55 +++++++++++++++++++ .../devicetree/bindings/sound/dmic.txt | 22 -------- 2 files changed, 55 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/dmic-codec.yaml delete mode 100644 Documentation/devicetree/bindings/sound/dmic.txt diff --git a/Documentation/devicetree/bindings/sound/dmic-codec.yaml b/Documentation/devicetree/bindings/sound/dmic-codec.yaml new file mode 100644 index 000000000000..767152fa99cc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/dmic-codec.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/dmic-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic PDM Digital microphone (DMIC) codec + +maintainers: + - Arnaud Pouliquen <arnaud.pouliquen(a)st.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + compatible: + const: dmic-codec + + '#sound-dai-cells': + const: 0 + + dmicen-gpios: + description: GPIO specifier for DMIC to control start and stop + maxItems: 1 + + num-channels: + description: Number of microphones on this DAI + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 8 + default: 8 + + modeswitch-delay-ms: + description: Delay (in ms) to complete DMIC mode switch + + wakeup-delay-ms: + description: Delay (in ms) after enabling the DMIC + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio.h> + + dmic { + compatible = "dmic-codec"; + dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>; + num-channels = <1>; + wakeup-delay-ms <50>; + modeswitch-delay-ms <35>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/dmic.txt b/Documentation/devicetree/bindings/sound/dmic.txt deleted file mode 100644 index 32e871037269..000000000000 --- a/Documentation/devicetree/bindings/sound/dmic.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device-Tree bindings for Digital microphone (DMIC) codec - -This device support generic PDM digital microphone. - -Required properties: - - compatible: should be "dmic-codec". - -Optional properties: - - dmicen-gpios: GPIO specifier for dmic to control start and stop - - num-channels: Number of microphones on this DAI - - wakeup-delay-ms: Delay (in ms) after enabling the DMIC - - modeswitch-delay-ms: Delay (in ms) to complete DMIC mode switch - -Example node: - - dmic_codec: dmic@0 { - compatible = "dmic-codec"; - dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>; - num-channels = <1>; - wakeup-delay-ms <50>; - modeswitch-delay-ms <35>; - }; -- 2.35.1

3 3

[PATCH v5 0/9] ASoC: cleanups and improvements for jz4740-i2s
by Aidan MacDonald 23 Oct '22

23 Oct '22

This series is a preparatory cleanup of the jz4740-i2s driver before adding support for a new SoC. The two improvements are lifting unnecessary restrictions on sample rates and formats -- the existing ones appear to be derived from the limitations of the JZ4740's internal codec and don't reflect the actual capabilities of the I2S controller. I'm unable to test the series on any JZ47xx SoCs, but I have tested on an X1000 (which is the SoC I'll be adding in a followup series). Changes in v5: * Drop 'mem' resource removal patch already upstream. * Update FIFO flush bits fix to address Paul's review comments. * Drop PLL clock name patch, that needs a different approach. Link for v4: URLHERE Aidan MacDonald (9): ASoC: jz4740-i2s: Handle independent FIFO flush bits ASoC: jz4740-i2s: Convert to regmap API ASoC: jz4740-i2s: Simplify using regmap fields ASoC: jz4740-i2s: Use FIELD_PREP() macros in hw_params callback ASoC: jz4740-i2s: Align macro values and sort includes ASoC: jz4740-i2s: Support S20_LE and S24_LE sample formats ASoC: jz4740-i2s: Support continuous sample rate ASoC: jz4740-i2s: Move component functions near the component driver ASoC: jz4740-i2s: Refactor DAI probe/remove ops as component ops sound/soc/jz4740/Kconfig | 1 + sound/soc/jz4740/jz4740-i2s.c | 455 ++++++++++++++++++---------------- 2 files changed, 243 insertions(+), 213 deletions(-) -- 2.38.1

2 14

[PATCH] ALSA: hda/realtek: Add another HP ZBook G9 model quirks
by Takashi Iwai 22 Oct '22

22 Oct '22

HP ZBook Firefly 16 G9 (103c:896d) and HP ZBook Power 15.6 G9 (103c:89c0) require the same quirk for enabling CS35L41 speaker amps. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9945861f02ef..701a72ec5629 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9323,6 +9323,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8898, "HP EliteBook 845 G8 Notebook PC", ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x103c, 0x88d0, "HP Pavilion 15-eh1xxx (mainboard 88D0)", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8902, "HP OMEN 16", ALC285_FIXUP_HP_MUTE_LED), + SND_PCI_QUIRK(0x103c, 0x896d, "HP ZBook Firefly 16 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x896e, "HP EliteBook x360 830 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8971, "HP EliteBook 830 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8972, "HP EliteBook 840 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), @@ -9341,6 +9342,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x89aa, "HP EliteBook 630 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ac, "HP EliteBook 640 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ae, "HP EliteBook 650 G9", ALC236_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x89c0, "HP ZBook Power 15.6 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89c3, "Zbook Studio G9", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89c6, "Zbook Fury 17 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ca, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), -- 2.35.3

1 0

Using snd_device_name_hint() with iface "card"
by GitHub issues - edited 22 Oct '22

22 Oct '22

alsa-project/alsa-lib issue #277 was edited from MathisMARION: Hello, I have been experimenting with the `alsa` library, and I tried to use the `snd_device_name_hint()` function to print information about devices. It doesn't seem documented [here](https://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html) so I looked up for examples online, and explored the source code as well. Looking at the [source code](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name…, it seems like the function should be able to take `"card"` as a valid interface. However when I run this function, it returns `ENOENT`. I ran my program with `gdb` and found that [this call](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name… to `add_card()` was returning the error. `add_card` calls `snd_config_search` which loops through a list to find a match. In my case I found out that the list contained `"cards"` (with an `s`), while the code was searching for `"card"` so I am left wondering if this was done on purpose. Moreover I can get info about my sound cards using `/proc/asound/cards` (with an `s` again) so it makes me doubt even more... I am running Ubuntu 20.04.5, and have installed `libasound2-dev` version `1.2.2-2.1ubuntu2.5`. I can give more info about my setup if needed, I am just unsure what other info would help as of right now. Here's a simple program reproducing my issue: ```c #include <alsa/asoundlib.h> #include <stdio.h> int main() { void **hints; int ret; ret = snd_device_name_hint(-1, "card", &hints); if (ret) { printf("snd_device_name_hint: %s\n", snd_strerror(ret)); return EXIT_FAILURE; } snd_device_name_free_hint(hints); return EXIT_SUCCESS; } ``` ``` snd_device_name_hint: No such file or directory ``` Putting `"cards"` instead results in `EINVAL`: ``` snd_device_name_hint: Invalid argument ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/277 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Using snd_device_name_hint() with iface "card"
by GitHub issues - edited 22 Oct '22

22 Oct '22

alsa-project/alsa-lib issue #277 was edited from MathisMARION: Hello, I have been experimenting with the `alsa` library, and I tried to use the `snd_device_name_hint()` function to print information about devices. It doesn't seem documented [here](https://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html) so I looked up for examples online, and explored the source code as well. Looking at the [source code](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name…, it seems like the function should be able to take `"card"` as a valid interface. However when I run this function, it returns `ENOENT`. I ran my program with `gdb` and found that [this call](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name… to `add_card()` was returning the error. `add_card` calls `snd_config_search` which loops through a list to find a match. In my case I found out that the list contained `"cards"` (with an `s`), while the code was searching for `"card"` so I am left wondering if this was done on purpose. Moreover I can get info about my sound cards using `/proc/asound/cards` (with an `s` again) so it makes me doubt even more... I am running Ubuntu 20.04.5, and have installed `libasound2-dev` version `1.2.2-2.1ubuntu2.5`. I can give more info about my setup if needed, I am just unsure what other info would help as of right now. Here's a simple program reproducing my issue: ```c #include <alsa/asoundlib.h> #include <stdio.h> int main() { void **hints; int ret; ret = snd_device_name_hint(-1, "card", &hints); if (ret) { printf("snd_device_name_hint: %s\n", snd_strerror(ret)); return EXIT_FAILURE; } snd_device_name_free_hint(hints); return EXIT_SUCCESS; } ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/277 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Using snd_device_name_hint() with iface "card"
by GitHub issues - opened 22 Oct '22

22 Oct '22

alsa-project/alsa-lib issue #277 was opened from MathisMARION: Hello, I have been experimenting with the `alsa` library, and I tried to use the `snd_device_name_hint()` function to print information about devices. It doesn't seem documented [here](https://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html) so I looked up for examples online, and explored the source code as well. Looking at the [source code](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name…, it seems like the function should be able to take `"card"` as a valid interface. However when I run this function, it returns `ENOENT`. I ran my program with `gdb` and found that [this call](https://github.com/alsa-project/alsa-lib/blob/master/src/control/name… to `add_card()` was returning the error. `add_card` calls `snd_config_search` which loops through a list to find a match. In my case I found out that the list contained `"cards"` (with an `s`), while the code was searching for `"card"` so I am left wondering if this was done on purpose. Moreover I can get info about my sound cards using `/proc/asound/cards` (with an `s` again) so it makes me doubt even more... I am running Ubuntu 20.04.5, and have installed `libasound2-dev` version `1.2.2-2.1ubuntu2.5`. I can give more info about my setup if needed, I am just unsure what other info would help as of right now. Issue URL : https://github.com/alsa-project/alsa-lib/issues/277 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v2 00/19] ASoC: SOF: Intel/IPC4: Support for external firmware libraries
by Peter Ujfalusi 21 Oct '22

21 Oct '22

Hi, Changes since v1: - rebased on "[PATCH v2] ASoC: SOF: Intel: pci-tgl: fix ADL-N descriptor" Cover letter: In IPC4 all DSP loadable executable is a 'library' containing modules. The main or basefw is also a library which contains multiple modules. IPC4 allows to use loadable libraries to extend the functionality of the booted basefw. This series adds support for loading external libraries in case they are needed by the loaded topology file. The libraries must be placed to a specific firmware directory (fw_lib_prefix), which is: intel/avs-lib|sof-ipc4-lib/ followed by the platform name and in case of community key use a 'community' directory. For example for upx-i11 (community key): intel/avs-lib/tgl/community is the default path. The name of the library should be the UUID of the module it contains since the library loading is going to look for the file as <module_UUID>.bin In case there is a need to bundle multiple modules into single library, symlinks can be used to point to the file: module_boundle.bin <UUID1>.bin -> module_boundle.bin <UUID2>.bin -> module_boundle.bin <UUID3>.bin -> module_boundle.bin But note that in this case all modules will be loaded to the DSP since only the whole library can be loaded, not individual modules. Regards, Peter --- Peter Ujfalusi (18): ASoC: SOF: Introduce container struct for SOF firmware ASoC: SOF: amd: Use the basefw firmware container directly ASoC: SOF: Intel: hda-loader: Use the basefw firmware container directly ASoC: SOF: Intel: hda-loader-skl: Use the basefw firmware container directly ASoC: SOF: Drop the firmware and fw_offset from snd_sof_pdata ASoC: SOF: ipc: ops: Add support for optional init and exit callbacks ASoC: SOF: ipc4-loader: Save the maximum number of libraries supported ASoC: SOF: ipc4: Convert the firmware handling (loader) to library convention ASoC: SOF: IPC4: Add helper for looking up module by UUID ASoC: SOF: Add path definition for external firmware libraries ASoC: SOF: Intel: Set the default firmware library path for IPC4 ASoC: SOF: ipc4: Define platform dependent library loading callback ASoC: SOF: Intel: hda: Add flag to indicate that the firmware is IMR booted ASoC: SOF: Intel: Add ipc4 library loading implementation ASoC: SOF: loader: Add support for IPC dependent post firmware boot ops ASoC: SOF: ipc4: Stop using the query_fw_configuration fw_loader ops ASoC: SOF: loader: Remove the query_fw_configuration ops ASoC: SOF: ipc4-loader: Support for loading external libraries Ranjani Sridharan (1): ASoC: SOF: loader: Set complete state before post_fw_run op include/sound/sof.h | 10 +- include/sound/sof/ipc4/header.h | 4 + sound/soc/sof/amd/acp-loader.c | 6 +- sound/soc/sof/intel/apl.c | 3 + sound/soc/sof/intel/cnl.c | 3 + sound/soc/sof/intel/hda-loader-skl.c | 7 +- sound/soc/sof/intel/hda-loader.c | 83 +++++++++- sound/soc/sof/intel/hda.h | 4 + sound/soc/sof/intel/icl.c | 3 + sound/soc/sof/intel/mtl.c | 3 + sound/soc/sof/intel/pci-apl.c | 6 + sound/soc/sof/intel/pci-cnl.c | 9 ++ sound/soc/sof/intel/pci-icl.c | 6 + sound/soc/sof/intel/pci-mtl.c | 3 + sound/soc/sof/intel/pci-tgl.c | 24 +++ sound/soc/sof/intel/tgl.c | 3 + sound/soc/sof/ipc.c | 6 + sound/soc/sof/ipc3-loader.c | 26 ++- sound/soc/sof/ipc4-loader.c | 233 ++++++++++++++++++++++++--- sound/soc/sof/ipc4-priv.h | 65 ++++++-- sound/soc/sof/ipc4-topology.c | 17 +- sound/soc/sof/ipc4.c | 41 +++++ sound/soc/sof/loader.c | 25 ++- sound/soc/sof/sof-pci-dev.c | 26 +++ sound/soc/sof/sof-priv.h | 27 +++- 25 files changed, 543 insertions(+), 100 deletions(-) -- 2.38.1

3 21

alsactl restore udev rule failing
by GitHub issues - edited 21 Oct '22

21 Oct '22

alsa-project/alsa-utils issue #175 was edited from rnhmjoj: It seems the udev rule to restore card settings is always failing during the boot: ``` $ journalctl -u systemd-udevd -b -o cat --grep alsa controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC1: Process '/sbin/alsactl restore 1' failed with exit code 99. controlC0: Process '/sbin/alsactl restore 0' failed with exit code 99. ``` I checked and made sure the file system is mounted and /var/lib/asound.state is ok by the time the rule runs. I guess the issue could be the hardware is not yet fully initialised. Somehow the settings of card 0 (HDA Intel PCH) are restored anyway, but not those of card 1 (HDA ATI HDMI). Manually running `alsactl restore 2` later works, albeit partially (some softvol controls are never recovered). Issue URL : https://github.com/alsa-project/alsa-utils/issues/175 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

alsactl restore udev rule failing
by GitHub issues - edited 21 Oct '22

21 Oct '22

alsa-project/alsa-utils issue #175 was edited from rnhmjoj: It seems the udev rule to restore card settings is always failing during the boot: ``` $ journalctl -u systemd-udevd -b -o cat --grep alsa controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC1: Process '/sbin/alsactl restore 1' failed with exit code 99. controlC0: Process '/sbin/alsactl restore 0' failed with exit code 99. ``` I checked and made sure the file system is mounted and /var/lib/asound.state is ok by the time the rule runs. I guess the issue could be the hardware is not yet fully initialised. Somehow the settings of card 0 (HDA Intel PCH) are restored anyway, but not those of card 2 (HDA ATI HDMI). Manually running `alsactl restore 2` later works, albeit partially (some softvol controls are never recovered). Issue URL : https://github.com/alsa-project/alsa-utils/issues/175 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

alsactl restore udev rule failing
by GitHub issues - opened 21 Oct '22

21 Oct '22

alsa-project/alsa-utils issue #175 was opened from rnhmjoj: It seems the udev rule to restore card settings is always failing during the boot: ``` $ journalctl -u systemd-udevd -b -o cat --grep alsa controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC2: Process '/sbin/alsactl restore 2' failed with exit code 99. controlC1: Process '/sbin/alsactl restore 1' failed with exit code 99. controlC0: Process '/sbin/alsactl restore 0' failed with exit code 99. ``` I checked and made sure the file system is mounted and /var/lib/asound.state is ok by the time the rule runs. I guess the issue could be the hardware is not yet fully initialised. Somehow the settings of card 0 (HDA Intel PCH) are restored anyway, but not those of card 2 (HDA ATI HDMI). Manually running `alsactl restore 2` later works, albeit partially (some softvol controls are never recovered). Issue URL : https://github.com/alsa-project/alsa-utils/issues/175 Repository URL: https://github.com/alsa-project/alsa-utils

1 0