August 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] drm: dw-hdmi-i2s: enable audio clock in audio_startup
by Cheng-Yi Chiang 02 Sep '19

02 Sep '19

In the designware databook, the sequence of enabling audio clock and setting format is not clearly specified. Currently, audio clock is enabled in the end of hw_param ops after setting format. On some monitors, there is a possibility that audio does not come out. Fix this by enabling audio clock in audio_startup ops before hw_param ops setting format. Signed-off-by: Cheng-Yi Chiang <cychiang(a)chromium.org> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index 5cbb71a866d5..08b4adbb1ddc 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c @@ -69,6 +69,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data, hdmi_write(audio, conf0, HDMI_AUD_CONF0); hdmi_write(audio, conf1, HDMI_AUD_CONF1); + return 0; +} + +static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data) +{ + struct dw_hdmi_i2s_audio_data *audio = data; + struct dw_hdmi *hdmi = audio->hdmi; + dw_hdmi_audio_enable(hdmi); return 0; @@ -105,6 +113,7 @@ static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component, } static struct hdmi_codec_ops dw_hdmi_i2s_ops = { + .audio_startup = dw_hdmi_i2s_audio_startup, .hw_params = dw_hdmi_i2s_hw_params, .audio_shutdown = dw_hdmi_i2s_audio_shutdown, .get_dai_id = dw_hdmi_i2s_get_dai_id, -- 2.23.0.187.g17f5b7556c-goog

3 3

[alsa-devel] [PATCH 1/3] ASoC: es8316: judge PCM rate at later timing
by Katsuhiro Suzuki 31 Aug '19

31 Aug '19

This patch change the judge timing about playing/capturing PCM rate. Original code set constraints list of PCM rate limits at set_sysclk. This strategy works well if system is using fixed rate clock. But some boards and SoC (such as RockPro64 and RockChip I2S) has connected SoC MCLK out to ES8316 MCLK in. In this case, SoC side I2S will choose suitable frequency of MCLK such as fs * mclk-fs when user starts playing or capturing. Bad scenario as follows (mclk-fs = 256): - Initialize sysclk by correct value (Ex. 12.288MHz) - ES8316 set constraints of PCM rate by sysclk 48kHz (1/256), 32kHz (1/384), 30.720kHz (1/400), 24kHz (1/512), 16kHz (1/768), 12kHz (1/1024) - Play 48kHz sound, it's acceptable - Sysclk is not changed - Play 32kHz sound, it's acceptable - Set sysclk by 8.192MHz (= fs * mclk-fs = 32k * 256) - ES8316 set constraints of PCM rate by sysclk 32kHz (1/256), 21.33kHz (1/384), 20.48kHz (1/400), 16kHz (1/512), 10.66kHz (1/768), 8kHz (1/1024) - Play 48kHz again, but it's NOT acceptable because constraints list does not allow 48kHz Root cause of this strange behavior is changing constraints list at set_sysclk timing. It seems that is too early to determine. So this patch does not use constraints list and check PCM rate limit more later timing at hw_params. Signed-off-by: Katsuhiro Suzuki <katsuhiro(a)katsuster.net> --- sound/soc/codecs/es8316.c | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c index ed2959dbe1fb..229808fa627c 100644 --- a/sound/soc/codecs/es8316.c +++ b/sound/soc/codecs/es8316.c @@ -363,27 +363,12 @@ static int es8316_set_dai_sysclk(struct snd_soc_dai *codec_dai, { struct snd_soc_component *component = codec_dai->component; struct es8316_priv *es8316 = snd_soc_component_get_drvdata(component); - int i; - int count = 0; es8316->sysclk = freq; if (freq == 0) return 0; - /* Limit supported sample rates to ones that can be autodetected - * by the codec running in slave mode. - */ - for (i = 0; i < NR_SUPPORTED_MCLK_LRCK_RATIOS; i++) { - const unsigned int ratio = supported_mclk_lrck_ratios[i]; - - if (freq % ratio == 0) - es8316->allowed_rates[count++] = freq / ratio; - } - - es8316->sysclk_constraints.list = es8316->allowed_rates; - es8316->sysclk_constraints.count = count; - return 0; } @@ -449,13 +434,6 @@ static int es8316_pcm_startup(struct snd_pcm_substream *substream, return -EINVAL; } - /* The set of sample rates that can be supported depends on the - * MCLK supplied to the CODEC. - */ - snd_pcm_hw_constraint_list(substream->runtime, 0, - SNDRV_PCM_HW_PARAM_RATE, - &es8316->sysclk_constraints); - return 0; } @@ -466,12 +444,27 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_soc_component *component = dai->component; struct es8316_priv *es8316 = snd_soc_component_get_drvdata(component); u8 wordlen = 0; + int i; if (!es8316->sysclk) { dev_err(component->dev, "No MCLK configured\n"); return -EINVAL; } + /* Limit supported sample rates to ones that can be autodetected + * by the codec running in slave mode. + */ + for (i = 0; i < NR_SUPPORTED_MCLK_LRCK_RATIOS; i++) { + const unsigned int ratio = supported_mclk_lrck_ratios[i]; + + if (es8316->sysclk % ratio != 0) + continue; + if (es8316->sysclk / ratio == params_rate(params)) + break; + } + if (i == NR_SUPPORTED_MCLK_LRCK_RATIOS) + return -EINVAL; + switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: wordlen = ES8316_SERDATA2_LEN_16; -- 2.23.0.rc1

2 4

[alsa-devel] [PATCH 0/4] ASoC: mediatek: mt8183: some cleanups
by Tzung-Bi Shih 30 Aug '19

30 Aug '19

The series contains some cleanup refactors and should not change any behavior. Tzung-Bi Shih (4): ASoC: mediatek: mt8183: move private structure ASoC: mediatek: mt8183: move headset jack to card-specific storage ASoC: mediatek: mt8183: remove forward declaration of headset_init ASoC: mediatek: mt8183: fix space issues .../mt8183/mt8183-mt6358-ts3a227-max98357.c | 55 +++++++++---------- 1 file changed, 26 insertions(+), 29 deletions(-) -- 2.23.0.187.g17f5b7556c-goog

2 8

[alsa-devel] [PATCH v2 1/5] ASoC: dt-bindings: sun4i-spdif: Fix dma-names warning
by Maxime Ripard 30 Aug '19

30 Aug '19

From: Maxime Ripard <maxime.ripard(a)bootlin.com> Even though the H6 compatible has been properly added, the exeption for the number of DMA channels hasn't been updated, leading in a validation warning. Fix this. Fixes: b20453031472 ("dt-bindings: sound: sun4i-spdif: Add Allwinner H6 compatible") Signed-off-by: Maxime Ripard <maxime.ripard(a)bootlin.com> --- Changes from v1: - Fix subject prefix --- .../devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml index e0284d8c3b63..38d4cede0860 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml @@ -70,7 +70,9 @@ allOf: properties: compatible: contains: - const: allwinner,sun8i-h3-spdif + enum: + - allwinner,sun8i-h3-spdif + - allwinner,sun50i-h6-spdif then: properties: -- 2.21.0

3 12

Re: [alsa-devel] [PATCH 2/2] ASoC: rt1011: ADCDAT pin config modification
by Mark Brown 30 Aug '19

30 Aug '19

On Wed, Aug 28, 2019 at 11:01:21AM +0000, Shuming [范書銘] wrote: > > > ADCDAT pin config sets to output mode in default. > > > And the driver creates the kcontrol to control ADCDAT pin configuration. > > Why would this change at runtime? I'd expect this to be controlled by the > > machine driver or a DT property. > It will not change at runtime in the normal case. > I think we may use it to test the feedback signal in factory mode. So really this is setting up a loopback for testing?

2 2

[alsa-devel] [PATCH 0/4] ASoC: ti: davinci: Fixes for daVinci boards with McBSP
by Peter Ujfalusi 30 Aug '19

30 Aug '19

Hi, Morimoto-san pointed out in a private thread that the davinci-i2s driver is using snd_soc_rtdcom_lookup(), which is should not really. It took a while to get access to a daVinci board which uses McBSP, but eventually I got access to a remote dm644x-evm and dma365-evm. Initially the audio was not even probing on them (fixes sent for mach-davinci), but then the driver was still crashing and not behaving correctly. With the 4 patch dm644x-evm have working audio and the offending snd_soc_rtdcom_lookup() is gone from the driver. dm365-evm still have some issues regarding to EDMA, but it looks like a system issue which can be fixed later. Regards, Peter --- Peter Ujfalusi (4): ASoC: ti: davinci-i2s: Add S32_LE as support format ASoC: ti: davinci-i2s: Move the XSYNCERR workaround to .prepare callback ASoC: ti: edma-pcm: Fix for legacy dma_slave_map based channel lookup ASoC: ti: davinci-evm: Do not fail if the dai_set_sysclk returns -ENOTSUPP sound/soc/ti/davinci-evm.c | 2 +- sound/soc/ti/davinci-i2s.c | 90 +++++++++++++++++--------------------- sound/soc/ti/edma-pcm.c | 17 ++++++- 3 files changed, 57 insertions(+), 52 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 8

[alsa-devel] [PATCH v2] ASoC: Intel: Baytrail: Fix implicit fallthrough warning
by Cezary Rojewski 30 Aug '19

30 Aug '19

Append fallthrough statement to fix warning reported during compilation. Fixes: b80d19c166c4 ("ASoC: Intel: Restore Baytrail ADSP streams only when ADSP was in reset") Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- Changes from v1: - made use of fallthrough statement as suggested by Pierre - updated commit message sound/soc/intel/baytrail/sst-baytrail-pcm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c b/sound/soc/intel/baytrail/sst-baytrail-pcm.c index 9cbc982d46a9..54f2ee3010ee 100644 --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c @@ -193,6 +193,7 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream *substream, int cmd) break; case SNDRV_PCM_TRIGGER_SUSPEND: pdata->restore_stream = false; + /* fallthrough */ case SNDRV_PCM_TRIGGER_PAUSE_PUSH: sst_byt_stream_pause(byt, pcm_data->stream); break; -- 2.17.1

