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

[alsa-devel] [PATCH][RFC] intel-hda: proper support for Asus N55SF/N75SF laptops with external subwoofer
by Andrew 06 Mar '12

06 Mar '12

Hello all, The following patch adds full support for Asus Laptops N55SF/N75SF (Possibly more models) with external subwoofer. It adds a new model (asus-nx5) and proper PCIID detection. Example asoundrc for upmixing and dmix is attached as well. (Thanks to K900 from AgiliaLinux dev. conference for it as well as testing on N55SF) Currently everything is supported except Subwoofer pin autosensing. It is somehow implemented in windows drivers, but I couldn't get it neither via codec's gpio or regular 0x16 unsol event. In 2ch mode the subwoofer is off, so should save a little bit of battery. I couldn't test automic feature and spdif, because I don't have the hardware around. Since alc662_quirks.c looks a little bit overbloated, I moved my quirks to a separate file. If that's not OK, I'll resubmit the patch. (This is my first patch to alsa-devel, so I might be missing something) Regards, Andrew

2 1

[alsa-devel] ALC892, Clevo P150HM: Input Source gets reset to "Mic" every resume
by Julian Sikorski 02 Mar '12

02 Mar '12

Hi, whenever I resume the machine, the Input Source would get changed back from "Internal Mic" to "Mic". This is a bit annoying, because pulseaudio is unaware of that change. As a result, everything looks fine in pavucontrol but no sound gets recorded. A quick look at alsamixer -c0 revealed the problem. My alsa info: http://www.alsa-project.org/db/?f=c5776b615a5f3b9ae624e4250fb0c2b69118ce26 This is unrelated to the other problems I have been reporting, since this happens on a mostly-stock Fedora 3.1.2 kernel (the patch I added deals with xhci, not alsa). Regards, Julian

3 8

[alsa-devel] [PATCH] ALSA : Au88x0 - Support 4 channels playback when AC97 codec has SDAC bit , Reduce the number of playback devices of au8830 from 32 to 16
by Raymond Yau 28 Feb '12

28 Feb '12

[PATCH - ALSA 1/2] Au88x0 - Support 4 channels playback when AC97 codecs has SDAC bit - Check SDAC bit of AC97 codec for supporting 4 channels playback. [PATCH - ALSA 2/2] Au88x0 - Reduce the number of playback subdevices of au8830 from 32 to 16 - The maximum number of playback streams depend on the number of sample rate conveters (16) and the number of DMA channels (32).

2 3

Re: [alsa-devel] [RFC PATCH] ARM ASoC: add sound driver for imx27pdk using mc13783 codec
by Fabio Estevam 09 Feb '12

09 Feb '12

Hi Philippe, On Wed, Jan 25, 2012 at 1:45 PM, Philippe Rétornaz <philippe.retornaz(a)epfl.ch> wrote: > I have a working sound support for the mx31moboard boards available here: > http://github.com/retornaz/linux/commits/moboard-sound That's cool :-) > It's basically Sascha mc13783 codec driver (from his git tree) rebased on 3.2 > and some mx31moboad specific code. > > I can playback & record sound on our board (2 channels@16Khz) with the sdma. > > Sascha, do you have any plan to upstream the mc13783 codec driver ? In case Sascha doesn't have plans to upstream mc13783, is this something you could do? Thanks, Fabio Estevam

3 6

[alsa-devel] [RESEND PATCH] davinci: CQ93VC: remove machine specific header file inclusion from codec driver
by Manjunath Hadli 08 Feb '12

08 Feb '12

remove unnecessary inclusion of machine specific header file mach/dm365.h from cq93vc.c voice codec driver which comes in the way of platform code consolidation. Signed-off-by: Manjunath Hadli <manjunath.hadli(a)ti.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Jaroslav Kysela <perex(a)perex.cz> CC: Takashi Iwai <tiwai(a)suse.de> Cc: <alsa-devel(a)alsa-project.org> Cc: <linux-kernel(a)vger.kernel.org> --- sound/soc/codecs/cq93vc.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c index 46dbfd0..ff4eb7a 100644 --- a/sound/soc/codecs/cq93vc.c +++ b/sound/soc/codecs/cq93vc.c @@ -38,8 +38,6 @@ #include <sound/soc.h> #include <sound/initval.h> -#include <mach/dm365.h> - static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, unsigned int reg) { -- 1.6.2.4

