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

[alsa-devel] [PATCH trivial] ASoC: Spelling s/configr/configur/
by Geert Uytterhoeven 25 Oct '19

25 Oct '19

Fix misspellings of "configuration" and "configure". Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- include/sound/wm8904.h | 2 +- sound/soc/codecs/cx2072x.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/sound/wm8904.h b/include/sound/wm8904.h index 14074405f5012f9a..88ac1870510ec063 100644 --- a/include/sound/wm8904.h +++ b/include/sound/wm8904.h @@ -120,7 +120,7 @@ * DRC configurations are specified with a label and a set of register * values to write (the enable bits will be ignored). At runtime an * enumerated control will be presented for each DRC block allowing - * the user to choose the configration to use. + * the user to choose the configuration to use. * * Configurations may be generated by hand or by using the DRC control * panel provided by the WISCE - see http://www.wolfsonmicro.com/wisce/ diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c index 1c1ba7bea4d81969..2ad00ed21bec6c59 100644 --- a/sound/soc/codecs/cx2072x.c +++ b/sound/soc/codecs/cx2072x.c @@ -1507,7 +1507,7 @@ static int cx2072x_probe(struct snd_soc_component *codec) regmap_multi_reg_write(cx2072x->regmap, cx2072x_reg_init, ARRAY_SIZE(cx2072x_reg_init)); - /* configre PortC as input device */ + /* configure PortC as input device */ regmap_update_bits(cx2072x->regmap, CX2072X_PORTC_PIN_CTRL, 0x20, 0x20); -- 2.17.1

2 1

[alsa-devel] [PATCH v2 0/2] ASoC: SOF: make hw_info platform specific
by Pierre-Louis Bossart 25 Oct '19

25 Oct '19

The SOF core blindly sets the hw_info, when it should really be platform-specific. This move enable us to temporarily fix PulseAudio issues resulting from inaccuracies in the hw_ptr position provided by the firmware on Baytrail-Broadwell. This is the first time we experiment with the GitHub low-level API to automagically keep track of 'approvers' by inserting a Reviewed-by tag when merging a pull-request, thanks to Ranjani for her initial work and bearing with my habit of breaking things :-) v2: make the code apply on Mark's tree. Sorry about that bad patch. Pierre-Louis Bossart (2): ASoC: SOF: define INFO_ flags in dsp_ops ASoC: SOF: Intel: only support INFO_BATCH for legacy platforms sound/soc/sof/imx/imx8.c | 7 +++++++ sound/soc/sof/intel/apl.c | 7 +++++++ sound/soc/sof/intel/bdw.c | 9 ++++++++- sound/soc/sof/intel/byt.c | 21 +++++++++++++++++++++ sound/soc/sof/intel/cnl.c | 7 +++++++ sound/soc/sof/pcm.c | 8 +++----- sound/soc/sof/sof-priv.h | 3 +++ 7 files changed, 56 insertions(+), 6 deletions(-) -- 2.20.1

2 4

[alsa-devel] [PATCH] ASoC: Intel: eve: Enable mclk and ssp sclk early for rt5514
by Brent Lu 25 Oct '19

25 Oct '19

