Fix for slow snd-ali5451 initialization

Fix for slow snd-ali5451 initialization

[Vince Busam]

The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
on a laptop that boots every day.  This patch lowers that to a much more 
managable time, and still works fine on my laptop.

Vince

     Summary: Speed up ali5451 initialization

     The patch speeds up loading the ali5451 driver by lowering the
     wait time in snd_ali_codec_ready()

     Author: Vince Busam <vince@sixpak.org
     Signed-off-by: Vince Busam <vince@sixpak.org>

--- linux-source-2.6.12/sound/pci/ali5451/ali5451.c	2005-10-10 05:12:34.000000000 -0700
+++ linux-source-2.6.12-new/sound/pci/ali5451/ali5451.c	2005-11-05 11:25:11.000000000 -0800
@@ -399,7 +399,7 @@ static int snd_ali_codec_ready(	ali_t *c
  	unsigned long end_time;
  	unsigned int res;

-	end_time = jiffies + 10 * (HZ >> 2);
+	end_time = jiffies + 10 * (HZ >> 6);
  	do {
  		res = snd_ali_5451_peek(codec,port);
  		if (! (res & 0x8000))

-- 
Vince Busam
vince@sixpak.org
http://sixpak.org/vince/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Lee Revell]

On Sat, 2005-11-05 at 11:38 -0800, Vince Busam wrote:
> The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
> on a laptop that boots every day.  This patch lowers that to a much more 
> managable time, and still works fine on my laptop.
> 
> Vince
> 
>      Summary: Speed up ali5451 initialization
> 
>      The patch speeds up loading the ali5451 driver by lowering the
>      wait time in snd_ali_codec_ready()

Does not apply against current ALSA or kernel sources.  Please provide
an updated patch.

Also, why is this an issue?  Do your distros init scripts delay the boot
until this driver is loaded?  Shouldn't it be loading all drivers in
parallel?

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Vince Busam]

Ubuntu and Fedora both wait until the driver is loaded.  If I don't load 
the driver on bootup, and manually load it later, the whole system will 
freeze for 10 seconds while the driver loads.

This function (snd_ali_codec_ready) fails 4 times during initialization, 
no matter how long it waits.  Why does it have to wait for 2.5 seconds 
each time?  As you can see, that total comes to 10 seconds.  Dropping the 
timeout here brings that down to a tolerable level with no ill effects for 
me.  A better fix might be to figure out why it's being called 4 times at 
all when it's going to fail, but I certainly don't know enough about this 
chip or driver to know if that's the case.

Vince

--- alsa-driver-1.0.10rc2/alsa-kernel/pci/ali5451/ali5451.c.orig        2005-11-05 18:01:22.000000000 -0800
+++ alsa-driver-1.0.10rc2/alsa-kernel/pci/ali5451/ali5451.c     2005-11-05 18:04:45.000000000 -0800
@@ -391,7 +391,7 @@ static int snd_ali_codec_ready(     ali_t *c
         unsigned long end_time;
         unsigned int res;

-       end_time = jiffies + 10 * msecs_to_jiffies(250);
+       end_time = jiffies + msecs_to_jiffies(150);
         do {
                 res = snd_ali_5451_peek(codec,port);
                 if (! (res & 0x8000))


On Sat, 5 Nov 2005, Lee Revell wrote:

> On Sat, 2005-11-05 at 11:38 -0800, Vince Busam wrote:
>> The snd-ali5451 driver takes 10 seconds to load, which is quite annoying
>> on a laptop that boots every day.  This patch lowers that to a much more
>> managable time, and still works fine on my laptop.
>>
>> Vince
>>
>>      Summary: Speed up ali5451 initialization
>>
>>      The patch speeds up loading the ali5451 driver by lowering the
>>      wait time in snd_ali_codec_ready()
>
> Does not apply against current ALSA or kernel sources.  Please provide
> an updated patch.
>
> Also, why is this an issue?  Do your distros init scripts delay the boot
> until this driver is loaded?  Shouldn't it be loading all drivers in
> parallel?
>
> Lee
>

-- 
Vince Busam
vince@sixpak.org
http://sixpak.org/vince/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Takashi Iwai]

At Sat, 5 Nov 2005 11:38:03 -0800 (PST),
Vince Busam wrote:
> 
> The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
> on a laptop that boots every day.  This patch lowers that to a much more 
> managable time, and still works fine on my laptop.
> 
> Vince
> 
>      Summary: Speed up ali5451 initialization
> 
>      The patch speeds up loading the ali5451 driver by lowering the
>      wait time in snd_ali_codec_ready()
> 
>      Author: Vince Busam <vince@sixpak.org
>      Signed-off-by: Vince Busam <vince@sixpak.org>

Well, it's not a good solution.  It's already strange that so many
timeouts occur.  And, the driver works correctly after that?  That is,
you don't get any timeouts once after the driver is initialized?

If the driver really works after initialization, then the primary
question is which function call failed at which timing.  If the
failures are consistent, that is the part to be fixed. 
For an easy test, add printk's to each call of snd_ali_codec_ready,
and check the log.


Takashi


> 
> --- linux-source-2.6.12/sound/pci/ali5451/ali5451.c	2005-10-10 05:12:34.000000000 -0700
> +++ linux-source-2.6.12-new/sound/pci/ali5451/ali5451.c	2005-11-05 11:25:11.000000000 -0800
> @@ -399,7 +399,7 @@ static int snd_ali_codec_ready(	ali_t *c
>   	unsigned long end_time;
>   	unsigned int res;
> 
> -	end_time = jiffies + 10 * (HZ >> 2);
> +	end_time = jiffies + 10 * (HZ >> 6);
>   	do {
>   		res = snd_ali_5451_peek(codec,port);
>   		if (! (res & 0x8000))
> 
> -- 
> Vince Busam
> vince@sixpak.org
> http://sixpak.org/vince/
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Sasha Khapyorsky]

On 11:54 Mon 07 Nov     , Takashi Iwai wrote:
> At Sat, 5 Nov 2005 11:38:03 -0800 (PST),
> Vince Busam wrote:
> > 
> > The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
> > on a laptop that boots every day.  This patch lowers that to a much more 
> > managable time, and still works fine on my laptop.
> > 
> > Vince
> > 
> >      Summary: Speed up ali5451 initialization
> > 
> >      The patch speeds up loading the ali5451 driver by lowering the
> >      wait time in snd_ali_codec_ready()
> > 
> >      Author: Vince Busam <vince@sixpak.org
> >      Signed-off-by: Vince Busam <vince@sixpak.org>
> 
> Well, it's not a good solution.  It's already strange that so many
> timeouts occur.  And, the driver works correctly after that?  That is,
> you don't get any timeouts once after the driver is initialized?

This could be initialization attempt of non-existed secondary codec. At
least such attempt was reported in the past.

Vince, could you drop the content of your /proc/asound/card0/ali5451 file?

Sasha.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Takashi Iwai]

At Mon, 7 Nov 2005 17:46:26 +0200,
Sasha Khapyorsky wrote:
> 
> On 11:54 Mon 07 Nov     , Takashi Iwai wrote:
> > At Sat, 5 Nov 2005 11:38:03 -0800 (PST),
> > Vince Busam wrote:
> > > 
> > > The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
> > > on a laptop that boots every day.  This patch lowers that to a much more 
> > > managable time, and still works fine on my laptop.
> > > 
> > > Vince
> > > 
> > >      Summary: Speed up ali5451 initialization
> > > 
> > >      The patch speeds up loading the ali5451 driver by lowering the
> > >      wait time in snd_ali_codec_ready()
> > > 
> > >      Author: Vince Busam <vince@sixpak.org
> > >      Signed-off-by: Vince Busam <vince@sixpak.org>
> > 
> > Well, it's not a good solution.  It's already strange that so many
> > timeouts occur.  And, the driver works correctly after that?  That is,
> > you don't get any timeouts once after the driver is initialized?
> 
> This could be initialization attempt of non-existed secondary codec. At
> least such attempt was reported in the past.

Yes, that's also my suspect.

Vince, are you using the latest ALSA code?  At least, the probe code
is a bit improved on 2.6.14 kernel, like ALSA CVS version.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Vince Busam]

This is with 2.6.12-9-k7 from Ubuntu and 2.6.13-1.1526_FC4 from Fedora 
Core 4.  I'll try pulling the latest code from CVS and see if that helps.

I don't think it's a problem with attempting the second mixer (which it 
does, and fails).  It happens while creating the first mixer, in the 
snd_ac97_mixer() call in this loop when i==0.

for ( i = 0 ; i < codec->num_of_codecs ; i++) {
   ac97.num = i;
   if ((err = snd_ac97_mixer(codec->ac97_bus, &ac97, &codec->ac97[i])) < 
0) {
     snd_printk("ali mixer %d creating error.\n", i);
     if(i == 0)
       return err;
    }
}

Vince

Takashi Iwai wrote:
> At Mon, 7 Nov 2005 17:46:26 +0200,
> Sasha Khapyorsky wrote:
> 
>>On 11:54 Mon 07 Nov     , Takashi Iwai wrote:
>>
>>>At Sat, 5 Nov 2005 11:38:03 -0800 (PST),
>>>Vince Busam wrote:
>>>
>>>>The snd-ali5451 driver takes 10 seconds to load, which is quite annoying 
>>>>on a laptop that boots every day.  This patch lowers that to a much more 
>>>>managable time, and still works fine on my laptop.
>>>>
>>>>Vince
>>>>
>>>>     Summary: Speed up ali5451 initialization
>>>>
>>>>     The patch speeds up loading the ali5451 driver by lowering the
>>>>     wait time in snd_ali_codec_ready()
>>>>
>>>>     Author: Vince Busam <vince@sixpak.org
>>>>     Signed-off-by: Vince Busam <vince@sixpak.org>
>>>
>>>Well, it's not a good solution.  It's already strange that so many
>>>timeouts occur.  And, the driver works correctly after that?  That is,
>>>you don't get any timeouts once after the driver is initialized?
>>
>>This could be initialization attempt of non-existed secondary codec. At
>>least such attempt was reported in the past.
> 
> 
> Yes, that's also my suspect.
> 
> Vince, are you using the latest ALSA code?  At least, the probe code
> is a bit improved on 2.6.14 kernel, like ALSA CVS version.
> 
> 
> Takashi


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Vince Busam]

> 
> Vince, could you drop the content of your /proc/asound/card0/ali5451 file?
> 

00: 00000000
04: 00000000
08: 00000000
0c: 00000000
10: 00000000
14: 00008000
18: 00000000
1c: 00000000
20: 88108088
24: 88108088
28: 88108088
2c: 88108088
30: 00003000
34: ffffffff
38: ffffffff
3c: ffffffff
40: 20100076
44: 00000000
48: 03114200
4c: 00000004
50: 00008000
54: 00f5ac44
58: 00000000
5c: 0204004a
60: 00000000
64: 00000000
68: 00000000
6c: 00000000
70: 02000000
74: 09050000
78: 00000000
7c: 00000000
80: 00000000
84: 00000000
88: 00000000
8c: 00000000
90: 00000000
94: 00000000
98: 00000000
9c: 00000000
a0: 00003000
a4: 00000000
a8: 00000000
ac: 00000000
b0: 00000000
b4: 00000000
b8: 00000000
bc: 00000000
c0: 00000000
c4: 00000000
c8: 050fa876
cc: 00000000
d0: 00000000
d4: 00000001
d8: 00000001
dc: 00000001
e0: 34068710
e4: 99a00000
e8: 3fff0eb3
ec: c8506eb9
f0: 8000f000
f4: 30000000
f8: 30000000
fc: 209d8e52


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Takashi Iwai]

