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

[alsa-devel] ALSA porting to h/w having kernel version 2.6.18.5
by Rakesh Kumar 17 Jul '09

17 Jul '09

Hi I am new to ALSA and going to start porting of ALSA driver on out H/W box which is having 2.6.18.5 kernel (ARM), soc scenario. ALSA version supported on 2.6.18.5 is 1.0.12. I have following questions: 1. Shall I go ahead with ALSA 1.0.12 (which is already part of my kernel)? 2. or shall I download latest ALSA version 1.0.20? I can go with either with 1.0.12 or 1.0.20 versions, I want to know what is general trend followed in this scenario. I tried building my kernel with latest ALSA (as a part of kernel) but facing some compilation errors. Thanks Regards, Rakesh _________________________________________________________________ Stay updated! Add Facebook, LinkedIn, MySpace & Hi5 friends to your Windows Live network instantly. Add Now! http://profile.live.com/webactivities/?mkt=en-in

2 1

Re: [alsa-devel] [PATCH 2/2] Add possibility to control the GPIO_STATUS shift
by Mark Brown 17 Jul '09

17 Jul '09

On Fri, Jul 17, 2009 at 10:01:16AM +0200, Marek Vasut wrote: > This patch allows tweaking the behaviour of GPIO_STATUS register > shift quirk that's in wm97xx-core. The problem with GPIO_STATUS > register being shifted by one doesn't appear on all hardware it > seems and causes problems with accelerated touchscreen drivers on > Palm hardware. Therefore an accelerated touchscreen driver can select > if the shift is/isn't happening on the hardware. Again, this isn't an ALSA patch. I've done some checking internally and I'm very suspicous that what's going on here is actually the masking of some other bug elsewhere in the system. Which CPU are the systems you're observing this on using? There is at least one special case in the current code for GPIO register readbacks in the PXA AC97 driver code and there have been a number of interoperabilty issues in that area...

2 6

[alsa-devel] [PATCH 1/2] Add Palm support to Mainstone accelerated touch
by Marek Vasut 17 Jul '09

17 Jul '09

From f32fa9ef6476be0cf8106bc57a98724c48d4baa1 Mon Sep 17 00:00:00 2001 From: Marek Vasut <marek.vasut(a)gmail.com> Date: Fri, 17 Jul 2009 09:54:13 +0200 Subject: [PATCH 1/2] Add Palm support to Mainstone accelerated touch This patch refactors the Mainstone accelerated touch code a little and adds support for interrupt driven touchscreen on Palm LifeDrive, TX and Tungsten T5. Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> --- drivers/input/touchscreen/Kconfig | 4 +- drivers/input/touchscreen/mainstone-wm97xx.c | 52 +++++++++++++++++-------- 2 files changed, 37 insertions(+), 19 deletions(-) diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 72e2712..0fdae1a 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -366,11 +366,11 @@ config TOUCHSCREEN_WM97XX_ATMEL be called atmel-wm97xx. config TOUCHSCREEN_WM97XX_MAINSTONE - tristate "WM97xx Mainstone accelerated touch" + tristate "WM97xx Mainstone/Palm accelerated touch" depends on TOUCHSCREEN_WM97XX && ARCH_PXA help Say Y here for support for streaming mode with WM97xx touchscreens - on Mainstone systems. + on Mainstone, Palm Tungsten T5, TX and LifeDrive systems. If unsure, say N. diff --git a/drivers/input/touchscreen/mainstone-wm97xx.c b/drivers/input/touchscreen/mainstone-wm97xx.c index 4cc047a..60bda9a 100644 --- a/drivers/input/touchscreen/mainstone-wm97xx.c +++ b/drivers/input/touchscreen/mainstone-wm97xx.c @@ -31,9 +31,13 @@ #include <linux/interrupt.h> #include <linux/wm97xx.h> #include <linux/io.h> +#include <linux/gpio.h> + #include <mach/regs-ac97.h> -#define VERSION "0.13" +#include <asm/mach-types.h> + +#define VERSION "0.14" struct continuous { u16 id; /* codec id */ @@ -62,6 +66,7 @@ static const struct continuous cinfo[] = { /* continuous speed index */ static int sp_idx; static u16 last, tries; +static int irq; /* * Pen sampling frequency (Hz) in continuous mode. @@ -171,7 +176,7 @@ up: static int wm97xx_acc_startup(struct wm97xx *wm) { - int idx = 0; + int idx = 0, ret = 0; /* check we have a codec */ if (wm->ac97 == NULL) @@ -191,18 +196,37 @@ static int wm97xx_acc_startup(struct wm97xx *wm) "mainstone accelerated touchscreen driver, %d samples/sec\n", cinfo[sp_idx].speed); + /* IRQ driven touchscreen is used on Palm hardware */ + if (machine_is_palmt5() || machine_is_palmtx() || machine_is_palmld()) { + pen_int = 1; + irq = 27; + } else if (machine_is_mainstone() && pen_int) + irq = 4; + + if (irq) { + ret = gpio_request(irq, "Touchscreen IRQ"); + if (ret) + goto out; + + ret = gpio_direction_input(irq); + if (ret) { + gpio_free(irq); + goto out; + } + + wm->pen_irq = gpio_to_irq(irq); + set_irq_type(wm->pen_irq, IRQ_TYPE_EDGE_BOTH); + } else /* pen irq not supported */ + pen_int = 0; + /* codec specific irq config */ if (pen_int) { switch (wm->id) { case WM9705_ID2: - wm->pen_irq = IRQ_GPIO(4); - set_irq_type(IRQ_GPIO(4), IRQ_TYPE_EDGE_BOTH); break; case WM9712_ID2: case WM9713_ID2: - /* enable pen down interrupt */ /* use PEN_DOWN GPIO 13 to assert IRQ on GPIO line 2 */ - wm->pen_irq = MAINSTONE_AC97_IRQ; wm97xx_config_gpio(wm, WM97XX_GPIO_13, WM97XX_GPIO_IN, WM97XX_GPIO_POL_HIGH, WM97XX_GPIO_STICKY, @@ -220,23 +244,17 @@ static int wm97xx_acc_startup(struct wm97xx *wm) } } - return 0; +out: + return ret; } static void wm97xx_acc_shutdown(struct wm97xx *wm) { /* codec specific deconfig */ if (pen_int) { - switch (wm->id & 0xffff) { - case WM9705_ID2: - wm->pen_irq = 0; - break; - case WM9712_ID2: - case WM9713_ID2: - /* disable interrupt */ - wm->pen_irq = 0; - break; - } + if (irq) + gpio_free(irq); + wm->pen_irq = 0; } } -- 1.6.3.3