The first DMIC capture always fail (zero sequence data from PCM port) after using DSP hotwording function (i.e. Google assistant). The DMIC is attached to rt5514 which also require eaily mclk/sclk like rt5663. Therefore we add a dapm route to provide ssp mclk/sclk early to rt5514. The rt5514 is attached to SSP0 and the rt5663 is attached to SSP1 so we create another supply widget to provide SSP0 mclk/sclk to rt5514. Signed-off-by: Brent Lu <brent.lu(a)intel.com> --- .../soc/intel/boards/kbl_rt5663_rt5514_max98927.c | 136 ++++++++++++++------- 1 file changed, 92 insertions(+), 44 deletions(-) diff --git a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c index dc09a85..1755efa 100644 --- a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c @@ -53,8 +53,10 @@ struct kbl_codec_private { struct snd_soc_jack kabylake_headset; struct list_head hdmi_pcm_list; struct snd_soc_jack kabylake_hdmi[2]; - struct clk *mclk; - struct clk *sclk; + struct clk *ssp0_mclk; + struct clk *ssp0_sclk; + struct clk *ssp1_mclk; + struct clk *ssp1_sclk; }; enum { @@ -77,13 +79,31 @@ static const struct snd_kcontrol_new kabylake_controls[] = { }; static int platform_clock_control(struct snd_soc_dapm_widget *w, - struct snd_kcontrol *k, int event) + struct snd_kcontrol *k, int event, int ssp_num) { struct snd_soc_dapm_context *dapm = w->dapm; struct snd_soc_card *card = dapm->card; struct kbl_codec_private *priv = snd_soc_card_get_drvdata(card); + struct clk *mclk, *sclk; + unsigned long sclk_rate; int ret = 0; + switch (ssp_num) { + case 0: + mclk = priv->ssp0_mclk; + sclk = priv->ssp0_sclk; + sclk_rate = 6144000; + break; + case 1: + mclk = priv->ssp1_mclk; + sclk = priv->ssp1_sclk; + sclk_rate = 3072000; + break; + default: + dev_err(card->dev, "Invalid ssp_num %d\n", ssp_num); + return -EINVAL; + } + /* * MCLK/SCLK need to be ON early for a successful synchronization of * codec internal clock. And the clocks are turned off during @@ -92,37 +112,39 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w, switch (event) { case SND_SOC_DAPM_PRE_PMU: /* Enable MCLK */ - ret = clk_set_rate(priv->mclk, 24000000); + ret = clk_set_rate(mclk, 24000000); if (ret < 0) { - dev_err(card->dev, "Can't set rate for mclk, err: %d\n", - ret); + dev_err(card->dev, "Can't set rate for ssp%d_mclk, err: %d\n", + ssp_num, ret); return ret; } - ret = clk_prepare_enable(priv->mclk); + ret = clk_prepare_enable(mclk); if (ret < 0) { - dev_err(card->dev, "Can't enable mclk, err: %d\n", ret); + dev_err(card->dev, "Can't enable ssp%d_mclk, err: %d\n", + ssp_num, ret); return ret; } /* Enable SCLK */ - ret = clk_set_rate(priv->sclk, 3072000); + ret = clk_set_rate(sclk, sclk_rate); if (ret < 0) { - dev_err(card->dev, "Can't set rate for sclk, err: %d\n", - ret); - clk_disable_unprepare(priv->mclk); + dev_err(card->dev, "Can't set rate for ssp%d_sclk, err: %d\n", + ssp_num, ret); + clk_disable_unprepare(mclk); return ret; } - ret = clk_prepare_enable(priv->sclk); + ret = clk_prepare_enable(sclk); if (ret < 0) { - dev_err(card->dev, "Can't enable sclk, err: %d\n", ret); - clk_disable_unprepare(priv->mclk); + dev_err(card->dev, "Can't enable ssp%d_sclk, err: %d\n", + ssp_num, ret); + clk_disable_unprepare(mclk); } break; case SND_SOC_DAPM_POST_PMD: - clk_disable_unprepare(priv->mclk); - clk_disable_unprepare(priv->sclk); + clk_disable_unprepare(mclk); + clk_disable_unprepare(sclk); break; default: return 0; @@ -131,6 +153,18 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w, return 0; } +static int platform_clock_control_ssp0(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *k, int event) +{ + return platform_clock_control(w, k, event, 0); +} + +static int platform_clock_control_ssp1(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *k, int event) +{ + return platform_clock_control(w, k, event, 1); +} + static const struct snd_soc_dapm_widget kabylake_widgets[] = { SND_SOC_DAPM_HP("Headphone Jack", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), @@ -139,15 +173,17 @@ static const struct snd_soc_dapm_widget kabylake_widgets[] = { SND_SOC_DAPM_MIC("DMIC", NULL), SND_SOC_DAPM_SPK("HDMI1", NULL), SND_SOC_DAPM_SPK("HDMI2", NULL), - SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, - platform_clock_control, SND_SOC_DAPM_PRE_PMU | + SND_SOC_DAPM_SUPPLY("Platform Clock SSP0", SND_SOC_NOPM, 0, 0, + platform_clock_control_ssp0, SND_SOC_DAPM_PRE_PMU | + SND_SOC_DAPM_POST_PMD), + SND_SOC_DAPM_SUPPLY("Platform Clock SSP1", SND_SOC_NOPM, 0, 0, + platform_clock_control_ssp1, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), - }; static const struct snd_soc_dapm_route kabylake_map[] = { /* Headphones */ - { "Headphone Jack", NULL, "Platform Clock" }, + { "Headphone Jack", NULL, "Platform Clock SSP1" }, { "Headphone Jack", NULL, "HPOL" }, { "Headphone Jack", NULL, "HPOR" }, @@ -156,7 +192,7 @@ static const struct snd_soc_dapm_route kabylake_map[] = { { "Right Spk", NULL, "Right BE_OUT" }, /* other jacks */ - { "Headset Mic", NULL, "Platform Clock" }, + { "Headset Mic", NULL, "Platform Clock SSP1" }, { "IN1P", NULL, "Headset Mic" }, { "IN1N", NULL, "Headset Mic" }, @@ -180,6 +216,7 @@ static const struct snd_soc_dapm_route kabylake_map[] = { { "ssp0 Rx", NULL, "Right HiFi Capture" }, /* DMIC */ + { "DMIC", NULL, "Platform Clock SSP0" }, { "DMIC1L", NULL, "DMIC" }, { "DMIC1R", NULL, "DMIC" }, { "DMIC2L", NULL, "DMIC" }, @@ -704,6 +741,29 @@ static struct snd_soc_card kabylake_audio_card = { .late_probe = kabylake_card_late_probe, }; +static int kabylake_audio_clk_get(struct device *dev, const char *id, + struct clk **clk) +{ + int ret = 0; + + if (!clk) + return -EINVAL; + + *clk = devm_clk_get(dev, id); + if (IS_ERR(*clk)) { + ret = PTR_ERR(*clk); + if (ret == -ENOENT) { + dev_info(dev, "Failed to get %s, defer probe\n", id); + return -EPROBE_DEFER; + } + + dev_err(dev, "Failed to get %s with err:%d\n", id, ret); + return ret; + } + + return ret; +} + static int kabylake_audio_probe(struct platform_device *pdev) { struct kbl_codec_private *ctx; @@ -724,33 +784,21 @@ static int kabylake_audio_probe(struct platform_device *pdev) dmic_constraints = mach->mach_params.dmic_num == 2 ? &constraints_dmic_2ch : &constraints_dmic_channels; - ctx->mclk = devm_clk_get(&pdev->dev, "ssp1_mclk"); - if (IS_ERR(ctx->mclk)) { - ret = PTR_ERR(ctx->mclk); - if (ret == -ENOENT) { - dev_info(&pdev->dev, - "Failed to get ssp1_mclk, defer probe\n"); - return -EPROBE_DEFER; - } + ret = kabylake_audio_clk_get(&pdev->dev, "ssp0_mclk", &ctx->ssp0_mclk); + if (ret != 0) + return ret; - dev_err(&pdev->dev, "Failed to get ssp1_mclk with err:%d\n", - ret); + ret = kabylake_audio_clk_get(&pdev->dev, "ssp0_sclk", &ctx->ssp0_sclk); + if (ret != 0) return ret; - } - ctx->sclk = devm_clk_get(&pdev->dev, "ssp1_sclk"); - if (IS_ERR(ctx->sclk)) { - ret = PTR_ERR(ctx->sclk); - if (ret == -ENOENT) { - dev_info(&pdev->dev, - "Failed to get ssp1_sclk, defer probe\n"); - return -EPROBE_DEFER; - } + ret = kabylake_audio_clk_get(&pdev->dev, "ssp1_mclk", &ctx->ssp1_mclk); + if (ret != 0) + return ret; - dev_err(&pdev->dev, "Failed to get ssp1_sclk with err:%d\n", - ret); + ret = kabylake_audio_clk_get(&pdev->dev, "ssp1_sclk", &ctx->ssp1_sclk); + if (ret != 0) return ret; - } return devm_snd_soc_register_card(&pdev->dev, &kabylake_audio_card); } -- 2.7.4

3 2

Re: [alsa-devel] [PATCH] ASoC: fsl_asrc: refine the setting of internal clock divider
by S.j. Wang 25 Oct '19

25 Oct '19

Hi > > On Wed, Oct 23, 2019 at 06:25:20AM +0000, S.j. Wang wrote: > > > On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote: > > > > For P2P output, the output divider should align with the output > > > > sample > > > > > > I think we should avoid "P2P" (or "M2M") keyword in the mainline > > > code as we know M2M will never get merged while somebody working > > > with the mainline and caring about new feature might be confused. > > > > Ok. But we still curious that is there a way to upstream m2m? > > Hmm..I would love to see that happening. Here is an old discussion that > you may want to take a look: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > man.alsa-project.org%2Fpipermail%2Falsa-devel%2F2014- > May%2F076797.html&data=02%7C01%7Cshengjiu.wang%40nxp.com%7 > Ce902d2bac4254d2faa0f08d757ecac0e%7C686ea1d3bc2b4c6fa92cd99c5c301 > 635%7C0%7C0%7C637074546320396681&sdata=bg%2BLwRQnUPhW8f > mE972O%2F53MyVftJkK140PSnmC%2FDKQ%3D&reserved=0 > > > > It makes sense to me, yet I feel that the delay at the beginning of > > > the audio playback might be longer as a compromise. I am okay with > > > this decision though... > > > > > > > The maximum divider of asrc clock is 1024, but there is no > > > > judgement for this limitaion in driver, which may cause the > > > > divider setting not correct. > > > > > > > > For non-ideal ratio mode, the clock rate should divide the sample > > > > rate with no remainder, and the quotient should be less than 1024. > > > > > > > > Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> > > > > > @@ -351,7 +352,9 @@ static int fsl_asrc_config_pair(struct > > > > fsl_asrc_pair > > > *pair) > > > > /* We only have output clock for ideal ratio mode */ > > > > clk = asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]]; > > > > > > > > - div[IN] = clk_get_rate(clk) / inrate; > > > > + clk_rate = clk_get_rate(clk); > > > > > > The fsl_asrc.c file has config.inclk being set to INCLK_NONE and > > > this sets the "ideal" in this function to true. So, although we tend > > > to not use ideal ratio setting for p2p cases, yet the input clock is > > > still not physically connected, so we still use output clock for div[IN] > calculation? > > > > For p2p case, it can be ideal or non-ideal. For non-ideal, we still > > use Output clock for div calculation. > > > > > > > > I am thinking something simplier: if we decided not to use ideal > > > ratio for "P2P", instead of adding "bool p2p" with the confusing > > > "ideal" in this function, could we just set config.inclk to the same > > > clock as the output one for "P2P"? By doing so, "P2P" won't go > > > through ideal ratio mode while still having a clock rate from the output > clock for div[IN] calculation here. > > > > Bool p2p is to force output rate to be sample rate, no impact to ideal > > Ratio mode. > > I just realized that the function has a bottom part for ideal mode > exclusively -- if we treat p2p as !ideal, those configurations will be missing. > So you're right, should have an extra boolean variable. > > > > > > > > + rem[IN] = do_div(clk_rate, inrate); > > > > + div[IN] = (u32)clk_rate; > > > > if (div[IN] == 0) { > > > > > > Could we check div[IN] and rem[IN] here? Like: > > > if (div[IN] == 0 || div[IN] > 1024) { > > > pair_err(); > > > goto out; > > > } > > > > > > if (!ideal && rem[IN]) { > > > pair_err(); > > > goto out; > > > } > > > > > > According to your commit log, I think the max-1024 limitation should > > > be applied to all cases, not confined to "!ideal" cases right? And > > > we should add some comments also, indicating it is limited by hardware. > > > > For ideal mode, my test result is the divider not impact the output result. > > Which means it is ok for ideal mode even divider is not correct... > > OK. > > > > > > > > pair_err("failed to support input sample rate %dHz > > > > by > > > asrck_%x\n", > > > > inrate, clk_index[ideal ? OUT : > > > > IN]); @@ > > > > -360,11 +363,20 @@ static int fsl_asrc_config_pair(struct > > > > fsl_asrc_pair *pair) > > > > > > > > clk = asrc_priv->asrck_clk[clk_index[OUT]]; > > > > > > > > - /* Use fixed output rate for Ideal Ratio mode (INCLK_NONE) */ > > > > - if (ideal) > > > > - div[OUT] = clk_get_rate(clk) / IDEAL_RATIO_RATE; > > > > - else > > > > - div[OUT] = clk_get_rate(clk) / outrate; > > > > + /* > > > > + * When P2P mode, output rate should align with the out > samplerate. > > > > + * if set too high output rate, there will be lots of Overload. > > > > + * When M2M mode, output rate should also need to align with > > > > + the out > > > > > > For this "should", do you actually mean "M2M could also"? Sorry, I'm > > > just trying to understand everyting here, not intentionally being picky at > words. > > > My understanding is that we still keep the ideal ratio setting > > > because "M2M" still uses it. > > > > We use IDEAL_RATIO_RATE as output rate for m2m mode, it likes a Tricky > > operation, in order to improve the performance. I think The correct > > operation is to use the real output rate, but the performance Is bad. > > So it is a compromise. > > I see. > > > > > > > > + * samplerate, but M2M must use less time to achieve good > > > performance. > > > > + */ > > > > + clk_rate = clk_get_rate(clk); > > > > + if (p2p || !ideal) { > > > > + rem[OUT] = do_div(clk_rate, outrate); > > > > + div[OUT] = clk_rate; > > > > + } else { > > > > + rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE); > > > > + div[OUT] = clk_rate; > > > > + } > > > > > > > > if (div[OUT] == 0) { > > > > pair_err("failed to support output sample rate %dHz > > > > by asrck_%x\n", @@ -372,6 +384,16 @@ static int > > > > fsl_asrc_config_pair(struct > > > fsl_asrc_pair *pair) > > > > return -EINVAL; > > > > } > > > > > > > > + if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || > > > > + rem[IN] != 0 || rem[OUT] != 0)) { > > > > + if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || rem[IN] > > > > + || rem[OUT] != 0)) { > > > > > > So for ideal == true, these limitaions are not applied any more? > > > Remember that the "ideal" is true for "p2p == true" cases here. > > > > No, not applied. for ideal, the div don't impact the output result > > Even it is not accurate. > > I see. > > > > > > > > + pair_err("The divider can't be used for non ideal mode\n"); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + /* Divider range is [1, 1024] */ > > > > + div[IN] = min_t(u32, 1024, div[IN]); > > > > + div[OUT] = min_t(u32, 1024, div[OUT]); > > > > > > Hmm, this looks like we want to allow ideal ratio cases and p2p > > > cases to operate any way, even if the divider wasn't within the > > > range to get the in/out rates from the output clock? > > > > Yes. We still allow the p2p = true, ideal = false. Note that p2p is > > not Equal to ideal. > > Got it. > > Overall, I feel it's better to have a naming to state the purpose of using > ideal configurations without the IDEAL_RATIO_RATE setup. > bool use_ideal_rate; > And we can put into the asrc_config structure if there's no major problem. > Asrc_config may exposed to user, I don't think user need to care about The using of ideal rate or not. > So the condition check for the calculation would be: > + if (ideal && config->use_ideal_rate) > + rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE); > + else > + rem[OUT] = do_div(clk_rate, outrate); > + div[OUT] = clk_rate; > > And for that if (!ideal && div[IN]....rem[OUT]), I feel it would be clear to > have them separately, as the existing "div[IN] == 0" > and "div[OUT] == 0" checks, so that we can tell users which side of the > divider is out of range and what the sample rate and clock rate are. > Do you mean need to combine this judgement with "div[IN] == 0" Or "div[OUT] == 0"? Best regards Wang shengjiu

2 1

Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Add spin lock to protect reset and stop
by S.j. Wang 25 Oct '19

25 Oct '19

Hi > > On Wed, Oct 23, 2019 at 03:29:49PM +0800, Shengjiu Wang wrote: > > xrun may happen at the end of stream, the > > trigger->fsl_esai_trigger_stop maybe called in the middle of > > fsl_esai_hw_reset, this may cause esai in wrong state after stop, and > > there may be endless xrun interrupt. > > What about fsl_esai_trigger_start? It touches ESAI_xFCR_xFEN bit that is > being checked in the beginning of fsl_esai_hw_reset. > > Could the scenario below be possible also? > > 1) ESAI TX starts > 2) Xrun happens to TX > 3) Starting fsl_esai_hw_reset (enabled[TX] = true; enabled[RX] = false) > 4) ESAI RX starts > 5) Finishing fsl_esai_hw_reset (enabled[RX] is still false) > > Good catch, this may possible. Will update in v2. Best regards Wang shengjiu