At Mon, 07 Nov 2005 21:14:30 -0800,
Vince Busam wrote:
> 
> This is with 2.6.12-9-k7 from Ubuntu and 2.6.13-1.1526_FC4 from Fedora 
> Core 4.  I'll try pulling the latest code from CVS and see if that helps.
> 
> I don't think it's a problem with attempting the second mixer (which it 
> does, and fails).  It happens while creating the first mixer, in the 
> snd_ac97_mixer() call in this loop when i==0.

OK, then the problem is not that easy...
We'll need to track down which call fails.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Sasha Khapyorsky]

On 21:17 Mon 07 Nov     , Vince Busam wrote:
> >
> >Vince, could you drop the content of your /proc/asound/card0/ali5451 file?
> >
> 
> 48: 03114200

This '03' indicates that secondary codec is ready. But as I am
understanding you don't have secondary codec there.
Or hw report is invalid or we are using bad method (datasheet is
unavailable).

Sasha.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Vince Busam]

On Tue, 8 Nov 2005, Takashi Iwai wrote:

> OK, then the problem is not that easy...
> We'll need to track down which call fails.
>

What can I try?  I've noticed it happens when calling snd_ali_codec_peek() 
with secondary=0 and reg=0x7e.  The first couple calls with those 
paramaters succeed, then 4 fail.  Is there any good way to print a stack 
trace when the call fails?

