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

[alsa-devel] [PATCH] ASoC: wm2200: Convert to devm APIs
by Mark Brown 01 Oct '12

01 Oct '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2200.c | 39 ++++++++++++++------------------------- 1 file changed, 14 insertions(+), 25 deletions(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index efa93dbb..02ea49e 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -2011,7 +2011,7 @@ static __devinit int wm2200_i2c_probe(struct i2c_client *i2c, wm2200->dev = &i2c->dev; init_completion(&wm2200->fll_lock); - wm2200->regmap = regmap_init_i2c(i2c, &wm2200_regmap); + wm2200->regmap = devm_regmap_init_i2c(i2c, &wm2200_regmap); if (IS_ERR(wm2200->regmap)) { ret = PTR_ERR(wm2200->regmap); dev_err(&i2c->dev, "Failed to allocate register map: %d\n", @@ -2027,8 +2027,9 @@ static __devinit int wm2200_i2c_probe(struct i2c_client *i2c, for (i = 0; i < ARRAY_SIZE(wm2200->core_supplies); i++) wm2200->core_supplies[i].supply = wm2200_core_supply_names[i]; - ret = regulator_bulk_get(&i2c->dev, ARRAY_SIZE(wm2200->core_supplies), - wm2200->core_supplies); + ret = devm_regulator_bulk_get(&i2c->dev, + ARRAY_SIZE(wm2200->core_supplies), + wm2200->core_supplies); if (ret != 0) { dev_err(&i2c->dev, "Failed to request core supplies: %d\n", ret); @@ -2044,8 +2045,9 @@ static __devinit int wm2200_i2c_probe(struct i2c_client *i2c, } if (wm2200->pdata.ldo_ena) { - ret = gpio_request_one(wm2200->pdata.ldo_ena, - GPIOF_OUT_INIT_HIGH, "WM2200 LDOENA"); + ret = devm_gpio_request_one(&i2c->dev, wm2200->pdata.ldo_ena, + GPIOF_OUT_INIT_HIGH, + "WM2200 LDOENA"); if (ret < 0) { dev_err(&i2c->dev, "Failed to request LDOENA %d: %d\n", wm2200->pdata.ldo_ena, ret); @@ -2055,8 +2057,9 @@ static __devinit int wm2200_i2c_probe(struct i2c_client *i2c, } if (wm2200->pdata.reset) { - ret = gpio_request_one(wm2200->pdata.reset, - GPIOF_OUT_INIT_HIGH, "WM2200 /RESET"); + ret = devm_gpio_request_one(&i2c->dev, wm2200->pdata.reset, + GPIOF_OUT_INIT_HIGH, + "WM2200 /RESET"); if (ret < 0) { dev_err(&i2c->dev, "Failed to request /RESET %d: %d\n", wm2200->pdata.reset, ret); @@ -2165,23 +2168,16 @@ static __devinit int wm2200_i2c_probe(struct i2c_client *i2c, err_pm_runtime: pm_runtime_disable(&i2c->dev); err_reset: - if (wm2200->pdata.reset) { + if (wm2200->pdata.reset) gpio_set_value_cansleep(wm2200->pdata.reset, 0); - gpio_free(wm2200->pdata.reset); - } err_ldo: - if (wm2200->pdata.ldo_ena) { + if (wm2200->pdata.ldo_ena) gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 0); - gpio_free(wm2200->pdata.ldo_ena); - } err_enable: regulator_bulk_disable(ARRAY_SIZE(wm2200->core_supplies), wm2200->core_supplies); err_core: - regulator_bulk_free(ARRAY_SIZE(wm2200->core_supplies), - wm2200->core_supplies); err_regmap: - regmap_exit(wm2200->regmap); err: return ret; } @@ -2193,17 +2189,10 @@ static __devexit int wm2200_i2c_remove(struct i2c_client *i2c) snd_soc_unregister_codec(&i2c->dev); if (i2c->irq) free_irq(i2c->irq, wm2200); - if (wm2200->pdata.reset) { + if (wm2200->pdata.reset) gpio_set_value_cansleep(wm2200->pdata.reset, 0); - gpio_free(wm2200->pdata.reset); - } - if (wm2200->pdata.ldo_ena) { + if (wm2200->pdata.ldo_ena) gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 0); - gpio_free(wm2200->pdata.ldo_ena); - } - regulator_bulk_free(ARRAY_SIZE(wm2200->core_supplies), - wm2200->core_supplies); - regmap_exit(wm2200->regmap); return 0; } -- 1.7.10.4