1 0

[alsa-devel] [PATCH v2 00/22] ASoC: soc-core cleanup - step 4
by Kuninori Morimoto 25 Oct '19

25 Oct '19

Hi Mark These are v2 of soc-core cleanup. These are related to topology, but according to Intel CI, there is no damage to it. Some of them need more review. I added some mark to such patch. I merged posted-but-not-yet-accepted patch on top of it. Kuninori Morimoto (22): ASoC: soc-pcm: fixup dpcm_prune_paths() loop continue ASoC: soc-core: remove for_each_rtdcom_safe() ASoC: soc-core: add for_each_rtd_components() and replace ASoC: soc-core: snd_soc_unbind_card() cleanup ASoC: soc-core: remove unneeded snd_soc_tplg_component_remove() ASoC: soc-core: move soc_init_dai_link() ASoC: soc-core: tidyup soc_init_dai_link() ASoC: soc-core: remove duplicated soc_is_dai_link_bound() ASoC: soc-core: call soc_bind_dai_link() under snd_soc_add_dai_link() ASoC: soc-core: add soc_unbind_dai_link() ASoC: soc-core: move snd_soc_lookup_component() ASoC: soc-core: add snd_soc_del_component_unlocked() ASoC: soc-core: remove snd_soc_component_add/del() ASoC: soc-core: use snd_soc_lookup_component() at snd_soc_unregister_component() ASoC: soc-core: move snd_soc_register_dai() ASoC: soc-core: move snd_soc_unregister_dais() ASoC: soc-core: add snd_soc_unregister_dai() ASoC: soc-core: have legacy_dai_naming at snd_soc_register_dai() ASoC: soc-core: don't call snd_soc_dapm_new_dai_widgets() at snd_soc_register_dai() ASoC: soc-core: call snd_soc_register_dai() from snd_soc_register_dais() ASoC: soc-core: remove topology specific operation ASoC: soc.h: dobj is used only when SND_SOC_TOPOLOGY include/sound/soc.h | 25 ++- sound/soc/soc-component.c | 43 +--- sound/soc/soc-compress.c | 52 ++--- sound/soc/soc-core.c | 561 ++++++++++++++++++++-------------------------- sound/soc/soc-pcm.c | 55 ++--- sound/soc/soc-topology.c | 17 +- 6 files changed, 322 insertions(+), 431 deletions(-) -- 2.7.4

2 28

[alsa-devel] [PATCH] ASoC: soc-dpcm: tidyup for_each_dpcm_xx() macro
by Kuninori Morimoto 25 Oct '19