3 3

[alsa-devel] [PATCH 1/15] sound/soc/mxs/mxs-saif.c: add missing iounmap
by Julia Lawall 08 Feb '12

08 Feb '12

From: Julia Lawall <Julia.Lawall(a)lip6.fr> Add missing iounmap in error handling code, in a case where the function already preforms iounmap on some other execution path. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e; statement S,S1; int ret; @@ e = \(ioremap\|ioremap_nocache\)(...) ... when != iounmap(e) if (<+...e...+>) S ... when any when != iounmap(e) *if (...) { ... when != iounmap(e) return ...; } ... when any iounmap(e); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr> --- sound/soc/mxs/mxs-saif.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index 049e543..5ee0adb 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -680,7 +680,7 @@ static int mxs_saif_probe(struct platform_device *pdev) ret = -ENODEV; dev_err(&pdev->dev, "failed to get dma resource: %d\n", ret); - goto failed_ioremap; + goto failed_get_resource; } saif->dma_param.chan_num = dmares->start; @@ -739,6 +739,7 @@ failed_register: failed_get_irq2: free_irq(saif->irq, saif); failed_get_irq1: +failed_get_resource: iounmap(saif->base); failed_ioremap: release_mem_region(iores->start, resource_size(iores));

6 29

[alsa-devel] [PATCH 1/2] ASoC: Convert kirkwood-t5325 to use snd_soc_register_card()
by Axel Lin 07 Feb '12

07 Feb '12