1 0

Re: [alsa-devel] 0.2ms latency
by Pavel Roskin 01 Oct '12

01 Oct '12

Quoting Uwaysi Bin Kareem <uwaysi.bin.kareem(a)paradoxuncreated.com>: > Hi. I am aiming for 0.2ms latency with a HDA onboard soundcard. > > I recently did 0.3ms on a firewire card, with realtime streams. (which > is the lowest possible for firewire protocol.) > This does not work with the alsa HDA device. (some clicking) > Is this a weakness software-wise, that can be improved? > I also do notice that the driver (probably) seems to allow lower > latencies at 96k. Hello! This is the first time I got a message from this list. I subscribed to it about a month ago to report a kernel bug. I guess this mailing list is defunct and the discussion is happening elsewhere. -- Regards, Pavel Roskin -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

3 2

Re: [alsa-devel] [PATCH] ASoC: Revert 'ASoC: imx-ssi: Remove mono support'
by Mark Brown 01 Oct '12

01 Oct '12

On Mon, Oct 01, 2012 at 11:33:45AM +0200, javier Martin wrote: > Hi Mark, Fabio, > this patch should be applied as a fix to stable 3.6 too. Otherwise, > audio for Visstrim M10 will continue broken in 3.6. You need to tell the stable team about this, then.

1 0

[alsa-devel] ASoC updates for 3.7
by Mark Brown 01 Oct '12

01 Oct '12