25 Oct '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> for_each_dpcm_xx() macro is using "dpcm" as parameter (1), but, it is also struct member (2). #define for_each_dpcm_fe(be, stream, dpcm) \ list_for_each_entry(dpcm, &(be)->dpcm[stream]...) ^^^^(1) ^^^^(2) Thus, it will be compile error if user not used "dpcm" as parameter for_each_dpcm_fe(be, stream, dp) ^^ This patch fixup it. Reported-by: Pavel Machek <pavel(a)denx.de> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- include/sound/soc-dpcm.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/sound/soc-dpcm.h b/include/sound/soc-dpcm.h index ff53037..fbe9e3d 100644 --- a/include/sound/soc-dpcm.h +++ b/include/sound/soc-dpcm.h @@ -103,13 +103,13 @@ struct snd_soc_dpcm_runtime { int trigger_pending; /* trigger cmd + 1 if pending, 0 if not */ }; -#define for_each_dpcm_fe(be, stream, dpcm) \ - list_for_each_entry(dpcm, &(be)->dpcm[stream].fe_clients, list_fe) +#define for_each_dpcm_fe(be, stream, _dpcm) \ + list_for_each_entry(_dpcm, &(be)->dpcm[stream].fe_clients, list_fe) -#define for_each_dpcm_be(fe, stream, dpcm) \ - list_for_each_entry(dpcm, &(fe)->dpcm[stream].be_clients, list_be) -#define for_each_dpcm_be_safe(fe, stream, dpcm, _dpcm) \ - list_for_each_entry_safe(dpcm, _dpcm, &(fe)->dpcm[stream].be_clients, list_be) +#define for_each_dpcm_be(fe, stream, _dpcm) \ + list_for_each_entry(_dpcm, &(fe)->dpcm[stream].be_clients, list_be) +#define for_each_dpcm_be_safe(fe, stream, _dpcm, __dpcm) \ + list_for_each_entry_safe(_dpcm, __dpcm, &(fe)->dpcm[stream].be_clients, list_be) /* can this BE stop and free */ int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe, -- 2.7.4

2 2

[alsa-devel] [PATCH v4 0/2] Add CML M/C for RT5682 and RT1011
by sathya.prakash.m.r＠intel.com 24 Oct '19

24 Oct '19

From: Sathya Prakash M R <sathya.prakash.m.r(a)intel.com> The series adds CML m/c driver with RT5682 on SSP0 and RT1011 on SSP1. The RT1011 is smart AMP which supports 2 Whoofers and 2 tweeter support. RT5682 is headset codec supporting playback and record. The m/c supports HDMI playback and DMIC record. Naveen Manohar (2): ASoC: Intel: boards: Add CML m/c using RT1011 and RT5682 ASoC: Intel: Add acpi match for rt1011 based m/c driver sound/soc/intel/boards/Kconfig | 18 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/cml_rt1011_rt5682.c | 473 ++++++++++++++++++++++ sound/soc/intel/common/soc-acpi-intel-cnl-match.c | 7 + 4 files changed, 500 insertions(+) create mode 100644 sound/soc/intel/boards/cml_rt1011_rt5682.c -- V3 Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Changes from V3: repost with more recipients and edits to commit messages Changes from V2: re ordered match table to ensure non i2c device matches are at the end Changes from V1: Addressed comments on ASoC: Intel: boards: Add CML m/c using RT1011 and RT5682 1.9.1

3 5

[alsa-devel] KASAN: use-after-free Read in build_audio_procunit
by syzbot 24 Oct '19

24 Oct '19

Hello, syzbot found the following crash on: HEAD commit: 22be26f7 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=17cdccc4e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5 dashboard link: https://syzkaller.appspot.com/bug?extid=fd965c77e4711eb13b82 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13fe752f600000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17989fd8e00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fd965c77e4711eb13b82(a)syzkaller.appspotmail.com usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: syz usb 1-1: Manufacturer: syz usb 1-1: SerialNumber: syz ================================================================== BUG: KASAN: use-after-free in uac_extension_unit_iExtension include/uapi/linux/usb/audio.h:483 [inline] BUG: KASAN: use-after-free in build_audio_procunit+0xeab/0x13f0 sound/usb/mixer.c:2434 Read of size 1 at addr ffff8881d4c0140d by task kworker/0:1/12 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506 kasan_report+0xe/0x20 mm/kasan/common.c:634 uac_extension_unit_iExtension include/uapi/linux/usb/audio.h:483 [inline] build_audio_procunit+0xeab/0x13f0 sound/usb/mixer.c:2434 parse_audio_extension_unit sound/usb/mixer.c:2483 [inline] parse_audio_unit+0x1812/0x36f0 sound/usb/mixer.c:2761 snd_usb_mixer_controls+0x715/0xb90 sound/usb/mixer.c:3095 snd_usb_create_mixer+0x2b5/0x1890 sound/usb/mixer.c:3445 usb_audio_probe+0xc76/0x2010 sound/usb/card.c:653 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2201 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2201 usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 12: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:510 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:483 kmalloc include/linux/slab.h:561 [inline] usb_alloc_urb+0x65/0xb0 drivers/usb/core/urb.c:73 usb_internal_control_msg drivers/usb/core/message.c:94 [inline] usb_control_msg+0x1c9/0x4a0 drivers/usb/core/message.c:152 usb_get_descriptor+0xc1/0x1b0 drivers/usb/core/message.c:647 usb_get_configuration+0x28e/0x3050 drivers/usb/core/config.c:836 usb_enumerate_device drivers/usb/core/hub.c:2369 [inline] usb_new_device+0xd3/0x160 drivers/usb/core/hub.c:2505 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 12: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] kasan_set_free_info mm/kasan/common.c:332 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:471 slab_free_hook mm/slub.c:1424 [inline] slab_free_freelist_hook mm/slub.c:1475 [inline] slab_free mm/slub.c:3018 [inline] kfree+0xe4/0x320 mm/slub.c:3967 urb_destroy drivers/usb/core/urb.c:26 [inline] kref_put include/linux/kref.h:65 [inline] usb_free_urb.part.0+0x7a/0xc0 drivers/usb/core/urb.c:95 usb_free_urb+0x1b/0x30 drivers/usb/core/urb.c:94 usb_start_wait_urb+0x1e5/0x2b0 drivers/usb/core/message.c:79 usb_internal_control_msg drivers/usb/core/message.c:101 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:152 usb_get_descriptor+0xc1/0x1b0 drivers/usb/core/message.c:647 usb_get_configuration+0x28e/0x3050 drivers/usb/core/config.c:836 usb_enumerate_device drivers/usb/core/hub.c:2369 [inline] usb_new_device+0xd3/0x160 drivers/usb/core/hub.c:2505 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff8881d4c01400 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 13 bytes inside of 192-byte region [ffff8881d4c01400, ffff8881d4c014c0) The buggy address belongs to the page: page:ffffea0007530040 refcount:1 mapcount:0 mapping:ffff8881da002a00 index:0x0 flags: 0x200000000000200(slab) raw: 0200000000000200 ffffea000754fec0 0000000200000002 ffff8881da002a00 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d4c01300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881d4c01380: 00 00 00 07 fc fc fc fc fc fc fc fc fc fc fc fc > ffff8881d4c01400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d4c01480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8881d4c01500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

2 1

[alsa-devel] KASAN: use-after-free Read in parse_term_proc_unit
by syzbot 24 Oct '19

24 Oct '19