Thanks,
Vince

-- 
Vince Busam
vince@sixpak.org
http://sixpak.org/vince/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Fix for slow snd-ali5451 initialization

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

At Wed, 9 Nov 2005 21:17:32 -0800 (PST),
Vince Busam wrote:
> 
> On Tue, 8 Nov 2005, Takashi Iwai wrote:
> 
> > OK, then the problem is not that easy...
> > We'll need to track down which call fails.
> >
> 
> What can I try?  I've noticed it happens when calling snd_ali_codec_peek() 
> with secondary=0 and reg=0x7e.  The first couple calls with those 
> paramaters succeed, then 4 fail.  Is there any good way to print a stack 
> trace when the call fails?

Could you try the patch below, to sync our code base, before further
looking?  It's for the latest ALSA CVS version (or 1.0.10rc3).


Takashi

[-- Attachment #2: ali5451-fix.diff --]
[-- Type: application/octet-stream, Size: 9097 bytes --]

--- alsa-kernel/pci/ali5451/ali5451.c	24 Oct 2005 13:59:31 -0000	1.75
+++ alsa-kernel/pci/ali5451/ali5451.c	11 Nov 2005 14:00:52 -0000
@@ -387,26 +387,24 @@
 }
 
 static int snd_ali_codec_ready(	ali_t *codec,
-				unsigned int port,
-				int sched )
+				unsigned int port )
 {
 	unsigned long end_time;
 	unsigned int res;
 	
-	end_time = jiffies + 10 * msecs_to_jiffies(250);
+	end_time = jiffies + msecs_to_jiffies(250);
 	do {
 		res = snd_ali_5451_peek(codec,port);
 		if (! (res & 0x8000))
 			return 0;
-		if (sched)
-			schedule_timeout_uninterruptible(1);
+		schedule_timeout_uninterruptible(1);
 	} while (time_after_eq(end_time, jiffies));
 	snd_ali_5451_poke(codec, port, res & ~0x8000);
 	snd_printdd("ali_codec_ready: codec is not ready.\n ");
 	return -EIO;
 }
 
