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

[alsa-devel] [PATCH] ASoC: audio-graph-card: fix type mismatch warning
by Arnd Bergmann 13 Jul '19

13 Jul '19

The new temporary variable is lacks a 'const' annotation: sound/soc/generic/audio-graph-card.c:87:7: error: assigning to 'u32 *' (aka 'unsigned int *') from 'const void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] Fixes: c152f8491a8d ("ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/generic/audio-graph-card.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c index c8abb86afefa..288df245b2f0 100644 --- a/sound/soc/generic/audio-graph-card.c +++ b/sound/soc/generic/audio-graph-card.c @@ -63,7 +63,7 @@ static int graph_get_dai_id(struct device_node *ep) struct device_node *endpoint; struct of_endpoint info; int i, id; - u32 *reg; + const u32 *reg; int ret; /* use driver specified DAI ID if exist */ -- 2.20.0

2 1

[alsa-devel] [PATCH] ASoC: audio-graph-card: add missing const at graph_get_dai_id()
by Kuninori Morimoto 12 Jul '19

12 Jul '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit c152f8491a8d9 ("ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()") fixups use-after-free issue, but, it need to use "const" for reg. This patch adds it. We will have below without this patch LINUX/sound/soc/generic/audio-graph-card.c: In function 'graph_get_dai_id': LINUX/sound/soc/generic/audio-graph-card.c:87:7: warning: assignment discards\ 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] reg = of_get_property(node, "reg", NULL); Fixes: c152f8491a8d9 ("ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/generic/audio-graph-card.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c index 343ede8..ebf2ca3 100644 --- a/sound/soc/generic/audio-graph-card.c +++ b/sound/soc/generic/audio-graph-card.c @@ -63,7 +63,7 @@ static int graph_get_dai_id(struct device_node *ep) struct device_node *endpoint; struct of_endpoint info; int i, id; - u32 *reg; + const u32 *reg; int ret; /* use driver specified DAI ID if exist */ -- 2.7.4

3 4

[alsa-devel] How to treat old style platform components
by Daniel Baluta 12 Jul '19

12 Jul '19

HI Morimoto-san, I'm using simple-card with an out of tree PCM DMA driver which basically just does this: static struct snd_soc_component_driver imx_soc_platform = { .ops» » = &imx_pcm_ops, .pcm_new» = imx_pcm_new, }; Then somewhere in the DAI driver we call: devm_snd_soc_register_component(dev, &imx_soc_platform, NULL, 0); I'm using simple-card with the following configuration: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/ar… After latest changes it seems that imx_pcm_ops->open() function is no longer called. Any idea? Please feel free to not waste any time on this, as we are using an out of tree driver. thanks, Daniel.

2 3

[alsa-devel] [PATCH] ASoC: audio-graph-card: Constify reg in graph_get_dai_id
by Nathan Chancellor 12 Jul '19

12 Jul '19

clang errors: sound/soc/generic/audio-graph-card.c:87:7: error: assigning to 'u32 *' (aka 'unsigned int *') from 'const void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] reg = of_get_property(node, "reg", NULL); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Move the declaration up a bit to keep the reverse christmas tree look. Fixes: c152f8491a8d ("ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()") Link: https://github.com/ClangBuiltLinux/linux/issues/599 Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- sound/soc/generic/audio-graph-card.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c index c8abb86afefa..c0d262a2ce2c 100644 --- a/sound/soc/generic/audio-graph-card.c +++ b/sound/soc/generic/audio-graph-card.c @@ -62,8 +62,8 @@ static int graph_get_dai_id(struct device_node *ep) struct device_node *node; struct device_node *endpoint; struct of_endpoint info; + const u32 *reg; int i, id; - u32 *reg; int ret; /* use driver specified DAI ID if exist */ -- 2.22.0

2 3

Re: [alsa-devel] DW-DMA: Probe failures on broadwell
by Andy Shevchenko 11 Jul '19

11 Jul '19