Hello, syzbot found the following crash on: HEAD commit: 22be26f7 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=13a38628e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5 dashboard link: https://syzkaller.appspot.com/bug?extid=97e24236f1e2918ad968 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12184764e00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1432ae28e00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+97e24236f1e2918ad968(a)syzkaller.appspotmail.com usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: syz usb 1-1: Manufacturer: syz usb 1-1: SerialNumber: syz ================================================================== BUG: KASAN: use-after-free in uac_processing_unit_iProcessing include/uapi/linux/usb/audio.h:429 [inline] BUG: KASAN: use-after-free in parse_term_proc_unit+0x57a/0x5e0 sound/usb/mixer.c:896 Read of size 1 at addr ffff8881d5346d0e by task kworker/1:2/83 CPU: 1 PID: 83 Comm: kworker/1:2 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506 kasan_report+0xe/0x20 mm/kasan/common.c:634 uac_processing_unit_iProcessing include/uapi/linux/usb/audio.h:429 [inline] parse_term_proc_unit+0x57a/0x5e0 sound/usb/mixer.c:896 __check_input_term+0xc32/0x13f0 sound/usb/mixer.c:984 parse_audio_feature_unit sound/usb/mixer.c:1875 [inline] parse_audio_unit+0x101d/0x36f0 sound/usb/mixer.c:2753 snd_usb_mixer_controls+0x715/0xb90 sound/usb/mixer.c:3095 snd_usb_create_mixer+0x2b5/0x1890 sound/usb/mixer.c:3445 usb_audio_probe+0xc76/0x2010 sound/usb/card.c:653 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2201 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2201 usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 83: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:510 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:483 kmalloc include/linux/slab.h:561 [inline] usb_alloc_urb+0x65/0xb0 drivers/usb/core/urb.c:73 usb_internal_control_msg drivers/usb/core/message.c:94 [inline] usb_control_msg+0x1c9/0x4a0 drivers/usb/core/message.c:152 usb_get_descriptor+0xc1/0x1b0 drivers/usb/core/message.c:647 usb_get_configuration+0x28e/0x3050 drivers/usb/core/config.c:836 usb_enumerate_device drivers/usb/core/hub.c:2369 [inline] usb_new_device+0xd3/0x160 drivers/usb/core/hub.c:2505 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 83: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] kasan_set_free_info mm/kasan/common.c:332 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:471 slab_free_hook mm/slub.c:1424 [inline] slab_free_freelist_hook mm/slub.c:1475 [inline] slab_free mm/slub.c:3018 [inline] kfree+0xe4/0x320 mm/slub.c:3967 urb_destroy drivers/usb/core/urb.c:26 [inline] kref_put include/linux/kref.h:65 [inline] usb_free_urb.part.0+0x7a/0xc0 drivers/usb/core/urb.c:95 usb_free_urb+0x1b/0x30 drivers/usb/core/urb.c:94 usb_start_wait_urb+0x1e5/0x2b0 drivers/usb/core/message.c:79 usb_internal_control_msg drivers/usb/core/message.c:101 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:152 usb_get_descriptor+0xc1/0x1b0 drivers/usb/core/message.c:647 usb_get_configuration+0x28e/0x3050 drivers/usb/core/config.c:836 usb_enumerate_device drivers/usb/core/hub.c:2369 [inline] usb_new_device+0xd3/0x160 drivers/usb/core/hub.c:2505 hub_port_connect drivers/usb/core/hub.c:5183 [inline] hub_port_connect_change drivers/usb/core/hub.c:5323 [inline] port_event drivers/usb/core/hub.c:5469 [inline] hub_event+0x1dd0/0x37e0 drivers/usb/core/hub.c:5551 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff8881d5346d00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 14 bytes inside of 192-byte region [ffff8881d5346d00, ffff8881d5346dc0) The buggy address belongs to the page: page:ffffea000754d180 refcount:1 mapcount:0 mapping:ffff8881da002a00 index:0x0 flags: 0x200000000000200(slab) raw: 0200000000000200 ffffea0007548ac0 0000000900000009 ffff8881da002a00 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d5346c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881d5346c80: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc > ffff8881d5346d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d5346d80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8881d5346e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

2 1

[alsa-devel] [PATCH] ALSA: hda/realtek - Fix 2 front mics of codec 0x623
by Aaron Ma 24 Oct '19

24 Oct '19

These 2 ThinkCentres installed a new realtek codec ID 0x623, it has 2 front mics with the same location on pin 0x18 and 0x19. Apply fixup ALC283_FIXUP_HEADSET_MIC to change 1 front mic location to right, then pulseaudio can handle them. One "Front Mic" and one "Mic" will be shown, and audio output works fine. Signed-off-by: Aaron Ma <aaron.ma(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b000b36ac3c6..c34d8b435f58 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7186,6 +7186,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x312f, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION), SND_PCI_QUIRK(0x17aa, 0x313c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION), SND_PCI_QUIRK(0x17aa, 0x3151, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x3178, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x3176, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI), SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC), SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC269_FIXUP_DMIC_THINKPAD_ACPI), @@ -9187,6 +9189,7 @@ static const struct hda_device_id snd_hda_id_realtek[] = { HDA_CODEC_ENTRY(0x10ec0298, "ALC298", patch_alc269), HDA_CODEC_ENTRY(0x10ec0299, "ALC299", patch_alc269), HDA_CODEC_ENTRY(0x10ec0300, "ALC300", patch_alc269), + HDA_CODEC_ENTRY(0x10ec0623, "ALC623", patch_alc269), HDA_CODEC_REV_ENTRY(0x10ec0861, 0x100340, "ALC660", patch_alc861), HDA_CODEC_ENTRY(0x10ec0660, "ALC660-VD", patch_alc861vd), HDA_CODEC_ENTRY(0x10ec0861, "ALC861", patch_alc861), -- 2.17.1

4 10

[alsa-devel] [PATCH 0/2] ASoC: hdmi-codec: fix locking issue
by Jerome Brunet 24 Oct '19

24 Oct '19

This patchset fixes the locking issue reported by Russell. As explained a mutex was used as flag and held while returning to userspace. Patch 2 is entirely optional and switches from bit atomic operation to mutex again. I tend to prefer bit atomic operation in this particular case but either way should be fine. Jerome Brunet (2): Revert "ASoC: hdmi-codec: re-introduce mutex locking" ASoC: hdmi-codec: re-introduce mutex locking again sound/soc/codecs/hdmi-codec.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) -- 2.21.0

4 10

[alsa-devel] [PATCH] ASoC: rt5650: Add Kahlee platform specfic changes
by Curtis Malainey 24 Oct '19

24 Oct '19

From: Akshu Agrawal <akshu.agrawal(a)amd.com> Add platform specific data for Kahlee project. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> Signed-off-by: Shirish S <shirish.s(a)amd.com> Signed-off-by: Curtis Malainey <cujomalainey(a)chromium.org> --- sound/soc/codecs/rt5645.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 1c06b3b9218c5..a15e4ecd2a241 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -3636,6 +3636,12 @@ static const struct rt5645_platform_data lattepanda_board_platform_data = { .inv_jd1_1 = true }; +static const struct rt5645_platform_data kahlee_platform_data = { + .dmic1_data_pin = RT5645_DMIC_DATA_GPIO5, + .dmic2_data_pin = RT5645_DMIC_DATA_IN2P, + .jd_mode = 3, +}; + static const struct dmi_system_id dmi_platform_data[] = { { .ident = "Chrome Buddy", @@ -3742,6 +3748,13 @@ static const struct dmi_system_id dmi_platform_data[] = { }, .driver_data = (void *)&lattepanda_board_platform_data, }, + { + .ident = "Chrome Kahlee", + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "Kahlee"), + }, + .driver_data = (void *)&kahlee_platform_data, + }, { } }; -- 2.24.0.rc0.303.g954a862665-goog

2 1

[alsa-devel] [PATCH v3 0/5] soundwire: intel/cadence: better initialization
by Pierre-Louis Bossart 24 Oct '19

24 Oct '19

Changes since v2: addressed feedback from Vinod Koul on patch 2&4 Add kernel taint when using debugfs hw_reset (similar to regmap) Remove useless goto label Changes since v1: addressed feedback from Vinod Koul clarified init changes impact Intel and Cadence sides remove unnecessary intermediate variable disable interrupts when exit_reset fails, updated error handling returned -EINVAL on debugfs invalid parameter Pierre-Louis Bossart (5): soundwire: intel/cadence: fix startup sequence soundwire: cadence_master: add hw_reset capability in debugfs soundwire: intel: add helper for initialization soundwire: intel/cadence: add flag for interrupt enable soundwire: cadence_master: make clock stop exit configurable on init drivers/soundwire/cadence_master.c | 134 +++++++++++++++++++++-------- drivers/soundwire/cadence_master.h | 5 +- drivers/soundwire/intel.c | 39 ++++++--- 3 files changed, 129 insertions(+), 49 deletions(-) -- 2.20.1

