Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep

[Takashi Iwai]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/