September 2013 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [PATCH] ASoC: rt5640: Omit ACPI match table only if !ACPI
by Mark Brown 19 Sep '13

19 Sep '13

On Thu, Sep 19, 2013 at 01:21:04PM +0200, Thierry Reding wrote: > Or perhaps we can annotate the table so that the compiler will stop > complaining but remove the table nonetheless if it isn't used. Similarly > to what we can do with > > if (IS_ENABLED(CONFIG_FOO)) { > ... > } > > constructs. I can't really think of a way to do that, though. Perhaps > gcc will throw away the table anyway, so we'll just need a way to make > it shut up? There's an annotation which can stop the unreferenced variable warning and then modern compilers are able to eliminate unreferenced static symbols. Not sure if it's actually worth the effort of doing all this though, but it is nice to be able to avoid needing multiple builds.

1 0

[alsa-devel] [PATCH] ASoC: fsl: imx-sgtl5000: fix error path if codec driver not found
by Andrew Gabbasov 19 Sep '13

19 Sep '13

Handling of this error condition should make some cleanup on function exit instead of immediate return. Signed-off-by: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> --- sound/soc/fsl/imx-sgtl5000.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c index 46c5b4f..7ea5658 100644 --- a/sound/soc/fsl/imx-sgtl5000.c +++ b/sound/soc/fsl/imx-sgtl5000.c @@ -119,7 +119,8 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev) { dev_err(&pdev->dev, "failed to find codec platform device\n"); - return -EPROBE_DEFER; + ret = -EPROBE_DEFER; + goto fail; } data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: fsl: imx-wm8962: defer probing if ssi/codec not found
by Andrew Gabbasov 19 Sep '13

19 Sep '13

If the ssi or codec driver is not yet loaded by the time of imx-wm8962 driver probing, this probe should be deferred until the dependent drivers loading. Return -EPROBE_DEFER in this case. Signed-off-by: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> --- sound/soc/fsl/imx-wm8962.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/imx-wm8962.c b/sound/soc/fsl/imx-wm8962.c index 722afe6..9e60aa8 100644 --- a/sound/soc/fsl/imx-wm8962.c +++ b/sound/soc/fsl/imx-wm8962.c @@ -211,13 +211,13 @@ static int imx_wm8962_probe(struct platform_device *pdev) ssi_pdev = of_find_device_by_node(ssi_np); if (!ssi_pdev) { dev_err(&pdev->dev, "failed to find SSI platform device\n"); - ret = -EINVAL; + ret = -EPROBE_DEFER; goto fail; } codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev || !codec_dev->driver) { dev_err(&pdev->dev, "failed to find codec platform device\n"); - ret = -EINVAL; + ret = -EPROBE_DEFER; goto fail; } -- 1.7.10.4

1 0

[alsa-devel] [PATCH 1/3] mfd: mc13xxx: Don't require lock for simple register I/O
by Mark Brown 19 Sep '13

19 Sep '13

