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

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

21 Jul '09

On Fri, Jul 17, 2009 at 04:45:21PM +0200, Marek Vasut wrote: > From 1ea286d088993e05b5b374a08ee6f933242d3561 Mon Sep 17 00:00:00 2001 > From: Marek Vasut <marek.vasut(a)gmail.com> > Date: Thu, 4 Jun 2009 21:56:59 +0200 > Subject: [PATCH 2/2] Add possibility to control the GPIO_STATUS shift > > 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. Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> > --- > drivers/input/touchscreen/mainstone-wm97xx.c | 3 +++ > drivers/input/touchscreen/wm97xx-core.c | 6 ++++-- > include/linux/wm97xx.h | 7 +++++++ > 3 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/mainstone-wm97xx.c b/drivers/input/touchscreen/mainstone-wm97xx.c > index de02f87..e000ab3 100644 > --- a/drivers/input/touchscreen/mainstone-wm97xx.c > +++ b/drivers/input/touchscreen/mainstone-wm97xx.c > @@ -198,6 +198,9 @@ static int wm97xx_acc_startup(struct wm97xx *wm) > if (machine_is_palmt5() || machine_is_palmtx() || machine_is_palmld()) { > pen_int = 1; > irq = 27; > + /* There is some obscure mutant of WM9712 interbred with WM9713 > + * used on Palm HW */ > + wm->variant = WM97xx_WM1613; > } else if (machine_is_mainstone() && pen_int) > irq = 4; > > diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c > index 2957d48..252eb11 100644 > --- a/drivers/input/touchscreen/wm97xx-core.c > +++ b/drivers/input/touchscreen/wm97xx-core.c > @@ -204,7 +204,7 @@ void wm97xx_set_gpio(struct wm97xx *wm, u32 gpio, > else > reg &= ~gpio; > > - if (wm->id == WM9712_ID2) > + if (wm->id == WM9712_ID2 && wm->variant != WM97xx_WM1613) > wm97xx_reg_write(wm, AC97_GPIO_STATUS, reg << 1); > else > wm97xx_reg_write(wm, AC97_GPIO_STATUS, reg); > @@ -307,7 +307,7 @@ static void wm97xx_pen_irq_worker(struct work_struct *work) > WM97XX_GPIO_13); > } > > - if (wm->id == WM9712_ID2) > + if (wm->id == WM9712_ID2 && wm->variant != WM97xx_WM1613) > wm97xx_reg_write(wm, AC97_GPIO_STATUS, (status & > ~WM97XX_GPIO_13) << 1); > else > @@ -582,6 +582,8 @@ static int wm97xx_probe(struct device *dev) > > wm->id = wm97xx_reg_read(wm, AC97_VENDOR_ID2); > > + wm->variant = WM97xx_GENERIC; > + > dev_info(wm->dev, "detected a wm97%02x codec\n", wm->id & 0xff); > > switch (wm->id & 0xff) { > diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h > index 6f69968..0c98781 100644 > --- a/include/linux/wm97xx.h > +++ b/include/linux/wm97xx.h > @@ -16,6 +16,12 @@ > #include <linux/platform_device.h> > > /* > + * WM97xx variants > + */ > +#define WM97xx_GENERIC 0x0000 > +#define WM97xx_WM1613 0x1613 > + > +/* > * WM97xx AC97 Touchscreen registers > */ > #define AC97_WM97XX_DIGITISER1 0x76 > @@ -283,6 +289,7 @@ struct wm97xx { > unsigned pen_is_down:1; /* Pen is down */ > unsigned aux_waiting:1; /* aux measurement waiting */ > unsigned pen_probably_down:1; /* used in polling mode */ > + u16 variant; /* WM97xx chip variant */ > u16 suspend_mode; /* PRP in suspend mode */ > }; > > -- > 1.6.3.3 >

2 1

[alsa-devel] [PATCH 0/2]ad1938 dai and board driver clean-up according to feedback
by Barry Song 20 Jul '09

20 Jul '09

Hi Mark, Update bf5xx-tdm dai(patch 1) and bf5xx-ad1938 machine(patch 2) drivers according to your feedback. Thanks Barry

3 4

[alsa-devel] [PATCH] ALSA: hda - Add quirk for Gateway T6834c laptop
by 宋浩 20 Jul '09

20 Jul '09

From: Hao Song <baritono.tux(a)gmail.com> Gateway T6834c laptops need EAPD always on while the default behavior for the STAC9205 reference board is to turn it off upon every HP plug. By using the special "eapd" model, which is first introduced for Gateway T1616 laptops for this same reason, this peculiarity can be properly handled. Signed-off-by: Hao Song <baritono.tux(a)gmail.com> --- sound/pci/hda/patch_sigmatel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 41b5b3a..d9efe5c 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -2379,6 +2379,7 @@ static struct snd_pci_quirk stac9205_cfg_tbl[] = { "Dell Vostro 1500", STAC_9205_DELL_M42), /* Gateway */ SND_PCI_QUIRK(0x107b, 0x0565, "Gateway T1616", STAC_9205_EAPD), + SND_PCI_QUIRK(0x107b, 0x0560, "Gateway T6834c", STAC_9205_EAPD), {} /* terminator */ }; -- 1.6.0.4 -- 宋浩 Song, Hao Institute of Theoretical Computer Science and Communications Room 117, Ho Sin Hang Engineering Building Chinese University of Hong Kong, Hong Kong, P.R.China E-mail: baritono.tux(a)gmail.com Office Tel: (+8600852)-31634255

