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

[PATCH] Allow choice in ac97 gpio reset line
by Robert Jarzmik 19 Feb '09

19 Feb '09

As the PXA series allow 2 gpios to reset the ac97 bus, allow through configuration the definition of the correct gpio which will reset the AC97 bus. This comes from a silicon defect on the PXA series, where the gpio must be manually controlled in warm reset cases. Signed-off-by: Robert Jarzmik <rjarzmik(a)free.fr> --- sound/arm/Kconfig | 17 +++++++++++ sound/arm/pxa2xx-ac97-lib.c | 68 +++++++++++++++++++++++++++++++++++++++--- 2 files changed, 80 insertions(+), 5 deletions(-) diff --git a/sound/arm/Kconfig b/sound/arm/Kconfig index f8e6de4..2749274 100644 --- a/sound/arm/Kconfig +++ b/sound/arm/Kconfig @@ -39,6 +39,23 @@ config SND_PXA2XX_LIB config SND_PXA2XX_LIB_AC97 bool +choice + prompt "PXA GPIO line used to reset AC97 bus" + depends on SND_PXA2XX_LIB_AC97 + help + Choose which GPIO is assigned the AC97 reset function. + + Usually board designers use GPIO 113, but GPIO 95 can be used + as well. + +config SND_PXA2XX_LIB_AC97_RESET113 + bool "GPIO113" + +config SND_PXA2XX_LIB_AC97_RESET95 + bool "GPIO95" + +endchoice + config SND_PXA2XX_AC97 tristate "AC97 driver for the Intel PXA2xx chip" depends on ARCH_PXA diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c index 35afd0c..aa522d2 100644 --- a/sound/arm/pxa2xx-ac97-lib.c +++ b/sound/arm/pxa2xx-ac97-lib.c @@ -31,6 +31,8 @@ static DECLARE_WAIT_QUEUE_HEAD(gsr_wq); static volatile long gsr_bits; static struct clk *ac97_clk; static struct clk *ac97conf_clk; +static int is_ac97_resetgpio_95; +static int is_ac97_resetgpio_113; /* * Beware PXA27x bugs: @@ -42,6 +44,55 @@ static struct clk *ac97conf_clk; * 1 jiffy timeout if interrupt never comes). */ +enum { + RESETGPIO_FORCE_HIGH, + RESETGPIO_FORCE_LOW, + RESETGPIO_NORMAL_ALTFUNC +}; + +/** + * set_resetgpio_mode - computes and sets the AC97_RESET gpio mode on PXA + * @mode: chosen action + * + * As the PXA CPUs suffer from a AC97 bug, a manual control of the reset + * line must be done to insure proper work of AC97 reset line. + * This function computes the correct gpio_mode for further use by reset + * functions, and applied the change through pxa_gpio_mode. + */ +static void set_resetgpio_mode(int resetgpio_action) +{ + int mode = 0; + + if (is_ac97_resetgpio_113) + switch (resetgpio_action) { + case RESETGPIO_FORCE_LOW: + mode = 113 | GPIO_OUT | GPIO_DFLT_LOW; + break; + case RESETGPIO_FORCE_HIGH: + mode = 113 | GPIO_OUT | GPIO_DFLT_HIGH; + break; + case RESETGPIO_NORMAL_ALTFUNC: + mode = 113 | GPIO_ALT_FN_2_OUT; + break; + }; + + if (is_ac97_resetgpio_95) + switch (resetgpio_action) { + case RESETGPIO_FORCE_LOW: + mode = 95 | GPIO_OUT | GPIO_DFLT_LOW; + break; + case RESETGPIO_FORCE_HIGH: + mode = 95 | GPIO_OUT | GPIO_DFLT_HIGH; + break; + case RESETGPIO_NORMAL_ALTFUNC: + mode = 95 | GPIO_ALT_FN_1_OUT; + break; + }; + + if (mode) + pxa_gpio_mode(mode); +} + unsigned short pxa2xx_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { unsigned short val = -1; @@ -137,10 +188,10 @@ static inline void pxa_ac97_warm_pxa27x(void) /* warm reset broken on Bulverde, so manually keep AC97 reset high */ - pxa_gpio_mode(113 | GPIO_OUT | GPIO_DFLT_HIGH); + set_resetgpio_mode(RESETGPIO_FORCE_HIGH); udelay(10); GCR |= GCR_WARM_RST; - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); udelay(500); } @@ -308,8 +359,8 @@ int pxa2xx_ac97_hw_resume(void) pxa_gpio_mode(GPIO29_SDATA_IN_AC97_MD); } if (cpu_is_pxa27x()) { - /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + /* Use GPIO 113 or 95 as AC97 Reset on Bulverde */ + set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); } clk_enable(ac97_clk); return 0; @@ -321,6 +372,13 @@ int __devinit pxa2xx_ac97_hw_probe(struct platform_device *dev) { int ret; +#ifdef CONFIG_SND_PXA2XX_LIB_AC97_RESET113 + is_ac97_resetgpio_113 = 1; +#endif +#ifdef CONFIG_SND_PXA2XX_LIB_AC97_RESET95 + is_ac97_resetgpio_95 = 1; +#endif + if (cpu_is_pxa25x() || cpu_is_pxa27x()) { pxa_gpio_mode(GPIO31_SYNC_AC97_MD); pxa_gpio_mode(GPIO30_SDATA_OUT_AC97_MD); @@ -330,7 +388,7 @@ int __devinit pxa2xx_ac97_hw_probe(struct platform_device *dev) if (cpu_is_pxa27x()) { /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); ac97conf_clk = clk_get(&dev->dev, "AC97CONFCLK"); if (IS_ERR(ac97conf_clk)) { ret = PTR_ERR(ac97conf_clk); -- 1.5.6.5

1 0

Re: [alsa-devel] Regression: snd_hda_intel driver causes quake3 to hang
by Takashi Iwai 19 Feb '09

19 Feb '09

At Thu, 19 Feb 2009 16:55:39 +0000, Charlie Baylis wrote: > > On Tue, Feb 17, 2009 at 01:05:46PM +0100, Takashi Iwai wrote: > > At Tue, 17 Feb 2009 11:49:17 +0000, Charlie Baylis wrote: > > > > > > > > > Hi > > > > > > Some time ago, quake3 stopped running correctly on my PC. This occured when > > > changing kernel from 2.6.25 to 2.6.27. The symptom is that within a > > > fraction of a second of gameplay, the game freezes. Switching to a console > > > allows the game to be killed. I am using standard kernel.org kernels with > > > no additional patches. > > > > Could you check whether it happens with 2.6.29-rc5? On 2.6.29, the delayed > > handling is done via its own workqueue, so this might be no longer a problem. > > > > Also you could try position_fix=1 instead of bdl_pos_adj. > > > > The problem is likely your hardware does unreliable DMA position reporting. > > Detecting such a broken hardware would be possible, but it'll be a bit > > tricky... > > I tried the latest git (shortly after 2.6.29-rc5) and I found that the same > symptoms occur. This happens with the driver defaults, or with bdl_pos_adj=0, > or with position_fix=1. So 2.6.29 is worse, because there seems to be no > workaround. > > Is there a way to find out whether my hardware really is broken? I had no > problems until the bdl_pos_adj workaround/feature was added. On 2.6.29, bdl_pos_adj=0 disables that. So it'll be a workaround for you, at least. Takashi

1 0

[alsa-devel] [PATCH] Remove documentation for OSS CS4232 driver
by Krzysztof Helt 19 Feb '09

19 Feb '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> There is no OSS cs4232 driver in the kernel any more and this documentation does not contain any info useful for ALSA driver. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- Documentation/sound/oss/CS4232 | 23 ----------------------- 1 files changed, 0 insertions(+), 23 deletions(-) delete mode 100644 Documentation/sound/oss/CS4232 diff --git a/Documentation/sound/oss/CS4232 b/Documentation/sound/oss/CS4232 deleted file mode 100644 index 7d6af7a..0000000 --- a/Documentation/sound/oss/CS4232 +++ /dev/null @@ -1,23 +0,0 @@ -To configure the Crystal CS423x sound chip and activate its DSP functions, -modules may be loaded in this order: - - modprobe sound - insmod ad1848 - insmod uart401 - insmod cs4232 io=* irq=* dma=* dma2=* - -This is the meaning of the parameters: - - io--I/O address of the Windows Sound System (normally 0x534) - irq--IRQ of this device - dma and dma2--DMA channels (DMA2 may be 0) - -On some cards, the board attempts to do non-PnP setup, and fails. If you -have problems, use Linux' PnP facilities. - -To get MIDI facilities add - - insmod opl3 io=* - -where "io" is the I/O address of the OPL3 synthesizer. This will be shown -in /proc/sys/pnp and is normally 0x388. -- 1.5.2.2 ---------------------------------------------------------------------- Promocja w Speak Up. Kurs angielskiego za darmo. Liczba miejsc ograniczona. Sprawd�!>> http://link.interia.pl/f205c

2 1

[alsa-devel] [PATCH] alsa-info.sh: Use pgrep -f to match against command line; fix misspellings
by crimsunkg＠yahoo.com 19 Feb '09

19 Feb '09

Hi, The current alsa-info.sh script fails to report running pulseaudio/esd/artsd instances due to missing -f passed to pgrep. The attached patch resolves said issue and corrects trivial misspellings. Thanks, Dan

2 1

[alsa-devel] [PATCH 0/1] ASoC: TWL4030: Digital loopback support
by Peter Ujfalusi 18 Feb '09

18 Feb '09

Hello, The following patch adds the digital loopback support for TWL4030 codec driver. Effectively the digital loopback is routing the audio from the TX1 capture path to the RX2 playback path. With the patch applied, the audio coming from digimic0 can be routed back to the playback path without any CPU interaction. Also one can use this loopback instead of the analog bypass for the analog inputs as well, given that the TX1 capture path is configured in such a way. --- Peter Ujfalusi (1): ASoC: TWL4030: Add digital loopback support sound/soc/codecs/twl4030.c | 57 +++++++++++++++++++++++++++++++++++++++---- 1 files changed, 51 insertions(+), 6 deletions(-)

2 2

[alsa-devel] longname in sound/core/jack.c
by Takashi Iwai 18 Feb '09

18 Feb '09

Mark, I'm not sure whether I've already asked it, but I find it ugly to refer to card->longname for the input device name in sound/core/jack.c. Can it be changed to card->shortname, at least? The long name is often really long like "HDA Intel at 0xf8400000 irq 21", thus the resultant name will be "HDA Intel at 0xf8400000 irq 21 Line Out at Ext Left" as the jack name. Takashi --- diff --git a/sound/core/jack.c b/sound/core/jack.c index 43b10d6..c8254c6 100644 --- a/sound/core/jack.c +++ b/sound/core/jack.c @@ -55,7 +55,7 @@ static int snd_jack_dev_register(struct snd_device *device) int err; snprintf(jack->name, sizeof(jack->name), "%s %s", - card->longname, jack->id); + card->shortname, jack->id); jack->input_dev->name = jack->name; /* Default to the sound card device. */