From: Mark Brown <broonie(a)linaro.org> Since the conversion to regmap there has been no need for device level locking for I/O as regmap provides locking so remove the locks. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/mfd/mc13xxx-core.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c index 2a9b100..dbbf8ee 100644 --- a/drivers/mfd/mc13xxx-core.c +++ b/drivers/mfd/mc13xxx-core.c @@ -158,8 +158,6 @@ int mc13xxx_reg_read(struct mc13xxx *mc13xxx, unsigned int offset, u32 *val) { int ret; - BUG_ON(!mutex_is_locked(&mc13xxx->lock)); - if (offset > MC13XXX_NUMREGS) return -EINVAL; @@ -172,8 +170,6 @@ EXPORT_SYMBOL(mc13xxx_reg_read); int mc13xxx_reg_write(struct mc13xxx *mc13xxx, unsigned int offset, u32 val) { - BUG_ON(!mutex_is_locked(&mc13xxx->lock)); - dev_vdbg(mc13xxx->dev, "[0x%02x] <- 0x%06x\n", offset, val); if (offset > MC13XXX_NUMREGS || val > 0xffffff) @@ -186,7 +182,6 @@ EXPORT_SYMBOL(mc13xxx_reg_write); int mc13xxx_reg_rmw(struct mc13xxx *mc13xxx, unsigned int offset, u32 mask, u32 val) { - BUG_ON(!mutex_is_locked(&mc13xxx->lock)); BUG_ON(val & ~mask); dev_vdbg(mc13xxx->dev, "[0x%02x] <- 0x%06x (mask: 0x%06x)\n", offset, val, mask); -- 1.8.4.rc3

2 8

[alsa-devel] [PATCH] ASoC: rt5640: ifdef for ACPI module table
by Olof Johansson 19 Sep '13

19 Sep '13

Commit 02b80773de37 (ASoC: rt5640: Add ACPI probing support.) causes a warning due to unreferenced variable on non-ACPI configs such as tegra_defconfig on ARM: sound/soc/codecs/rt5640.c:2085:30: warning: 'rt5640_acpi_match' defined but not used [-Wunused-variable] Signed-off-by: Olof Johansson <olof(a)lixom.net> --- sound/soc/codecs/rt5640.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 0bfb960..a856706 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -2082,11 +2082,13 @@ static const struct i2c_device_id rt5640_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, rt5640_i2c_id); +#if CONFIG_ACPI static struct acpi_device_id rt5640_acpi_match[] = { { "INT33CA", 0 }, { }, }; MODULE_DEVICE_TABLE(acpi, rt5640_acpi_match); +#endif static int rt5640_parse_dt(struct rt5640_priv *rt5640, struct device_node *np) { -- 1.7.10.4

3 11

[alsa-devel] [PATCH] ASoC: kirkwood: fix loss of external clock at probe time
by Jean-Francois Moine 19 Sep '13

19 Sep '13

At probe time, when the clock driver is not yet initialized, the external clock of the kirkwood sound device will not be usable. This patch fixes this problem defering the device probe. Signed-off-by: Jean-Francois Moine <moinejf(a)free.fr> --- sound/soc/kirkwood/kirkwood-i2s.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c index 0f3d73d..14f32d9 100644 --- a/sound/soc/kirkwood/kirkwood-i2s.c +++ b/sound/soc/kirkwood/kirkwood-i2s.c @@ -496,7 +496,10 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) return err; priv->extclk = devm_clk_get(&pdev->dev, "extclk"); - if (!IS_ERR(priv->extclk)) { + if (IS_ERR(priv->extclk)) { + if (np && of_property_match_string(np, "clock-names", "extclk") >= 0) + return -EPROBE_DEFER; + } else { if (priv->extclk == priv->clk) { devm_clk_put(&pdev->dev, priv->extclk); priv->extclk = ERR_PTR(-EINVAL); -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/

2 1

Re: [alsa-devel] [PATCH] ASoC: rt5640: Omit ACPI match table only if !ACPI
by Mark Brown 19 Sep '13

19 Sep '13

On Thu, Sep 19, 2013 at 11:18:06AM +0200, Thierry Reding wrote: > The ACPI_PTR() macro evaluates to NULL if ACPI is disabled and hence the > ACPI match table won't be used, causing the compiler to complain. Avoid > this by protecting the table using an #ifdef CONFIG_ACPI. Applied, thanks. Like I was saying to Olof we really should be able to do better than needing the ifdefs though.

1 0

[alsa-devel] [PATCH 1/1] ASoC: SPEAr spdif_out: Remove redundant variable
by Sachin Kamat 19 Sep '13

19 Sep '13

Return directly and remove the intermediate local variable. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/spear/spdif_out.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/soc/spear/spdif_out.c b/sound/soc/spear/spdif_out.c index 70fc4d6..b6ef6f7 100644 --- a/sound/soc/spear/spdif_out.c +++ b/sound/soc/spear/spdif_out.c @@ -280,7 +280,6 @@ static int spdif_out_probe(struct platform_device *pdev) struct spdif_out_dev *host; struct spear_spdif_platform_data *pdata; struct resource *res; - int ret; host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL); if (!host) { @@ -307,9 +306,8 @@ static int spdif_out_probe(struct platform_device *pdev) dev_set_drvdata(&pdev->dev, host); - ret = devm_snd_soc_register_component(&pdev->dev, &spdif_out_component, - &spdif_out_dai, 1); - return ret; + return devm_snd_soc_register_component(&pdev->dev, &spdif_out_component, + &spdif_out_dai, 1); } #ifdef CONFIG_PM -- 1.7.9.5

2 1

[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
by Colomban Wendling 18 Sep '13

18 Sep '13

Here's my initial mail, but with gzipped outputs. Regards, Colomban -------- Message original -------- Sujet: Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again) Date : Thu, 10 Nov 2011 02:11:17 +0100 De : Colomban Wendling <lists.ban(a)herbesfolles.org> Pour : Takashi Iwai <tiwai(a)suse.de> Copie à : alsa-devel(a)alsa-project.org Hi again, and sorry for the delay. Le 08/11/2011 07:32, Takashi Iwai a écrit : > At Mon, 07 Nov 2011 23:45:40 +0100, > Colomban Wendling wrote: >> >> Hi, >> >> Back to 3.0, the sound on my soundcard [1] started to be choppy, I >> reported it [2] and it got fixed (thanks to Takashi Iwai!). >> >> However, the story repeated with 3.1 (and probably 3.0.8 or before [3]): >> I've got similar choppy sound again. >> >> I bisected the few commits that happened on >> sound/pci/hda/patch_realtek.c, and finally found the villain: >> >> "8974bd51 ALSA: hda/realtek - Fix auto-mute with HP+LO configuration" >> >> Reverting it from v3.1 fixes the problem. > > Does it? Very weird. This patch has nothing to do with the HD-audio > controller side but purely a codec change. Yep, I just check once again and it really fixes the problem here. >> master (94956ee) also suffers of the problem, but I couldn't test >> without that commit because reverting it fails, too much changes happened. > > Did you try to pass position_fix=1 (or 2) option? > Also, passing enable_msi=0 (or 1) may change anything? I just tried with the 3 kernels: * vanilla v3.1 * vanilla 3.2-rc1 (master at 1ea6b8f) * v3.1 with 8974bd51 reverted and none of the option changed anything: both vanilla always failed, the third always succeeded. Though, I haven't combined the options, just tried each at once. > In anyway, please give alsa-info.sh output again with the fresh > kernel. Run it with --no-upload option and attach the output. Here it is, for the 3 kernels cited above. Regards, Colomban

4 14

Re: [alsa-devel] snd_pcm_delay issue - How to debug?
by Sander Jansen 18 Sep '13

18 Sep '13

Never mind. Issue not related to alsa. On Tue, Jul 16, 2013 at 6:27 PM, Sander Jansen <s.jansen(a)gmail.com> wrote: > Here the two alsa-info dumps for the hardware I'm having the problem with. > Also a log of my music player. It reports: > > The 'position' the number of frames it has written to the device (also > reported in seconds) and the delay at that time (after writing). > Also the 'timestamp' which is the reported playback progress in seconds > reported to the UI. When the second track is played (line 590), the > problems start to become noticeable eg. playback progress is a couple of > seconds out of sync. > > Any ideas? > > Thanks, > > Sander > > > > On Tue, Jul 16, 2013 at 9:28 AM, Sander Jansen <s.jansen(a)gmail.com> wrote: > >> Hi, >> >> I'm seeing an issue where snd_pcm_delay is returning bogus values >> (usually a lot larger than in actuality) in that it ultimately affects the >> progress timer in my audio player. Both are HDA based audio cards, though >> one connects to the HDMI output and while the other connects to analog out. >> >> I'm suspecting I'm seeing a driver bug since I only start noticing the >> issue since a few kernel releases ago (though not sure which one started >> it). >> >> How can i best debug this issue and find out the cause. >> >> Thanks, >> >> Sander >> > >

1 0