2 3

Re: [alsa-devel] [PATCH] hda: add bounds checking for the codec command fields v2
by Takashi Iwai 17 Jul '09

17 Jul '09

At Fri, 17 Jul 2009 12:46:01 +0200, I wrote: > > At Fri, 17 Jul 2009 18:41:05 +0800, > Guo, Chaohong wrote: > > > > Although it does address this issue, I am not comfortable with this fixing. > > It seems more like a workaround than fix. > > No, it's rather for catching a bug. This is definitely neither > "workaround" nor "fix". BTW, I fixed the patch again as below. Takashi --- From 82e1b804b03defe46fb69ffd2c8b19e6649bcb0d Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 17 Jul 2009 12:47:34 +0200 Subject: [PATCH] ALSA: hda - Fix the previous sanity check in make_codec_cmd() The newly added sanity-check for a codec verb can be better written with logical ORs. Also, the parameter can be more than 8bit. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index d9d3262..35f0f22 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -150,8 +150,8 @@ make_codec_cmd(struct hda_codec *codec, hda_nid_t nid, int direct, { u32 val; - if ((codec->addr & ~0xf) | (direct & ~1) | (nid & ~0x7f) | - (verb & ~0xfff) | (parm & ~0xff)) { + if ((codec->addr & ~0xf) || (direct & ~1) || (nid & ~0x7f) || + (verb & ~0xfff) || (parm & ~0xffff)) { printk(KERN_ERR "hda-codec: out of range cmd %x:%x:%x:%x:%x\n", codec->addr, direct, nid, verb, parm); return ~0; -- 1.6.3.2

2 1

[PATCH] oss - Add missing initialization of fragments
by Takashi Iwai 17 Jul '09

17 Jul '09

The periods calculation was missing for initializing OSS fragments. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- oss/pcm_oss.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/oss/pcm_oss.c b/oss/pcm_oss.c index 8a2a672..d43b44c 100644 --- a/oss/pcm_oss.c +++ b/oss/pcm_oss.c @@ -181,6 +181,7 @@ static int oss_hw_params(snd_pcm_ioplug_t *io, fprintf(stderr, "*** OSS: invalid period size %d\n", (int)io->period_size); return -EINVAL; } + oss->periods = io->buffer_size / io->period_size; _retry: tmp = oss->period_shift | (oss->periods << 16); -- 1.6.3.2

1 0

[alsa-devel] [PATCH] hda: add bounds checking for the codec command fields
by Wu Fengguang 17 Jul '09