The following changes since commit ddfb43f3881edb47aa0083651ad31983cdc42c33: Merge tag 'v3.6-rc6' into for-3.7 (2012-09-22 11:26:27 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 for you to fetch changes up to 9911f7f7562a25381eff93fdc660a4a3b4c0f6e0: ASoC: codecs: Add DA9055 codec driver (2012-09-28 14:21:54 +0100) ---------------------------------------------------------------- ASoC: Additional updates for v3.7 A couple more updates for 3.7, enhancements to the ux500 and wm2000 drivers, a new driver for DA9055 and the support for regulator bypass mode. With the exception of the DA9055 this has all had a chance to soak in -next (the driver was added on Friday so should be in -next today). ---------------------------------------------------------------- Ashish Chavan (1): ASoC: codecs: Add DA9055 codec driver Charles Keepax (1): ASoC: wm5110: Adding missing volume update bits Daniel Mack (1): ALSA: ASoC: add DT bindings for CS4271 Fabio Estevam (2): ASoC: cs4270: Remove mono support ASoC: eukrea-tlv320: Convert it to platform driver Lee Jones (7): ASoC: Ux500: Move MSP pinctrl setup into the MSP driver ASoC: Ux500: Enable MOP500 driver for Device Tree ASoC: Ux500: Enable ux500 MSP driver for Device Tree ASoC: codecs: Enable AB8500 CODEC for Device Tree ASoC: Ux500: Minor coding layout changes Documentation: Define the MOP500 Audio Machine Driver Device Tree bindings Documentation: Define the MSP Driver Device Tree bindings Mark Brown (22): regulator: core: Support bypass mode regulator: core: Provide regmap get/set bypass operations regulator: arizona-ldo: Support get/set bypass regulator: arizona-micsupp: Support get/set bypass regulator: wm831x-ldo: Add bypass support extcon: arizona: Use bypass mode for MICVDD ASoC: wm2000: Convert to devm_regmap_init_i2c() ASoC: wm2000: Add regulator support Merge remote-tracking branch 'asoc/topic/ux500' into for-3.7 Merge tag 'bypass' of git://git.kernel.org/.../broonie/regulator into for-3.7 ASoC: dapm: Allow regulators to bypass as well as disable when idle ASoC: wm5102: Enable bypass mode for MICVDD ASoC: wm5110: Enable bypass mode for MICVDD ASoC: wm0010: Allow slow GPIO for reset ASoC: wm0010: Don't check if reset GPIO is defined when removing ASoC: wm0010: Initialise chip state before we register the interrupt ASoC: arizona: Add more DSP options for mixer input muxes ASoC: arizona: Add more clock rates ASoC: wm5110: Rename EPOUT to HPOUT3 ASoC: wm5110: Add AEC loopback support ASoC: wm5110: Add OUT3R support ASoC: wm_hubs: Ensure volume updates are handled during class W startup Documentation/ABI/testing/sysfs-class-regulator | 21 + Documentation/devicetree/bindings/sound/cs4271.txt | 36 + .../devicetree/bindings/sound/ux500-mop500.txt | 39 + .../devicetree/bindings/sound/ux500-msp.txt | 43 + arch/arm/mach-imx/eukrea_mbimx27-baseboard.c | 1 + arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 1 + arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c | 1 + arch/arm/mach-imx/eukrea_mbimxsd51-baseboard.c | 1 + arch/arm/mach-ux500/board-mop500-msp.c | 79 +- arch/arm/mach-ux500/include/mach/msp.h | 2 - drivers/extcon/extcon-arizona.c | 5 + drivers/regulator/arizona-ldo1.c | 4 + drivers/regulator/arizona-micsupp.c | 5 + drivers/regulator/core.c | 126 ++ drivers/regulator/wm831x-ldo.c | 8 + include/linux/mfd/abx500/ab8500-codec.h | 6 +- include/linux/regulator/consumer.h | 8 + include/linux/regulator/driver.h | 14 + include/linux/regulator/machine.h | 2 + include/sound/da9055.h | 33 + include/sound/soc-dapm.h | 3 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ab8500-codec.c | 81 ++ sound/soc/codecs/arizona.c | 42 + sound/soc/codecs/arizona.h | 2 +- sound/soc/codecs/cs4270.c | 4 +- sound/soc/codecs/cs4271.c | 24 +- sound/soc/codecs/da9055.c | 1510 ++++++++++++++++++++ sound/soc/codecs/wm0010.c | 18 +- sound/soc/codecs/wm2000.c | 60 +- sound/soc/codecs/wm5102.c | 2 +- sound/soc/codecs/wm5110.c | 79 +- sound/soc/codecs/wm_hubs.c | 5 + sound/soc/fsl/eukrea-tlv320.c | 37 +- sound/soc/soc-dapm.c | 23 +- sound/soc/ux500/mop500.c | 47 +- sound/soc/ux500/ux500_msp_dai.c | 6 + sound/soc/ux500/ux500_msp_i2s.c | 89 +- sound/soc/ux500/ux500_msp_i2s.h | 8 +- 40 files changed, 2307 insertions(+), 174 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/cs4271.txt create mode 100644 Documentation/devicetree/bindings/sound/ux500-mop500.txt create mode 100644 Documentation/devicetree/bindings/sound/ux500-msp.txt create mode 100644 include/sound/da9055.h create mode 100644 sound/soc/codecs/da9055.c

1 0

Re: [alsa-devel] [PATCH] ASoC: fixup simple-card probe order
by Mark Brown 01 Oct '12

01 Oct '12

On Mon, Oct 01, 2012 at 09:44:37AM +0900, Do Q.Thang wrote: > Hi all, > > KZM-A9-GT board and Armadillo-800eva board use the asoc-simple-card. > but probe of this sound card needs the fsi-dai's registered before. > So this message appear in the bootlog. > > " asoc-simple-card asoc-simple-card.0: CPU DAI fsia-dai not registered > platform asoc-simple-card.0: Driver asoc-simple-card requests probe > deferral " > > The asoc-simple-card was probed while fsi-dai probe hasn't run yet. > So asoc-simple-card probe deferral is requested. > I think the simple-card should be probed after the fsi-dai probe. > I think this patch can fix this issue. > > What do you think about this? The above is normal and expected behaviour, there is no issue here.

1 0