December 2011 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
by Mark Brown 31 Dec '11

31 Dec '11

On Fri, Dec 30, 2011 at 07:34:29PM +0000, Måns Rullgård wrote: > Måns Rullgård <mans(a)mansr.com> writes: > > In which tree? I haven't seen anything of the kind. The random sampling of drivers I looked at seemed to be doing something sensible. > That would be this one: > http://article.gmane.org/gmane.linux.alsa.devel/89052 Oh, well. Liam is a bit lossy sometimes. You really need to repost patches if they're worthwhile, don't just let them rot.

1 0

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
by Mark Brown 31 Dec '11

31 Dec '11

On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote: > On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown > > On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: > >> >> > That should not be required, the modules should be loadable in any > >> >> > order. > >> Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. > > That is compltelely orthogonal to what you were saying above about the > > ordering of module loading. > Not really, because if both are compiled as modules, > snd_soc_tlv320aic3x will always be loaded first (automatically by > udev). Which is relevant because...? To repeat, the ordering of module loading is totally ortogonal as any ordering of modules is supported. You appear to be totally ignoring what I am writing here. > > The reason the driver is not loaded automatically is that the OMAP > > machine drivers have not been converted to platform devices. > Well, if that's the case then there's a real issue. There doesn't seem > to be a MODULE_DEPENDS(), or anything like that. A MODULE_DEPENDS() would also be irrelevant here. > snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through > codec_dai_name, and codec_name, and so on. I don't know how this > dependency is supposed to work out. All the drivers should load via the normal driver instantiation mechainsms and when they're all there they'll get matched together.

1 0

Re: [alsa-devel] [PATCH 0/6] snd-usb endpoint rework, version 6
by Daniel Mack 30 Dec '11

30 Dec '11

On 12/30/2011 04:16 PM, Felix Homann wrote: > Hi Daniel, > > 2011/12/30 Daniel Mack <zonque(a)gmail.com>: >> >> Any chance that more people who've been waiting for support of the FTU >> can use the lazy time between the years and quickly test this set? > > Could you please put a combined patch on your github place? Done: https://gist.github.com/1168715 > Should it be OK to use the alsa-driver/alsa-kernel update approach or > would I need to build a complete kernel image? Take Linus' tree, merge Takashi's tree (from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git master) and then apply the gist. Daniel

1 0

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
by Mark Brown 30 Dec '11

30 Dec '11

On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: > On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown > > On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote: > >> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown > >> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote: > >> >> It was not working for me, but it seems the problem was related to > >> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51. > >> > That should not be required, the modules should be loadable in any > >> > order. > >> Are you sure? I recall having a similar discussion with Rusell King, > >> and the conclusion is that certain modules are supposed to be loaded > >> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them. > > I'm absolutely positive. ASoC supports loading the modules in any > > order. udev is supposed to load anything autoloadable at boot time, > > including I2C devices, but that's orthogonal to the order in which > > things actually get loaded - udev can randomly reorder things if it > > feels like it. > Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. That is compltelely orthogonal to what you were saying above about the ordering of module loading. The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices.

3 3

[alsa-devel] pcm timer resolution out of range (rate = 0, period_size = 1), Division by zero in kernel
by Appalayagari Sreedhar 30 Dec '11

30 Dec '11

Hi, We are working with 2.6.32 kernel. we are working with ALSA model codec driver for conexant chipset. we are using OSS emulation for audio playback and recording. we are not setting the fragmenttaion block using OSS ioctl function (SNDCTL_DSP_SETFRAGMENT) , assuming that it will be taken care by the ALSA framework based on the sampling rate, bits per sample etc. we are facing the below issue randomly. ALSA sound/core/pcm_timer.c:71: -calling VIDIOC_pcm timer resolution out of range (rate = 0, period_size = 1) Division by zero in kernel. We tried to program the fragmentation block after the sampling rate, bits per sample etc are configured. it is working fine for 5 or 6 iterations for recording and playback. after that the audio quality is gone bad. the audio is not smooth and it is sharp. could you please help to resolve this problem. Thank you, Sreedhar.

2 3

[alsa-devel] [PATCH v2 3/4] ARM: OMAP1: ams-delta: update the modem to use regulator API
by Janusz Krzysztofik 30 Dec '11

30 Dec '11