2 6

[alsa-devel] [PATCH 0/2] ASoC: SOF: make hw_info platform specific
by Pierre-Louis Bossart 24 Oct '19

24 Oct '19

The SOF core blindly sets the hw_info, when it should really be platform-specific. This move enable us to temporarily fix PulseAudio issues resulting from inaccuracies in the hw_ptr position provided by the firmware on Baytrail-Broadwell. This is the first time we experiment with the GitHub low-level API to automagically keep track of 'approvers' by inserting a Reviewed-by tag when merging a pull-request, thanks to Ranjani for her initial work and bearing with my habit of breaking things :-) Pierre-Louis Bossart (2): ASoC: SOF: define INFO_ flags in dsp_ops ASoC: SOF: Intel: only support INFO_BATCH for legacy platforms sound/soc/sof/imx/imx8.c | 7 +++++++ sound/soc/sof/intel/apl.c | 7 +++++++ sound/soc/sof/intel/bdw.c | 9 ++++++++- sound/soc/sof/intel/byt.c | 21 +++++++++++++++++++++ sound/soc/sof/intel/cnl.c | 7 +++++++ sound/soc/sof/pcm.c | 8 +++----- sound/soc/sof/sof-priv.h | 3 +++ 7 files changed, 56 insertions(+), 6 deletions(-) -- 2.20.1

2 3

[alsa-devel] [PATCH] soundwire: slave: fix scanf format
by Pierre-Louis Bossart 24 Oct '19

24 Oct '19

fix cppcheck warning: [drivers/soundwire/slave.c:145]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'signed int *'. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- drivers/soundwire/slave.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c index 48a63ca130d2..6473fa602f82 100644 --- a/drivers/soundwire/slave.c +++ b/drivers/soundwire/slave.c @@ -128,7 +128,8 @@ int sdw_of_find_slaves(struct sdw_bus *bus) struct device_node *node; for_each_child_of_node(bus->dev->of_node, node) { - int link_id, sdw_version, ret, len; + int link_id, ret, len; + unsigned int sdw_version; const char *compat = NULL; struct sdw_slave_id id; const __be32 *addr; -- 2.20.1

2 1

[alsa-devel] AC97 audio-routing [was: Recording on WM9712]
by Matej Kupljen 24 Oct '19

24 Oct '19

Hi all, I am not sure how to specify audio-routing for AC97 codec. If I use the similar setting as the UDOO board (which was the only board that uses AC97 codec I could find) I get warnings during booting: [ 3.261369] fsl-asoc-card sound: ac97-hifi <-> 202c000.ssi mapping ok [ 3.267917] fsl-asoc-card sound: ASoC: no sink widget found for Playback [ 3.274642] fsl-asoc-card sound: ASoC: Failed to add route AC97 Playback -> direct -> Playback [ 3.283309] fsl-asoc-card sound: ASoC: no source widget found for Capture [ 3.290141] fsl-asoc-card sound: ASoC: Failed to add route Capture -> direct -> AC97 Capture This was tested on kernel Linux version 4.14.134. However, the card is detected: [ 4.041646] ALSA device list: [ 4.044628] #0: ac97-audio and I can use it for playback normally, but the capture is "slow" as described in my previous e-mail. Then I tried to build and boot the latest kernel from GIT (Linux version 5.4.0-rc4) using the same DTS, I get additional warnings from the kernel: [ 2.639878] fsl-asoc-card sound: ac97-hifi <-> 202c000.ssi mapping ok [ 2.651321] fsl-asoc-card sound: ASoC: source widget AC97 Playback overwritten [ 2.658595] fsl-asoc-card sound: ASoC: no sink widget found for Playback [ 2.665317] fsl-asoc-card sound: ASoC: Failed to add route AC97 Playback -> direct -> Playback [ 2.673974] fsl-asoc-card sound: ASoC: sink widget AC97 Capture overwritten [ 2.680986] fsl-asoc-card sound: ASoC: no source widget found for Capture [ 2.687822] fsl-asoc-card sound: ASoC: Failed to add route Capture -> direct -> AC97 Capture [ 2.718636] fsl-asoc-card sound: snd_soc_register_card failed (-19) and the card is not detected: [ 3.285543] ALSA device list: [ 3.288518] No soundcards found. As you can see, there are additional warnings about widget overwrite, because this check was added to the latest kernel, as seen from the kernel source code. This is the setting from my DTS file: sound { compatible = "fsl,imx-audio-ac97"; model = "fsl,imx6q-ac97"; audio-cpu = <&ssi2>; audio-routing = "RX", "Mic Jack", "Headphone Jack", "TX"; mux-int-port = <2>; mux-ext-port = <5>; }; As you can see, I do not even specify any routing about AC97 Playback/Capture and I still get those warnings. For the test, I commented out the code in sound/soc/soc-core.c in function snd_soc_instantiate_card, to ignore the return values from the call to snd_soc_dapm_add_routes and then I can use the card for playback, but the recording has the issues again. What seems to be wrong with this AC97 audio routing? Any suggestions? I am willing to test this on the latest kernel, or from some other GIT repo if needed. Thanks and BR, Matej

1 0

[alsa-devel] [PATCH] ALSA: usb-audio: Add Gustard U16/X26 device family to quirks for native DSD support
by Fly Pig 24 Oct '19

24 Oct '19

Hi There This patch add native DSD support for Gustard U16/X26 USB Interface. Tested on my unit, working properly. Hence submit the patch. Cheers. Thank you very much. Pig --- a/sound/usb/quirks.c 2019-09-22 21:28:09.757897000 +0000 +++ b/sound/usb/quirks.c 2019-09-22 21:33:36.892274800 +0000 @@ -1369,6 +1369,7 @@ case USB_ID(0x22d9, 0x0461): /* OPPO UDP-205 */ case USB_ID(0x2522, 0x0012): /* LH Labs VI DAC Infinity */ case USB_ID(0x2772, 0x0230): /* Pro-Ject Pre Box S2 Digital */ + case USB_ID(0x292b, 0xc4b3): /* Gustard U16 */ if (fp->altsetting == 2) return SNDRV_PCM_FMTBIT_DSD_U32_BE; break;

2 3

[alsa-devel] [asoc:for-5.5 160/172] sound/soc/codecs/rt5677-spi.c:148:33: sparse: sparse: Using plain integer as NULL pointer
by kbuild test robot 24 Oct '19

24 Oct '19

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5 head: 175fc928198236037174e5c5c066fe3c4691903e commit: a0e0d135427cf699fe2dee77da0924e0b47f3170 [160/172] ASoC: rt5677: Add a PCM device for streaming hotword via SPI reproduce: # apt-get install sparse # sparse version: v0.6.1-dirty git checkout a0e0d135427cf699fe2dee77da0924e0b47f3170 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> sparse warnings: (new ones prefixed by >>) >> sound/soc/codecs/rt5677-spi.c:148:33: sparse: sparse: Using plain integer as NULL pointer >> sound/soc/codecs/rt5677-spi.c:365:13: sparse: sparse: symbol 'rt5677_spi_pcm_page' was not declared. Should it be static? vim +148 sound/soc/codecs/rt5677-spi.c 139 140 static int rt5677_spi_hw_free( 141 struct snd_soc_component *component, 142 struct snd_pcm_substream *substream) 143 { 144 struct rt5677_dsp *rt5677_dsp = 145 snd_soc_component_get_drvdata(component); 146 147 mutex_lock(&rt5677_dsp->dma_lock); > 148 rt5677_dsp->substream = 0; 149 mutex_unlock(&rt5677_dsp->dma_lock); 150 151 return snd_pcm_lib_free_vmalloc_buffer(substream); 152 } 153 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[alsa-devel] [PATCH 00/18] soundwire: code hardening and suspend-resume support
by Pierre-Louis Bossart 23 Oct '19

23 Oct '19

this patchset applies on top of "[PATCH 00/14] soundwire: intel: implement new ASoC interfaces". It implements a series of improvements for: a) interrupt handling on Intel platforms in MSI mode b) race conditions on codec probe and enumeration c) suspend-resume issues (clock-stop mode not supported for now) d) underflow handling e) updates to the stream state machine which did not support valid ALSA transitions. These patches were tested extensively on 4 different platforms and are viewed as required for any sort of SoundWire-based product. Bard Liao (3): soundwire: intel/cadence: fix timeouts in MSI mode soundwire: stream: only prepare stream when it is configured. soundwire: intel: reinitialize IP+DSP in .prepare() Pierre-Louis Bossart (15): soundwire: fix race between driver probe and update_status callback soundwire: bus: add PM/no-PM versions of read/write functions soundwire: bus: write Slave Device Number without runtime_pm soundwire: intel: add helpers for link power down and shim wake soundwire: intel: Add basic power management support soundwire: intel: add pm_runtime support soundwire: intel: reset pm_runtime status during system resume soundwire: bus: add helper to reset Slave status to UNATTACHED soundwire: intel: call helper to reset Slave states on resume soundwire: bus: check first if Slaves become UNATTACHED soundwire: add enumeration_complete signaling soundwire: intel: disable pm_runtime when removing a master soundwire: bus: disable pm_runtime in sdw_slave_delete soundwire: stream: update state machine and add state checks soundwire: stream: do not update parameters during DISABLED-PREPARED transition Documentation/driver-api/soundwire/stream.rst | 63 +++- drivers/soundwire/bus.c | 157 +++++++-- drivers/soundwire/bus.h | 3 + drivers/soundwire/bus_type.c | 5 + drivers/soundwire/cadence_master.c | 17 +- drivers/soundwire/cadence_master.h | 4 + drivers/soundwire/intel.c | 328 ++++++++++++++++-- drivers/soundwire/intel.h | 2 + drivers/soundwire/intel_init.c | 45 ++- drivers/soundwire/slave.c | 3 + drivers/soundwire/stream.c | 64 +++- include/linux/soundwire/sdw.h | 1 + include/linux/soundwire/sdw_intel.h | 2 + 13 files changed, 623 insertions(+), 71 deletions(-) -- 2.20.1