-static int snd_ali_stimer_ready(ali_t *codec, int sched)
+static int snd_ali_stimer_ready(ali_t *codec)
 {
 	unsigned long end_time;
 	unsigned long dwChk1,dwChk2;
@@ -414,13 +412,12 @@
 	dwChk1 = snd_ali_5451_peek(codec, ALI_STIMER);
 	dwChk2 = snd_ali_5451_peek(codec, ALI_STIMER);
 
-	end_time = jiffies + 10 * msecs_to_jiffies(250);
+	end_time = jiffies + msecs_to_jiffies(250);
 	do {
 		dwChk2 = snd_ali_5451_peek(codec, ALI_STIMER);
 		if (dwChk2 != dwChk1)
 			return 0;
-		if (sched)
-			schedule_timeout_uninterruptible(1);
+		schedule_timeout_uninterruptible(1);
 	} while (time_after_eq(end_time, jiffies));
 	snd_printk(KERN_ERR "ali_stimer_read: stimer is not ready.\n");
 	return -EIO;
@@ -440,9 +437,9 @@
 
 	port = codec->chregs.regs.ac97write;
 
-	if (snd_ali_codec_ready(codec, port, 0) < 0)
+	if (snd_ali_codec_ready(codec, port) < 0)
 		return;
-	if (snd_ali_stimer_ready(codec, 0) < 0)
+	if (snd_ali_stimer_ready(codec) < 0)
 		return;
 
 	dwVal  = (unsigned int) (reg & 0xff);
@@ -469,9 +466,9 @@
 
 	port = codec->chregs.regs.ac97read;
 
-	if (snd_ali_codec_ready(codec, port, 0) < 0)
+	if (snd_ali_codec_ready(codec, port) < 0)
 		return ~0;
-	if (snd_ali_stimer_ready(codec, 0) < 0)
+	if (snd_ali_stimer_ready(codec) < 0)
 		return ~0;
 
 	dwVal  = (unsigned int) (reg & 0xff);
@@ -480,9 +477,9 @@
 
 	snd_ali_5451_poke(codec, port, dwVal);
 
-	if (snd_ali_stimer_ready(codec, 0) < 0)
+	if (snd_ali_stimer_ready(codec) < 0)
 		return ~0;
-	if (snd_ali_codec_ready(codec, port, 0) < 0)
+	if (snd_ali_codec_ready(codec, port) < 0)
 		return ~0;
 	
 	return (snd_ali_5451_peek(codec, port) & 0xffff0000)>>16;
@@ -770,7 +767,7 @@
 	currenttimer = inl(ALI_REG(codec, ALI_STIMER));
 
 	while (currenttimer < begintimer + interval) {
-		if(snd_ali_stimer_ready(codec, 1) < 0)
+		if(snd_ali_stimer_ready(codec) < 0)
 			break;
 		currenttimer = inl(ALI_REG(codec,  ALI_STIMER));
 	}
@@ -1065,35 +1062,34 @@
 static snd_ali_voice_t *snd_ali_alloc_voice(ali_t * codec, int type, int rec, int channel)
 {
 	snd_ali_voice_t *pvoice = NULL;
-	unsigned long flags;
 	int idx;
 
 	snd_ali_printk("alloc_voice: type=%d rec=%d\n",type,rec);
 
-	spin_lock_irqsave(&codec->voice_alloc, flags);
+	spin_lock_irq(&codec->voice_alloc);
 	if (type == SNDRV_ALI_VOICE_TYPE_PCM) {
 		idx = channel > 0 ? snd_ali_alloc_pcm_channel(codec, channel) :
 			snd_ali_find_free_channel(codec,rec);
 		if(idx < 0) {
 			snd_printk(KERN_ERR "ali_alloc_voice: err.\n");
-			spin_unlock_irqrestore(&codec->voice_alloc, flags);
+			spin_unlock_irq(&codec->voice_alloc);
 			return NULL;
 		}
 		pvoice = &(codec->synth.voices[idx]);
+		pvoice->codec = codec;
 		pvoice->use = 1;
 		pvoice->pcm = 1;
 		pvoice->mode = rec;
-		spin_unlock_irqrestore(&codec->voice_alloc, flags);
+		spin_unlock_irq(&codec->voice_alloc);
 		return pvoice;
 	}
-	spin_unlock_irqrestore(&codec->voice_alloc, flags);
+	spin_unlock_irq(&codec->voice_alloc);
 	return NULL;
 }
 
 
 static void snd_ali_free_voice(ali_t * codec, snd_ali_voice_t *pvoice)
 {
-	unsigned long flags;
 	void (*private_free)(void *);
 	void *private_data;
 
@@ -1101,7 +1097,7 @@
 	if (pvoice == NULL || !pvoice->use)
 		return;
 	snd_ali_clear_voices(codec, pvoice->number, pvoice->number);
-	spin_lock_irqsave(&codec->voice_alloc, flags);
+	spin_lock_irq(&codec->voice_alloc);
 	private_free = pvoice->private_free;
 	private_data = pvoice->private_data;
 	pvoice->private_free = NULL;
@@ -1111,7 +1107,7 @@
 	}
 	pvoice->use = pvoice->pcm = pvoice->synth = 0;
 	pvoice->substream = NULL;
-	spin_unlock_irqrestore(&codec->voice_alloc, flags);
+	spin_unlock_irq(&codec->voice_alloc);
 	if (private_free)
 		private_free(private_data);
 }
