May 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v2 1/2] ASoC: sta32x: Use devm_gpiod_get_optional at appropriate place
by Axel Lin 12 May '15

12 May '15

devm_gpiod_get_optional() is equivalent to devm_gpiod_get(), except that when no GPIO was assigned to the requested function it will return NULL. This is convenient for drivers that need to handle optional GPIOs. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- v2: Fixup subject line sound/soc/codecs/sta32x.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/sta32x.c b/sound/soc/codecs/sta32x.c index 033b7d9..847fb20 100644 --- a/sound/soc/codecs/sta32x.c +++ b/sound/soc/codecs/sta32x.c @@ -1095,16 +1095,10 @@ static int sta32x_i2c_probe(struct i2c_client *i2c, #endif /* GPIOs */ - sta32x->gpiod_nreset = devm_gpiod_get(dev, "reset"); - if (IS_ERR(sta32x->gpiod_nreset)) { - ret = PTR_ERR(sta32x->gpiod_nreset); - if (ret != -ENOENT && ret != -ENOSYS) - return ret; - - sta32x->gpiod_nreset = NULL; - } else { - gpiod_direction_output(sta32x->gpiod_nreset, 0); - } + sta32x->gpiod_nreset = devm_gpiod_get_optional(dev, "reset", + GPIOD_OUT_LOW); + if (IS_ERR(sta32x->gpiod_nreset)) + return PTR_ERR(sta32x->gpiod_nreset); /* regulators */ for (i = 0; i < ARRAY_SIZE(sta32x->supplies); i++) -- 2.1.0

2 3

Re: [alsa-devel] commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]
by Mario Limonciello 12 May '15

12 May '15

On 05/12/2015 12:43 PM, Matthew Garrett wrote: > On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello > <mario_limonciello(a)dell.com> wrote: >> Just to be clear, from the Dell side only the XPS 13 9343 has this _REV >> behavior. > The Inspiron 7437 queries _REV and uses it to modify its EC behaviour, > and apparently breaks on Linux without that. Thanks for bringing this to my attention. I'll check with my BIOS architecture team on this. XPS 13 9343 was supposed to be the only system doing this. >> What's wrong with a DMI quirk until I2S is mature on the kernel side and >> userspace is new enough in distros? Is it too early in boot for DMI quirks? >> That would enforce that no other machines can use _REV value of 5 to detect >> Linux without breaking the 9343. > DMI quirking is fine, but it has to be behind a config option. We're > going to have to carry the quirk for several years because we have to > support old userspace for an arbitrarily long time, and if there's no > config option then Linux will be stuck in HDA mode for that entire > time. > OK, that makes more sense to me. Thanks.

1 0

Re: [alsa-devel] commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]
by Mario Limonciello 12 May '15

12 May '15

On 05/12/2015 12:21 PM, Matthew Garrett wrote: > On Tue, May 12, 2015 at 9:18 AM, Mark Brown <broonie(a)kernel.org> wrote: >> You need PulseAudio 6.0 but otherwise yes, it works for me. > Since there's no way to get this working without using new userspace, > we're basically stuck with having to support _REV 5. And since we're > supposed to support old userspace basically forever, this isn't going > to be something that we can just remove in a few months. But since the > hardware is intended to be used in I2S mode, we don't want this quirk > to be there forever. So we're basically left with adding > CONFIG_ACPI_WORKAROUND_BROKEN_DELLS which enables the quirk, default > it to Y and then let distributions set it to N when they've got > sufficiently new userspace. Unless someone has a better plan? Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior. What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks? That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

2 1

Re: [alsa-devel] commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]
by Mark Brown 12 May '15

12 May '15

On Tue, May 12, 2015 at 10:21:41AM -0700, Matthew Garrett wrote: > Since there's no way to get this working without using new userspace, > we're basically stuck with having to support _REV 5. And since we're > supposed to support old userspace basically forever, this isn't going > to be something that we can just remove in a few months. But since the > hardware is intended to be used in I2S mode, we don't want this quirk > to be there forever. So we're basically left with adding > CONFIG_ACPI_WORKAROUND_BROKEN_DELLS which enables the quirk, default > it to Y and then let distributions set it to N when they've got > sufficiently new userspace. Unless someone has a better plan? That makes sense to me given that the firmware doesn't seem to do anything problematic in Linux mode - hopefully we won't have too many more of these systems to contend with.

1 0

Re: [alsa-devel] [PATCH v2 02/17] leds: port locomo leds driver to new locomo core
by Dmitry Eremin-Solenikov 12 May '15