1 18

Re: [alsa-devel] [PATCH] ASoC: fsl_asrc: refine the setting of internal clock divider
by S.j. Wang 23 Oct '19

23 Oct '19

Hi > > On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote: > > For P2P output, the output divider should align with the output sample > > I think we should avoid "P2P" (or "M2M") keyword in the mainline code as > we know M2M will never get merged while somebody working with the > mainline and caring about new feature might be confused. Ok. But we still curious that is there a way to upstream m2m? > > > rate, if use ideal sample rate, there will be a lot of overload, which > > would cause underrun. > > If I understand it correctly, setting to ideal ratio provides a faster converting > speed but increases the load of the processor of ASRC. So we choose a > slower converting speed here since real- time playback mode doesn't really > need a faster conversion? Yes. Slower speed is enough for real-time playback > > It makes sense to me, yet I feel that the delay at the beginning of the audio > playback might be longer as a compromise. I am okay with this decision > though... > > > The maximum divider of asrc clock is 1024, but there is no judgement > > for this limitaion in driver, which may cause the divider setting not > > correct. > > > > For non-ideal ratio mode, the clock rate should divide the sample rate > > with no remainder, and the quotient should be less than 1024. > > > > Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> > > --- > > sound/soc/fsl/fsl_asrc.c | 40 > > +++++++++++++++++++++++++++++++--------- > > 1 file changed, 31 insertions(+), 9 deletions(-) > > > > diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index > > 0bf91a6f54b9..44d05ec28bd3 100644 > > --- a/sound/soc/fsl/fsl_asrc.c > > +++ b/sound/soc/fsl/fsl_asrc.c > > @@ -260,7 +260,7 @@ static int fsl_asrc_set_ideal_ratio(struct > fsl_asrc_pair *pair, > > * of struct asrc_config which includes in/output sample rate, width, > channel > > * and clock settings. > > */ > > -static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair) > > +static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool p2p) > > { > > struct asrc_config *config = pair->config; > > struct fsl_asrc *asrc_priv = pair->asrc_priv; @@ -268,7 +268,8 > > @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair) > > enum asrc_word_width input_word_width; > > enum asrc_word_width output_word_width; > > u32 inrate, outrate, indiv, outdiv; > > - u32 clk_index[2], div[2]; > > + u32 clk_index[2], div[2], rem[2]; > > + u64 clk_rate; > > int in, out, channels; > > int pre_proc, post_proc; > > struct clk *clk; > > @@ -351,7 +352,9 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair > *pair) > > /* We only have output clock for ideal ratio mode */ > > clk = asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]]; > > > > - div[IN] = clk_get_rate(clk) / inrate; > > + clk_rate = clk_get_rate(clk); > > The fsl_asrc.c file has config.inclk being set to INCLK_NONE and this sets the > "ideal" in this function to true. So, although we tend to not use ideal ratio > setting for p2p cases, yet the input clock is still not physically connected, so > we still use output clock for div[IN] calculation? For p2p case, it can be ideal or non-ideal. For non-ideal, we still use Output clock for div calculation. > > I am thinking something simplier: if we decided not to use ideal ratio for > "P2P", instead of adding "bool p2p" with the confusing "ideal" in this > function, could we just set config.inclk to the same clock as the output one > for "P2P"? By doing so, "P2P" won't go through ideal ratio mode while still > having a clock rate from the output clock for div[IN] calculation here. Bool p2p is to force output rate to be sample rate, no impact to ideal Ratio mode. > > > + rem[IN] = do_div(clk_rate, inrate); > > + div[IN] = (u32)clk_rate; > > if (div[IN] == 0) { > > Could we check div[IN] and rem[IN] here? Like: > if (div[IN] == 0 || div[IN] > 1024) { > pair_err(); > goto out; > } > > if (!ideal && rem[IN]) { > pair_err(); > goto out; > } > > According to your commit log, I think the max-1024 limitation should be > applied to all cases, not confined to "!ideal" cases right? And we should > add some comments also, indicating it is limited by hardware. For ideal mode, my test result is the divider not impact the output result. Which means it is ok for ideal mode even divider is not correct... > > > pair_err("failed to support input sample rate %dHz by > asrck_%x\n", > > inrate, clk_index[ideal ? OUT : IN]); @@ > > -360,11 +363,20 @@ static int fsl_asrc_config_pair(struct > > fsl_asrc_pair *pair) > > > > clk = asrc_priv->asrck_clk[clk_index[OUT]]; > > > > - /* Use fixed output rate for Ideal Ratio mode (INCLK_NONE) */ > > - if (ideal) > > - div[OUT] = clk_get_rate(clk) / IDEAL_RATIO_RATE; > > - else > > - div[OUT] = clk_get_rate(clk) / outrate; > > + /* > > + * When P2P mode, output rate should align with the out samplerate. > > + * if set too high output rate, there will be lots of Overload. > > + * When M2M mode, output rate should also need to align with the > > + out > > For this "should", do you actually mean "M2M could also"? Sorry, I'm just > trying to understand everyting here, not intentionally being picky at words. > My understanding is that we still keep the ideal ratio setting because > "M2M" still uses it. We use IDEAL_RATIO_RATE as output rate for m2m mode, it likes a Tricky operation, in order to improve the performance. I think The correct operation is to use the real output rate, but the performance Is bad. So it is a compromise. > > > + * samplerate, but M2M must use less time to achieve good > performance. > > + */ > > + clk_rate = clk_get_rate(clk); > > + if (p2p || !ideal) { > > + rem[OUT] = do_div(clk_rate, outrate); > > + div[OUT] = clk_rate; > > + } else { > > + rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE); > > + div[OUT] = clk_rate; > > + } > > > > if (div[OUT] == 0) { > > pair_err("failed to support output sample rate %dHz by > > asrck_%x\n", @@ -372,6 +384,16 @@ static int fsl_asrc_config_pair(struct > fsl_asrc_pair *pair) > > return -EINVAL; > > } > > > > + if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || > > + rem[IN] != 0 || rem[OUT] != 0)) { > > + if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || rem[IN] || > > + rem[OUT] != 0)) { > > So for ideal == true, these limitaions are not applied any more? > Remember that the "ideal" is true for "p2p == true" cases here. No, not applied. for ideal, the div don't impact the output result Even it is not accurate. > > > + pair_err("The divider can't be used for non ideal mode\n"); > > + return -EINVAL; > > + } > > + > > + /* Divider range is [1, 1024] */ > > + div[IN] = min_t(u32, 1024, div[IN]); > > + div[OUT] = min_t(u32, 1024, div[OUT]); > > Hmm, this looks like we want to allow ideal ratio cases and p2p cases to > operate any way, even if the divider wasn't within the range to get the > in/out rates from the output clock? Yes. We still allow the p2p = true, ideal = false. Note that p2p is not Equal to ideal. Best regards Wang shengjiu

2 1

[alsa-devel] [PATCH] ASoC: kirkwood: fix external clock probe defer
by Russell King 23 Oct '19

23 Oct '19

When our call to get the external clock fails, we forget to clean up the enabled internal clock correctly. Enable the clock after we have obtained all our resources. Fixes: 84aac6c79bfd ("ASoC: kirkwood: fix loss of external clock at probe time") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> --- sound/soc/kirkwood/kirkwood-i2s.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c index 3446a113f482..c323ae314b55 100644 --- a/sound/soc/kirkwood/kirkwood-i2s.c +++ b/sound/soc/kirkwood/kirkwood-i2s.c @@ -559,10 +559,6 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) return PTR_ERR(priv->clk); } - err = clk_prepare_enable(priv->clk); - if (err < 0) - return err; - priv->extclk = devm_clk_get(&pdev->dev, "extclk"); if (IS_ERR(priv->extclk)) { if (PTR_ERR(priv->extclk) == -EPROBE_DEFER) @@ -578,6 +574,10 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) } } + err = clk_prepare_enable(priv->clk); + if (err < 0) + return err; + /* Some sensible defaults - this reflects the powerup values */ priv->ctl_play = KIRKWOOD_PLAYCTL_SIZE_24; priv->ctl_rec = KIRKWOOD_RECCTL_SIZE_24; -- 2.20.1