2 4

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 18 Feb '09

18 Feb '09

The following changes since commit 59544d33ff3118f22a484d8be06cdf5cfc2fdca5: Mark Brown (1): ASoC: Remove version display from the WM8753 driver are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 Mark Brown (2): ASoC: Include I2C headers for corgi and poodle ASoC: Implement SPI device unregistration for WM8731 sound/soc/codecs/wm8731.c | 7 ++++++- sound/soc/pxa/corgi.c | 1 + sound/soc/pxa/poodle.c | 1 +

3 5

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 18 Feb '09

18 Feb '09

The following changes since commit f1464ede550b8fda75086cb9bacf8d60fc9f6780: Takashi Iwai (1): Merge branch 'for-2.6.30' of git://git.kernel.org/.../broonie/sound-2.6 into topic/asoc are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 Kevin Hilman (1): ASoC: Fix DaVinci module unload error Mark Brown (9): ASoC: Remove version display from the WM8731 driver ASoC: Clean up WM8731 bias level configuration ASoC: Improve diagnostics for AT91SAM9G20-EK probe ASoC: Check machine type before loading on AT91SAM9G20-EK ASoC: Actively manage MCLK for AT91SAM9G20-EK ASoC: Rename AT91SAMG20-EK for applications ASoC: Shuffle WM8731 SPI and I2C device registration ASoC: Refactor WM8731 device registration ASoC: Remove version display from the WM8753 driver Paul Fertser (1): ASoC: Fix WM8753 DAIs unregistering sound/soc/atmel/sam9g20_wm8731.c | 124 +++++++++++-- sound/soc/codecs/wm8731.c | 377 ++++++++++++++++-------------------- sound/soc/codecs/wm8731.h | 6 - sound/soc/codecs/wm8753.c | 9 +- sound/soc/davinci/davinci-evm.c | 3 +- sound/soc/davinci/davinci-sffsdr.c | 3 +- sound/soc/pxa/corgi.c | 43 ++++- sound/soc/pxa/poodle.c | 41 ++++- 8 files changed, 361 insertions(+), 245 deletions(-)