@@ -1357,7 +1353,6 @@
 	snd_pcm_runtime_t *runtime = substream->runtime;
 	snd_ali_voice_t *pvoice = (snd_ali_voice_t *) runtime->private_data;
 	snd_ali_voice_t *evoice = pvoice->extra;
-	unsigned long flags;
 
 	unsigned int LBA;
 	unsigned int Delta;
@@ -1370,7 +1365,7 @@
 	
 	snd_ali_printk("playback_prepare ...\n");
 
-	spin_lock_irqsave(&codec->reg_lock, flags);	
+	spin_lock_irq(&codec->reg_lock);	
 	
 	/* set Delta (rate) value */
 	Delta = snd_ali_convert_rate(runtime->rate, 0);
@@ -1435,7 +1430,7 @@
 				     CTRL,
 				     EC);
 	}
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
+	spin_unlock_irq(&codec->reg_lock);
 	return 0;
 }
 
@@ -1445,7 +1440,6 @@
 	ali_t *codec = snd_pcm_substream_chip(substream);
 	snd_pcm_runtime_t *runtime = substream->runtime;
 	snd_ali_voice_t *pvoice = (snd_ali_voice_t *) runtime->private_data;
-	unsigned long flags;
 	unsigned int LBA;
 	unsigned int Delta;
 	unsigned int ESO;