After the CX20442 codec driver already takes care of enabling the codec power for itself, but before dropping the old bias control method from the Amstrad Delta ASoC sound card file, which in fact keeps the modem power always on, even after the ASoC device close for now, extend the modem setup with a power management callback, which toggles the regulator up to the modem's needs, reusing the previously set up regulator consumer for this. Also, drop the MODEM_NRESET pin setup from the modem initialization procedure, as this operation was already ineffective since patch 1/4, and not needed because the regulator is set up as initially enabled. Depends on patch 1/4 "ARM: OMAP1: ams-delta: set up a regulator over the modem reset GPIO pin" to apply cleanly, and requires patch 2/4 "ASoC: cx20442: add bias control over a platform provided regulator" for the sound card / codec bundle to still work. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- No functional changes against initial version. arch/arm/mach-omap1/board-ams-delta.c | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 074d3b5..3389237 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -526,6 +526,16 @@ static void __init ams_delta_init(void) omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1); } +static void modem_pm(struct uart_port *port, unsigned int state, unsigned old) +{ + struct modem_private_data *priv = port->private_data; + + if (state == old) + return; + + regulator_toggle(priv, state == 0); +} + static struct plat_serial8250_port ams_delta_modem_ports[] = { { .membase = IOMEM(MODEM_VIRT), @@ -536,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = { .iotype = UPIO_MEM, .regshift = 1, .uartclk = BASE_BAUD * 16, + .pm = modem_pm, + .private_data = &modem_priv, }, { }, }; @@ -584,9 +596,8 @@ static int __init late_init(void) mutex_init(&modem_priv.consumer.lock); modem_priv.regulator = ERR_PTR(-ENODEV); - ams_delta_latch2_write( - AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, - AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC); + ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, + AMS_DELTA_LATCH2_MODEM_CODEC); err = platform_device_register(&ams_delta_modem_device); if (err) @@ -595,8 +606,9 @@ static int __init late_init(void) /* * Once the modem device is registered, the modem_nreset * regulator can be requested on behalf of that device. - * The regulator is used via ams_delta_latch_write() - * by the modem and ASoC drivers until updated. + * In addition to the modem .pm callback, that regulator + * is still used via the ams_delta_latch_write() wrapper + * by the ASoC driver until updated. */ modem_priv.regulator = regulator_get(&ams_delta_modem_device.dev, "RESET#"); -- 1.7.3.4

1 0

[alsa-devel] [PATCH v2 1/4] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
by Janusz Krzysztofik 30 Dec '11

30 Dec '11