3 2

[alsa-devel] [PATCH] ASoC: fsl_ssi: Fix clock control issue in master mode
by Shengjiu Wang 30 Aug '19

30 Aug '19

The test case is arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav & aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav There will be error after end of arecord: aplay: pcm_write:2051: write error: Input/output error Capture and Playback work in parallel in master mode, one substream stops, the other substream is impacted, the reason is that clock is disabled wrongly. The clock's reference count is not increased when second substream starts, the hw_param() function returns in the beginning because first substream is enabled, then in end of first substream, the hw_free() disables the clock. This patch is to move the clock enablement to the place before checking of the device enablement in hw_param(). Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl_ssi.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index b0a6fead1a6a..537dc69256f0 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -799,15 +799,6 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream, u32 wl = SSI_SxCCR_WL(sample_size); int ret; - /* - * SSI is properly configured if it is enabled and running in - * the synchronous mode; Note that AC97 mode is an exception - * that should set separate configurations for STCCR and SRCCR - * despite running in the synchronous mode. - */ - if (ssi->streams && ssi->synchronous) - return 0; - if (fsl_ssi_is_i2s_master(ssi)) { ret = fsl_ssi_set_bclk(substream, dai, hw_params); if (ret) @@ -823,6 +814,15 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream, } } + /* + * SSI is properly configured if it is enabled and running in + * the synchronous mode; Note that AC97 mode is an exception + * that should set separate configurations for STCCR and SRCCR + * despite running in the synchronous mode. + */ + if (ssi->streams && ssi->synchronous) + return 0; + if (!fsl_ssi_is_ac97(ssi)) { /* * Keep the ssi->i2s_net intact while having a local variable -- 2.21.0