(I think this is okay to go on public here) +Cc: Pierre, Liam, DMA Engine ML, ASoC ML On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote: > Hello Andy, > > I am reaching out to you as you are the main author for > drivers/dma/dw/core.c and we are seeing a failure in there on some of > our samus devices. On certain device we are seeing the following > failure (debugging enabled in this log.) > > [ 3.587515] sst-acpi INT3438:00: DW_PARAMS: 0x00000000 AFAIK, when Synopsys DesignWare DMA IP is in use in Intel, we almost always (yes, I know couple of exceptions), enable auto configuration block. Thus, the *private* DMA controllers used in Broadwell are actually Intel iDMA 32-bit. Nowadays the differences can be seen in drivers/dma/dw/idma32.c. Note, DMA in the driver is used solely for firmware load, simplest workaround is to disable DMA. Though, personally, for sake of test coverage, I would like to see how it works in DMA case. > [ 3.587519] haswell-pcm-audio haswell-pcm-audio: error: DMA device > register failed > [ 3.587524] haswell-pcm-audio haswell-pcm-audio: sst_dma_new failed -22 > [ 3.598010] bdw-rt5677 bdw-rt5677: ASoC: failed to init link System PCM > > I don't have the datasheets for this component but I am wondering if > you could help us troubleshoot this bug it would be greatly > appreciated if possible. I am not sure if we are seeing a hardware > boot failure or a boot race. I was hoping you could shed some light on > this and if it is a boot race help us recover from it. I know Intel > relies on no defers typically but it would be nice to see if we can > fix this. Below is where I have traced the error source to in core.c. So, the correct fix is to provide a platform data, like it's done in drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call idma32_dma_probe() with idma32_dma_remove() respectively on removal stage. (It will require latest patches to be applied, which are material for v5.x) > dw_params = dma_readl(dw, DW_PARAMS); > dev_dbg(chip->dev, "DW_PARAMS: 0x%08x\n", dw_params); > > autocfg = dw_params >> DW_PARAMS_EN & 1; > if (!autocfg) { > err = -EINVAL; > goto err_pdata; > } > Let me know if you have any ideas on how to mitigate this, thanks. -- With Best Regards, Andy Shevchenko

2 8

[alsa-devel] [PATCH 1/2] ASoC: rt1011: fix DC calibration offset not applying
by shumingf＠realtek.com 11 Jul '19

11 Jul '19

