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

[PATCH treewide 00/11] ASoC: Clean up {hp,mic}-det-gpio handling
by Geert Uytterhoeven 09 Dec '24

09 Dec '24

Hi all, The "gpio" suffix for GPIO consumers was deprecated a while ago, in favor of the "gpios" suffix. However, there are still several users of the "hp-det-gpio" and "mic-det-gpio" properties, in DT bindings, drivers, and DT source files. Drivers that use gpiolib handle both the deprecated and new properties transparently, but that is not the case when using of_property_*() calls directly. - The first patch fixes a bug, as the Freescale Generic ASoC Sound driver handles only the deprecated properties, while there is already a user of the new variants, - The second patch updates the Audio Graph and Simple Audio Card DT bindings, - Patches 3-9 converts various DTS files to use the new properties, - The last 2 patches convert Freescale sound device nodes to use the new properties. All patches can be applied independently, except for the last two, which depend on the first patch to avoid regressions. This series was compile-tested only. Thanks for your comments! Geert Uytterhoeven (11): ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios ASoC: dt-bindings: Deprecate {hp,mic}-det-gpio ARM: dts: marvell: mmp2-olpc-xo-1-75: Switch to {hp,mic}-det-gpios arm64: dts: freescale: imx: Switch to simple-audio-card,hp-det-gpios arm64: dts: renesas: beacon-renesom: Switch to mic-det-gpios arm64: dts: rockchip: Switch to simple-audio-card,hp-det-gpios arm64: dts: rockchip: Switch to hp-det-gpios arm64: dts: uniphier: Switch to hp-det-gpios mips: dts: ingenic: Switch to simple-audio-card,hp-det-gpios ARM: dts: nxp: imx: Switch to {hp,mic}-det-gpios arm64: dts: freescale: imx: Switch to hp-det-gpios .../devicetree/bindings/sound/audio-graph.yaml | 6 ++++++ .../devicetree/bindings/sound/simple-card.yaml | 12 ++++++++++++ arch/arm/boot/dts/marvell/mmp2-olpc-xo-1-75.dts | 4 ++-- arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 4 ++-- arch/arm/boot/dts/nxp/imx/imx6sl-evk.dts | 2 +- arch/arm/boot/dts/nxp/imx/imx6sll-evk.dts | 2 +- arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 +- arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 2 +- arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 2 +- .../boot/dts/freescale/imx8mq-librem5-devkit.dts | 2 +- arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 2 +- arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 2 +- arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 2 +- arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 2 +- .../boot/dts/renesas/beacon-renesom-baseboard.dtsi | 2 +- .../boot/dts/rockchip/rk3326-anbernic-rg351m.dtsi | 2 +- .../arm64/boot/dts/rockchip/rk3326-gameforce-chi.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3326-odroid-go.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3368-lba3368.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399-roc-pc-plus.dts | 2 +- .../boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts | 2 +- .../boot/dts/rockchip/rk3399-rock-pi-4b-plus.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +- .../boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg-arc.dtsi | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg353p.dts | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg353ps.dts | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg353v.dts | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg353vs.dts | 2 +- .../boot/dts/rockchip/rk3566-anbernic-rg503.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 2 +- .../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts | 2 +- .../boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 2 +- .../boot/dts/rockchip/rk3588s-gameforce-ace.dts | 2 +- .../boot/dts/socionext/uniphier-ld11-global.dts | 2 +- .../boot/dts/socionext/uniphier-ld20-global.dts | 2 +- arch/mips/boot/dts/ingenic/gcw0.dts | 2 +- arch/mips/boot/dts/ingenic/rs90.dts | 2 +- sound/soc/fsl/fsl-asoc-card.c | 8 +++++--- 50 files changed, 72 insertions(+), 52 deletions(-) -- 2.34.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

8 30

[PATCH v2 0/3] ASoC: mediatek:mt8186: fix both the speaker and hdmi
by Jiaxin Yu 06 Dec '24

06 Dec '24