17 Jul '09

A recent bug involves passing auto detected >0x7f NID to codec command, creating an invalid codec addr field, and finally lead to cmd timeout and fall back into single command mode. Jaroslav fixed that bug in alc880_parse_auto_config(). It would be safer to further check the bounds of all cmd fields. Cc: Jaroslav Kysela <perex(a)perex.cz> Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 462e2ce..7d09650 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -150,6 +150,16 @@ make_codec_cmd(struct hda_codec *codec, hda_nid_t nid, int direct, { u32 val; + if ((direct & ~1) || (nid & ~0x7f) || + (verb & ~0xfff) || (parm & ~0xff)) { + printk(KERN_ERR "hda-codec: out of range cmd %x:%x:%x:%x:%x\n", + codec->addr, direct, nid, verb, parm); + direct &= 1; + nid &= 0x7f; + verb &= 0xfff; + parm &= 0xff; + } + val = (u32)(codec->addr & 0x0f) << 28; val |= (u32)direct << 27; val |= (u32)nid << 20;

2 3

Re: [alsa-devel] [PATCH]HDA: Add support for new AMD HD audio devices
by Takashi Iwai 17 Jul '09

17 Jul '09

At Fri, 17 Jul 2009 11:32:32 +0800, Andiry Brienza wrote: > > Add support for new AMD HD audio devices. Use generic driver to detect HD audio > devices with Vendor ID AMD. > > Signed-off-by: Andiry Xu <andiry.xu(a)amd.com> Thanks, applied now. Takashi > diff -ruN a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > --- a/sound/pci/hda/hda_intel.c 2009-07-17 10:46:24.000000000 +0800 > +++ b/sound/pci/hda/hda_intel.c 2009-07-17 11:04:45.000000000 +0800 > @@ -2604,11 +2604,15 @@ > /* this entry seems still valid -- i.e. without emu20kx chip */ > { PCI_DEVICE(0x1102, 0x0009), .driver_data = AZX_DRIVER_GENERIC }, > #endif > - /* AMD Generic, PCI class code and Vendor ID for HD Audio */ > + /* AMD/ATI Generic, PCI class code and Vendor ID for HD Audio */ > { PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_ANY_ID), > .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, > .class_mask = 0xffffff, > .driver_data = AZX_DRIVER_GENERIC }, > + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_ANY_ID), > + .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, > + .class_mask = 0xffffff, > + .driver_data = AZX_DRIVER_GENERIC }, > { 0, } > }; > MODULE_DEVICE_TABLE(pci, azx_ids); > >

1 0

[alsa-devel] Callbacks from opening or closing alsa streams
by Baek Chang 17 Jul '09

17 Jul '09

Hi, I was wondering if it was possible to get callbacks from opening and closing of alsa streams with the alsa sink name that was opened. So if I have an asound.conf configured like so: pcm.music { type hw card 0 } Is it possible to get a callback saying that a stream on the "music" sink was opened? Thanks Baek -- Baek Chang baeksan(a)ccrma.stanford.edu

2 1

[alsa-devel] ANYONE have spdif working with the ADI AD1986A chipset? (Asus M2NPV-VM mainboard)
by VDR User 17 Jul '09

17 Jul '09

This mainboard isn't that new but from what I've read spdif worked in alsa some time in the past. I get the IEC958/IEC958 D options in alsamixer but can not get any sound. Analog works fine. If anyone has spdif working on this mainboard then PLEASE post your exact setup & settings! The only other option would be to buy new hardware and that's not an option right now. Thanks for any/all help! -Derek

1 0

[alsa-devel] While recording from mono codec twice as much data is received
by Louis Lee 16 Jul '09

16 Jul '09

Hi everyone, I am able to do playback from 8 kHz samples to 48 kHz samples properly. However, when recording using the exact same setup for the data interface I am not getting favorable results. For instance, if I record for 5 seconds I get output in a file for 10 seconds of audio (arecord or sox). This results in my recording being stretched. I change the DAI to stereo capture and record two channels and the recorded output comes back correctly (5 seconds recorded is 5 seconds). I'm using a wolfsom WM8974. I'm developing using ASoC framework (can I call it that?) reusing the WM8974 codec from the Linux GIT repository. The development is using a i.MX27. Data interface is a SSI bus in DSP mode. I believe my PCM code is correct since it works for playback. I'm stuck now. From my understanding the clocks are setup the same way for both playback and capture. Has anyone ran into this problem before? The WM8974 is a mono codec so I should not have to set the DAI to stereo in order to capture data properly. Any help is appreciated. Best regards,Louis _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=9666046

2 3