12 May '15

2015-05-06 18:05 GMT+03:00 Jacek Anaszewski <j.anaszewski(a)samsung.com>: > On 04/28/2015 01:55 AM, Dmitry Eremin-Solenikov wrote: >> >> Adapt locomo leds driver to new locomo core setup. >> >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> >> --- >> drivers/leds/Kconfig | 1 - >> drivers/leds/leds-locomo.c | 119 >> +++++++++++++++++++++++---------------------- >> 2 files changed, 61 insertions(+), 59 deletions(-) >> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 966b960..4b4650b 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -79,7 +79,6 @@ config LEDS_LM3642 >> config LEDS_LOCOMO >> tristate "LED Support for Locomo device" >> depends on LEDS_CLASS >> - depends on SHARP_LOCOMO > > > Why do you remove this dependency? Because SHARP_LOCOMO is a Kconfig symbol for the old driver. New driver uses MFD_LOCOMO Kconfig entry. Also the driver now uses generic platform device and regmap interfaces, so there is no direct dependency on main LoCoMo driver. And the policy (IIRC) was not to have such dependencies. > >> help >> This option enables support for the LEDs on Sharp Locomo. >> Zaurus models SL-5500 and SL-5600. >> diff --git a/drivers/leds/leds-locomo.c b/drivers/leds/leds-locomo.c >> index 80ba048..7fde812 100644 >> --- a/drivers/leds/leds-locomo.c >> +++ b/drivers/leds/leds-locomo.c >> @@ -9,89 +9,92 @@ >> */ >> >> #include <linux/kernel.h> >> -#include <linux/init.h> >> -#include <linux/module.h> >> -#include <linux/device.h> >> #include <linux/leds.h> >> - >> -#include <mach/hardware.h> >> -#include <asm/hardware/locomo.h> >> +#include <linux/module.h> >> +#include <linux/platform_device.h> >> +#include <linux/regmap.h> >> +#include <linux/mfd/locomo.h> > > > Please keep alphabetical order. Ack > >> + >> +struct locomo_led { >> + struct led_classdev led; >> + struct regmap *regmap; >> + unsigned int reg; >> +}; >> >> static void locomoled_brightness_set(struct led_classdev *led_cdev, >> - enum led_brightness value, int offset) >> + enum led_brightness value) >> { >> - struct locomo_dev *locomo_dev = LOCOMO_DEV(led_cdev->dev->parent); >> - unsigned long flags; >> + struct locomo_led *led = container_of(led_cdev, struct locomo_led, >> led); >> >> - local_irq_save(flags); >> - if (value) >> - locomo_writel(LOCOMO_LPT_TOFH, locomo_dev->mapbase + >> offset); >> - else >> - locomo_writel(LOCOMO_LPT_TOFL, locomo_dev->mapbase + >> offset); >> - local_irq_restore(flags); >> + regmap_write(led->regmap, led->reg, >> + value ? LOCOMO_LPT_TOFH : LOCOMO_LPT_TOFL); >> } > > > Please use work queue for setting brightness. This is required for the > driver to be compatible with led triggers. You can refer to the > existing LED drivers on how to implement this. Hmm. Why? The regmap here uses MMIO access, so it is atomic operation and doesn't need to be wrapped into work queue, does it? [skipped] -- With best wishes Dmitry

1 0

[alsa-devel] ALC298 headset mode support
by Kailang 12 May '15

12 May '15

Hi Takashi, I finished the alc298 headset mode supported. But it only tested via our develop system. BR, Kailang

2 3

[alsa-devel] [PATCH] Revert "ASoC: rsnd: make sure it uses lock when it calls rsnd_dai_call"
by Kuninori Morimoto 12 May '15