Use snd_soc_register_card() instead of creating a "soc-audio" platform device. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- I don't have this hardware, I'd appreciate if someone can test this patch. Axel arch/arm/mach-kirkwood/t5325-setup.c | 6 ++++ sound/soc/kirkwood/kirkwood-t5325.c | 47 +++++++++++++++++---------------- 2 files changed, 30 insertions(+), 23 deletions(-) diff --git a/arch/arm/mach-kirkwood/t5325-setup.c b/arch/arm/mach-kirkwood/t5325-setup.c index 966b2b3..f9d2a11 100644 --- a/arch/arm/mach-kirkwood/t5325-setup.c +++ b/arch/arm/mach-kirkwood/t5325-setup.c @@ -106,6 +106,11 @@ static struct platform_device hp_t5325_button_device = { } }; +static struct platform_device hp_t5325_audio_device = { + .name = "t5325-audio", + .id = -1, +}; + static unsigned int hp_t5325_mpp_config[] __initdata = { MPP0_NF_IO2, MPP1_SPI_MOSI, @@ -179,6 +184,7 @@ static void __init hp_t5325_init(void) kirkwood_sata_init(&hp_t5325_sata_data); kirkwood_ehci_init(); platform_device_register(&hp_t5325_button_device); + platform_device_register(&hp_t5325_audio_device); i2c_register_board_info(0, i2c_board_info, ARRAY_SIZE(i2c_board_info)); kirkwood_audio_init(); diff --git a/sound/soc/kirkwood/kirkwood-t5325.c b/sound/soc/kirkwood/kirkwood-t5325.c index 16b83e5..ce4f408 100644 --- a/sound/soc/kirkwood/kirkwood-t5325.c +++ b/sound/soc/kirkwood/kirkwood-t5325.c @@ -80,7 +80,6 @@ static struct snd_soc_dai_link t5325_dai[] = { }, }; - static struct snd_soc_card t5325 = { .name = "t5325", .owner = THIS_MODULE, @@ -93,38 +92,40 @@ static struct snd_soc_card t5325 = { .num_dapm_routes = ARRAY_SIZE(t5325_route), }; -static struct platform_device *t5325_snd_device; - -static int __init t5325_init(void) +static int __devinit t5325_probe(struct platform_device *pdev) { + struct snd_soc_card *card = &t5325; int ret; - if (!machine_is_t5325()) - return 0; - - t5325_snd_device = platform_device_alloc("soc-audio", -1); - if (!t5325_snd_device) - return -ENOMEM; - - platform_set_drvdata(t5325_snd_device, - &t5325); - - ret = platform_device_add(t5325_snd_device); - if (ret) { - printk(KERN_ERR "%s: platform_device_add failed\n", __func__); - platform_device_put(t5325_snd_device); - } + card->dev = &pdev->dev; + ret = snd_soc_register_card(card); + if (ret) + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", + ret); return ret; } -module_init(t5325_init); -static void __exit t5325_exit(void) +static int __devexit t5325_remove(struct platform_device *pdev) { - platform_device_unregister(t5325_snd_device); + struct snd_soc_card *card = platform_get_drvdata(pdev); + + snd_soc_unregister_card(card); + return 0; } -module_exit(t5325_exit); + +static struct platform_driver t5325_driver = { + .driver = { + .name = "t5325-audio", + .owner = THIS_MODULE, + }, + .probe = t5325_probe, + .remove = __devexit_p(t5325_remove), +}; + +module_platform_driver(t5325_driver); MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("ALSA SoC t5325 audio client"); MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:t5325-audio"); -- 1.7.5.4

2 2

Re: [alsa-devel] [PATCH 1/7 v2] dmaengine: add a simple dma library
by Guennadi Liakhovetski 06 Feb '12

06 Feb '12

Hi Shimoda-san On Fri, 27 Jan 2012, Shimoda, Yoshihiro wrote: > Hello Guennadi-san, > > 2012/01/26 23:56, Guennadi Liakhovetski wrote: > > This patch adds a library of functions, helping to implement dmaengine > > drivers for hardware, unable to handle scatter-gather lists natively. > > The first version of this driver only supports memcpy and slave DMA > > operation. > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> > > --- > > > > v2: > > > > 1. switch from using a tasklet to threaded IRQ, which allowed to > > I tested this driver on 2 environment, but it could not work correctly. > - renesas_usbhs driver with shdma driver on the mackerel board > - renesas_usbhs driver with experimental SUDMAC driver > > In this case, should we modify the renesas_usbhs driver? Yes, you do. Please, see the respective version of the shdma patch. It doesn't request channel IRQs any more directly, instead, it uses a dma-simple wrapper function. Also operations change a bit. Thanks Guennadi > For reference, if I changed the threaded IRQ to tasklet, > the 2 environment worked correctly: > ============== > diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c > index 49d8f7d..65a5170 100644 > --- a/drivers/dma/dma-simple.c > +++ b/drivers/dma/dma-simple.c > @@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev) > > spin_lock(&schan->chan_lock); > > - ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE; > + ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE; > + if (ret == IRQ_HANDLED) > + tasklet_schedule(&schan->tasklet); > > spin_unlock(&schan->chan_lock); > > return ret; > } > > -static irqreturn_t chan_irqt(int irq, void *dev) > +static void chan_irqt(unsigned long dev) > { > - struct dma_simple_chan *schan = dev; > + struct dma_simple_chan *schan = (struct dma_simple_chan *)dev; > const struct dma_simple_ops *ops = > to_simple_dev(schan->dma_chan.device)->ops; > struct dma_simple_desc *sdesc; > @@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev) > spin_unlock_irq(&schan->chan_lock); > > simple_chan_ld_cleanup(schan, false); > - > - return IRQ_HANDLED; > } > > int dma_simple_request_irq(struct dma_simple_chan *schan, int irq, > unsigned long flags, const char *name) > { > - int ret = request_threaded_irq(irq, chan_irq, chan_irqt, > - flags, name, schan); > + int ret = request_irq(irq, chan_irq, flags, name, schan); > + tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan); > > schan->irq = ret < 0 ? ret : irq; > > diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h > index 5336674..beb1489 100644 > --- a/include/linux/dma-simple.h > +++ b/include/linux/dma-simple.h > @@ -68,6 +68,7 @@ struct dma_simple_chan { > int id; /* Raw id of this channel */ > int irq; /* Channel IRQ */ > enum dma_simple_pm_state pm_state; > + struct tasklet_struct tasklet; > }; > > /** > ============== > > Best regards, > Yoshihiro Shimoda > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/

3 11

[alsa-devel] [PATCH 0/7 v2] extract a simple dmaengine library from shdma.c
by Guennadi Liakhovetski 06 Feb '12

06 Feb '12

This is v2 of the simple DMA dmaengine library. It addresses Paul's comments to v1 - thanks, adds some comments. Guennadi Liakhovetski (7): dmaengine: add a simple dma library dma: shdma: prepare for simple DMA conversion mmc: sh_mmcif: remove unneeded struct sh_mmcif_dma, prepare for simple DMA mmc: sh_mobile_sdhi: prepare for conversion to simple DMA serial: sh-sci: prepare for conversion to simple DMA ASoC: SIU: prepare for conversion to simple DMA dma: shdma: convert to the simple DMA library drivers/dma/Kconfig | 4 + drivers/dma/Makefile | 1 + drivers/dma/dma-simple.c | 873 ++++++++++++++++++++++++++++ drivers/dma/shdma.c | 1138 +++++++++---------------------------- drivers/dma/shdma.h | 45 +- drivers/mmc/host/sh_mmcif.c | 24 +- drivers/mmc/host/sh_mobile_sdhi.c | 8 +- drivers/tty/serial/sh-sci.c | 8 +- include/linux/dma-simple.h | 124 ++++ include/linux/mmc/sh_mmcif.h | 8 +- include/linux/sh_dma.h | 39 +- sound/soc/sh/siu_pcm.c | 8 +- 12 files changed, 1334 insertions(+), 946 deletions(-) create mode 100644 drivers/dma/dma-simple.c create mode 100644 include/linux/dma-simple.h -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/

3 19

[alsa-devel] Some questions related to ALSA based duplex audio processing
by public-hk 02 Feb '12

02 Feb '12

Hi, I have just started to develop a duplex audio processing application based on ALSA. My development goals are - of course - maximum stability as well as lowest possible delay (latency). So, here is what I did on my Ubuntu laptop: 1) Setup of device/soundcard "hw:0,0" for processing at a samplerate of 44.1 kHz, buffersize 128 samples. 2) I created one input PCM device and one output PCM device handle 3) I use the function "snd_async_add_pcm_handler" to install a callback function (ASYNC mode), one for input, one for output. 4) I use "snd_pcm_link" to synchronize both pcm handles. 5) I use the mmap'ed area access My motivation to work the way I do is to maximize the control of processing behavior and to minimize the latency. E.g., I have understood from the docs that the snd_pcm_read/snd_pcm_write functions do nothing else than addressing the memory mapped areas. As a conclusion, I realize this access myself to have more control about it. And by using the async callbacks, I do not have to deal with blocking or non-blocking read functions or polling related issues. So far, I have realized the playback part and noticed some aspects which are not clear to me from the ALSA documentation: a) What is the most efficient way to realize duplex audio processing, the async way with mmap'ed read/write that I follow? b) At first, I created the pcm handles as follows: "snd_pcm_open (.., SND_PCM_ASYNC);" When starting to process audio (call of "snd_pcm_start"), I realized that the registered callback functions do not get called. I had to change this to "snd_pcm_open (.., 0);". Is that really intended, it seems contradictory? c) The function "snd_pcm_info_get_sync" is supposed to return a description of the synchronization behavior of a soundcard. In my case, I called this function for two soundcards (one USB and the laptop integrated soundcard). In both cases, the returned content is all zeros. Should not this be different for both devices? d) By default, it seems that the callbacks for audio frames come within a thread with normal priority. On Windows OS, I am used to increase the thread priority whenever starting my threads, but it is commonly not a good idea to increase the process priority. In the ALSA latency-example, the PROCESS priority is increased (which can be done only with superuser priv.). What is the recommended way in Linux to achieve lower latencies? In the future I will have to deal with synchronization of input and output since the samples arrive/leave my application in two independent callback functions. So what will I do: Once input samples are available I will store these in one buffer, and these samples will be output the next time when there is space in the output ring buffer. In order to minimize the latency, I would need to know more about the intended exact behavior of the ALSA lib which I did not find in the documentation: I) If linking input and output with "snd_pcm_link", I have understood that the changes of state for input and output PCM handle will occur synchronously. That is, when doing the operation such as "snd_pcm_prepare" on one of the handles, both handles will be affected. However, what does this means for audio processing on the frame level: If I use two callbacks for signal processing for input and output respectively installed based on the function "snd_async_add_pcm_handler", will these callbacks occur simultaneously? On Windows OS (speaking of ASIO sound) there is one callback in which input and output is handled simultaneously. Can I somehow setup ALSA to have a similar behavor? Thank you for any assistance and best regards HK

3 7