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

Enabling fsl_sai MCLK before codec probe
by Michael Welling 20 Jun '22

20 Jun '22

So I have a tricky race condition that comes up with hardware that combines imx8 with a pcm1681 codec. The pcm1681 requires that MCLK be enabled for 65536 cycles before accessing the I2C management port. The imx8 sai driver on the other hand does not start the built in MCLK until a confluence of events that is not triggered until just before streaming starts which is too late. Is there a clean way to start the imx8 sai MCLK before the codec probe occurs? Or have it started and delayed during the codec probe before it tries to access i2c? We have a working solution but it is a bit overreaching and adds a callback function to the snd_soc_dai_ops struct to start the clock, and adds the code to the fsl_sai.c to toggle the appropriate bits in the SoC sai driver to make a clock appear and registers to the new function callback. Then the simple-card was amended to add the appropriate enabling through the new callback such that the clock is on long enough before the codec is probed. There was some suggestion of caching the i2c registers until the clock is enabled but this would be difficult given the clock is not started until streaming starts and we don't want to stream until the codec is initialized. I am looking for a solution that is minimal and robust. Any pointers would be greatly appreciated.

1 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > Just for my understanding, are you suggesting to set a device tree > > property to force a fixed behavior in the driver ? > Yes. Why should we use a fixed behavior ? > > WM8904 allows using both a DMIC and LINEIN, switching between one or > > the other and this is how we currently use it. > > Why the user should not be allowed to switch between DMIC and LINEIN ? > The device shares pins between the line inputs and the DMIC inputs so at > least some of the configuration is going to be determinted at system > design time, that will fix the usable values of at least one of the > controls which ought to be reflected in the runtime behaviour. In our design we use: - pin 1: DMIC_CLK - pin 24: LINEIN2R - pin 26: LINEIN2L - pin 27: DMIC_DATA we have no pins shared among DMIC and LINEIN. We have several customer switching between DMIC and LINEIN at runtime. > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. I beg your pardon: it should be fixed now.

2 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > > Via firmware description. > > Can you please provide any reference approach in the kernel code ? > git grep of_ > git grep fwnode_ > and I don't immediately remember what the prefix is for ACPI functions. Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ? WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it. Why the user should not be allowed to switch between DMIC and LINEIN ?

2 1

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

Hi All, > > + - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property > > + > > + - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC) > > + The list must be (4 x num-drc-cfgs) entries long. > > + If absent or incomplete, DRC is disabled. > > What is the purpose of having num-drc-cfgs? We can tell how large > drc-cfg-regs is so it just seems redundant. Can you please point me to any reference implementation doing this ? > > + - num-retune-mobile-cfgs: Number of retune modes available from > > + retune-mobile-cfg-regs property > > Same here. Thanks Best Regards Pier

2 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > > > +static const char *cin_text[] = { > > > > + "ADC", "DMIC" > > > > +}; > > > > +static SOC_ENUM_SINGLE_DECL(cin_enum, > > > > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text); > > > Why would this be runtime selectable? I'd expect the decision to use > > > an analogue or digital microphone to be made in the hardware design. > > I agree that dedicated HW is required, but currently SW side there's no support at all. > > This patch is aiming to provide a way to enable DMIC on boards using it. > > Is this supposed to be managed in a different way ? > Via firmware description. Can you please provide any reference approach in the kernel code ?

2 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

Hi All, > > +static const char *cin_text[] = { > > + "ADC", "DMIC" > > +}; > > + > > +static SOC_ENUM_SINGLE_DECL(cin_enum, > > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text); > > Why would this be runtime selectable? I'd expect the decision to use > an analogue or digital microphone to be made in the hardware design. I agree that dedicated HW is required, but currently SW side there's no support at all. This patch is aiming to provide a way to enable DMIC on boards using it. Is this supposed to be managed in a different way ? Thanks Best Regards Pier

2 1

[PATCH] MAINTAINERS: update ASoC Qualcomm maintainer email-id
by Srinivas Kandagatla 20 Jun '22

20 Jun '22

Update Banajit's email address from codeaurora.org to quicinc.com, as codeaurora.org is not in use anymore. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 440f3d7c93b9..171fa3160696 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16247,7 +16247,7 @@ F: drivers/crypto/qat/ QCOM AUDIO (ASoC) DRIVERS M: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> -M: Banajit Goswami <bgoswami(a)codeaurora.org> +M: Banajit Goswami <bgoswami(a)quicinc.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) S: Supported F: sound/soc/codecs/lpass-va-macro.c -- 2.25.1

2 1

No sound on main speaker : Zenbook UX3402/ALC294/Fedora 36
by GitHub issues - opened 20 Jun '22

20 Jun '22

alsa-project/alsa-ucm-conf issue #174 was opened from hereblur: My laptop has no sound on main speakers. 3.5mm jack and bluetooth is working fine. Asus Zenbook UX3402 ALC294 Fedora 36 Here is my `alsaucm -c hw:0 dump text` and `alsa-info.sh` output [https://paste.debian.net/1244631/](https://paste.debian.net/1244631/) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/174 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ASoC: fsl_asrc_dma: Use dmaengine_terminate_async()
by Sascha Hauer 20 Jun '22

20 Jun '22

dmaengine_terminate_all() is deprecated and should no longer be used. Use dmaengine_terminate_async() instead. This involves no functional change since both functions do the same. After dmaengine_terminate_async() dmaengine_synchronize() must be called to make sure the channel has really stopped before the underlying memory is freed. This is done implicitly by dma_release_channel() called from the .hw_free hook. Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- sound/soc/fsl/fsl_asrc_dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c index fec56dbb64e60..6c4d161ddad85 100644 --- a/sound/soc/fsl/fsl_asrc_dma.c +++ b/sound/soc/fsl/fsl_asrc_dma.c @@ -114,8 +114,8 @@ static int fsl_asrc_dma_trigger(struct snd_soc_component *component, case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - dmaengine_terminate_all(pair->dma_chan[OUT]); - dmaengine_terminate_all(pair->dma_chan[IN]); + dmaengine_terminate_async(pair->dma_chan[OUT]); + dmaengine_terminate_async(pair->dma_chan[IN]); break; default: return -EINVAL; -- 2.30.2

2 1

[PATCH 1/2] ALSA: hda/conexant: Fix missing beep setup
by Takashi Iwai 20 Jun '22

20 Jun '22

Currently the Conexant codec driver sets up the beep NID after calling snd_hda_gen_parse_auto_config(). It turned out that this results in the insufficient setup for the beep control, as the generic parser handles the fake path in snd_hda_gen_parse_auto_config() only if the beep_nid is set up beforehand. For dealing with the beep widget properly, call cx_auto_parse_beep() before snd_hda_gen_parse_auto_config() call. Fixes: 51e19ca5f755 ("ALSA: hda/conexant - Clean up beep code") Cc: <stable(a)vger.kernel.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216152 Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_conexant.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 1248d1a51cf0..3e541a4c0423 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -1079,11 +1079,11 @@ static int patch_conexant_auto(struct hda_codec *codec) if (err < 0) goto error; - err = snd_hda_gen_parse_auto_config(codec, &spec->gen.autocfg); + err = cx_auto_parse_beep(codec); if (err < 0) goto error; - err = cx_auto_parse_beep(codec); + err = snd_hda_gen_parse_auto_config(codec, &spec->gen.autocfg); if (err < 0) goto error; -- 2.35.3

1 1