From: Shuming Fan <shumingf(a)realtek.com> There are two issues to fix: - DC offset calibration data will be reset after stopping playback. - DC offset calibration data should be applied in the initial setting. Signed-off-by: Shuming Fan <shumingf(a)realtek.com> --- sound/soc/codecs/rt1011.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt1011.c b/sound/soc/codecs/rt1011.c index 5605b660f4bf..0a6ff13d76e1 100644 --- a/sound/soc/codecs/rt1011.c +++ b/sound/soc/codecs/rt1011.c @@ -39,7 +39,7 @@ static const struct reg_sequence init_list[] = { { RT1011_POWER_9, 0xa840 }, { RT1011_ADC_SET_5, 0x0a20 }, - { RT1011_DAC_SET_2, 0xa232 }, + { RT1011_DAC_SET_2, 0xa032 }, { RT1011_ADC_SET_1, 0x2925 }, { RT1011_SPK_PRO_DC_DET_1, 0xb00c }, @@ -1917,7 +1917,7 @@ static int rt1011_set_bias_level(struct snd_soc_component *component, snd_soc_component_write(component, RT1011_SYSTEM_RESET_2, 0x0000); snd_soc_component_write(component, - RT1011_SYSTEM_RESET_3, 0x0000); + RT1011_SYSTEM_RESET_3, 0x0001); snd_soc_component_write(component, RT1011_SYSTEM_RESET_1, 0x003f); snd_soc_component_write(component, -- 2.22.0

2 1

[alsa-devel] [PATCH v2 0/6] VAG power control improvement for sgtl5000 codec
by Oleksandr Suvorov 11 Jul '19

11 Jul '19

VAG power control is improved to fit the manual. This fixes as minimum one bug: if customer muxes Headphone to Line-In right after boot w/o playing any sound, the VAG power remains off that leads to poor sound quality from line-in. I.e. after boot: - Connect sound source to Line-In jack; - Connect headphone to HP jack; - Run following commands: $ amixer set 'Headphone' 80% $ amixer set 'Headphone Mux' LINE_IN Also this series includes fixes of non-important bugs in sgtl5000 codec driver. Fix patch formatting in patchset v2. Oleksandr Suvorov (6): ASoC: sgtl5000: Fix definition of VAG Ramp Control ASoC: sgtl5000: add ADC mute control ASoC: sgtl5000: Fix of unmute outputs on probe ASoC: sgtl5000: Fix charge pump source assignment ASoC: Define a set of DAPM pre/post-up events ASoC: sgtl5000: Improve VAG power and mute control include/sound/soc-dapm.h | 2 + sound/soc/codecs/sgtl5000.c | 250 ++++++++++++++++++++++++++++++------ sound/soc/codecs/sgtl5000.h | 2 +- 3 files changed, 212 insertions(+), 42 deletions(-) -- 2.20.1

2 11

[alsa-devel] [PATCH 2/2] ASoC: rt1011: Add R0 temperature and TDM1 ADC2DAT Swap control
by shumingf＠realtek.com 11 Jul '19

11 Jul '19

From: Shuming Fan <shumingf(a)realtek.com> - The user level application could set the R0 temperature after booting system. The degree Celsius of R0 temperature store in the non-volatile space when doing R0 calibration. - TDM1 ADC2DAT Swap controls use to control TDM slot2/3 data Signed-off-by: Shuming Fan <shumingf(a)realtek.com> --- sound/soc/codecs/rt1011.c | 9 ++++++++- sound/soc/codecs/rt1011.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt1011.c b/sound/soc/codecs/rt1011.c index 0a6ff13d76e1..b25b4c1127ca 100644 --- a/sound/soc/codecs/rt1011.c +++ b/sound/soc/codecs/rt1011.c @@ -1029,6 +1029,8 @@ static const char * const rt1011_tdm_adc_swap_select[] = { static SOC_ENUM_SINGLE_DECL(rt1011_tdm_adc1_1_enum, RT1011_TDM1_SET_3, 6, rt1011_tdm_adc_swap_select); +static SOC_ENUM_SINGLE_DECL(rt1011_tdm_adc2_1_enum, RT1011_TDM1_SET_3, 4, + rt1011_tdm_adc_swap_select); static void rt1011_reset(struct regmap *regmap) { @@ -1333,7 +1335,8 @@ static const struct snd_kcontrol_new rt1011_snd_controls[] = { /* TDM1 Data Out Selection */ SOC_ENUM("TDM1 DOUT Source", rt1011_tdm1_adc1_dat_enum), SOC_ENUM("TDM1 DOUT Location", rt1011_tdm1_adc1_loc_enum), - SOC_ENUM("TDM1 ADCDAT Swap Select", rt1011_tdm_adc1_1_enum), + SOC_ENUM("TDM1 ADC1DAT Swap Select", rt1011_tdm_adc1_1_enum), + SOC_ENUM("TDM1 ADC2DAT Swap Select", rt1011_tdm_adc2_1_enum), /* Data Out Mode */ SOC_ENUM("I2S ADC DOUT Mode", rt1011_adc_dout_mode_enum), @@ -1355,6 +1358,10 @@ static const struct snd_kcontrol_new rt1011_snd_controls[] = { SOC_SINGLE_EXT("R0 Calibration", SND_SOC_NOPM, 0, 1, 0, rt1011_r0_cali_get, rt1011_r0_cali_put), RT1011_R0_LOAD("R0 Load Mode"), + + /* R0 temperature */ + SOC_SINGLE("R0 Temperature", RT1011_STP_INITIAL_RESISTANCE_TEMP, + 2, 255, 0), }; static int rt1011_is_sys_clk_from_pll(struct snd_soc_dapm_widget *source, diff --git a/sound/soc/codecs/rt1011.h b/sound/soc/codecs/rt1011.h index 98a38800c4df..5d431d7f1d16 100644 --- a/sound/soc/codecs/rt1011.h +++ b/sound/soc/codecs/rt1011.h @@ -227,6 +227,7 @@ #define RT1011_STP_CALIB_RS_TEMP 0x152a #define RT1011_INIT_RECIPROCAL_REG_24_16 0x1538 #define RT1011_INIT_RECIPROCAL_REG_15_0 0x1539 +#define RT1011_STP_INITIAL_RESISTANCE_TEMP 0x153c #define RT1011_STP_ALPHA_RECIPROCAL_MSB 0x153e #define RT1011_SPK_RESISTANCE_1 0x1544 #define RT1011_SPK_RESISTANCE_2 0x1546 -- 2.22.0

1 0

Re: [alsa-devel] [PATCH V3 2/2] ASoC: fsl_esai: recover the channel swap after xrun
by S.j. Wang 11 Jul '19

11 Jul '19

> > Hi Shengjiu, > > Mostly looks good to me, just some small comments. > > On Mon, Jul 08, 2019 at 02:38:52PM +0800, shengjiu.wang(a)nxp.com wrote: > > > +static void fsl_esai_hw_reset(unsigned long arg) { > > + struct fsl_esai *esai_priv = (struct fsl_esai *)arg; > > + u32 saisr, tfcr, rfcr; > > + bool tx = true, rx = false, enabled[2]; > > Could we swap the lines of u32 and bool? It'd look better. > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, > > + ESAI_xCR_xPR_MASK, ESAI_xCR_xPR); > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, > > + ESAI_xCR_xPR_MASK, ESAI_xCR_xPR); > > Let's add a line of comments for these two: > /* Enforce ESAI personal resets for both TX and RX */ > > > + /* > > + * Restore registers by regcache_sync, and ignore > > + * return value > > + */ > > Could fit into single-line? > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, > > + ESAI_xCR_xPR_MASK, 0); > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, > > + ESAI_xCR_xPR_MASK, 0); > > + > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC, > > + ESAI_PRRC_PDC_MASK, ESAI_PRRC_PDC(ESAI_GPIO)); > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_PCRC, > > + ESAI_PCRC_PC_MASK, ESAI_PCRC_PC(ESAI_GPIO)); > > Could remove the blank line and add a line of comments: > /* Remove ESAI personal resets by configuring PCRC and PRRC also */ > > Btw, I still feel this personal reset can be stuffed into one of the wrapper > functions. But let's keep this simple for now. > > > + regmap_read(esai_priv->regmap, REG_ESAI_SAISR, &saisr); > > Why do we read saisr here? All its bits would get cleared by the hardware > reset. If it's a must to clear again, we should add a line of comments to > emphasize it. This line can be removed. Best regards Wang Shengjiu

1 0

[alsa-devel] [PATCH V3 0/2] recover the channel swap after xrun
by shengjiu.wang＠nxp.com 11 Jul '19

11 Jul '19

From: Shengjiu Wang <shengjiu.wang(a)nxp.com> recover the channel swap after xrun Shengjiu Wang (2): ASoC: fsl_esai: Wrap some operations to be functions ASoC: fsl_esai: recover the channel swap after xrun sound/soc/fsl/fsl_esai.c | 270 ++++++++++++++++++++++++++++----------- 1 file changed, 197 insertions(+), 73 deletions(-) Changes in V3 - update code sytle. Changes in v2 - add one patch for wrap operations to functions. - fix some coding style issue -- 2.21.0

2 3