3 2

[alsa-devel] [PATCH] ASoC: SOF/Intel: fix selection of SND_INTEL_NHTL
by Pierre-Louis Bossart 30 Aug '19

30 Aug '19

We should only select SND_INTEL_NHLT when ACPI is defined. This was done for the legacy HDAudio driver but not for DSP-enabled cases, leading to compilation errors with randconfig. Fix by aligning on the same solution. For the Skylake driver this is overkill since there is a top-level dependency on ACPI, but it doesn't hurt and it's better to have consistency. Fixes: 68b953aeb50d9 ('ASoC: SOF: Intel: hda: fixup HDaudio topology name with DMIC number') Reported-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/intel/Kconfig | 2 +- sound/soc/sof/intel/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index a3ec17fd63cd..01c99750212a 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -215,7 +215,7 @@ config SND_SOC_INTEL_SKYLAKE_COMMON select SND_SOC_INTEL_SST select SND_SOC_HDAC_HDA if SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC select SND_SOC_ACPI_INTEL_MATCH - select SND_INTEL_NHLT + select SND_INTEL_NHLT if ACPI help If you have a Intel Skylake/Broxton/ApolloLake/KabyLake/ GeminiLake or CannonLake platform with the DSP enabled in the BIOS diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index 889b6202d054..479ba249e219 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -286,7 +286,7 @@ config SND_SOC_SOF_HDA tristate select SND_HDA_EXT_CORE if SND_SOC_SOF_HDA_LINK select SND_SOC_HDAC_HDA if SND_SOC_SOF_HDA_AUDIO_CODEC - select SND_INTEL_NHLT + select SND_INTEL_NHLT if ACPI help This option is not user-selectable but automagically handled by 'select' statements at a higher level -- 2.20.1

2 1

[alsa-devel] [PATCH 0/4] ASoC: Intel: Haswell: Adjust machine device private
by Cezary Rojewski 30 Aug '19

30 Aug '19

Apart from Haswell machines, all other devices have their private data set to snd_soc_acpi_mach instance. Changes for HSW/ BDW boards introduced with series: https://patchwork.kernel.org/cover/10782035/ added support for dai_link platform_name adjustments within card probe routines. These take for granted private_data points to snd_soc_acpi_mach whereas for Haswell, it's sst_pdata instead. Change private context of platform_device - representing machine board - to address this. Caught by recent cleanups where content of sst_pdata was moved. Currently, despite the incorrect cast, dereferenced field points happily to NULL (uninitialized field), so no panics were observed. Cezary Rojewski (4): ASoC: Intel: Haswell: Adjust machine device private context ASoC: Intel: haswell: Simplify device probe ASoC: Intel: bdw-rt5677: Simplify device probe ASoC: Intel: broadwell: Simplify device probe sound/soc/intel/boards/bdw-rt5677.c | 6 +----- sound/soc/intel/boards/broadwell.c | 6 +----- sound/soc/intel/boards/haswell.c | 6 +----- sound/soc/intel/common/sst-acpi.c | 3 ++- 4 files changed, 5 insertions(+), 16 deletions(-) -- 2.17.1

3 21