July 2023 - Alsa-devel - mailman.alsa-project.org

[RFC] ASoC: fsl_sai: Do not set MCTL_MCLK_EN based on the number of registers
by Fabio Estevam 06 Jul '23

06 Jul '23

From: Fabio Estevam <festevam(a)denx.de> Since commit ff87d619ac18 ("ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode") Andreas reports that on an i.MX8MP-based system where MCLK needs to be an input, the MCLK pin is actually an output, despite not having the 'fsl,sai-mclk-direction-output' property present in the devicetree. This commit explains the following: "On i.MX8MM, the MCTL_MCLK_EN bit it is not only the gate for MCLK output to PAD, but also the gate bit between root clock and SAI module, So it is need to be enabled for master mode, otherwise there is no bclk generated." Currently, the decision of using MCTL_MCLK_EN as a clock gate is based on the number of SAI registers present on a platform. This is fragile as it causes issues on i.MX8MP, for example. Fix the problem by introducing a new boolean mclk_en_gates_clock member in the fsl_sai_soc_data structure that indicates that the MCTL_MCLK_EN bit also acts as a gate between the root clock and the SAI block. This allows i.MX8MM to turn on FSL_SAI_MCTL_MCLK_EN as intended and other SoCs such as i.MX8MP can still use MCLK as input. Fixes: ff87d619ac18 ("ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode") Reported-by: Andreas Henriksson <andreas(a)fatal.se> Signed-off-by: Fabio Estevam <festevam(a)denx.de> Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Hi Shengjiu, Is imx8mm the only SoC that needs mclk_en_gates_clock = true? What about imx8mn and imx93? sound/soc/fsl/fsl_sai.c | 12 +++++++++++- sound/soc/fsl/fsl_sai.h | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index 5e09f634c61b..e4dc6964f011 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -507,7 +507,7 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) savediv / 2 - 1); } - if (sai->soc_data->max_register >= FSL_SAI_MCTL) { + if (sai->soc_data->mclk_en_gates_clock) { /* SAI is in master mode at this point, so enable MCLK */ regmap_update_bits(sai->regmap, FSL_SAI_MCTL, FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN); @@ -1513,6 +1513,7 @@ static const struct fsl_sai_soc_data fsl_sai_vf610_data = { .reg_offset = 0, .mclk0_is_mclk1 = false, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RMR, }; @@ -1524,6 +1525,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx6sx_data = { .reg_offset = 0, .mclk0_is_mclk1 = true, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RMR, }; @@ -1535,6 +1537,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx7ulp_data = { .reg_offset = 8, .mclk0_is_mclk1 = false, .flags = PMQOS_CPU_LATENCY, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RMR, }; @@ -1546,6 +1549,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mq_data = { .reg_offset = 8, .mclk0_is_mclk1 = false, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RMR, }; @@ -1557,6 +1561,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8qm_data = { .reg_offset = 0, .mclk0_is_mclk1 = false, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RMR, }; @@ -1568,6 +1573,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mm_data = { .mclk0_is_mclk1 = false, .pins = 8, .flags = 0, + .mclk_en_gates_clock = true, .max_register = FSL_SAI_MCTL, }; @@ -1579,6 +1585,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mn_data = { .mclk0_is_mclk1 = false, .pins = 8, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_MDIV, }; @@ -1590,6 +1597,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mp_data = { .mclk0_is_mclk1 = false, .pins = 8, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_MDIV, .mclk_with_tere = true, }; @@ -1602,6 +1610,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8ulp_data = { .mclk0_is_mclk1 = false, .pins = 4, .flags = PMQOS_CPU_LATENCY, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_RTCAP, }; @@ -1613,6 +1622,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx93_data = { .mclk0_is_mclk1 = false, .pins = 4, .flags = 0, + .mclk_en_gates_clock = false, .max_register = FSL_SAI_MCTL, .max_burst = {8, 8}, }; diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h index 8254c3547b87..473260b0fbea 100644 --- a/sound/soc/fsl/fsl_sai.h +++ b/sound/soc/fsl/fsl_sai.h @@ -232,6 +232,7 @@ struct fsl_sai_soc_data { bool use_edma; bool mclk0_is_mclk1; bool mclk_with_tere; + bool mclk_en_gates_clock; unsigned int fifo_depth; unsigned int pins; unsigned int reg_offset; -- 2.34.1

1 1

[PATCH] ALSA: jack: Fix mutex call in snd_jack_report()
by Takashi Iwai 06 Jul '23

06 Jul '23

snd_jack_report() is supposed to be callable from an IRQ context, too, and it's indeed used in that way from virtsnd driver. The fix for input_dev race in commit 1b6a6fc5280e ("ALSA: jack: Access input_dev under mutex"), however, introduced a mutex lock in snd_jack_report(), and this resulted in a potential sleep-in-atomic. For addressing that problem, this patch changes the relevant code to use the object get/put and removes the mutex usage. That is, snd_jack_report(), it takes input_get_device() and leaves with input_put_device() for assuring the input_dev being assigned. Although the whole mutex could be reduced, we keep it because it can be still a protection for potential races between creation and deletion. Fixes: 1b6a6fc5280e ("ALSA: jack: Access input_dev under mutex") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/cf95f7fe-a748-4990-8378-000491b40329@moroto.mount… Tested-by: Amadeusz Sławiński <amadeuszx.slawinski(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/jack.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/sound/core/jack.c b/sound/core/jack.c index 88493cc31914..03d155ed362b 100644 --- a/sound/core/jack.c +++ b/sound/core/jack.c @@ -654,6 +654,7 @@ void snd_jack_report(struct snd_jack *jack, int status) struct snd_jack_kctl *jack_kctl; unsigned int mask_bits = 0; #ifdef CONFIG_SND_JACK_INPUT_DEV + struct input_dev *idev; int i; #endif @@ -670,17 +671,15 @@ void snd_jack_report(struct snd_jack *jack, int status) status & jack_kctl->mask_bits); #ifdef CONFIG_SND_JACK_INPUT_DEV - mutex_lock(&jack->input_dev_lock); - if (!jack->input_dev) { - mutex_unlock(&jack->input_dev_lock); + idev = input_get_device(jack->input_dev); + if (!idev) return; - } for (i = 0; i < ARRAY_SIZE(jack->key); i++) { int testbit = ((SND_JACK_BTN_0 >> i) & ~mask_bits); if (jack->type & testbit) - input_report_key(jack->input_dev, jack->key[i], + input_report_key(idev, jack->key[i], status & testbit); } @@ -688,13 +687,13 @@ void snd_jack_report(struct snd_jack *jack, int status) int testbit = ((1 << i) & ~mask_bits); if (jack->type & testbit) - input_report_switch(jack->input_dev, + input_report_switch(idev, jack_switch_types[i], status & testbit); } - input_sync(jack->input_dev); - mutex_unlock(&jack->input_dev_lock); + input_sync(idev); + input_put_device(idev); #endif /* CONFIG_SND_JACK_INPUT_DEV */ } EXPORT_SYMBOL(snd_jack_report); -- 2.35.3

1 0

[bug report] ALSA: jack: Access input_dev under mutex
by Dan Carpenter 06 Jul '23

06 Jul '23

Hello Amadeusz Sławiński, The patch 1b6a6fc5280e: "ALSA: jack: Access input_dev under mutex" from Apr 12, 2022, leads to the following Smatch static checker warning: sound/core/jack.c:673 snd_jack_report() warn: sleeping in atomic context sound/core/jack.c 663 jack->hw_status_cache = status; 664 665 list_for_each_entry(jack_kctl, &jack->kctl_list, list) 666 if (jack_kctl->sw_inject_enable) 667 mask_bits |= jack_kctl->mask_bits; 668 else 669 snd_kctl_jack_report(jack->card, jack_kctl->kctl, 670 status & jack_kctl->mask_bits); 671 672 #ifdef CONFIG_SND_JACK_INPUT_DEV --> 673 mutex_lock(&jack->input_dev_lock); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That patch adds this mutex but we can't take mutex because we're already holding a spinlock. The problematic call trees are: virtsnd_event_notify_cb() <- disables preempt virtsnd_disable_event_vq() <- disables preempt -> virtsnd_event_dispatch() -> virtsnd_jack_event() -> snd_jack_report() The virtsnd_event_notify_cb() and virtsnd_disable_event_vq() functions take the spin_lock_irqsave(&queue->lock, flags); regards, dan carpenter

3 4

[PATCH] ASoC: qcom: q6afe-dai: fix Display Port Playback stream name
by Srinivas Kandagatla 06 Jul '23

06 Jul '23

With recent changes to add more display ports did not change the Stream name in q6afe-dai. This results in below error "ASoC: Failed to add route DISPLAY_PORT_RX -> Display Port Playback(*)" and sound card fails to probe. Fix this by adding correct stream name. Fixes: 90848a2557fe ("ASoC: qcom: q6dsp: add support to more display ports") Reported-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- sound/soc/qcom/qdsp6/q6afe-dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/qcom/qdsp6/q6afe-dai.c b/sound/soc/qcom/qdsp6/q6afe-dai.c index 31e0bad71e95..dbff55a97162 100644 --- a/sound/soc/qcom/qdsp6/q6afe-dai.c +++ b/sound/soc/qcom/qdsp6/q6afe-dai.c @@ -476,7 +476,7 @@ static int q6afe_mi2s_set_sysclk(struct snd_soc_dai *dai, static const struct snd_soc_dapm_route q6afe_dapm_routes[] = { {"HDMI Playback", NULL, "HDMI_RX"}, - {"Display Port Playback", NULL, "DISPLAY_PORT_RX"}, + {"DISPLAY_PORT_RX_0 Playback", NULL, "DISPLAY_PORT_RX"}, {"Slimbus Playback", NULL, "SLIMBUS_0_RX"}, {"Slimbus1 Playback", NULL, "SLIMBUS_1_RX"}, {"Slimbus2 Playback", NULL, "SLIMBUS_2_RX"}, -- 2.25.1

3 2

[PATCH v2 0/3] AMD Vangogh support for NAU8821/MAX98388
by Cristian Ciocaltea 06 Jul '23

06 Jul '23

This patch series extends the Vangogh machine driver to support a variant based on the Nuvoton NAU88L21 Codec and the Analog Devices MAX98388 Speaker Amplifier. Changes in v2: * Reworked series to ensure the existing devices based on the CS35L41 codec continue to work fine * Rebased onto next-20230703 Cristian Ciocaltea (3): ASoC: amd: vangogh: Make use of DRV_NAME ASoC: amd: vangogh: Use dmi_first_match() for DMI quirk handling ASoC: amd: vangogh: Add support for NAU8821/MAX98388 variant sound/soc/amd/Kconfig | 5 +- sound/soc/amd/vangogh/acp5x-mach.c | 167 +++++++++++++++++++++++++---- 2 files changed, 149 insertions(+), 23 deletions(-) -- 2.41.0

2 5

[tiwai-sound:topic/midi20-gadget 63/63] htmldocs: Documentation/usb/gadget-testing.rst:1019: WARNING: Malformed table.
by kernel test robot 05 Jul '23

05 Jul '23

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git topic/midi20-gadget head: be0c9761ecd79271d4a3efacaec6963a4010a297 commit: be0c9761ecd79271d4a3efacaec6963a4010a297 [63/63] usb: gadget: midi2: Add testing documentation reproduce: (https://download.01.org/0day-ci/archive/20230706/202307060422.HHYZIPqX-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202307060422.HHYZIPqX-lkp@intel.com/ All warnings (new ones prefixed by >>): >> Documentation/usb/gadget-testing.rst:1019: WARNING: Malformed table. vim +1019 Documentation/usb/gadget-testing.rst 1003 1004 =============== =============================================== 1005 name Function Block name string 1006 direction Direction of this FB 1007 1: input, 2: output, or 3: bidirectional 1008 first_group The first UMP Group number (0-15) 1009 num_groups The number of groups in this FB (1-16) 1010 ui_hint UI-hint of this FB 1011 0: unknown, 1: receiver, 2: sender, 3: both 1012 midi_ci_verison Supported MIDI-CI version number (8 bit) 1013 is_midi1 Legacy MIDI 1.0 device (0-2) 1014 0: MIDI 2.0 device, 1015 1: MIDI 1.0 without restriction, or 1016 2: MIDI 1.0 with low speed 1017 sysex8_streams Max number of SysEx8 streams (8 bit) 1018 active Bool flag for FB activity (0 or 1) > 1019 ============= =============================================== 1020 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[tiwai-sound:test/snd_ctl_remove-lock-fix 40/54] htmldocs: ./include/sound/control.h:162: warning: expecting prototype for snd_ctl_find_id(). Prototype was for snd_ctl_find_id_mixer() instead
by kernel test robot 05 Jul '23

05 Jul '23

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git test/snd_ctl_remove-lock-fix head: 9ad18619a06d551105bd84191dca5bb5295277c7 commit: 59444a29dbfd44718fef15083aa339c2c8b579b5 [40/54] ALSA: control: Introduce snd_ctl_find_id_mixer() reproduce: (https://download.01.org/0day-ci/archive/20230706/202307060119.mTXEyy6N-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202307060119.mTXEyy6N-lkp@intel.com/ All warnings (new ones prefixed by >>): >> ./include/sound/control.h:162: warning: expecting prototype for snd_ctl_find_id(). Prototype was for snd_ctl_find_id_mixer() instead vim +162 ./include/sound/control.h 147 148 /** 149 * snd_ctl_find_id - find the control instance with the given name string 150 * @card: the card instance 151 * @name: the name string 152 * 153 * Finds the control instance with the given name and 154 * @SNDRV_CTL_ELEM_IFACE_MIXER. Other fields are set to zero. 155 * 156 * This is merely a wrapper to snd_ctl_find_id(). 157 * 158 * Return: The pointer of the instance if found, or %NULL if not. 159 */ 160 static inline struct snd_kcontrol * 161 snd_ctl_find_id_mixer(struct snd_card *card, const char *name) > 162 { 163 struct snd_ctl_elem_id id = {}; 164 165 id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; 166 strscpy(id.name, name, sizeof(id.name)); 167 return snd_ctl_find_id(card, &id); 168 } 169 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH v3 0/6] Introduce STM32 system bus
by Gatien Chevallier 05 Jul '23

05 Jul '23

Document STM32 System Bus. This bus is intended to control firewall access for the peripherals connected to it. For every peripheral, the bus checks the firewall registers to see if the peripheral is configured as non-secure. If the peripheral is configured as secure, the node is marked populated, so the device won't be probed. This is useful as a firewall configuration sanity check and avoid platform crashes in case peripherals are incorrectly configured. The STM32 System Bus implements the feature-domain-controller bindings. It is used by peripherals to reference a domain controller, in this case the firewall feature domain. The bus uses the ID referenced by the feature-domains property to know where to look in the firewall to get the security configuration for the peripheral. This allows a device tree description rather than a hardcoded peripheral table in the bus driver. On STM32MP13/15 platforms, the firewall bus is represented by the ETZPC node, which is responsible for the securing / MCU isolating the capable peripherals. STM32MP13/15 device trees are updated in this series to implement the bus. All peripherals that are securable or MCU isolation capable by the ETZPC are connected to the bus. Changes in V2: - Corrected YAMLS errors highlighted by Rob's robot - Re-ordered Signed-off-by tags in two patches Changes in V3: - Document feature-domains property in YAML documentation for concerned periperals under the System Bus - Fix STM32 System Bus YAML documentation - Remove STM32 System bus bindings that were currently used as helpers for device tree - Correct few errors in driver - Add missing peripherals under the System Bus that were in SoC variation device tree files - Fix node names Gatien Chevallier (5): dt-bindings: treewide: add feature-domains description in binding files dt-bindings: bus: add STM32 System Bus bus: stm32_sys_bus: add support for STM32MP15 and STM32MP13 system bus ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards Oleksii Moisieiev (1): dt-bindings: Document common device controller bindings .../devicetree/bindings/bus/st,sys-bus.yaml | 127 + .../bindings/crypto/st,stm32-hash.yaml | 5 + .../devicetree/bindings/dma/st,stm32-dma.yaml | 5 + .../bindings/dma/st,stm32-dmamux.yaml | 5 + .../feature-domain-controller.yaml | 84 + .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 5 + .../bindings/iio/adc/st,stm32-adc.yaml | 5 + .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 5 + .../bindings/iio/dac/st,stm32-dac.yaml | 5 + .../bindings/media/st,stm32-cec.yaml | 5 + .../bindings/media/st,stm32-dcmi.yaml | 5 + .../memory-controllers/st,stm32-fmc2-ebi.yaml | 5 + .../bindings/mfd/st,stm32-lptimer.yaml | 5 + .../bindings/mfd/st,stm32-timers.yaml | 6 + .../devicetree/bindings/mmc/arm,pl18x.yaml | 5 + .../devicetree/bindings/net/stm32-dwmac.yaml | 5 + .../bindings/phy/phy-stm32-usbphyc.yaml | 5 + .../bindings/regulator/st,stm32-vrefbuf.yaml | 5 + .../devicetree/bindings/rng/st,stm32-rng.yaml | 5 + .../bindings/serial/st,stm32-uart.yaml | 5 + .../bindings/sound/st,stm32-i2s.yaml | 5 + .../bindings/sound/st,stm32-sai.yaml | 5 + .../bindings/sound/st,stm32-spdifrx.yaml | 5 + .../bindings/spi/st,stm32-qspi.yaml | 5 + .../devicetree/bindings/spi/st,stm32-spi.yaml | 5 + .../devicetree/bindings/usb/dwc2.yaml | 5 + MAINTAINERS | 6 + arch/arm/boot/dts/stm32mp131.dtsi | 407 +-- arch/arm/boot/dts/stm32mp133.dtsi | 51 +- arch/arm/boot/dts/stm32mp13xc.dtsi | 19 +- arch/arm/boot/dts/stm32mp13xf.dtsi | 18 +- arch/arm/boot/dts/stm32mp151.dtsi | 2722 +++++++++-------- arch/arm/boot/dts/stm32mp153.dtsi | 52 +- arch/arm/boot/dts/stm32mp15xc.dtsi | 19 +- drivers/bus/Kconfig | 9 + drivers/bus/Makefile | 1 + drivers/bus/stm32_sys_bus.c | 168 + 37 files changed, 2208 insertions(+), 1596 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/st,sys-bus.yaml create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml create mode 100644 drivers/bus/stm32_sys_bus.c -- 2.35.3

7 23

Garbage returned while reading unused S/PDIF, A CM106 like sound card
by Aurélien 05 Jul '23

05 Jul '23

Hello, I encounter troubles while using S/PDIF input on an CM106 like sound card (vendor 0x0d8c, device 0x0102) when the remote device which is connected by S/ PDIF to the sound card is powered off. In that case garbage data are reading from the S/PDIF rather than.. nothing It is really boring since this S/PDIF input is connected to the output speakers and once the remote deviced is powered off it emits a really disturbing sound. Since there is no input on the S/PDIF I guess that it could be a driver bug? If it's an hardware bug (I don't encounter the problem under windows..) is it possible to make a hack in order to distinguish between real data and noise on the S/PDIF input? Unfortunately this test is performed on an embedded device which runs linux 5.16.17-sun50iw6. I don't know if this problem still occurs with newer alsa version. Thank you in advance for your help. Regards, Aurélien

2 1

[PATCH 2/3] ASoC: rt5645: check return value after reading device id
by shumingf＠realtek.com 05 Jul '23

05 Jul '23

From: Shuming Fan <shumingf(a)realtek.com> If the I2C controller encounters some problems like timed-out, the codec driver will report the error code for the first read. Signed-off-by: Shuming Fan <shumingf(a)realtek.com> --- sound/soc/codecs/rt5645.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index c0d56a8f7f47..b0953e9bcaf9 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -3967,7 +3967,11 @@ static int rt5645_i2c_probe(struct i2c_client *i2c) * read and power On. */ msleep(TIME_TO_POWER_MS); - regmap_read(regmap, RT5645_VENDOR_ID2, &val); + ret = regmap_read(regmap, RT5645_VENDOR_ID2, &val); + if (ret < 0) { + dev_err(&i2c->dev, "Failed to read: 0x%02X\n, ret = %d", RT5645_VENDOR_ID2, ret); + goto err_enable; + } switch (val) { case RT5645_DEVICE_ID: -- 2.41.0

2 1