The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin, with the intention of updating both drivers to manipulate that regulator, not the GPIO pin directly. Before the ASoC driver is updated and the modem platform data expanded with a power management callback for switching its power, the ams_delta_latch_write() function, which still provides the old API for accessing latch2 functionality from not updated drivers, is modified to toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper function provided for balancing the regulator enable/disable operations, together with the consumer data needed for tracking the regulator state, will be removed once the drivers are updated. Depends on patch series "ARM: OMAP1: ams-delta: replace custom I/O with GPIO". Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- Changes against initial version: * rename consumer setup elements to match their final, modem only related purpose, * initialize the regulator pointer and mutex before first use, then omit testing that pointer against NULL value. arch/arm/mach-omap1/Kconfig | 2 + arch/arm/mach-omap1/board-ams-delta.c | 104 +++++++++++++++++++++++++++++++-- 2 files changed, 100 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index 5b1edba..4b6a774 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -157,6 +157,8 @@ config MACH_AMS_DELTA select FIQ select GPIO_GENERIC_PLATFORM select LEDS_GPIO_REGISTER + select REGULATOR + select REGULATOR_FIXED_VOLTAGE help Support for the Amstrad E3 (codename Delta) videophone. Say Y here if you have such a device. diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 673cf21..074d3b5 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -18,7 +18,11 @@ #include <linux/input.h> #include <linux/interrupt.h> #include <linux/leds.h> +#include <linux/mutex.h> #include <linux/platform_device.h> +#include <linux/regulator/consumer.h> +#include <linux/regulator/fixed.h> +#include <linux/regulator/machine.h> #include <linux/serial_8250.h> #include <linux/export.h> @@ -237,11 +241,6 @@ static struct gpio latch_gpios[] __initconst = { .label = "scard_cmdvcc", }, { - .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET, - .flags = GPIOF_OUT_INIT_LOW, - .label = "modem_nreset", - }, - { .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC, .flags = GPIOF_OUT_INIT_LOW, .label = "modem_codec", @@ -258,6 +257,71 @@ static struct gpio latch_gpios[] __initconst = { }, }; +static struct regulator_consumer_supply modem_nreset_consumers[] __initconst = { + REGULATOR_SUPPLY("RESET#", "serial8250.1"), + REGULATOR_SUPPLY("POR", "cx20442-codec"), +}; + +static struct regulator_init_data modem_nreset_data __initconst = { + .constraints = { + .valid_ops_mask = REGULATOR_CHANGE_STATUS, + .boot_on = 1, + }, + .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers), + .consumer_supplies = modem_nreset_consumers, +}; + +static struct fixed_voltage_config modem_nreset_config __initconst = { + .supply_name = "modem_nreset", + .microvolts = 3300000, + .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET, + .startup_delay = 25000, + .enable_high = 1, + .enabled_at_boot = 1, + .init_data = &modem_nreset_data, +}; + +static struct platform_device modem_nreset_device = { + .name = "reg-fixed-voltage", + .id = -1, + .dev = { + .platform_data = &modem_nreset_config, + }, +}; + +struct modem_private_data { + struct regulator *regulator; + struct { + struct mutex lock; + bool enabled; + } consumer; +}; + +static int regulator_toggle(struct modem_private_data *priv, bool enable) +{ + int err = 0; + + mutex_lock(&priv->consumer.lock); + if (IS_ERR(priv->regulator)) { + err = PTR_ERR(priv->regulator); + } else if (enable) { + if (!priv->consumer.enabled) { + err = regulator_enable(priv->regulator); + priv->consumer.enabled = true; + } + } else { + if (priv->consumer.enabled) { + err = regulator_disable(priv->regulator); + priv->consumer.enabled = false; + } + } + mutex_unlock(&priv->consumer.lock); + + return err; +} + +static struct modem_private_data modem_priv; + void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value) { int bit = 0; @@ -266,7 +330,10 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value) for (; bit < ngpio; bit++, bitpos = bitpos << 1) { if (!(mask & bitpos)) continue; - gpio_set_value(base + bit, (value & bitpos) != 0); + else if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET) + regulator_toggle(&modem_priv, (value & bitpos) != 0); + else + gpio_set_value(base + bit, (value & bitpos) != 0); } } EXPORT_SYMBOL(ams_delta_latch_write); @@ -496,6 +563,12 @@ static int __init late_init(void) platform_add_devices(late_devices, ARRAY_SIZE(late_devices)); + err = platform_device_register(&modem_nreset_device); + if (err) { + pr_err("Couldn't register the modem regulator device\n"); + return err; + } + omap_cfg_reg(M14_1510_GPIO2); ams_delta_modem_ports[0].irq = gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ); @@ -507,6 +580,10 @@ static int __init late_init(void) } gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ); + /* Initialize the modem_nreset regulator consumer before use */ + mutex_init(&modem_priv.consumer.lock); + modem_priv.regulator = ERR_PTR(-ENODEV); + ams_delta_latch2_write( AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC); @@ -514,8 +591,23 @@ static int __init late_init(void) err = platform_device_register(&ams_delta_modem_device); if (err) goto gpio_free; + + /* + * Once the modem device is registered, the modem_nreset + * regulator can be requested on behalf of that device. + * The regulator is used via ams_delta_latch_write() + * by the modem and ASoC drivers until updated. + */ + modem_priv.regulator = regulator_get(&ams_delta_modem_device.dev, + "RESET#"); + if (IS_ERR(modem_priv.regulator)) { + err = PTR_ERR(modem_priv.regulator); + goto unregister; + } return 0; +unregister: + platform_device_unregister(&ams_delta_modem_device); gpio_free: gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ); return err; -- 1.7.3.4

1 0

[alsa-devel] [PATCH v2 0/4] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
by Janusz Krzysztofik 30 Dec '11

30 Dec '11

The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. Changes against initial version: * in both the codec and the modem callbacks, don't track the regulator enable/disable state, compare new targert bias level (the codec case) or power state (the modem case) with the old value instead; thanks to Mark Brown who suggested this solution, * a few other minor changes, mostly stylistic. Janusz Krzysztofik (4): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ASoC: cx20442: add bias control over a platform provided regulator ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig | 2 + arch/arm/mach-omap1/board-ams-delta.c | 94 +++++++++++++++++++-- arch/arm/plat-omap/include/plat/board-ams-delta.h | 1 - sound/soc/codecs/cx20442.c | 48 ++++++++++- sound/soc/omap/ams-delta.c | 34 -------- 5 files changed, 133 insertions(+), 46 deletions(-) -- 1.7.3.4