@@ -1456,7 +1450,7 @@
 	unsigned int EC;
 	u8	 bValue;
 
-	spin_lock_irqsave(&codec->reg_lock, flags);
+	spin_lock_irq(&codec->reg_lock);
 
 	snd_ali_printk("ali_prepare...\n");
 
@@ -1471,15 +1465,16 @@
 
 		unsigned int rate;
 		
-		if (codec->revision != ALI_5451_V02) {
-			spin_unlock_irqrestore(&codec->reg_lock, flags);			
+		spin_unlock_irq(&codec->reg_lock);
+		if (codec->revision != ALI_5451_V02)
 			return -1;
-		}
+
 		rate = snd_ali_get_spdif_in_rate(codec);
 		if (rate == 0) {
 			snd_printk(KERN_WARNING "ali_capture_preapre: spdif rate detect err!\n");
 			rate = 48000;
 		}
+		spin_lock_irq(&codec->reg_lock);
 		bValue = inb(ALI_REG(codec,ALI_SPDIF_CTRL));
 		if (bValue & 0x10) {
 			outb(bValue,ALI_REG(codec,ALI_SPDIF_CTRL));
@@ -1521,7 +1516,7 @@
 				     EC);
 
 
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
+	spin_unlock_irq(&codec->reg_lock);
 
 	return 0;
 }
@@ -1554,16 +1549,15 @@
 	snd_pcm_runtime_t *runtime = substream->runtime;
 	snd_ali_voice_t *pvoice = (snd_ali_voice_t *) runtime->private_data;
 	unsigned int cso;
-	unsigned long flags;
 
-	spin_lock_irqsave(&codec->reg_lock, flags);
+	spin_lock(&codec->reg_lock);
 	if (!pvoice->running) {
-		spin_unlock_irqrestore(&codec->reg_lock, flags);
+		spin_unlock_irq(&codec->reg_lock);
 		return 0;
 	}
 	outb(pvoice->number, ALI_REG(codec, ALI_GC_CIR));
 	cso = inw(ALI_REG(codec, ALI_CSO_ALPHA_FMS + 2));
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
+	spin_unlock(&codec->reg_lock);
 
 	return cso;
 }