2 1

Re: [alsa-devel] New Audio Driver Design
by Daniel Mack 20 Jul '09

20 Jul '09

On Thu, Jul 16, 2009 at 09:13:28AM +0900, jassi brar wrote: > On Thu, Jul 16, 2009 at 5:22 AM, Daniel Mack <daniel(a)caiaq.de> wrote: > > Are these decoder instruction something you need to do at runtime? Or > > would it suffice to provide them once when the driver is probed? > > The decoder insn, params atleast, depend upon the mp3 file i want the dsp to > decode and play. > So, let us assume, i have to load decoder insns and params into the dsp for > every mp3 file playback. Then the alsa control API seems appropriate. Unless there is any other interface for that specific purpose I'm not aware of. > Also, by what interface name(like I2S/PCM/AC97) shud my driver get encoded > mp3 data from my mp3-player and then decode that mp3 data by dsp and play > the output pcm stream? > I am afraid i must bypass/hack ALSA stack to directly get mp3 data from > user-space. Am i right? Have a look at include/sound/pcm.h - there are more formats defined than just linear PCM, and I think SNDRV_PCM_FMTBIT_MPEG could be something you can use. But I'm not sure and never used something like that before, so maybe anyone else can elaborate more? Daniel

1 0

[alsa-devel] CS42L52 codec
by Anna White 20 Jul '09

20 Jul '09

Hello, I am working with CS42L52 codec under Linux. I have CS42L52 driver code, but I need ALSA configuration files. Does somebody have ALSA configuration files ? Or recomendation how to write them ? Thanks for responces. P.S. It may be related to thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-February/006130.h…

2 1

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

20 Jul '09

On Fri, Jul 17, 2009 at 06:46:01PM +0800, Takashi Iwai 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". Yes, I wrote this mainly for catching unknown bugs. > > Moreover, if long format node > > ID is used in the future, the code will cause little trouble for maintaining. > > Well, the current code doesn't support the long id (as the restriction > of HD-audio controller side), so we'd need major changes in anyway. > Thus this check is no big issue for maintenance, at least to me :) Does the HDA spec define cmd format that accept long form NID? If so, can you point me to the specific location please? Thanks. > > what I want is to fix it during parsing connection list, and verify the node > > id is valid there . > > Heh, this was already fixed :) AFAIK, snd_hda_get_connections() won't return NIDs bigger than 0x7f(short) or 0x7ffff(long). Thanks, Fengguang

2 1

[alsa-devel] [RFC] tty (or char) bus?
by Janusz Krzysztofik 19 Jul '09

19 Jul '09

