At Mon, 07 Jan 2008 20:53:33 +0100,
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

--

Dear Takashi-san,
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,
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.
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

--

hda_intel.c works for me in rc8.
Many thanx to all
Harri
--

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 Adap...
[ message continues ]

At Wed, 09 Jan 2008 07:03:18 +0100,
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);

 }
 /*

--

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,
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 <...
[ message continues ]

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,
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
Use mm branch.  The main branch is just an old Linus tree.
thanks,
Takashi

--

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
--

At Sat, 12 Jan 2008 10:41:21 +0100,
Hm?  Ingo's patch replaces msleep(1) with udelay(10) +

cond_resched().  This is the patch we're arguing.  This was already
Interesting...  What about udelay(1000)?  Then it'll be closer to
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

--

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 r...
[ message continues ]

At Sat, 12 Jan 2008 12:11:20 -0500,
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

--

On Monday 14 January 2008 06:04:20 Takashi Iwai wrote:
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 16:03:22 -0500,
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.

--

"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
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
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
--

At Fri, 11 Jan 2008 22:55:28 +0100,
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
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
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
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

--

Dear Takashi-san,
Seems that there was some misunderstanding: I thought your patch

for sigmatel.c was supposed to fix the "missing sound" problem,
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
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
--

At Mon, 14 Jan 2008 21:46:58 +0100,
There are three patches.

- Ingo's patch to reduce latency.  This was applied after rc6, and

  reverted after rc7.

- My first test patch
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

--

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

--