Hi folks,
Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
can access /dev/dsp, change the volume and so on, but the speakers
are quiet. Moving back to rc6 there is no such problem.
Of course the config files are the same (except for some new
CONFIG_SLABINFO variable).
lspci says:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1b.0 0403: 8086:284b (rev 02)
% aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
this:
diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
--- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21 02:25:48.000000000 +0100
+++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06 22:45:38.000000000 +0100
@@ -555,7 +555,8 @@
}
if (!chip->rirb.cmds)
return chip->rirb.res; /* the last value */
- schedule_timeout_uninterruptible(1);
+ udelay(10);
+ cond_resched();
} while (time_after_eq(timeout, jiffies));
if (chip->msi) {
Do you think this could be related to the problem?
Any hint would be highly appreciated. Please mail if I can help to
track this down.
Regards
Harri
At Mon, 07 Jan 2008 20:53:33 +0100,
Harald Dunkel wrote:
>
> Hi folks,
>
> Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
> can access /dev/dsp, change the volume and so on, but the speakers
> are quiet. Moving back to rc6 there is no such problem.
>
> Of course the config files are the same (except for some new
> CONFIG_SLABINFO variable).
>
>
> lspci says:
>
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
> 00:1b.0 0403: 8086:284b (rev 02)
>
> % aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>
>
>
> The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
> this:
>
> diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
> --- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21 02:25:48.000000000 +0100
> +++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06 22:45:38.000000000 +0100
> @@ -555,7 +555,8 @@
> }
> if (!chip->rirb.cmds)
> return chip->rirb.res; /* the last value */
> - schedule_timeout_uninterruptible(1);
> + udelay(10);
> + cond_resched();
> } while (time_after_eq(timeout, jiffies));
>
> if (chip->msi) {
>
>
> Do you think this could be related to the problem?
Could you revert it and check whether the problem still exists?
I hardly believe it's the culprit, but if this is the only change in
the sound subsystem...
thanks,
Takashi
* Takashi Iwai <[email protected]> wrote:
> > The only difference between rc6 and rc7 in sound/pci/hda/hda_intel.c is
> > this:
> >
> > diff -ur linux-2.6.24-rc6/sound/pci/hda/hda_intel.c linux-2.6.24-rc7/sound/pci/hda/hda_intel.c
> > --- linux-2.6.24-rc6/sound/pci/hda/hda_intel.c 2007-12-21 02:25:48.000000000 +0100
> > +++ linux-2.6.24-rc7/sound/pci/hda/hda_intel.c 2008-01-06 22:45:38.000000000 +0100
> > @@ -555,7 +555,8 @@
> > }
> > if (!chip->rirb.cmds)
> > return chip->rirb.res; /* the last value */
> > - schedule_timeout_uninterruptible(1);
> > + udelay(10);
> > + cond_resched();
> > } while (time_after_eq(timeout, jiffies));
> >
> > if (chip->msi) {
> >
> >
> > Do you think this could be related to the problem?
>
> Could you revert it and check whether the problem still exists?
>
> I hardly believe it's the culprit, but if this is the only change in
> the sound subsystem...
lets revert it (commit 57a04513cb3) if it's causing problems. This patch
sat in -mm for quite some time - so it seems -rc7 is getting pretty good
test coverage.
Ingo
Dear Takashi-san,
Takashi Iwai wrote:
>
> Could you revert it and check whether the problem still exists?
>
I did, and sound is back :-).
Please mail, if you need the .config file. BTW, I missed to send
the output of uname. Here is:
Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux
Its 64bit.
Regards
Harri
At Tue, 08 Jan 2008 18:01:48 +0100,
Harald Dunkel wrote:
>
> Dear Takashi-san,
>
> Takashi Iwai wrote:
> >
> > Could you revert it and check whether the problem still exists?
> >
>
> I did, and sound is back :-).
Wow, you are the first bug reporter regarding this patch.
Linus, please revert the commit 57a04513cb3 as now.
The life can go well without this patch.
But, anyway we need to track down the problem. So...
> Please mail, if you need the .config file. BTW, I missed to send
> the output of uname. Here is:
>
> Linux daffy 2.6.24-rc7 #1 SMP Tue Jan 8 07:17:39 CET 2008 x86_64 GNU/Linux
Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware
(laptop, product name, whatever) exactly?
Also, please show the contents of /proc/asound/card0/codec#* files.
Do you see difference in these files between with and without the
patch?
thanks,
Takashi
Takashi Iwai wrote:
>
> Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware
> (laptop, product name, whatever) exactly?
>
CONFIG_SND_HDA_POWER_SAVE is not set.
Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz,
2 GByte RAM. lspci:
00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c)
00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 (rev a1)
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05)
03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
> Also, please show the contents of /proc/asound/card0/codec#* files.
> Do you see difference in these files between with and without the
> patch?
>
See below. There is no difference between both.
Regards
Harri
========================================================================
Codec: SigmaTel STAC9228
Address: 0
Vendor Id: 0x83847616
Subsystem Id: 0x10280209
Revision Id: 0x100201
No Modem Function Group found
Default PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0x7f 0x7f]
Power: 0x0
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Power: 0x0
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Power: 0x0
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Power: 0x0
Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Power: 0x0
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1b
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1c
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1d
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x02214020: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
Pin-ctls: 0xc0: OUT HP
Connection: 2
0x02* 0x03
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x02a19080: [Jack] Mic at Ext Front
Conn = 1/8, Color = Pink
Pin-ctls: 0x24: IN
Connection: 2
0x02 0x03*
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x0181304e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
Pin-ctls: 0x20: IN
Connection: 1
0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
Pin-ctls: 0x40: OUT
Connection: 1
0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x01a19040: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
Pin-ctls: 0x24: IN
Connection: 1
0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
Pin-ctls: 0x40: OUT
Connection: 1
0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect
Pin Default 0x01016011: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Orange
Pin-ctls: 0x40: OUT
Connection: 1
0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect
Pin Default 0x40000100: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Connection: 1
0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x40000100: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x40000100: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Node 0x14 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x40000100: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e 0x12 0x0f 0x0b* 0x0c 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 3
0x18* 0x13 0x14
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 3
0x19* 0x13 0x14
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 3
0x1a* 0x13 0x14
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Connection: 1
0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x0810: OUT
Pin Default 0x01442070: [Jack] SPDIF Out at Ext Rear
Conn = RCA, Color = Grey
Pin-ctls: 0x40: OUT
Connection: 5
0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
Pincap 0x0810024: IN EAPD Detect
Pin Default 0x40000100: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
Amp-Out vals: [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
At Wed, 09 Jan 2008 07:03:18 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> >
> > Did you enable CONFIG_SND_HDA_POWER_SAVE feature? And which hardware
> > (laptop, product name, whatever) exactly?
> >
>
> CONFIG_SND_HDA_POWER_SAVE is not set.
That's fine.
> Hardware is a Dell XPS M1330. CPU is Core2 Duo T7500, 2.20GHz,
> 2 GByte RAM. lspci:
>
> 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c)
> 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c)
> 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02)
> 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02)
> 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02)
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
> 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
> 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
> 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2)
> 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 02)
> 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0427 (rev a1)
> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 (rev 05)
> 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
> 03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
> 03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
> 09:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02)
> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
>
> > Also, please show the contents of /proc/asound/card0/codec#* files.
> > Do you see difference in these files between with and without the
> > patch?
> >
>
> See below. There is no difference between both.
Thanks. Then the possible reason might be the registers that don't
appear in this proc output, such as GPIO.
Could you try the patch below with the latency patch (you reverted) in
rc7?
Takashi
diff -r d773ad622068 sound/pci/hda/patch_sigmatel.c
--- a/sound/pci/hda/patch_sigmatel.c Tue Jan 08 18:13:27 2008 +0100
+++ b/sound/pci/hda/patch_sigmatel.c Wed Jan 09 08:29:49 2008 +0100
@@ -1624,12 +1624,13 @@ static void stac92xx_enable_gpio_mask(st
AC_VERB_SET_GPIO_DIRECTION, spec->gpio_mask);
/* Configure GPIOx as CMOS */
snd_hda_codec_write_cache(codec, codec->afg, 0, 0x7e7, 0x00000000);
+ /* Enable GPIOx */
+ snd_hda_codec_write_cache(codec, codec->afg, 0,
+ AC_VERB_SET_GPIO_MASK, spec->gpio_mask);
+ msleep(1);
/* Assert GPIOx */
snd_hda_codec_write_cache(codec, codec->afg, 0,
AC_VERB_SET_GPIO_DATA, spec->gpio_data);
- /* Enable GPIOx */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_MASK, spec->gpio_mask);
}
/*
Takashi Iwai wrote:
>
> Thanks. Then the possible reason might be the registers that don't
> appear in this proc output, such as GPIO.
> Could you try the patch below with the latency patch (you reverted) in
> rc7?
>
Using rc7:
hda_intel.c(rc6) + patch for sigmatel.c: sound works
hda_intel.c(rc7) + patch for sigmatel.c: sound does not work
Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix
the problem.
Regards
Harri
At Wed, 09 Jan 2008 21:10:41 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> >
> > Thanks. Then the possible reason might be the registers that don't
> > appear in this proc output, such as GPIO.
> > Could you try the patch below with the latency patch (you reverted) in
> > rc7?
> >
>
> Using rc7:
>
> hda_intel.c(rc6) + patch for sigmatel.c: sound works
> hda_intel.c(rc7) + patch for sigmatel.c: sound does not work
>
> Sorry to say, but AFAICS the patch for sigmatel.c doesn't fix
> the problem.
Hm... Just to be sure, try the patch below. It's a clean up patch
that I'd like to apply later.
The perex/alsa.git mm branch on kernel.org has many fixes. Could you
give it a try, too?
thanks,
Takashi
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 0401223..9048d43 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -110,7 +110,6 @@ struct sigmatel_spec {
unsigned int mic_switch: 1;
unsigned int alt_switch: 1;
unsigned int hp_detect: 1;
- unsigned int gpio_mute: 1;
unsigned int gpio_mask, gpio_data;
@@ -1245,22 +1244,6 @@ static void stac92xx_set_config_regs(struct hda_codec *codec)
spec->pin_configs[i]);
}
-static void stac92xx_enable_gpio_mask(struct hda_codec *codec)
-{
- struct sigmatel_spec *spec = codec->spec;
- /* Configure GPIOx as output */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, spec->gpio_mask);
- /* Configure GPIOx as CMOS */
- snd_hda_codec_write_cache(codec, codec->afg, 0, 0x7e7, 0x00000000);
- /* Assert GPIOx */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DATA, spec->gpio_data);
- /* Enable GPIOx */
- snd_hda_codec_write_cache(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_MASK, spec->gpio_mask);
-}
-
/*
* Analog playback callbacks
*/
@@ -2183,38 +2166,38 @@ static int stac9200_parse_auto_config(struct hda_codec *codec)
* funky external mute control using GPIO pins.
*/
-static void stac922x_gpio_mute(struct hda_codec *codec, int pin, int muted)
+static void stac_gpio_set(struct hda_codec *codec, unsigned int mask,
+ unsigned int data)
{
unsigned int gpiostate, gpiomask, gpiodir;
+ if (!mask)
+ return;
+
gpiostate = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_DATA, 0);
-
- if (!muted)
- gpiostate |= (1 << pin);
- else
- gpiostate &= ~(1 << pin);
+ gpiostate = (gpiostate & ~mask) | (data & mask);
gpiomask = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_MASK, 0);
- gpiomask |= (1 << pin);
+ gpiomask |= mask;
gpiodir = snd_hda_codec_read(codec, codec->afg, 0,
AC_VERB_GET_GPIO_DIRECTION, 0);
- gpiodir |= (1 << pin);
+ gpiodir |= mask;
- /* AppleHDA seems to do this -- WTF is this verb?? */
+ /* Configure GPIOx as CMOS */
snd_hda_codec_write(codec, codec->afg, 0, 0x7e7, 0);
snd_hda_codec_write(codec, codec->afg, 0,
AC_VERB_SET_GPIO_MASK, gpiomask);
- snd_hda_codec_write(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DIRECTION, gpiodir);
+ snd_hda_codec_read(codec, codec->afg, 0,
+ AC_VERB_SET_GPIO_DIRECTION, gpiodir); /* sync */
msleep(1);
- snd_hda_codec_write(codec, codec->afg, 0,
- AC_VERB_SET_GPIO_DATA, gpiostate);
+ snd_hda_codec_read(codec, codec->afg, 0,
+ AC_VERB_SET_GPIO_DATA, gpiostate); /* sync */
}
static void enable_pin_detect(struct hda_codec *codec, hda_nid_t nid,
@@ -2273,10 +2256,7 @@ static int stac92xx_init(struct hda_codec *codec)
stac92xx_auto_set_pinctl(codec, cfg->dig_in_pin,
AC_PINCTL_IN_EN);
- if (spec->gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec->gpio_mask, spec->gpio_data);
return 0;
}
@@ -2400,10 +2380,7 @@ static int stac92xx_resume(struct hda_codec *codec)
stac92xx_set_config_regs(codec);
snd_hda_sequence_write(codec, spec->init);
- if (spec->gpio_mute) {
- stac922x_gpio_mute(codec, 0, 0);
- stac922x_gpio_mute(codec, 1, 0);
- }
+ stac_gpio_set(codec, spec->gpio_mask, spec->gpio_data);
snd_hda_codec_resume_amp(codec);
snd_hda_codec_resume_cache(codec);
/* invoke unsolicited event to reset the HP state */
@@ -2567,7 +2544,7 @@ static int patch_stac922x(struct hda_codec *codec)
stac922x_models,
stac922x_cfg_tbl);
if (spec->board_config == STAC_INTEL_MAC_V3) {
- spec->gpio_mute = 1;
+ spec->gpio_mask = spec->gpio_data = 0x03;
/* Intel Macs have all same PCI SSID, so we need to check
* codec SSID to distinguish the exact models
*/
@@ -2714,7 +2691,6 @@ static int patch_stac927x(struct hda_codec *codec)
spec->multiout.dac_nids = spec->dac_nids;
/* GPIO0 High = Enable EAPD */
spec->gpio_mask = spec->gpio_data = 0x00000001;
- stac92xx_enable_gpio_mask(codec);
err = stac92xx_parse_auto_config(codec, 0x1e, 0x20);
if (!err) {
@@ -2796,7 +2772,6 @@ static int patch_stac9205(struct hda_codec *codec)
break;
}
- stac92xx_enable_gpio_mask(codec);
err = stac92xx_parse_auto_config(codec, 0x1f, 0x20);
if (!err) {
if (spec->board_config < 0) {
Takashi Iwai wrote:
>
> Hm... Just to be sure, try the patch below. It's a clean up patch
> that I'd like to apply later.
>
Sorry, no sound.
> The perex/alsa.git mm branch on kernel.org has many fixes. Could you
> give it a try, too?
>
This version seems to work. But AFAICS it just reverts hda_intel.c back
to rc6 again, so this is no surprise.
Regards
Harri
At Thu, 10 Jan 2008 23:02:53 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> >
> > Hm... Just to be sure, try the patch below. It's a clean up patch
> > that I'd like to apply later.
> >
>
> Sorry, no sound.
OK, but I'd like to know whether this makes no regression to rc6.
Could you check?
Also, what exactly did you test? "No sound" means that no sound from
the headphone / line-out or from the speaker?
One interesting test would be to increase the value of udelay() in the
reverted patch. What happens if it's set to 500?
> > The perex/alsa.git mm branch on kernel.org has many fixes. Could you
> > give it a try, too?
> >
>
> This version seems to work. But AFAICS it just reverts hda_intel.c back
> to rc6 again, so this is no surprise.
Use mm branch. The main branch is just an old Linus tree.
thanks,
Takashi
Takashi Iwai wrote:
> At Thu, 10 Jan 2008 23:02:53 +0100,
> Harald Dunkel wrote:
>> Takashi Iwai wrote:
>>> Hm... Just to be sure, try the patch below. It's a clean up patch
>>> that I'd like to apply later.
>>>
>> Sorry, no sound.
>
> OK, but I'd like to know whether this makes no regression to rc6.
> Could you check?
>
"Regression" sounds like a test suite to me, verifying that the
old problems didn't come back. Maybe you could send me a pointer?
Of course I didn't try that much yet. The kernel booted as expected,
I saw XWindow running, the mouse pointer was moving, etc. There was
just no sound, as before with rc7.
> Also, what exactly did you test? "No sound" means that no sound from
> the headphone / line-out or from the speaker?
>
Speaker and first headphone are the same on this laptop. If I plugin
the headphone, then the tiny speakers are disconnected. But for the
last tests no headphone was plugged in.
I tested it by running gnome-alsamixer. I tried to switch off and
on the mute buttons, change the volume and other sliders, etc.
> One interesting test would be to increase the value of udelay() in the
> reverted patch. What happens if it's set to 500?
>
I will try tomorrow. What exactly is this delay good for?
>>> The perex/alsa.git mm branch on kernel.org has many fixes. Could you
>>> give it a try, too?
>>>
>> This version seems to work. But AFAICS it just reverts hda_intel.c back
>> to rc6 again, so this is no surprise.
>
> Use mm branch. The main branch is just an old Linus tree.
>
AFAICS I did use the mm branch. The command to grab the sources was
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm
Is this correct?
Regards
Harri
Takashi Iwai wrote:
> At Thu, 10 Jan 2008 23:02:53 +0100,
> Harald Dunkel wrote:
>> Takashi Iwai wrote:
>>> Hm... Just to be sure, try the patch below. It's a clean up patch
>>> that I'd like to apply later.
>>>
>> Sorry, no sound.
>
> OK, but I'd like to know whether this makes no regression to rc6.
> Could you check?
>
> Also, what exactly did you test? "No sound" means that no sound from
> the headphone / line-out or from the speaker?
>
> One interesting test would be to increase the value of udelay() in the
> reverted patch. What happens if it's set to 500?
>
There is no udelay() in the reverted patch. If I replace "udelay(10)"
by "udelay(500)" in the original rc7, then there is still no sound.
This is like fishing in the dark. We've got a working version. Why not
keep it?
Regards
Harri
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote:
> Takashi Iwai wrote:
> > At Thu, 10 Jan 2008 23:02:53 +0100,
> >
> > Harald Dunkel wrote:
> >> Takashi Iwai wrote:
> >>> Hm... Just to be sure, try the patch below. It's a clean up patch
> >>> that I'd like to apply later.
> >>
> >> Sorry, no sound.
> >
> > OK, but I'd like to know whether this makes no regression to rc6.
> > Could you check?
> >
> > Also, what exactly did you test? "No sound" means that no sound from
> > the headphone / line-out or from the speaker?
> >
> > One interesting test would be to increase the value of udelay() in the
> > reverted patch. What happens if it's set to 500?
>
> There is no udelay() in the reverted patch. If I replace "udelay(10)"
> by "udelay(500)" in the original rc7, then there is still no sound.
>
> This is like fishing in the dark. We've got a working version. Why not
> keep it?
>
>
> Regards
>
> Harri
Could this have anything to do with the following messages I've seen when
trying -rc7 ?
[ 7.760269] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760336] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760401] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760470] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760536] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760601] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760666] pnpacpi: exceeded the max number of mem resources: 12
[ 7.760984] pnp: PnP ACPI: found 12 devices
[ 7.761048] ACPI: ACPI bus type pnp unregistered
[ 7.761345] PCI: Using ACPI for IRQ routing
[ 7.761409] PCI: If a device doesn't work, try "pci=routeirq". If it
helps, post a report
And...
[ 7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved
[ 7.784546] system 00:08: iomem range 0xfed00000-0xfed003ff has been
reserved
[ 7.784617] system 00:09: ioport range 0x900-0x97f has been reserved
[ 7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved
[ 7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved
[ 7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved
[ 7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved
[ 7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved
[ 7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved
[ 7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved
[ 7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved
[ 7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved
[ 7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved
[ 7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved
[ 7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved
[ 7.785492] system 00:0b: iomem range 0x9f000-0x9ffff could not be reserved
[ 7.785560] system 00:0b: iomem range 0xc0000-0xcffff has been reserved
[ 7.785627] system 00:0b: iomem range 0xe0000-0xfffff has been reserved
[ 7.785696] system 00:0b: iomem range 0x100000-0x3f6923ff could not be
reserved
[ 7.785775] system 00:0b: iomem range 0x3f692400-0x3f6fffff could not be
reserved
[ 7.785854] system 00:0b: iomem range 0x3f700000-0x3f7fffff could not be
reserved
[ 7.785932] system 00:0b: iomem range 0x3f700000-0x3fefffff could not be
reserved
[ 7.786011] system 00:0b: iomem range 0xfff00000-0xffffffff could not be
reserved
[ 7.786090] system 00:0b: iomem range 0xffa00000-0xffafffff has been
reserved
[ 7.786157] system 00:0b: iomem range 0xfec00000-0xfec0ffff could not be
reserved
[ 7.786236] system 00:0b: iomem range 0xfee00000-0xfee0ffff could not be
reserved
That's almost the entirety of the differences between a dmesg from a
2.6.24-rc7 boot and a 2.6.22 boot.
System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and
userland - there is a "pop" from the speakers when booting, but no sound at
all. I'll pull a new tree from GIT, but I'm thinking that the above changes
are probably related to the move from ACPI motherboard drivers to the PNP
platform driver. What I don't understand is how, if there are only more mem
resources than the new PNP platform driver can handle, why there are also
ioport ranges that could not be reserved.
Additionally, with the same kernel, the iwlwifi driver appears to cause the
new 802.11 code to crash. This doesn't stop the driver or cause any problems
with the connection. I've been using the iwlwifi driver with 2.6.22 for a
while and haven't seen anything like this.
The message seen is:
[ 30.504842] eth1: Initial auth_alg=0
[ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba
[ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0
transaction
=2 status=0)
[ 30.506633] eth1: authenticated
[ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba
[ 30.509261] eth1: RX AssocResp from 00:11:50:fa:d4:ba (capab=0x411 status=0
a
id=2)
[ 30.509264] eth1: associated
[ 30.509269] eth1: switched to short barker preamble
(BSSID=00:11:50:fa:d4:ba)
[ 30.509297] eth1: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023
burst=0
[ 30.509300] eth1: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023
burst=0
[ 30.509303] eth1: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
[ 30.509306] eth1: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
[ 30.512840] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 30.894090] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
[ 30.894097] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #1
[ 30.894100]
[ 30.894101] Call Trace:
[ 30.894104] <IRQ>
[<ffffffff881c9e39>] :mac80211:__ieee80211_rx+0xc69/0xd30
[ 30.894161] [<ffffffff881ba87f>] :mac80211:ieee80211_tx_status+0x2af/0x4e0
[ 30.894172] [<ffffffff80458576>] _spin_unlock_irqrestore+0x16/0x40
[ 30.894187] [<ffffffff88209fb1>] :iwl3945:iwl_rx_queue_restock+0xd1/0x160
[ 30.894207]
[<ffffffff881bb53b>] :mac80211:ieee80211_tasklet_handler+0xbb/0x120
[ 30.894218] [<ffffffff802446c8>] tasklet_action+0x48/0xb0
[ 30.894224] [<ffffffff802445d9>] __do_softirq+0x59/0xd0
[ 30.894231] [<ffffffff8020d4fc>] call_softirq+0x1c/0x30
[ 30.894236] [<ffffffff8020ee85>] do_softirq+0x35/0x90
[ 30.894241] [<ffffffff80244505>] irq_exit+0x85/0x90
[ 30.894246] [<ffffffff8020ef60>] do_IRQ+0x80/0x100
[ 30.894252] [<ffffffff8020c851>] ret_from_intr+0x0/0xa
[ 30.894254] <EOI>
[<ffffffff8801651b>] :processor:acpi_processor_idle+0x2ef/0x4d8
[ 30.894279]
[<ffffffff88016511>] :processor:acpi_processor_idle+0x2e5/0x4d8
[ 30.894288] [<ffffffff8801622c>] :processor:acpi_processor_idle+0x0/0x4d8
[ 30.894295] [<ffffffff8020afc2>] cpu_idle+0x72/0xe0
[ 30.894302] [<ffffffff805bdb6a>] start_kernel+0x27a/0x300
[ 30.894309] [<ffffffff805bd129>] _sinittext+0x129/0x130
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
At Fri, 11 Jan 2008 22:55:28 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> > At Thu, 10 Jan 2008 23:02:53 +0100,
> > Harald Dunkel wrote:
> >> Takashi Iwai wrote:
> >>> Hm... Just to be sure, try the patch below. It's a clean up patch
> >>> that I'd like to apply later.
> >>>
> >> Sorry, no sound.
> >
> > OK, but I'd like to know whether this makes no regression to rc6.
> > Could you check?
> >
>
> "Regression" sounds like a test suite to me, verifying that the
> old problems didn't come back. Maybe you could send me a pointer?
The "regression" was your original problem, no sound on rc7, which was
fixed by reverting the patch. Now I'd like to know that my new patch
doesn't break after reverting the broken patch.
In short, try my patch on the latest Linus git tree. Check whether
the sound still works.
> Of course I didn't try that much yet. The kernel booted as expected,
> I saw XWindow running, the mouse pointer was moving, etc. There was
> just no sound, as before with rc7.
Yeah, I know that it doesn't fix the rc7.
> > Also, what exactly did you test? "No sound" means that no sound from
> > the headphone / line-out or from the speaker?
> >
>
> Speaker and first headphone are the same on this laptop. If I plugin
> the headphone, then the tiny speakers are disconnected. But for the
> last tests no headphone was plugged in.
>
> I tested it by running gnome-alsamixer. I tried to switch off and
> on the mute buttons, change the volume and other sliders, etc.
Hm. Looks like the problem appearing only with IDT STAC codecs.
The symptom indicates that it's not about the EAPD for the speaker but
in the deeper core initialization part...
> > One interesting test would be to increase the value of udelay() in the
> > reverted patch. What happens if it's set to 500?
> >
>
> I will try tomorrow. What exactly is this delay good for?
It's simply a delay. Basically Ingo's patch changed msleep() to
udelay() to reduce *unneeded* delays. The function waits until the
all pending commands are processed. The delay is simply to reduce the
system load. And, now, changing this delay causes a problem
surprisingly.
> >>> The perex/alsa.git mm branch on kernel.org has many fixes. Could you
> >>> give it a try, too?
> >>>
> >> This version seems to work. But AFAICS it just reverts hda_intel.c back
> >> to rc6 again, so this is no surprise.
> >
> > Use mm branch. The main branch is just an old Linus tree.
> >
>
> AFAICS I did use the mm branch. The command to grab the sources was
>
> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm
>
> Is this correct?
No. You'd better to clone Linus git tree, then pull from alsa.git mm
branch.
% git-clone $LINUS/linux-2.6.git
% cd linux-2.6
% git-pull $ALSA/alsa.git mm
Takashi
At Sat, 12 Jan 2008 10:41:21 +0100,
Harald Dunkel wrote:
>
> Takashi Iwai wrote:
> > At Thu, 10 Jan 2008 23:02:53 +0100,
> > Harald Dunkel wrote:
> >> Takashi Iwai wrote:
> >>> Hm... Just to be sure, try the patch below. It's a clean up patch
> >>> that I'd like to apply later.
> >>>
> >> Sorry, no sound.
> >
> > OK, but I'd like to know whether this makes no regression to rc6.
> > Could you check?
> >
> > Also, what exactly did you test? "No sound" means that no sound from
> > the headphone / line-out or from the speaker?
> >
> > One interesting test would be to increase the value of udelay() in the
> > reverted patch. What happens if it's set to 500?
> >
>
> There is no udelay() in the reverted patch.
Hm? Ingo's patch replaces msleep(1) with udelay(10) +
cond_resched(). This is the patch we're arguing. This was already
reverted (based on your report) on git.
> If I replace "udelay(10)"
> by "udelay(500)" in the original rc7, then there is still no sound.
Interesting... What about udelay(1000)? Then it'll be closer to
msleep(1).
> This is like fishing in the dark. We've got a working version. Why not
> keep it?
Yes, we are shooting in the dark now indeed. Honestly, I have no
concrete idea why the patch breaks the sound initialization.
It seems that Dell machines (or STAC codecs) have problems with the
initialization timing. I don't think that all commands but only
certain some command sequences that are so sensitive to the access
timing. We need to identify this.
Ingo's patch is basically a really nice fix. It reduces the
unnecessary delay, especially improves resume speed much. I'd love to
have it. And above all, I need to understand what is the real
problem. Unfortunately, I have no this hardware and the precise h/w
data, so must rely on testers and a guess work.
thanks,
Takashi
At Sat, 12 Jan 2008 12:11:20 -0500,
Daniel Hazelton wrote:
>
> On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote:
> > Takashi Iwai wrote:
> > > At Thu, 10 Jan 2008 23:02:53 +0100,
> > >
> > > Harald Dunkel wrote:
> > >> Takashi Iwai wrote:
> > >>> Hm... Just to be sure, try the patch below. It's a clean up patch
> > >>> that I'd like to apply later.
> > >>
> > >> Sorry, no sound.
> > >
> > > OK, but I'd like to know whether this makes no regression to rc6.
> > > Could you check?
> > >
> > > Also, what exactly did you test? "No sound" means that no sound from
> > > the headphone / line-out or from the speaker?
> > >
> > > One interesting test would be to increase the value of udelay() in the
> > > reverted patch. What happens if it's set to 500?
> >
> > There is no udelay() in the reverted patch. If I replace "udelay(10)"
> > by "udelay(500)" in the original rc7, then there is still no sound.
> >
> > This is like fishing in the dark. We've got a working version. Why not
> > keep it?
> >
> >
> > Regards
> >
> > Harri
>
> Could this have anything to do with the following messages I've seen when
> trying -rc7 ?
>
> [ 7.760269] pnpacpi: exceeded the max number of mem resources: 12
Judging from Harald's report, it looks like a different problem.
The buggy patch (regarding HDA-intel) was, at least, already reverted
on Linus git tree. Could you give it a try?
Takashi
Dear Takashi-san,
Takashi Iwai wrote:
>
> The "regression" was your original problem, no sound on rc7, which was
> fixed by reverting the patch. Now I'd like to know that my new patch
> doesn't break after reverting the broken patch.
>
Seems that there was some misunderstanding: I thought your patch
for sigmatel.c was supposed to fix the "missing sound" problem,
too.
> In short, try my patch on the latest Linus git tree. Check whether
> the sound still works.
>
It does.
rc7 plus the big "clean-up" patch for sigmatel.c plus hda_intel.c
taken from rc6 worked, too. Seems that I missed to mention it in a
previous EMail.
>
> It's simply a delay. Basically Ingo's patch changed msleep() to
> udelay() to reduce *unneeded* delays. The function waits until the
> all pending commands are processed. The delay is simply to reduce the
> system load. And, now, changing this delay causes a problem
> surprisingly.
>
I am glad to help, but could you please do me a favour? If I am
supposed to try some new version, then please create a complete(!)
patch using rc7 on kernel.org as the base, and send it as an
attachment using a unique filename. Very likely you have a much
better overview about the most recent kernel changes, but some
statements like "new patch" or "Ingo's patch" don't mean very much
to me. The "reverted" patch is a new patch, too, and AFAIK Ingo
reverted it, so maybe you can imagine that this is highly confusing.
>> AFAICS I did use the mm branch. The command to grab the sources was
>>
>> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm
>>
>> Is this correct?
>
> No. You'd better to clone Linus git tree, then pull from alsa.git mm
> branch.
>
> % git-clone $LINUS/linux-2.6.git
> % cd linux-2.6
> % git-pull $ALSA/alsa.git mm
>
AFAICS there shouldn't be a difference to my one-liner, unless Linus'
and Alsa's git trees are out of sync. Is this correct? Sorry, I am
more familiar with ClearCase and Accurev than with Git.
Regards
Harri
On Monday 14 January 2008 06:04:20 Takashi Iwai wrote:
<snip>
> >
> > Could this have anything to do with the following messages I've seen when
> > trying -rc7 ?
> >
> > [ 7.760269] pnpacpi: exceeded the max number of mem resources: 12
>
> Judging from Harald's report, it looks like a different problem.
> The buggy patch (regarding HDA-intel) was, at least, already reverted
> on Linus git tree. Could you give it a try?
>
>
> Takashi
Sorry, still no sound. Config, lspci and dmesg attached to help. System is, as
stated, Dell Inspiron 1420n running a 64bit kernel and userland.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
At Mon, 14 Jan 2008 21:46:58 +0100,
Harald Dunkel wrote:
>
> Dear Takashi-san,
>
> Takashi Iwai wrote:
> >
> > The "regression" was your original problem, no sound on rc7, which was
> > fixed by reverting the patch. Now I'd like to know that my new patch
> > doesn't break after reverting the broken patch.
> >
>
> Seems that there was some misunderstanding: I thought your patch
> for sigmatel.c was supposed to fix the "missing sound" problem,
> too.
>
> > In short, try my patch on the latest Linus git tree. Check whether
> > the sound still works.
> >
>
> It does.
>
> rc7 plus the big "clean-up" patch for sigmatel.c plus hda_intel.c
> taken from rc6 worked, too. Seems that I missed to mention it in a
> previous EMail.
OK, thanks. Then I'll queue this clean-up patch to ALSA tree.
> > It's simply a delay. Basically Ingo's patch changed msleep() to
> > udelay() to reduce *unneeded* delays. The function waits until the
> > all pending commands are processed. The delay is simply to reduce the
> > system load. And, now, changing this delay causes a problem
> > surprisingly.
> >
>
> I am glad to help, but could you please do me a favour? If I am
> supposed to try some new version, then please create a complete(!)
> patch using rc7 on kernel.org as the base, and send it as an
> attachment using a unique filename. Very likely you have a much
> better overview about the most recent kernel changes, but some
> statements like "new patch" or "Ingo's patch" don't mean very much
> to me. The "reverted" patch is a new patch, too, and AFAIK Ingo
> reverted it, so maybe you can imagine that this is highly confusing.
There are three patches.
- Ingo's patch to reduce latency. This was applied after rc6, and
reverted after rc7.
- My first test patch
- My second test patch (clean-up patch you tested lastly)
> >> AFAICS I did use the mm branch. The command to grab the sources was
> >>
> >> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git mm
> >>
> >> Is this correct?
> >
> > No. You'd better to clone Linus git tree, then pull from alsa.git mm
> > branch.
> >
> > % git-clone $LINUS/linux-2.6.git
> > % cd linux-2.6
> > % git-pull $ALSA/alsa.git mm
> >
>
> AFAICS there shouldn't be a difference to my one-liner, unless Linus'
> and Alsa's git trees are out of sync. Is this correct?
No, the second argument of git-clone is the destination directory to
clone, not the branch to pick up. The cloned repo has all branches
but doesn't point mm branch.
And, Linus and ALSA git trees are likely out of sync.
Takashi
At Mon, 14 Jan 2008 16:03:22 -0500,
Daniel Hazelton wrote:
>
> On Monday 14 January 2008 06:04:20 Takashi Iwai wrote:
> <snip>
> > >
> > > Could this have anything to do with the following messages I've seen when
> > > trying -rc7 ?
> > >
> > > [ 7.760269] pnpacpi: exceeded the max number of mem resources: 12
> >
> > Judging from Harald's report, it looks like a different problem.
> > The buggy patch (regarding HDA-intel) was, at least, already reverted
> > on Linus git tree. Could you give it a try?
> >
> >
> > Takashi
>
> Sorry, still no sound. Config, lspci and dmesg attached to help. System is, as
> stated, Dell Inspiron 1420n running a 64bit kernel and userland.
Hm, has the sound on ever 2.6.24-rc kernel worked with your machine?
Anyway, try to change HZ=300. I got a report that HZ=1000 causes the
similar problem but HZ=300 not.
Takashi
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote:
> At Mon, 14 Jan 2008 16:03:22 -0500,
>
> Daniel Hazelton wrote:
> > On Monday 14 January 2008 06:04:20 Takashi Iwai wrote:
> > <snip>
> >
> > > > Could this have anything to do with the following messages I've seen
> > > > when trying -rc7 ?
> > > >
> > > > [ 7.760269] pnpacpi: exceeded the max number of mem resources: 12
> > >
> > > Judging from Harald's report, it looks like a different problem.
> > > The buggy patch (regarding HDA-intel) was, at least, already reverted
> > > on Linus git tree. Could you give it a try?
> > >
> > >
> > > Takashi
> >
> > Sorry, still no sound. Config, lspci and dmesg attached to help. System
> > is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland.
>
> Hm, has the sound on ever 2.6.24-rc kernel worked with your machine?
>
> Anyway, try to change HZ=300. I got a report that HZ=1000 causes the
> similar problem but HZ=300 not.
>
>
> Takashi
That did it. Looks like the hardware really is that sensitive to the timing.
Strange, but I've seen worse.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
Takashi Iwai wrote:
>
> Linus, please revert the commit 57a04513cb3 as now.
> The life can go well without this patch.
>
hda_intel.c works for me in rc8.
Many thanx to all
Harri