Hi, In my attempt to add support for contols to a voice modem codec sound device driver, I found that in order to talk to the modem, it would be convenient if I can get access to a tty device from inside the kernel in a way similiar to that available form userspace. AFAICS, even if tty lowlevel write() could be used unmodified, a convenient way of reading characters from a tty is missing and should be implemented in a line discipline. Please correct me if I am wrong. OTOH, I found that some kind of abstraction layer for acccessing devices over a tty could be convenient. Instead of allocating a new line discipline for each specific device, sometimes found on a specific board only, why not just create a new bus type? Implemented as a line discipline, activated (hot-plugged) from userspace with ldattach, that new bus adapter would give kernel level access to an arbitrary device hanging off a tty. As the bus can be assumed point-to-point, a single generic device could be registered automatically in order to trigger that bus registerd drivers' probes (vendor/model id queries, for example). If not enough, an ioctl and a ldattach replacement could be provided for setting up a device id that would match a driver id (something like inputattach does for N_MOUSE). Once detected by a voice modem codec driver tty bus probe(), a codec subdevice could then be registered with a sound card. Please let me know if you like the idea. If not, please push me in a better direction. Many of the new code could be probably based on currently existing drivers and line discplines. As I'm not familiar enough with the linux kernel code, unlike most of you, so please give me some hints on what specific drivers should I look at to get examples best matching my idea. Thanks, Janusz

3 3

[alsa-devel] [PATCH] alsa-info.sh: include 1 line of dmesg context
by Wu Fengguang 19 Jul '09

19 Jul '09

So as to include possible ALSA messages without the common keywords, as well as be more confident on the completeness/coverage of the report. It also shows nice '--' separators between the dmesg ranges. Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- utils/alsa-info.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- alsa-driver.orig/utils/alsa-info.sh +++ alsa-driver/utils/alsa-info.sh @@ -247,7 +247,7 @@ withdmesg() { echo "!!ALSA/HDA dmesg" >> $FILE echo "!!------------------" >> $FILE echo "" >> $FILE - dmesg | grep -E 'ALSA|HDA|HDMI|sound|hda.codec|hda.intel' >> $FILE + dmesg | grep -C1 -E 'ALSA|HDA|HDMI|sound|hda.codec|hda.intel' >> $FILE echo "" >> $FILE echo "" >> $FILE }

2 1

[alsa-devel] [PATCH 6/6] sound/isa: convert nested spin_lock_irqsave to spin_lock
by Julia Lawall 19 Jul '09

19 Jul '09

From: Julia Lawall <julia(a)diku.dk> If spin_lock_irqsave is called twice in a row with the same second argument, the interrupt state at the point of the second call overwrites the value saved by the first call. Indeed, the second call does not need to save the interrupt state, so it is changed to a simple spin_lock. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression lock1,lock2; expression flags; @@ *spin_lock_irqsave(lock1,flags) ... when != flags *spin_lock_irqsave(lock2,flags) // </smpl> Signed-off-by: Julia Lawall <julia(a)diku.dk> --- sound/isa/gus/gus_pcm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/isa/gus/gus_pcm.c b/sound/isa/gus/gus_pcm.c index edb11ee..2dcf45b 100644 --- a/sound/isa/gus/gus_pcm.c +++ b/sound/isa/gus/gus_pcm.c @@ -795,13 +795,13 @@ static int snd_gf1_pcm_volume_put(struct snd_kcontrol *kcontrol, struct snd_ctl_ if (!(pcmp->flags & SNDRV_GF1_PCM_PFLG_ACTIVE)) continue; /* load real volume - better precision */ - spin_lock_irqsave(&gus->reg_lock, flags); + spin_lock(&gus->reg_lock); snd_gf1_select_voice(gus, pvoice->number); snd_gf1_ctrl_stop(gus, SNDRV_GF1_VB_VOLUME_CONTROL); vol = pvoice == pcmp->pvoices[0] ? gus->gf1.pcm_volume_level_left : gus->gf1.pcm_volume_level_right; snd_gf1_write16(gus, SNDRV_GF1_VW_VOLUME, vol); pcmp->final_volume = 1; - spin_unlock_irqrestore(&gus->reg_lock, flags); + spin_unlock(&gus->reg_lock); } spin_unlock_irqrestore(&gus->voice_alloc, flags); return change;

2 1

[alsa-devel] [PATCH 0/3] new support for ad1938 codec
by Barry Song 18 Jul '09

18 Jul '09

Hi Liam&Mark, The following series add support for ad1938 codec *PATCH 1: ad1938 codec driver *PATCH 2: blackfin I2S(in TDM mode) DAI driver Even though TDM mode can be as part of I2S DAI, but there are so much difference in configuration and data flow, it's very ugly to integrate I2S and TDM into a module. So we use the DAI type, but split normal I2S and TDM into individual files. *PATCH 3: board driver to connect bf5xx with ad1938 -- Thanks, Barry

2 7