2 1

[alsa-devel] [PATCH] ASoC: mediatek: Check SND_SOC_CROS_EC_CODEC dependency
by Mao Wenan 23 Oct '19

23 Oct '19

If SND_SOC_MT8183_MT6358_TS3A227E_MAX98357A=y, below errors can be seen: sound/soc/codecs/cros_ec_codec.o: In function `send_ec_host_command': cros_ec_codec.c:(.text+0x534): undefined reference to `cros_ec_cmd_xfer_status' cros_ec_codec.c:(.text+0x101c): undefined reference to `cros_ec_get_host_event' This is because it will select SND_SOC_CROS_EC_CODEC after commit 2cc3cd5fdc8b ("ASoC: mediatek: mt8183: support WoV"), but SND_SOC_CROS_EC_CODEC depends on CROS_EC. Fixes: 2cc3cd5fdc8b ("ASoC: mediatek: mt8183: support WoV") Signed-off-by: Mao Wenan <maowenan(a)huawei.com> --- sound/soc/mediatek/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig index 8b29f39..a656d20 100644 --- a/sound/soc/mediatek/Kconfig +++ b/sound/soc/mediatek/Kconfig @@ -125,7 +125,7 @@ config SND_SOC_MT8183_MT6358_TS3A227E_MAX98357A select SND_SOC_MAX98357A select SND_SOC_BT_SCO select SND_SOC_TS3A227E - select SND_SOC_CROS_EC_CODEC + select SND_SOC_CROS_EC_CODEC if CROS_EC help This adds ASoC driver for Mediatek MT8183 boards with the MT6358 TS3A227E MAX98357A audio codec. -- 2.7.4

4 6

[alsa-devel] [PATCH] ASoC: rsnd: add missing of_node_put()
by Kuninori Morimoto 23 Oct '19

23 Oct '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> This patch adds missing of_node_put() for rsnd_parse_tdm_split_mode() rsnd_parse_connect_graph() Reported-by: Pavel Machek <pavel(a)denx.de> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/rcar/core.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index fe681c5..14e86e4 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -1075,7 +1075,10 @@ static void rsnd_parse_tdm_split_mode(struct rsnd_priv *priv, j++; } + of_node_put(node); } + + of_node_put(ssiu_np); } static void rsnd_parse_connect_simple(struct rsnd_priv *priv, @@ -1093,11 +1096,13 @@ static void rsnd_parse_connect_graph(struct rsnd_priv *priv, struct device_node *endpoint) { struct device *dev = rsnd_priv_to_dev(priv); - struct device_node *remote_node = of_graph_get_remote_port_parent(endpoint); + struct device_node *remote_node; if (!rsnd_io_to_mod_ssi(io)) return; + remote_node = of_graph_get_remote_port_parent(endpoint); + /* HDMI0 */ if (strstr(remote_node->full_name, "hdmi@fead0000")) { rsnd_flags_set(io, RSND_STREAM_HDMI0); @@ -1111,6 +1116,8 @@ static void rsnd_parse_connect_graph(struct rsnd_priv *priv, } rsnd_parse_tdm_split_mode(priv, io, endpoint); + + of_node_put(remote_node); } void rsnd_parse_connect_common(struct rsnd_dai *rdai, -- 2.7.4

2 1

[alsa-devel] [PATCH] ASoC: rsnd: dma: set bus width to data width for monaural data
by Eugeniu Rosca 23 Oct '19

23 Oct '19

From: Jiada Wang <jiada_wang(a)mentor.com> According to R-Car3 HW manual 40.3.3 (Data Format on Audio Local Bus), in case of monaural data writing or reading through Audio-DMAC, it's always in Left Justified format, so both src and dst DMA Bus width should be equal to physical data width. Therefore set src and dst's DMA bus width to: - [monaural case] data width - [non-monaural case] 32bits (as prior applying the patch) Cc: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> Cc: Timo Wischer <twischer(a)de.adit-jv.com> Signed-off-by: Jiada Wang <jiada_wang(a)mentor.com> Signed-off-by: Eugeniu Rosca <erosca(a)de.adit-jv.com> --- sound/soc/sh/rcar/dma.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c index 28f65eba2bb4..95aa26d62e4f 100644 --- a/sound/soc/sh/rcar/dma.c +++ b/sound/soc/sh/rcar/dma.c @@ -165,14 +165,40 @@ static int rsnd_dmaen_start(struct rsnd_mod *mod, struct device *dev = rsnd_priv_to_dev(priv); struct dma_async_tx_descriptor *desc; struct dma_slave_config cfg = {}; + enum dma_slave_buswidth buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES; int is_play = rsnd_io_is_play(io); int ret; + /* + * in case of monaural data writing or reading through Audio-DMAC + * data is always in Left Justified format, so both src and dst + * DMA Bus width need to be set equal to physical data width. + */ + if (rsnd_runtime_channel_original(io) == 1) { + struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io); + int bits = snd_pcm_format_physical_width(runtime->format); + + switch (bits) { + case 8: + buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE; + break; + case 16: + buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES; + break; + case 32: + buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES; + break; + default: + dev_err(dev, "invalid format width %d\n", bits); + return -EINVAL; + } + } + cfg.direction = is_play ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM; cfg.src_addr = dma->src_addr; cfg.dst_addr = dma->dst_addr; - cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; - cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; + cfg.src_addr_width = buswidth; + cfg.dst_addr_width = buswidth; dev_dbg(dev, "%s %pad -> %pad\n", rsnd_mod_name(mod), -- 2.23.0

3 2