12 May '15

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> This reverts commit 'e9c390df671f ("ASoC: rsnd: make sure it uses lock when it calls rsnd_dai_call)' The additional locks make 1") lock issue when boot 2) lock issue when unbind/rmmod. And there is no problem without these locks. This patch revert it. Reported-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/rcar/core.c | 27 +++++---------------------- 1 file changed, 5 insertions(+), 22 deletions(-) diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index 99eb109..405cacd 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -731,15 +731,10 @@ static int rsnd_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_dai *dai = rsnd_substream_to_dai(substream); struct rsnd_dai *rdai = rsnd_dai_to_rdai(dai); - struct rsnd_priv *priv = rsnd_dai_to_priv(dai); struct rsnd_dai_stream *io = rsnd_rdai_to_io(rdai, substream); - unsigned long flags; int ret; - rsnd_lock(priv, flags); ret = rsnd_dai_call(hw_params, io, substream, hw_params); - rsnd_unlock(priv, flags); - if (ret) return ret; @@ -926,16 +921,14 @@ int rsnd_kctrl_new_e(struct rsnd_mod *mod, static int rsnd_pcm_new(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_dai *dai = rtd->cpu_dai; - struct rsnd_priv *priv = rsnd_dai_to_priv(dai); struct rsnd_dai *rdai = rsnd_dai_to_rdai(dai); - unsigned long flags; - int ret = 0; + int ret; - rsnd_lock(priv, flags); - ret |= rsnd_dai_call(pcm_new, &rdai->playback, rtd); - ret |= rsnd_dai_call(pcm_new, &rdai->capture, rtd); - rsnd_unlock(priv, flags); + ret = rsnd_dai_call(pcm_new, &rdai->playback, rtd); + if (ret) + return ret; + ret = rsnd_dai_call(pcm_new, &rdai->capture, rtd); if (ret) return ret; @@ -958,11 +951,8 @@ static const struct snd_soc_component_driver rsnd_soc_component = { static int rsnd_rdai_continuance_probe(struct rsnd_priv *priv, struct rsnd_dai_stream *io) { - unsigned long flags; int ret; - rsnd_lock(priv, flags); - ret = rsnd_dai_call(probe, io, priv); if (ret == -EAGAIN) { /* @@ -995,7 +985,6 @@ static int rsnd_rdai_continuance_probe(struct rsnd_priv *priv, */ ret = rsnd_dai_call(probe, io, priv); } - rsnd_unlock(priv, flags); return ret; } @@ -1011,7 +1000,6 @@ static int rsnd_probe(struct platform_device *pdev) struct rsnd_dai *rdai; const struct of_device_id *of_id = of_match_device(rsnd_of_match, dev); const struct rsnd_of_data *of_data; - unsigned long flags; int (*probe_func[])(struct platform_device *pdev, const struct rsnd_of_data *of_data, struct rsnd_priv *priv) = { @@ -1098,12 +1086,10 @@ static int rsnd_probe(struct platform_device *pdev) exit_snd_soc: snd_soc_unregister_platform(dev); exit_snd_probe: - rsnd_lock(priv, flags); for_each_rsnd_dai(rdai, priv, i) { rsnd_dai_call(remove, &rdai->playback, priv); rsnd_dai_call(remove, &rdai->capture, priv); } - rsnd_unlock(priv, flags); return ret; } @@ -1112,7 +1098,6 @@ static int rsnd_remove(struct platform_device *pdev) { struct rsnd_priv *priv = dev_get_drvdata(&pdev->dev); struct rsnd_dai *rdai; - unsigned long flags; void (*remove_func[])(struct platform_device *pdev, struct rsnd_priv *priv) = { rsnd_ssi_remove, @@ -1123,12 +1108,10 @@ static int rsnd_remove(struct platform_device *pdev) pm_runtime_disable(&pdev->dev); - rsnd_lock(priv, flags); for_each_rsnd_dai(rdai, priv, i) { ret |= rsnd_dai_call(remove, &rdai->playback, priv); ret |= rsnd_dai_call(remove, &rdai->capture, priv); } - rsnd_unlock(priv, flags); for (i = 0; i < ARRAY_SIZE(remove_func); i++) remove_func[i](pdev, priv); -- 1.9.1

2 1

[alsa-devel] [PATCH v2] ASoC: dapm: Add cache to speed up adding of routes
by Charles Keepax 12 May '15

12 May '15