The speaker and hdmi of mt8186 platform are shared the same port of I2S, when connect the external display, use build-in speakers to play audio, they both playback at the same time. So we want to manage the playback device through DAPM events. Change since v1: Support audio function for it6505 bridge to hdmi-codec Jiaxin Yu (3): ASoC: hdmi-codec: Add event handler for hdmi TX ASoC: mediatek: mt8186: correct the HDMI widgets drm/bridge: it6505: Add audio support drivers/gpu/drm/bridge/ite-it6505.c | 81 +++++++++++++++++-- include/sound/hdmi-codec.h | 6 ++ sound/soc/codecs/hdmi-codec.c | 37 ++++++++- .../mt8186/mt8186-mt6366-da7219-max98357.c | 2 +- .../mt8186/mt8186-mt6366-rt1019-rt5682s.c | 2 +- 5 files changed, 116 insertions(+), 12 deletions(-) -- 2.18.0

3 16

[PATCH] ASoC: tas2781: Fix redundant logical jump
by Tang Bin 02 Dec '24

02 Dec '24

In these functions, some logical jump of "goto" and variable are redundant, thus remove them. Signed-off-by: Tang Bin <tangbin(a)cmss.chinamobile.com> --- sound/soc/codecs/tas2781-i2c.c | 68 +++++++++++++--------------------- 1 file changed, 25 insertions(+), 43 deletions(-) diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c index 68887799e..27f2f84a4 100644 --- a/sound/soc/codecs/tas2781-i2c.c +++ b/sound/soc/codecs/tas2781-i2c.c @@ -489,14 +489,11 @@ static int tas2563_calib_start_put(struct snd_kcontrol *kcontrol, struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol); struct tasdevice_priv *tas_priv = snd_soc_component_get_drvdata(comp); const int sum = ARRAY_SIZE(tas2563_cali_start_reg); - int rc = 1; int i, j; guard(mutex)(&tas_priv->codec_lock); - if (tas_priv->chip_id != TAS2563) { - rc = -1; - goto out; - } + if (tas_priv->chip_id != TAS2563) + return -1; for (i = 0; i < tas_priv->ndev; i++) { struct tasdevice *tasdev = tas_priv->tasdevice; @@ -523,8 +520,8 @@ static int tas2563_calib_start_put(struct snd_kcontrol *kcontrol, q[j].val, 4); } } -out: - return rc; + + return 1; } static void tas2563_calib_stop_put(struct tasdevice_priv *tas_priv) @@ -576,7 +573,7 @@ static int tasdev_cali_data_put(struct snd_kcontrol *kcontrol, struct cali_reg *p = &cali_data->cali_reg_array; unsigned char *src = ucontrol->value.bytes.data; unsigned char *dst = cali_data->data; - int rc = 1, i = 0; + int i = 0; int j; guard(mutex)(&priv->codec_lock); @@ -605,7 +602,7 @@ static int tasdev_cali_data_put(struct snd_kcontrol *kcontrol, i += 3; memcpy(dst, &src[i], cali_data->total_sz); - return rc; + return 1; } static int tas2781_latch_reg_get(struct snd_kcontrol *kcontrol, @@ -1115,25 +1112,21 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) char *conf_name, *prog_name; int nr_controls = 4; int mix_index = 0; - int ret; /* Alloc kcontrol via devm_kzalloc, which don't manually * free the kcontrol */ dsp_ctrls = devm_kcalloc(tas_priv->dev, nr_controls, sizeof(dsp_ctrls[0]), GFP_KERNEL); - if (!dsp_ctrls) { - ret = -ENOMEM; - goto out; - } + if (!dsp_ctrls) + return -ENOMEM; /* Create mixer items for selecting the active Program and Config */ prog_name = devm_kstrdup(tas_priv->dev, "Speaker Program Id", GFP_KERNEL); - if (!prog_name) { - ret = -ENOMEM; - goto out; - } + if (!prog_name) + return -ENOMEM; + dsp_ctrls[mix_index].name = prog_name; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_programs; @@ -1143,10 +1136,9 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) conf_name = devm_kstrdup(tas_priv->dev, "Speaker Config Id", GFP_KERNEL); - if (!conf_name) { - ret = -ENOMEM; - goto out; - } + if (!conf_name) + return -ENOMEM; + dsp_ctrls[mix_index].name = conf_name; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_configurations; @@ -1156,10 +1148,9 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) active_dev_num = devm_kstrdup(tas_priv->dev, "Activate Tasdevice Num", GFP_KERNEL); - if (!active_dev_num) { - ret = -ENOMEM; - goto out; - } + if (!active_dev_num) + return -ENOMEM; + dsp_ctrls[mix_index].name = active_dev_num; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_active_num; @@ -1168,21 +1159,17 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) mix_index++; chip_id = devm_kstrdup(tas_priv->dev, "Tasdevice Chip Id", GFP_KERNEL); - if (!chip_id) { - ret = -ENOMEM; - goto out; - } + if (!chip_id) + return -ENOMEM; + dsp_ctrls[mix_index].name = chip_id; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_chip_id; dsp_ctrls[mix_index].get = tasdevice_get_chip_id; mix_index++; - ret = snd_soc_add_component_controls(tas_priv->codec, dsp_ctrls, + return snd_soc_add_component_controls(tas_priv->codec, dsp_ctrls, nr_controls < mix_index ? nr_controls : mix_index); - -out: - return ret; } static int tasdevice_create_cali_ctrls(struct tasdevice_priv *priv) @@ -1469,7 +1456,6 @@ static int tasdevice_hw_params(struct snd_pcm_substream *substream, unsigned int slot_width; unsigned int fsrate; int bclk_rate; - int rc = 0; fsrate = params_rate(params); switch (fsrate) { @@ -1479,8 +1465,7 @@ static int tasdevice_hw_params(struct snd_pcm_substream *substream, default: dev_err(tas_priv->dev, "%s: incorrect sample rate = %u\n", __func__, fsrate); - rc = -EINVAL; - goto out; + return -EINVAL; } slot_width = params_width(params); @@ -1493,20 +1478,17 @@ static int tasdevice_hw_params(struct snd_pcm_substream *substream, default: dev_err(tas_priv->dev, "%s: incorrect slot width = %u\n", __func__, slot_width); - rc = -EINVAL; - goto out; + return -EINVAL; } bclk_rate = snd_soc_params_to_bclk(params); if (bclk_rate < 0) { dev_err(tas_priv->dev, "%s: incorrect bclk rate = %d\n", __func__, bclk_rate); - rc = bclk_rate; - goto out; + return bclk_rate; } -out: - return rc; + return 0; } static int tasdevice_set_dai_sysclk(struct snd_soc_dai *codec_dai, -- 2.33.0

3 2

[RFC PATCH 0/2] Add support for stacked and parallel memories
by Amit Kumar Mahapatra 25 Nov '24

25 Nov '24

Hello Everyone, Following an email discussion with Miquel regarding the binding changes and overall architecture for implementing support for stacked and parallel memories, I’m sharing this RFC to initiate a discussion on the proposed updates to current bindings and to finalize the implementation architecture. Before diving into the main topic, here is some background on stacked and parallel memories. The AMD QSPI controller supports two advanced connection modes(Stacked and Parallel) which allow the controller to treat two different flashes as one storage. Stacked: Flashes share the same SPI bus, but different CS line, controller driver asserts the CS of the flash to which it needs to communicate. Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the core needs to split it into two separate operations and adjust the data length accordingly. Parallel(Multi-CS): Both the flashes have their separate SPI bus, CS of both the flashes will be asserted/de-asserted at the same time. In this mode data will be split across both the flashes by enabling the STRIPE setting in the controller. Parallel mode is a controller feature where if the STRIPE bit is set then the controller internally handles the data split during data write to the flashes and while reading data from the flash the controller internally merges data from both the flashes before writing to the controller FIFO. If STRIPE is not enabled, then same data will be sent to both the devices. In parallel mode both the flashes should be identical. For more information on the modes please feel free to go through the controller flash interface below [1]. Mirochip QSPI controller[2] also supports "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode". Initially in [3] [4] [5] Miquel had tried to extend MTD-CONCAT driver to support Stacked mode, but the bindings were not accepted. So, the MTD-CONCAT approach was dropped and the DT bindings that got accepted [6] [7] [8] that describes the two flash devices as being one. SPI core changes to support the above bindings were added [9]. While adding the support in SPI-NOR Tudor provided additional feedback, leading to a discussion on updating the current stacked and parallel DT bindings. Proposed Solution: The solution has two parts: 1. Update MTD-CONCAT Update MTD-CONCAT to create virtual concatinated mtd devices as defined in the device tree. 2. Add a New Layer Add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of spi-nor, located in mtd/spi-nor/, can be included/excluded via Kconfig, will be maintained by AMD and will: - During probing, store information from all connected flashes in stacked or parallel mode and present them as a single device to the MTD layer. - Register callbacks and manage MTD device registration within the new layer instead of spi-nor/core.c. - Make minimal changes in spi-nor/core.c, as stacked and parallel handling will be managed by the new layer on top of SPI-NOR. - Handle odd byte count requests from the MTD layer during flash operations in parallel mode. [1] https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interf… [2] https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDoc… [3] https://lore.kernel.org/all/20191113171505.26128-4-miquel.raynal@bootlin.co… [4] https://lore.kernel.org/all/20191127105522.31445-5-miquel.raynal@bootlin.co… [5]https://lore.kernel.org/all/20211112152411.818321-1-miquel.raynal@bootlin… [6] https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592ac… [7] https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014ea… [8] https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2a9… [9]https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e… Thanks, Amit Amit Kumar Mahapatra (2): dt-bindings: mtd: Add bindings for describing concatinated MTD devices dt-bindings: spi: Update stacked and parallel bindings .../mtd/partitions/fixed-partitions.yaml | 18 +++++++++++++++ .../bindings/mtd/partitions/partitions.yaml | 6 +++++ .../bindings/spi/spi-controller.yaml | 23 +++++++++++++++++-- .../bindings/spi/spi-peripheral-props.yaml | 9 +++----- 4 files changed, 48 insertions(+), 8 deletions(-) -- 2.34.1

6 15

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

ASoC Kernel 6.1: Query regarding dynamic dai link/dapm registration during bootup
by Shalini Manjunatha (Consultant) (QUIC) 08 Nov '24

08 Nov '24

Hi All, On kernel6.1 based Qualcomm target for automotive platform based on Android U, we have a feature early services to launch certain early apps at early init of android bootup cycle. Hence in order to launch early chime sound of audio at early init of android boot up cycle, we need to load all required audio kernel modules at early init stage in order to get sound card registered. We have certain KPI goals for every early apps to get completed within lesser duration so that we can achieve final KPI goal of android boot complete as per the target specification. In this journey, while optimizing the sound card registration through machine driver probe to achieve lower KPI for audio early chime sound, we find that for early chime launch we required only selected pcm front end dai links only. Hence if we keep FE dai link structure in our machine driver with only required items for early chime, overall sound card registrations gets completed within 200msec from the time it starts, which is a very good KPI number to achieve. So we were trying out code change to split overall FE dai link structure into two, one for early chime and another for all other required dai link's, then some how we need to register early chime related dai link during early init so that sound card registration process gets completed quickly, later stage we want to dynamically load all other FE dai links. Could you please help us to suggest on how can we achieve this?. Is there any possible way out to avoid static FE dai link registration for all required ones from machine driver during machine driver probe, instead register only limited list of dai links. Later can we dynamically register the dai links in order to get PCM devices entries created based on use case. Currently we have this API devm_snd_soc_register_card() being called with snd_soc_card parameter which has all possible FE dai links populated at once. Queries: 1) can we register sound card twice during bootup, once with limited dai links and next with all required ones? 2) can we register dai links/dapm dynamically based on use case requriement? 3) If it is possible, could you share any reference from any other vendor who is able to achieve the same?. Regards, Shalini M

3 3

[PATCH 0/8] ASoC: cleasnup rtd and its ID
by Kuninori Morimoto 05 Nov '24

05 Nov '24

Hi Mark rtd has own ID, but it is naming "num" for it. The naming is confusable. This patch rename it to "id". And many functions request both "rtd" and its "id" as function parameter, but rtd itself has rtd->id. This patch cleanup it. And, Qcom driver want to use irregular rtd ID because of its topology, and thus, soc-core need irregular calculation. I'm not sure why only Qcom needs such calculation, but this patch also cleanup it. But I guess we want to cleanup is not soc-core but Qcom side (?) Kuninori Morimoto (8): ASoC: rename rtd->num to rtd->id ASoC: fsl: switch to use rtd->id from rtd->num ASoC: meson: switch to use rtd->id from rtd->num ASoC: sh: switch to use rtd->id from rtd->num ASoC: generic: switch to use rtd->id from rtd->num ASoC: remove rtd->num ASoC: soc-core: do rtd->id trick at snd_soc_add_pcm_runtime() ASoC: cleanup function parameter for rtd and its id include/sound/soc-dai.h | 5 ++- include/sound/soc.h | 8 ++--- sound/soc/fsl/imx-card.c | 6 ++-- sound/soc/generic/simple-card-utils.c | 10 +++--- sound/soc/meson/axg-card.c | 6 ++-- sound/soc/meson/gx-card.c | 2 +- sound/soc/sh/rcar/core.c | 2 +- sound/soc/soc-compress.c | 9 +++-- sound/soc/soc-core.c | 50 +++++++++++++++------------ sound/soc/soc-dai.c | 4 +-- sound/soc/soc-pcm.c | 16 ++++----- 11 files changed, 60 insertions(+), 58 deletions(-) -- 2.43.0

3 11

[PATCH] ASoC: codecs: ES8326: Reduce pop noise
by Zhang Yi 05 Nov '24

05 Nov '24

We modify the value of ES8326_ANA_MICBIAS to reduce the pop noise Signed-off-by: Zhang Yi <zhangyi(a)everest-semi.com> --- sound/soc/codecs/es8326.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/es8326.c b/sound/soc/codecs/es8326.c index aa3e364827c8..a5603b617688 100755 --- a/sound/soc/codecs/es8326.c +++ b/sound/soc/codecs/es8326.c @@ -616,7 +616,7 @@ static int es8326_mute(struct snd_soc_dai *dai, int mute, int direction) 0x0F, 0x0F); if (es8326->version > ES8326_VERSION_B) { regmap_update_bits(es8326->regmap, ES8326_VMIDSEL, 0x40, 0x40); - regmap_update_bits(es8326->regmap, ES8326_ANA_MICBIAS, 0x70, 0x00); + regmap_update_bits(es8326->regmap, ES8326_ANA_MICBIAS, 0x70, 0x10); } } } else { @@ -1082,7 +1082,7 @@ static void es8326_init(struct snd_soc_component *component) regmap_write(es8326->regmap, ES8326_ADC2_SRC, 0x66); es8326_disable_micbias(es8326->component); if (es8326->version > ES8326_VERSION_B) { - regmap_update_bits(es8326->regmap, ES8326_ANA_MICBIAS, 0x73, 0x03); + regmap_update_bits(es8326->regmap, ES8326_ANA_MICBIAS, 0x73, 0x13); regmap_update_bits(es8326->regmap, ES8326_VMIDSEL, 0x40, 0x40); } -- 2.17.1

2 1

Add support for ASRock X870E Taichi
by GitHub pull_request - opened 31 Oct '24

31 Oct '24

alsa-project/alsa-ucm-conf pull request #457 was opened from julmajustus: Included id 26ce:0a0b to realtek-alc4080 list. USB Audio S/PDIF Output, USB Audio Rear input and USB Audio Front Headphones seems to work now without issues with HiFi 2.0 channels. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/457 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/457.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Direct MIDI event delivery to ALSA sequencer's hardware port without any connections/subscriptions fails with -ENODEV.
by giedrius＠blokas.io 31 Oct '24

31 Oct '24

Hello, I had written an `aseqsend` utility to send MIDI events from hex strings to ALSA sequencer ports, similar to the -S arg of `amidi`, but I just noticed that while sending events directly to application ALSA Sequencer ports works just fine, trying to send to a hardware MIDI port fails with -19 (-ENODEV). Here's the aseqsend utility code, the highlighted line is the one returning -ENODEV: https://github.com/BlokasLabs/aseqsend/blob/main/aseqsend.c#L173 Here's some sample commands showcasing the problem (I've added a printf with drain result just after the indicated line above locally): https://paste.debian.net/hidden/9690d660/ It shows that in case there's no active subscriptions to the port, the event delivery fails, with no data ever reaching the hardware device. As long as there's at least one subscription to the port, it works ok. I've reproduced this on 5.15.36-rt41-v7+ and 6.6.58-v8-16k (running on Raspberry Pi, based on https://github.com/raspberrypi/linux) I've traced the -ENODEV to be returned at this location: https://elixir.bootlin.com/linux/v6.6.58/source/sound/core/seq/seq_midi.c#L… Whenever there's a subscription, the 'substream' is not NULL. But what I would naturally expect is for the events to get delivered to the hardware port when using direct addressing, regardless of its subscription status, the same way how it's possible to send events to application aseq ports: -- Terminal 1 -- patch@patchbox:~ $ aseqdump Waiting for data at port 128:0. Press Ctrl+C to end. Source Event Ch Data 129:0 Note on 0, note 64, velocity 48 -- Terminal 2 -- patch@patchbox:~/work/aseqsend $ ./aseqsend 128:0 90 40 30 drain: 0 Is this a bug in ALSA Sequencer, or is my expectation of being able to write directly to a hardware ALSA sequencer port incorrect?

3 3