1 0

[alsa-devel] [PATCH 1/3] ASoC: pxa: Convert poodle to use snd_soc_register_card()
by Axel Lin 30 Dec '11

30 Dec '11

Use snd_soc_register_card() instead of creating a "soc-audio" platform device. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- arch/arm/mach-pxa/poodle.c | 6 ++++++ sound/soc/pxa/poodle.c | 42 +++++++++++++++++++++++------------------- 2 files changed, 29 insertions(+), 19 deletions(-) diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c index 69036e4..744baee 100644 --- a/arch/arm/mach-pxa/poodle.c +++ b/arch/arm/mach-pxa/poodle.c @@ -158,6 +158,11 @@ static struct scoop_pcmcia_config poodle_pcmcia_config = { EXPORT_SYMBOL(poodle_scoop_device); +static struct platform_device poodle_audio_device = { + .name = "poodle-audio", + .id = -1, +}; + /* LoCoMo device */ static struct resource locomo_resources[] = { [0] = { @@ -407,6 +412,7 @@ static struct platform_device sharpsl_rom_device = { static struct platform_device *devices[] __initdata = { &poodle_locomo_device, &poodle_scoop_device, + &poodle_audio_device, &sharpsl_nand_device, &sharpsl_rom_device, }; diff --git a/sound/soc/pxa/poodle.c b/sound/soc/pxa/poodle.c index 4c29bc1..c9e24bf 100644 --- a/sound/soc/pxa/poodle.c +++ b/sound/soc/pxa/poodle.c @@ -281,22 +281,18 @@ static struct snd_soc_dai_link poodle_dai = { }; /* poodle audio machine driver */ -static struct snd_soc_card snd_soc_poodle = { +static struct snd_soc_card poodle = { .name = "Poodle", .dai_link = &poodle_dai, .num_links = 1, .owner = THIS_MODULE, }; -static struct platform_device *poodle_snd_device; - -static int __init poodle_init(void) +static int __devinit poodle_probe(struct platform_device *pdev) { + struct snd_soc_card *card = &poodle; int ret; - if (!machine_is_poodle()) - return -ENODEV; - locomo_gpio_set_dir(&poodle_locomo_device.dev, POODLE_LOCOMO_GPIO_AMP_ON, 0); /* should we mute HP at startup - burning power ?*/ @@ -305,28 +301,36 @@ static int __init poodle_init(void) locomo_gpio_set_dir(&poodle_locomo_device.dev, POODLE_LOCOMO_GPIO_MUTE_R, 0); - poodle_snd_device = platform_device_alloc("soc-audio", -1); - if (!poodle_snd_device) - return -ENOMEM; - - platform_set_drvdata(poodle_snd_device, &snd_soc_poodle); - ret = platform_device_add(poodle_snd_device); + card->dev = &pdev->dev; + ret = snd_soc_register_card(card); if (ret) - platform_device_put(poodle_snd_device); - + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", + ret); return ret; } -static void __exit poodle_exit(void) +static int __devexit poodle_remove(struct platform_device *pdev) { - platform_device_unregister(poodle_snd_device); + struct snd_soc_card *card = platform_get_drvdata(pdev); + + snd_soc_unregister_card(card); + return 0; } -module_init(poodle_init); -module_exit(poodle_exit); +static struct platform_driver poodle_driver = { + .driver = { + .name = "poodle-audio", + .owner = THIS_MODULE, + }, + .probe = poodle_probe, + .remove = __devexit_p(poodle_remove), +}; + +module_platform_driver(poodle_driver); /* Module information */ MODULE_AUTHOR("Richard Purdie"); MODULE_DESCRIPTION("ALSA SoC Poodle"); MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:poodle-audio"); -- 1.7.5.4

3 4

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
by Mark Brown 29 Dec '11

29 Dec '11

On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote: > On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown > > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote: > >> It was not working for me, but it seems the problem was related to > >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51. > > That should not be required, the modules should be loadable in any > > order. > Are you sure? I recall having a similar discussion with Rusell King, > and the conclusion is that certain modules are supposed to be loaded > by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them. I'm absolutely positive. ASoC supports loading the modules in any order. udev is supposed to load anything autoloadable at boot time, including I2C devices, but that's orthogonal to the order in which things actually get loaded - udev can randomly reorder things if it feels like it.

1 0