Some CODECs have a significant number of DAPM routes and for each route, when it is added to the card, the entire card widget list must be searched. When adding routes it is very likely, however, that adjacent routes will require adjacent widgets. For example all the routes for a mux are likely added in a block and the sink widget will be the same each time and it is also quite likely that the source widgets are sequential located in the widget list. This patch adds a cache to the DAPM context, this cache will hold the source and sink widgets from the last call to snd_soc_dapm_add_route for that context. A small search of the widget list will be made from those points for both the sink and source. Currently this search only checks both the last widget and the one adjacent to it. On wm8280 which has approximately 500 widgets and 30000 routes (one of the largest CODECs in mainline), the number of paths that hit the cache is 24000, which significantly improves probe time. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- Changes since v1: - Provide better encapsulation of the cache, to make swapping out the implementation simpler - Put the cache in the DAPM context instead of passing explicitly to snd_soc_dapm_add_route. I went with the context over the card as it is likely that requests on the same context will hit the cache in the case we have multiple context's interleaving requests. I hope you don't mind Lars but I didn't pull your reviewed-by forward as the code has changed quite a bit for what you reviewed. Thanks, Charles include/sound/soc-dapm.h | 7 +++++++ sound/soc/soc-dapm.c | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+), 0 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index bfc415e..2f66e1c 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -593,6 +593,10 @@ struct snd_soc_dapm_update { int val; }; +struct snd_soc_dapm_wcache { + struct snd_soc_dapm_widget *widget; +}; + /* DAPM context */ struct snd_soc_dapm_context { enum snd_soc_bias_level bias_level; @@ -614,6 +618,9 @@ struct snd_soc_dapm_context { int (*set_bias_level)(struct snd_soc_dapm_context *dapm, enum snd_soc_bias_level level); + struct snd_soc_dapm_wcache path_sink_cache; + struct snd_soc_dapm_wcache path_source_cache; + #ifdef CONFIG_DEBUG_FS struct dentry *debugfs_dapm; #endif diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 7654161..327f9357 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -572,6 +572,35 @@ static void soc_dapm_async_complete(struct snd_soc_dapm_context *dapm) snd_soc_component_async_complete(dapm->component); } +static struct snd_soc_dapm_widget * +dapm_wcache_lookup(struct snd_soc_dapm_wcache *wcache, const char *name) +{ + struct snd_soc_dapm_widget *w = wcache->widget; + struct list_head *wlist; + const int depth = 2; + int i = 0; + + if (w) { + wlist = &w->dapm->card->widgets; + + list_for_each_entry_from(w, wlist, list) { + if (!strcmp(name, w->name)) + return w; + + if (++i == depth) + break; + } + } + + return NULL; +} + +static inline void dapm_wcache_update(struct snd_soc_dapm_wcache *wcache, + struct snd_soc_dapm_widget *w) +{ + wcache->widget = w; +} + /** * snd_soc_dapm_force_bias_level() - Sets the DAPM bias level * @dapm: The DAPM context for which to set the level @@ -2610,6 +2639,12 @@ static int snd_soc_dapm_add_route(struct snd_soc_dapm_context *dapm, source = route->source; } + wsource = dapm_wcache_lookup(&dapm->path_source_cache, source); + wsink = dapm_wcache_lookup(&dapm->path_sink_cache, sink); + + if (wsink && wsource) + goto skip_search; + /* * find src and dest widgets over all widgets but favor a widget from * current DAPM context @@ -2644,6 +2679,10 @@ static int snd_soc_dapm_add_route(struct snd_soc_dapm_context *dapm, return -ENODEV; } +skip_search: + dapm_wcache_update(&dapm->path_sink_cache, wsink); + dapm_wcache_update(&dapm->path_source_cache, wsource); + ret = snd_soc_dapm_add_path(dapm, wsource, wsink, route->control, route->connected); if (ret) -- 1.7.2.5

2 1

[alsa-devel] [PATCH] ALSA: hda - Remove unused call to "get_pin" in patch_hdmi.c
by David Henningsson 12 May '15

12 May '15

Janitorial patch (no functional change) Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_hdmi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index e8d8478..fd11ad7 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2049,9 +2049,7 @@ static int generic_hdmi_build_pcms(struct hda_codec *codec) for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { struct hda_pcm *info; struct hda_pcm_stream *pstr; - struct hdmi_spec_per_pin *per_pin; - per_pin = get_pin(spec, pin_idx); info = snd_hda_codec_pcm_new(codec, "HDMI %d", pin_idx); if (!info) return -ENOMEM; -- 1.9.1

2 2

[alsa-devel] [PATCH 0/5] ASoC: rsnd: tidyup patches
by Kuninori Morimoto 12 May '15

12 May '15

Hi Mark These are not so very important, but tidyup patches for Renesas R-Car driver. Kuninori Morimoto (5): ASoC: rsnd: add rsnd_dai_to_priv() macro ASoC: rsnd: make sure it uses lock when it calls rsnd_dai_call ASoC: rsnd: tidyup SSI parent related function/macro names ASoC: rsnd: make sure SSI parent/child uses same number of sound channel. ASoC: rsnd: care snd_kcontrol's index sound/soc/sh/rcar/core.c | 34 +++++++++++++++++++++++++++------- sound/soc/sh/rcar/ssi.c | 52 +++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 72 insertions(+), 14 deletions(-) Best regards --- Kuninori Morimoto

3 11