@@ -1618,15 +1612,12 @@
 
 static void snd_ali_pcm_free_substream(snd_pcm_runtime_t *runtime)
 {
-	unsigned long flags;
 	snd_ali_voice_t *pvoice = (snd_ali_voice_t *) runtime->private_data;
 	ali_t *codec;
 
 	if (pvoice) {
 		codec = pvoice->codec;
-		spin_lock_irqsave(&codec->reg_lock, flags);
 		snd_ali_free_voice(pvoice->codec, pvoice);
-		spin_unlock_irqrestore(&codec->reg_lock, flags);
 	}
 }
 
@@ -1636,16 +1627,10 @@
 	ali_t *codec = snd_pcm_substream_chip(substream);
 	snd_pcm_runtime_t *runtime = substream->runtime;
 	snd_ali_voice_t *pvoice;
-	unsigned long flags = 0;
 
-	spin_lock_irqsave(&codec->reg_lock, flags);
 	pvoice = snd_ali_alloc_voice(codec, SNDRV_ALI_VOICE_TYPE_PCM, rec, channel);
-	if (pvoice == NULL) {
-		spin_unlock_irqrestore(&codec->reg_lock, flags);
+	if (pvoice == NULL)
 		return -EAGAIN;
-	}
-	pvoice->codec = codec;
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
 
 	pvoice->substream = substream;
 	runtime->private_data = pvoice;
@@ -1864,13 +1849,12 @@
 
 static int snd_ali5451_spdif_get(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
-	unsigned long flags;
 	ali_t *codec = kcontrol->private_data;
 	unsigned int enable;
 
 	enable = ucontrol->value.integer.value[0] ? 1 : 0;
 
-	spin_lock_irqsave(&codec->reg_lock, flags);
+	spin_lock_irq(&codec->reg_lock);
 	switch(kcontrol->private_value) {
 	case 0:
 		enable = (codec->spdif_mask & 0x02) ? 1 : 0;
@@ -1885,19 +1869,18 @@
 		break;
 	}
 	ucontrol->value.integer.value[0] = enable;
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
+	spin_unlock_irq(&codec->reg_lock);
 	return 0;
 }
 
 static int snd_ali5451_spdif_put(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
-	unsigned long flags;
 	ali_t *codec = kcontrol->private_data;
 	unsigned int change = 0, enable = 0;
 
 	enable = ucontrol->value.integer.value[0] ? 1 : 0;
 
-	spin_lock_irqsave(&codec->reg_lock, flags);
+	spin_lock_irq(&codec->reg_lock);
 	switch (kcontrol->private_value) {
 	case 0:
 		change = (codec->spdif_mask & 0x02) ? 1 : 0;
@@ -1942,7 +1925,7 @@
 	default:
 		break;
 	}
-	spin_unlock_irqrestore(&codec->reg_lock, flags);
+	spin_unlock_irq(&codec->reg_lock);
 	
 	return change;
 }

Re: Fix for slow snd-ali5451 initialization

[Vince Busam]

That works well, I see it's got a better version of the patch I posted in 
the beginning of this thread in it.

Thanks,
Vince

On Fri, 11 Nov 2005, Takashi Iwai wrote:

> At Wed, 9 Nov 2005 21:17:32 -0800 (PST),
> Vince Busam wrote:
>>
>> On Tue, 8 Nov 2005, Takashi Iwai wrote:
>>
>>> OK, then the problem is not that easy...
>>> We'll need to track down which call fails.
>>>
>>
>> What can I try?  I've noticed it happens when calling snd_ali_codec_peek()
>> with secondary=0 and reg=0x7e.  The first couple calls with those
>> paramaters succeed, then 4 fail.  Is there any good way to print a stack
>> trace when the call fails?
>
> Could you try the patch below, to sync our code base, before further
> looking?  It's for the latest ALSA CVS version (or 1.0.10rc3).
>
>
> Takashi
>

-- 
Vince Busam
vince@sixpak.org
http://sixpak.org/vince/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php