[alsa-devel] Recent code changes for HD-audio on HG repo

[Takashi Iwai]

At Wed, 15 Aug 2007 21:40:33 +0200,
Nicola Fagnani wrote:
> 
> 
> Il giorno 15/ago/07, alle ore 12:10, Takashi Iwai ha scritto:
> 
> > At Tue, 14 Aug 2007 20:41:04 +0200,
> > nicfagn wrote:
> >>
> >> I tested the alsa-driver-hg20070814 snapshot on my system and  
> >> after the power save timeout (10 secs) the sound stops working.
> >> I am on an iMac 24''(2006) with hda and realtek ALC885 and Ubuntu  
> >> Gutsy with a 2.6.22-9 kernel.
> >> If I can help in some way, let me know.
> >
> > Try hg20070815.  Some bugs were fixed yesterday :)
> >
> >
> > Takashi
> 
> Sorry, but hg20070815 still not working. After 10 seconds the sound  
> goes mute.

Which hardware, which codec and what mixer setting?
How did you check it went to mute?

> hg20070812 is the last snapshot where the sound worked as usual, but  
> that didn't include the fix for the test at the entry of the  
> azx_stop_chip() function in hda_intel.c, so the code in that function  
> was always skipped and the azx_init_chip() function was called only  
> once.
> What these functions do is clear enough from their names, but the low  
> level details are a bit too much in depth for me. :-)
> Is there anything I could check or test to help?

Try to add printk in hda_power_up(), hda_power_down(), and
hda_power_work() functions to show the current codec->power_count
and codec->power_on values.  The up and down have to be called at each
PCM open and close, respecitvely.  Also the access to each mixer
element invokes up and down, too.

When the counts of all codecs go to zero, azx_power_notify() calls
azx_stop_chip().  OTOH, when a codec is powered on, azx_power_notify()
calls azx_init_chip() again.  If these functions get called properly,
then there must be a problem in the initialization / resume phase.

You can set power_save_controller=0 module option to disable the call
of azx_stop_chip().  If this cures the problem, then the problem is in
the resume of the controller chip.  If not, it's in another place,
e.g. the resume of codec registers.  So, it's important to know the
detail of your hardware.  The current driver works fine on my
systems.

BTW, the patch below is a fix I forgot to apply (now already on HG
tree), but it shouldn't influence on the "mute after 10 seconds"
behavior.


Takashi

---
# HG changeset patch
# User tiwai
# Date 1187209102 -7200
# Node ID 22fe10ab35e8e98413a3d95697579fb5dd0c7908
# Parent  e02b6e9d22d79b4a6724561d49a398976fddc1d6
hda-intel - Add flush_scheduled_work() in snd_hda_codec_free()

Added flush_scheduled_work() in snd_hda_codec_free() to make sure that
the all work is gone.  Also, optimized the condition to schedule the
delayed work in snd_hda_power_down().

diff -r e02b6e9d22d7 -r 22fe10ab35e8 pci/hda/hda_codec.c
--- a/pci/hda/hda_codec.c	Wed Aug 15 16:44:04 2007 +0200
+++ b/pci/hda/hda_codec.c	Wed Aug 15 22:18:22 2007 +0200
@@ -525,6 +525,7 @@ static void snd_hda_codec_free(struct hd
 		return;
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	cancel_delayed_work(&codec->power_work);
+	flush_scheduled_work();
 #endif
 	list_del(&codec->list);
 	codec->bus->caddr_tbl[codec->addr] = NULL;
@@ -2223,7 +2224,7 @@ void snd_hda_power_down(struct hda_codec
 void snd_hda_power_down(struct hda_codec *codec)
 {
 	--codec->power_count;
-	if (!codec->power_on)
+	if (!codec->power_on || codec->power_count)
 		return;
 	if (power_save)
 		schedule_delayed_work(&codec->power_work,