2 18

[alsa-devel] [PATCH] OSS: missing parentheses?
by Roel Kluin 18 Feb '09

18 Feb '09

Please review. --------------------------->8-------------8<------------------------------ Add missing parentheses Signed-off-by: Roel Kluin <roel.kluin(a)gmail.com> --- diff --git a/sound/oss/pas2_card.c b/sound/oss/pas2_card.c index 25f3a22..7f377ec 100644 --- a/sound/oss/pas2_card.c +++ b/sound/oss/pas2_card.c @@ -156,9 +156,7 @@ static int __init config_pas_hw(struct address_info *hw_config) * 0x80 */ , 0xB88); - pas_write(0x80 - | joystick?0x40:0 - ,0xF388); + pas_write(0x80 | (joystick ? 0x40 : 0), 0xF388); if (pas_irq < 0 || pas_irq > 15) {

2 1

Re: [alsa-devel] HP pavilion dv5 1110ew - no hdmi sound
by Jean-Pierre André 18 Feb '09

18 Feb '09

Hi all, > Dnia 2009-02-14, sob o godzinie 11:30 +0100, Takashi Iwai pisze: > >> At Fri, 13 Feb 2009 22:48:26 +0100, >> Bartłomiej Holdenmayer wrote: >> >> > > I did ehat You wrote. Here is my dmesg: > [ 14.729023] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) > -> IRQ 2 > 2 > [ 14.729028] hda_intel: codec_mask forced to 0xff > [ 14.729054] HDA Intel 0000:00:1b.0: setting latency timer to 64 > [ 15.776021] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:634: hda_intel: azx_get_response timeout, > switching to > polling mode: last cmd=0x100f0000 > [ 16.780019] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #1 probe error; > disabling it... > [ 17.816508] > ALSA /usr/src/Alsa-1.0.19/alsa-driver-1.0.19/pci/hda/../../alsa-k > ernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #3 probe error; > disabling it... > [ 17.921600] input: HDA Digital PCBeep > as /devices/pci0000:00/0000:00:1b.0/inp > ut/input11 > [ 18.052194] input: HDA Intel at 0x9f300000 irq 22 Mic at Ext Front > Jack as /d > evices/pci0000:00/0000:00:1b.0/input/input12 > [ 18.052587] input: HDA Intel at 0x9f300000 irq 22 Mic at Sep UNKNOWN > Jack as > /devices/pci0000:00/0000:00:1b.0/input/input13 > [ 18.052894] input: HDA Intel at 0x9f300000 irq 22 HP Out at Ext Front > Jack as > /devices/pci0000:00/0000:00:1b.0/input/input14 This is very interesting for me, as I have another HP dv4 computer with the same sound chip, and I get roughly similar results, but with a significant difference (using Tagashi's snapshot from yesterday) : HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 HDA Intel 0000:00:1b.0: PCI INT B -> GSI 22 (level, low) -> IRQ 22 hda_intel: codec_mask forced to 0xff HDA Intel 0000:00:1b.0: setting latency timer to 64 ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:634: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #1 probe error; disabling it... ALSA /home/linux/rpmbuild/BUILD/alsa-driver-1.0.19.217/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1271: hda_intel: Codec #3 probe error; disabling it... input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input12 input: HDA Intel at 0xdf300000 irq 22 Line In at Ext Rear Jack as /devices/pci0000:00/0000:00:1b.0/input/input13 input: HDA Intel at 0xdf300000 irq 22 Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input14 input: HDA Intel at 0xdf300000 irq 22 HP Out at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input15 The point is I never get an IRQ 22, I get IRQ 20 instead, so most players do not work unless I boot with irqpoll or noapic options (mplayer is ok though) Now, you get the IRQ 22 routed by APIC from PCI INT A, whereas I have the IRQ 22 routed by APIC from PCI INT B. And I have the PCI INT A routed to IRQ 20 for USB : ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 ehci_hcd 0000:00:1d.7: setting latency timer to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller From this I conclude that both our sound chips trigger INT A, but in my case, it is wrongly the INT B that has been connected to IRQ 22. So my question to all the techies on this list : how on earth can I influence on this IRQ routing ? Regards Jean-Pierre

1 0