[ALSA - driver 0001138]: errors when installing au8820 modules

[ALSA - driver 0001138]: errors when installing au8820 modules

[bugtrack]

The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138> 
======================================================================
Reported By:                penguinparty
Assigned To:                mjander
======================================================================
Project:                    ALSA - driver
Issue ID:                   1138
Category:                   PCI - au88x0
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
Distribution:               ubuntu 5.04
Kernel Version:             2.6.11.11 2.6.11.8 and 2.6.10
======================================================================
Date Submitted:             05-28-2005 22:22 CEST
Last Modified:              05-28-2005 22:22 CEST
======================================================================
Summary:                    errors when installing au8820 modules
Description: 
Please see the section additional information for a dump of my dmesg output
regarding the au8820 module.

I have tried installing this module using 2.6.11.11 2.6.11.8 and 2.6.10
kernels. The shipping alsa support under each of these kerenls provies me
with the same result. I have also tried installing each of these kernels
without alsa support only CONFIG_SOUND and then installing the
alsa-drivers 1.0.9rc4a

I get the same result every time I do the modprobe snd-au8820

Using older versions of debian as well as the ubuntu live cd's I am able
to get this sound card working.
======================================================================

Issue History
Date Modified  Username       Field                    Change              
======================================================================
05-28-05 22:22 penguinparty   New Issue                                    
05-28-05 22:22 penguinparty   Distribution              => ubuntu 5.04     
05-28-05 22:22 penguinparty   Kernel Version            => 2.6.11.11 2.6.11.8
and 2.6.10
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

The au88x0 driver need patch to run on 64-bits platform.

http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948


bugtrack@alsa-project.org wrote:
> The following issue has been SUBMITTED.
> ======================================================================
> <https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138> 
> ======================================================================
> Reported By:                penguinparty
> Assigned To:                mjander
> ======================================================================
> Project:                    ALSA - driver
> Issue ID:                   1138
> Category:                   PCI - au88x0
> Reproducibility:            always
> Severity:                   crash
> Priority:                   normal
> Status:                     assigned
> Distribution:               ubuntu 5.04
> Kernel Version:             2.6.11.11 2.6.11.8 and 2.6.10
> ======================================================================
> Date Submitted:             05-28-2005 22:22 CEST
> Last Modified:              05-28-2005 22:22 CEST
> ======================================================================
> Summary:                    errors when installing au8820 modules
> Description: 
> Please see the section additional information for a dump of my dmesg output
> regarding the au8820 module.
> 
> I have tried installing this module using 2.6.11.11 2.6.11.8 and 2.6.10
> kernels. The shipping alsa support under each of these kerenls provies me
> with the same result. I have also tried installing each of these kernels
> without alsa support only CONFIG_SOUND and then installing the
> alsa-drivers 1.0.9rc4a
> 
> I get the same result every time I do the modprobe snd-au8820
> 
> Using older versions of debian as well as the ubuntu live cd's I am able
> to get this sound card working.
> ======================================================================
> 
> Issue History
> Date Modified  Username       Field                    Change              
> ======================================================================
> 05-28-05 22:22 penguinparty   New Issue                                    
> 05-28-05 22:22 penguinparty   Distribution              => ubuntu 5.04     
> 05-28-05 22:22 penguinparty   Kernel Version            => 2.6.11.11 2.6.11.8
> and 2.6.10
> ======================================================================
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Mon, 06 Jun 2005 10:09:26 +0800,
Raymond wrote:
> 
> The au88x0 driver need patch to run on 64-bits platform.
> 
> http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948

Could you feed the patch to alsa-devel ML for review?
(The addition of Signed-off-by would be preferred, too)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

The patch (diff11.diff) cause segmenation fault on my 32bit machine 
during /etc/init.d/alsasound start

http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948

Do anyone know why readl() and writel() behave different in i386 
(32bits) and AMD64 (64bits) ?

http://sourceforge.net/mailarchive/message.php?msg_id=10773530


#ifndef CONFIG_X86_64

#define        hwread(x,y) readl((x)+((y)>>2))
#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))

#else

#define        hwread(x,y) readl((x)+(y))
#define        hwwrite(x,y,z) writel((z),(x)+(y))

#endif


Takashi Iwai wrote:
> At Mon, 06 Jun 2005 10:09:26 +0800,
> Raymond wrote:
> 
>>The au88x0 driver need patch to run on 64-bits platform.
>>
>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> 
> 
> Could you feed the patch to alsa-devel ML for review?
> (The addition of Signed-off-by would be preferred, too)
> 
> 







-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op dinsdag 7 juni 2005 17:05, schreef Raymond:
> The patch (diff11.diff) cause segmenation fault on my 32bit machine
> during /etc/init.d/alsasound start
>
> http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>
> Do anyone know why readl() and writel() behave different in i386
> (32bits) and AMD64 (64bits) ?
>
> http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>
>
> #ifndef CONFIG_X86_64
>
> #define        hwread(x,y) readl((x)+((y)>>2))
> #define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>
> #else
>
> #define        hwread(x,y) readl((x)+(y))
> #define        hwwrite(x,y,z) writel((z),(x)+(y))
>
> #endif

that doesn't look good, unless the mmio is void* in 32bit and unsigned long* 
in x86_64...

'unsigned long* mmio' should be preferred and together with '#define        
hwread(x,y) readl((x)+(y))' , this works for both platforms

> Takashi Iwai wrote:
> > At Mon, 06 Jun 2005 10:09:26 +0800,
> >
> > Raymond wrote:
> >>The au88x0 driver need patch to run on 64-bits platform.
> >>
> >>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> >
> > Could you feed the patch to alsa-devel ML for review?
> > (The addition of Signed-off-by would be preferred, too)
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the office
> luge track? If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Tue, 7 Jun 2005 17:16:02 +0200,
Alien wrote:
> 
> [1  <text/plain; iso-8859-1 (quoted-printable)>]
> Op dinsdag 7 juni 2005 17:05, schreef Raymond:
> > The patch (diff11.diff) cause segmenation fault on my 32bit machine
> > during /etc/init.d/alsasound start
> >
> > http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> >
> > Do anyone know why readl() and writel() behave different in i386
> > (32bits) and AMD64 (64bits) ?
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=10773530
> >
> >
> > #ifndef CONFIG_X86_64
> >
> > #define        hwread(x,y) readl((x)+((y)>>2))
> > #define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
> >
> > #else
> >
> > #define        hwread(x,y) readl((x)+(y))
> > #define        hwwrite(x,y,z) writel((z),(x)+(y))
> >
> > #endif
> 
> that doesn't look good, unless the mmio is void* in 32bit and unsigned long* 
> in x86_64...
> 
> 'unsigned long* mmio' should be preferred and together with '#define        
> hwread(x,y) readl((x)+(y))' , this works for both platforms

I guess using "unsigned long" for both architectures is broken, too.
Should be "u32" to be arch-independent.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Takashi Iwai wrote:
> At Tue, 7 Jun 2005 17:16:02 +0200,
> Alien wrote:
> 
>>[1  <text/plain; iso-8859-1 (quoted-printable)>]
>>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
>>
>>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
>>>during /etc/init.d/alsasound start
>>>
>>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>>>
>>>Do anyone know why readl() and writel() behave different in i386
>>>(32bits) and AMD64 (64bits) ?
>>>
>>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>>>
>>>
>>>#ifndef CONFIG_X86_64
>>>
>>>#define        hwread(x,y) readl((x)+((y)>>2))
>>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>>
>>>#else
>>>
>>>#define        hwread(x,y) readl((x)+(y))
>>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
>>>
>>>#endif
>>
>>that doesn't look good, unless the mmio is void* in 32bit and unsigned long* 
>>in x86_64...
>>
>>'unsigned long* mmio' should be preferred and together with '#define        
>>hwread(x,y) readl((x)+(y))' , this works for both platforms
> 
> 
> I guess using "unsigned long" for both architectures is broken, too.
> Should be "u32" to be arch-independent.
> 

I strongly believe readl() and writel() on x86_64 does 32 bit reads/writes.
(checked linux-2.6.12-rc5). Therefore reads/writes are of correct size with
that patch - should be something different.

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op dinsdag 7 juni 2005 19:05, schreef Igor Kovalenko:
> Takashi Iwai wrote:
> > At Tue, 7 Jun 2005 17:16:02 +0200,
> >
> > Alien wrote:
> >>[1  <text/plain; iso-8859-1 (quoted-printable)>]
> >>
> >>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
> >>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
> >>>during /etc/init.d/alsasound start
> >>>
> >>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> >>>
> >>>Do anyone know why readl() and writel() behave different in i386
> >>>(32bits) and AMD64 (64bits) ?
> >>>
> >>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
> >>>
> >>>
> >>>#ifndef CONFIG_X86_64
> >>>
> >>>#define        hwread(x,y) readl((x)+((y)>>2))
> >>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
> >>>
> >>>#else
> >>>
> >>>#define        hwread(x,y) readl((x)+(y))
> >>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
> >>>
> >>>#endif
> >>
> >>that doesn't look good, unless the mmio is void* in 32bit and unsigned
> >> long* in x86_64...
> >>
> >>'unsigned long* mmio' should be preferred and together with '#define
> >>hwread(x,y) readl((x)+(y))' , this works for both platforms
> >
> > I guess using "unsigned long" for both architectures is broken, too.
> > Should be "u32" to be arch-independent.
>
> I strongly believe readl() and writel() on x86_64 does 32 bit reads/writes.
> (checked linux-2.6.12-rc5). Therefore reads/writes are of correct size with
> that patch - should be something different.

i know that does not work!

when i started doing this, i got segfaults because of the >>2 .

readl and writel do long operations as evidenced by the 'l'

i know this seems weird, but this is memory-mapped, and appearantly it's 
memory mapped to long, anyway; when i do 'unsigned long* mmio' and i use 
readl and writel without any bitshifts, it works...

you may believe what you want, but i _know_ that on x86_64, i _NEED_ unsigned 
long* mmio and no bitshifting to get this to work.

maybe the problem lies with writel and readl to begin with, maybe if you wrote 
an int, it would work...

AL13N

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Alien wrote:
> Op dinsdag 7 juni 2005 19:05, schreef Igor Kovalenko:
> 
>>Takashi Iwai wrote:
>>
>>>At Tue, 7 Jun 2005 17:16:02 +0200,
>>>
>>>Alien wrote:
>>>
>>>>[1  <text/plain; iso-8859-1 (quoted-printable)>]
>>>>
>>>>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
>>>>
>>>>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
>>>>>during /etc/init.d/alsasound start
>>>>>
>>>>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>>>>>
>>>>>Do anyone know why readl() and writel() behave different in i386
>>>>>(32bits) and AMD64 (64bits) ?
>>>>>
>>>>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>>>>>
>>>>>
>>>>>#ifndef CONFIG_X86_64
>>>>>
>>>>>#define        hwread(x,y) readl((x)+((y)>>2))
>>>>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>>>>
>>>>>#else
>>>>>
>>>>>#define        hwread(x,y) readl((x)+(y))
>>>>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
>>>>>
>>>>>#endif
>>>>
>>>>that doesn't look good, unless the mmio is void* in 32bit and unsigned
>>>>long* in x86_64...
>>>>
>>>>'unsigned long* mmio' should be preferred and together with '#define
>>>>hwread(x,y) readl((x)+(y))' , this works for both platforms
>>>
>>>I guess using "unsigned long" for both architectures is broken, too.
>>>Should be "u32" to be arch-independent.
>>
>>I strongly believe readl() and writel() on x86_64 does 32 bit reads/writes.
>>(checked linux-2.6.12-rc5). Therefore reads/writes are of correct size with
>>that patch - should be something different.
> 
> 
> i know that does not work!
> 
> when i started doing this, i got segfaults because of the >>2 .
> 
> readl and writel do long operations as evidenced by the 'l'
> 
> i know this seems weird, but this is memory-mapped, and appearantly it's 
> memory mapped to long, anyway; when i do 'unsigned long* mmio' and i use 
> readl and writel without any bitshifts, it works...
> 
> you may believe what you want, but i _know_ that on x86_64, i _NEED_ unsigned 
> long* mmio and no bitshifting to get this to work.
> 
> maybe the problem lies with writel and readl to begin with, maybe if you wrote 
> an int, it would work...
> 
> AL13N

OK, then let's put it this way: change to void* and removal of shifts is to make
address operations correct. That is the address itself is at the same offset on
all arches. Then readl/writel just do 32 bit read/write which is what we need.
May be it is the mapping is wrong?

Please check if you applied the patch correctly - I suspect you used different
kernel version and patch may have missed some points... BTW the segfault (oops)
report would be handy.

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

[-- Attachment #1.1: Type: text/plain, Size: 3627 bytes --]

Op dinsdag 7 juni 2005 19:38, schreef Igor Kovalenko:
> Alien wrote:
> > Op dinsdag 7 juni 2005 19:05, schreef Igor Kovalenko:
> >>Takashi Iwai wrote:
> >>>At Tue, 7 Jun 2005 17:16:02 +0200,
> >>>
> >>>Alien wrote:
> >>>>[1  <text/plain; iso-8859-1 (quoted-printable)>]
> >>>>
> >>>>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
> >>>>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
> >>>>>during /etc/init.d/alsasound start
> >>>>>
> >>>>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> >>>>>
> >>>>>Do anyone know why readl() and writel() behave different in i386
> >>>>>(32bits) and AMD64 (64bits) ?
> >>>>>
> >>>>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
> >>>>>
> >>>>>
> >>>>>#ifndef CONFIG_X86_64
> >>>>>
> >>>>>#define        hwread(x,y) readl((x)+((y)>>2))
> >>>>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
> >>>>>
> >>>>>#else
> >>>>>
> >>>>>#define        hwread(x,y) readl((x)+(y))
> >>>>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
> >>>>>
> >>>>>#endif
> >>>>
> >>>>that doesn't look good, unless the mmio is void* in 32bit and unsigned
> >>>>long* in x86_64...
> >>>>
> >>>>'unsigned long* mmio' should be preferred and together with '#define
> >>>>hwread(x,y) readl((x)+(y))' , this works for both platforms
> >>>
> >>>I guess using "unsigned long" for both architectures is broken, too.
> >>>Should be "u32" to be arch-independent.
> >>
> >>I strongly believe readl() and writel() on x86_64 does 32 bit
> >> reads/writes. (checked linux-2.6.12-rc5). Therefore reads/writes are of
> >> correct size with that patch - should be something different.
> >
> > i know that does not work!
> >
> > when i started doing this, i got segfaults because of the >>2 .
> >
> > readl and writel do long operations as evidenced by the 'l'
> >
> > i know this seems weird, but this is memory-mapped, and appearantly it's
> > memory mapped to long, anyway; when i do 'unsigned long* mmio' and i use
> > readl and writel without any bitshifts, it works...
> >
> > you may believe what you want, but i _know_ that on x86_64, i _NEED_
> > unsigned long* mmio and no bitshifting to get this to work.
> >
> > maybe the problem lies with writel and readl to begin with, maybe if you
> > wrote an int, it would work...
> >
> > AL13N
>
> OK, then let's put it this way: change to void* and removal of shifts is to
> make address operations correct. That is the address itself is at the same
> offset on all arches. Then readl/writel just do 32 bit read/write which is
> what we need. May be it is the mapping is wrong?

change to void* and removal of shifts will make it wrong on both systems, 
unless you modify all the parameters to make them use byte-offsets, will 
'allthough that would be weird' make it work _only_ on 32bit systems...

> Please check if you applied the patch correctly - I suspect you used
> different kernel version and patch may have missed some points... BTW the
> segfault (oops) report would be handy.

I never did apply the patch, i made a modification before the patch (which is 
available on the net somewhere, probably some mailing list) before the patch 
was out. the oops is also at the same place... but that all is several months 
ago. i'll make a patch to what i have now, it's more or less similar to the 
original patch.

hmm, I seem to have applied the patch after all, and made a little 
modifications...

this is a patch against some CVS version of a few weeks ago not more than 3 
weeks i think...

see if this works for you

[-- Attachment #1.2: au88x0_12.patch --]
[-- Type: text/x-diff, Size: 17425 bytes --]

Index: alsa-kernel/pci/au88x0/au88x0.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0.c,v
retrieving revision 1.18
diff -u -r1.18 au88x0.c
--- alsa-kernel/pci/au88x0/au88x0.c	11 Apr 2005 15:58:27 -0000	1.18
+++ alsa-kernel/pci/au88x0/au88x0.c	7 Jun 2005 17:56:35 -0000
@@ -144,15 +144,18 @@
 	// check PCI availability (DMA).
 	if ((err = pci_enable_device(pci)) < 0)
 		return err;
-	if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
+	if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
+		pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
 		printk(KERN_ERR "error to set DMA mask\n");
+		pci_disable_device(pci);
 		return -ENXIO;
 	}
-	pci_set_dma_mask(pci, VORTEX_DMA_MASK);
 
 	chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
-	if (chip == NULL)
+	if (chip == NULL) {
+		pci_disable_device(pci);
 		return -ENOMEM;
+	}
 
 	chip->card = card;
 
@@ -202,6 +205,10 @@
 		goto alloc_out;
 	}
 
+	snd_card_set_dev(card, &pci->dev);
+
+	snd_card_set_dev(card, &pci->dev);
+
 	*rchip = chip;
 
 	return 0;
Index: alsa-kernel/pci/au88x0/au88x0.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0.h,v
retrieving revision 1.11
diff -u -r1.11 au88x0.h
--- alsa-kernel/pci/au88x0/au88x0.h	22 Mar 2005 08:50:55 -0000	1.11
+++ alsa-kernel/pci/au88x0/au88x0.h	7 Jun 2005 17:56:35 -0000
@@ -41,8 +41,8 @@
 
 #define	VORTEX_DMA_MASK	0xffffffff
 
-#define	hwread(x,y) readl((x)+((y)>>2))
-#define	hwwrite(x,y,z) writel((z),(x)+((y)>>2))
+#define	hwread(x,y) readl((x)+(y))
+#define	hwwrite(x,y,z) writel((z),(x)+(y))
 
 /* Vortex MPU401 defines. */
 #define	MIDI_CLOCK_DIV		0x61
@@ -107,7 +107,7 @@
 	//int this_08;          /* Still unknown */
 	int fifo_enabled;	/* this_24 */
 	int fifo_status;	/* this_1c */
-	int dma_ctrl;		/* this_78 (ADB), this_7c (WT) */
+	u32 dma_ctrl;		/* this_78 (ADB), this_7c (WT) */
 	int dma_unknown;	/* this_74 (ADB), this_78 (WT). WDM: +8 */
 	int cfg0;
 	int cfg1;
@@ -172,7 +172,7 @@
 
 	/* PCI hardware resources */
 	unsigned long io;
-	unsigned long __iomem *mmio;
+	void __iomem *mmio;
 	unsigned int irq;
 	spinlock_t lock;
 
@@ -195,14 +195,14 @@
 				     int count);
 static void vortex_adbdma_setmode(vortex_t * vortex, int adbdma, int ie,
 				  int dir, int fmt, int d,
-				  unsigned long offset);
+				  u32 offset);
 static void vortex_adbdma_setstartbuffer(vortex_t * vortex, int adbdma, int sb);
 #ifndef CHIP_AU8810
 static void vortex_wtdma_setbuffers(vortex_t * vortex, int wtdma,
 				    snd_pcm_sgbuf_t * sgbuf, int size,
 				    int count);
 static void vortex_wtdma_setmode(vortex_t * vortex, int wtdma, int ie, int fmt, int d,	/*int e, */
-				 unsigned long offset);
+				 u32 offset);
 static void vortex_wtdma_setstartbuffer(vortex_t * vortex, int wtdma, int sb);
 #endif
 
Index: alsa-kernel/pci/au88x0/au88x0_core.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_core.c,v
retrieving revision 1.11
diff -u -r1.11 au88x0_core.c
--- alsa-kernel/pci/au88x0/au88x0_core.c	23 Feb 2005 11:00:31 -0000	1.11
+++ alsa-kernel/pci/au88x0/au88x0_core.c	7 Jun 2005 17:56:37 -0000
@@ -376,7 +376,7 @@
 
 static void vortex_mixer_init(vortex_t * vortex)
 {
-	unsigned long addr;
+	u32 addr;
 	int x;
 
 	// FIXME: get rid of this crap.
@@ -639,7 +639,7 @@
 
 static void vortex_srcblock_init(vortex_t * vortex)
 {
-	unsigned long addr;
+	u32 addr;
 	int x;
 	hwwrite(vortex->mmio, VORTEX_SRC_SOURCESIZE, 0x1ff);
 	/*
@@ -1035,7 +1035,7 @@
 static void vortex_fifo_init(vortex_t * vortex)
 {
 	int x;
-	unsigned long addr;
+	u32 addr;
 
 	/* ADB DMA channels fifos. */
 	addr = VORTEX_FIFO_ADBCTRL + ((NR_ADB - 1) * 4);
@@ -1054,7 +1054,7 @@
 		hwwrite(vortex->mmio, addr, FIFO_U0);
 		if (hwread(vortex->mmio, addr) != FIFO_U0)
 			printk(KERN_ERR
-			       "bad wt fifo reset (0x%08lx, 0x%08x)!\n",
+			       "bad wt fifo reset (0x%08x, 0x%08x)!\n",
 			       addr, hwread(vortex->mmio, addr));
 		vortex_fifo_clearwtdata(vortex, x, FIFO_SIZE);
 		addr -= 4;
@@ -1152,7 +1152,7 @@
 
 static void
 vortex_adbdma_setmode(vortex_t * vortex, int adbdma, int ie, int dir,
-		      int fmt, int d, unsigned long offset)
+		      int fmt, int d, u32 offset)
 {
 	stream_t *dma = &vortex->dma_adb[adbdma];
 
@@ -1411,7 +1411,7 @@
 
 static void
 vortex_wtdma_setmode(vortex_t * vortex, int wtdma, int ie, int fmt, int d,
-		     /*int e, */ unsigned long offset)
+		     /*int e, */ u32 offset)
 {
 	stream_t *dma = &vortex->dma_wt[wtdma];
 
Index: alsa-kernel/pci/au88x0/au88x0_eq.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eq.c,v
retrieving revision 1.8
diff -u -r1.8 au88x0_eq.c
--- alsa-kernel/pci/au88x0/au88x0_eq.c	27 Oct 2004 07:31:16 -0000	1.8
+++ alsa-kernel/pci/au88x0/au88x0_eq.c	7 Jun 2005 17:56:37 -0000
@@ -377,23 +377,23 @@
 
 #endif
 /* Global Control */
-static void vortex_EqHw_SetControlReg(vortex_t * vortex, unsigned long reg)
+static void vortex_EqHw_SetControlReg(vortex_t * vortex, u32 reg)
 {
 	hwwrite(vortex->mmio, 0x2b440, reg);
 }
 
-static void vortex_EqHw_SetSampleRate(vortex_t * vortex, int sr)
+static void vortex_EqHw_SetSampleRate(vortex_t * vortex, u32 sr)
 {
 	hwwrite(vortex->mmio, 0x2b440, ((sr & 0x1f) << 3) | 0xb800);
 }
 
 #if 0
-static void vortex_EqHw_GetControlReg(vortex_t * vortex, unsigned long *reg)
+static void vortex_EqHw_GetControlReg(vortex_t * vortex, u32 *reg)
 {
 	*reg = hwread(vortex->mmio, 0x2b440);
 }
 
-static void vortex_EqHw_GetSampleRate(vortex_t * vortex, int *sr)
+static void vortex_EqHw_GetSampleRate(vortex_t * vortex, u32 *sr)
 {
 	*sr = (hwread(vortex->mmio, 0x2b440) >> 3) & 0x1f;
 }
@@ -554,7 +554,7 @@
 
 #if 0
 static int
-vortex_Eqlzr_GetAllBands(vortex_t * vortex, u16 * gains, unsigned long *cnt)
+vortex_Eqlzr_GetAllBands(vortex_t * vortex, u16 * gains, s32 *cnt)
 {
 	eqlzr_t *eq = &(vortex->eq);
 	int si = 0;
@@ -586,7 +586,7 @@
 }
 
 static int
-vortex_Eqlzr_SetAllBands(vortex_t * vortex, u16 gains[], unsigned long count)
+vortex_Eqlzr_SetAllBands(vortex_t * vortex, u16 gains[], s32 count)
 {
 	eqlzr_t *eq = &(vortex->eq);
 	int i;
@@ -604,11 +604,10 @@
 }
 
 static void
-vortex_Eqlzr_SetA3dBypassGain(vortex_t * vortex, unsigned long a,
-			      unsigned long b)
+vortex_Eqlzr_SetA3dBypassGain(vortex_t * vortex, u32 a, u32 b)
 {
 	eqlzr_t *eq = &(vortex->eq);
-	int eax, ebx;
+	u32 eax, ebx;
 
 	eq->this58 = a;
 	eq->this5c = b;
@@ -624,7 +623,7 @@
 static void vortex_Eqlzr_ProgramA3dBypassGain(vortex_t * vortex)
 {
 	eqlzr_t *eq = &(vortex->eq);
-	int eax, ebx;
+	u32 eax, ebx;
 
 	if (eq->this54)
 		eax = eq->this0e;
@@ -641,7 +640,7 @@
 		vortex_EqHw_ZeroA3DIO(vortex);
 }
 
-static void vortex_Eqlzr_SetBypass(vortex_t * vortex, long bp)
+static void vortex_Eqlzr_SetBypass(vortex_t * vortex, u32 bp)
 {
 	eqlzr_t *eq = &(vortex->eq);
 	
@@ -651,8 +650,8 @@
 		vortex_EqHw_SetBypassGain(vortex, eq->this08, eq->this08);
 	} else {
 		/* EQ disabled. */
-		vortex_EqHw_SetLeftGainsTarget(vortex, (u16 *) (eq->this14));
-		vortex_EqHw_SetRightGainsTarget(vortex, (u16 *) (eq->this14));
+		vortex_EqHw_SetLeftGainsTarget(vortex, eq->this14_array);
+		vortex_EqHw_SetRightGainsTarget(vortex, eq->this14_array);
 		vortex_EqHw_SetBypassGain(vortex, eq->this0c, eq->this0c);
 	}
 	vortex_Eqlzr_ProgramA3dBypassGain(vortex);
@@ -706,7 +705,7 @@
 	eq->this5c = 0xffff;
 
 	/* Set gains. */
-	memset(eq->this14, 0, 2 * 10);
+	memset(eq->this14_array, 0, sizeof(eq->this14_array));
 
 	/* Actual init. */
 	vortex_EqHw_ZeroState(vortex);
Index: alsa-kernel/pci/au88x0/au88x0_eq.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eq.h,v
retrieving revision 1.1
diff -u -r1.1 au88x0_eq.h
--- alsa-kernel/pci/au88x0/au88x0_eq.h	9 Mar 2004 11:52:13 -0000	1.1
+++ alsa-kernel/pci/au88x0/au88x0_eq.h	7 Jun 2005 17:56:37 -0000
@@ -18,26 +18,26 @@
 } auxxEqCoeffSet_t;
 
 typedef struct {
-	unsigned int *this00;	/*CAsp4HwIO */
-	long this04;		/* How many filters for each side (default = 10) */
-	long this08;		/* inited to cero. Stereo flag? */
+	u32 ptr_this00;		/*CAsp4HwIO */
+	s32 this04;		/* How many filters for each side (default = 10) */
+	s32 this08;		/* inited to cero. Stereo flag? */
 } eqhw_t;
 
 typedef struct {
-	unsigned int *this00;	/*CAsp4Core */
+	u32  ptr_this00;	/*CAsp4Core */
 	eqhw_t this04;		/* CHwEq */
-	short this08;		/* Bad codec flag ? SetBypassGain: bypass gain */
-	short this0a;
-	short this0c;		/* SetBypassGain: bypass gain when this28 is not set. */
-	short this0e;
+	u16 this08;		/* Bad codec flag ? SetBypassGain: bypass gain */
+	u16 this0a;
+	u16 this0c;		/* SetBypassGain: bypass gain when this28 is not set. */
+	u16 this0e;
 
-	long this10;		/* How many gains are used for each side (right or left). */
-	u16 this14[32];		/* SetLeftGainsTarget: Left (and right?) EQ gains  */
-	long this24;
-	long this28;		/* flag related to EQ enabled or not. Gang flag ? */
-	long this54;		/* SetBypass */
-	long this58;
-	long this5c;
+	s32 this10;		/* How many gains are used for each side (right or left). */
+	u16 this14_array[32];	/* SetLeftGainsTarget: Left (and right?) EQ gains  */
+	s32 this24;
+	s32 this28;		/* flag related to EQ enabled or not. Gang flag ? */
+	s32 this54;		/* SetBypass */
+	s32 this58;
+	s32 this5c;
 	/*0x60 */ auxxEqCoeffSet_t coefset;
 	/* 50 u16 word each channel. */
 	u16 this130[20];	/* Left and Right gains */
Index: alsa-kernel/pci/au88x0/au88x0_eqdata.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eqdata.c,v
retrieving revision 1.1
diff -u -r1.1 au88x0_eqdata.c
--- alsa-kernel/pci/au88x0/au88x0_eqdata.c	9 Mar 2004 11:52:13 -0000	1.1
+++ alsa-kernel/pci/au88x0/au88x0_eqdata.c	7 Jun 2005 17:56:37 -0000
@@ -104,7 +104,11 @@
 };
 
 /*_rodataba0:*/
-static long eq_levels[32] = {
+static u16 eq_levels[64] = {
+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
Index: alsa-kernel/pci/au88x0/au88x0_mpu401.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_mpu401.c,v
retrieving revision 1.2
diff -u -r1.2 au88x0_mpu401.c
--- alsa-kernel/pci/au88x0/au88x0_mpu401.c	29 Jun 2004 16:10:32 -0000	1.2
+++ alsa-kernel/pci/au88x0/au88x0_mpu401.c	7 Jun 2005 17:56:37 -0000
@@ -95,7 +95,7 @@
 		return temp;
 	}
 #else
-	port = (unsigned long)(vortex->mmio + (VORTEX_MIDI_DATA >> 2));
+	port = (unsigned long)(vortex->mmio + VORTEX_MIDI_DATA);
 	if ((temp =
 	     snd_mpu401_uart_new(vortex->card, 0, MPU401_HW_AUREAL, port,
 				 1, 0, 0, &rmidi)) != 0) {
@@ -105,7 +105,7 @@
 		return temp;
 	}
 	mpu = rmidi->private_data;
-	mpu->cport = (unsigned long)(vortex->mmio + (VORTEX_MIDI_CMD >> 2));
+	mpu->cport = (unsigned long)(vortex->mmio + VORTEX_MIDI_CMD);
 #endif
 	vortex->rmidi = rmidi;
 	return 0;
Index: alsa-kernel/pci/au88x0/au88x0_synth.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_synth.c,v
retrieving revision 1.3
diff -u -r1.3 au88x0_synth.c
--- alsa-kernel/pci/au88x0/au88x0_synth.c	24 Apr 2004 14:57:33 -0000	1.3
+++ alsa-kernel/pci/au88x0/au88x0_synth.c	7 Jun 2005 17:56:37 -0000
@@ -32,7 +32,7 @@
 					unsigned char mix, int a);
 static void vortex_fifo_wtinitialize(vortex_t * vortex, int fifo, int j);
 static int vortex_wt_SetReg(vortex_t * vortex, unsigned char reg, int wt,
-			    unsigned long val);
+			    u32 val);
 
 /* WT */
 
@@ -166,7 +166,7 @@
 /* WT hardware abstraction layer generic register interface. */
 static int
 vortex_wt_SetReg2(vortex_t * vortex, unsigned char reg, int wt,
-		  unsigned short val)
+		  u16 val)
 {
 	/*
 	   int eax, edx;
@@ -190,7 +190,7 @@
 #endif
 static int
 vortex_wt_SetReg(vortex_t * vortex, unsigned char reg, int wt,
-		 unsigned long val)
+		 u32 val)
 {
 	int ecx;
 
@@ -279,7 +279,7 @@
 
 static void vortex_wt_init(vortex_t * vortex)
 {
-	int var4, var8, varc, var10 = 0, edi;
+	u32 var4, var8, varc, var10 = 0, edi;
 
 	var10 &= 0xFFFFFFE3;
 	var10 |= 0x22;
@@ -353,7 +353,7 @@
 static void vortex_wt_SetFrequency(vortex_t * vortex, int wt, unsigned int sr)
 {
 	wt_voice_t *voice = &(vortex->wt_voice[wt]);
-	long int eax, edx;
+	u32 eax, edx;
 
 	//FIXME: 64 bit operation.
 	eax = ((sr << 0xf) * 0x57619F1) & 0xffffffff;
Index: alsa-kernel/pci/au88x0/au88x0_wt.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_wt.h,v
retrieving revision 1.1
diff -u -r1.1 au88x0_wt.h
--- alsa-kernel/pci/au88x0/au88x0_wt.h	9 Mar 2004 11:52:13 -0000	1.1
+++ alsa-kernel/pci/au88x0/au88x0_wt.h	7 Jun 2005 17:56:37 -0000
@@ -53,11 +53,11 @@
 #endif
 
 typedef struct {
-	unsigned int parm0;	/* this_1E4 */
-	unsigned int parm1;	/* this_1E8 */
-	unsigned int parm2;	/* this_1EC */
-	unsigned int parm3;	/* this_1F0 */
-	unsigned int this_1D0;
+	u32 parm0;	/* this_1E4 */
+	u32 parm1;	/* this_1E8 */
+	u32 parm2;	/* this_1EC */
+	u32 parm3;	/* this_1F0 */
+	u32 this_1D0;
 } wt_voice_t;
 
 #endif				/* _AU88X0_WT_H */
Index: alsa-kernel/pci/au88x0/au88x0_xtalk.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_xtalk.c,v
retrieving revision 1.3
diff -u -r1.3 au88x0_xtalk.c
--- alsa-kernel/pci/au88x0/au88x0_xtalk.c	6 Aug 2004 09:44:58 -0000	1.3
+++ alsa-kernel/pci/au88x0/au88x0_xtalk.c	7 Jun 2005 17:56:38 -0000
@@ -562,7 +562,7 @@
 vortex_XtalkHw_SetDelay(vortex_t * vortex, unsigned short right,
 			unsigned short left)
 {
-	int esp0 = 0;
+	u32 esp0 = 0;
 
 	esp0 &= 0x1FFFFFFF;
 	esp0 |= 0xA0000000;
@@ -632,18 +632,18 @@
 /* Control/Global stuff */
 
 #if 0
-static void vortex_XtalkHw_SetControlReg(vortex_t * vortex, unsigned long ctrl)
+static void vortex_XtalkHw_SetControlReg(vortex_t * vortex, u32 ctrl)
 {
 	hwwrite(vortex->mmio, 0x24660, ctrl);
 }
-static void vortex_XtalkHw_GetControlReg(vortex_t * vortex, unsigned long *ctrl)
+static void vortex_XtalkHw_GetControlReg(vortex_t * vortex, u32 *ctrl)
 {
 	*ctrl = hwread(vortex->mmio, 0x24660);
 }
 #endif
-static void vortex_XtalkHw_SetSampleRate(vortex_t * vortex, int sr)
+static void vortex_XtalkHw_SetSampleRate(vortex_t * vortex, u32 sr)
 {
-	int temp;
+	u32 temp;
 
 	temp = (hwread(vortex->mmio, 0x24660) & 0x1FFFFFFF) | 0xC0000000;
 	temp = (temp & 0xffffff07) | ((sr & 0x1f) << 3);
@@ -651,7 +651,7 @@
 }
 
 #if 0
-static void vortex_XtalkHw_GetSampleRate(vortex_t * vortex, int *sr)
+static void vortex_XtalkHw_GetSampleRate(vortex_t * vortex, u32 *sr)
 {
 	*sr = (hwread(vortex->mmio, 0x24660) >> 3) & 0x1f;
 }
@@ -659,7 +659,7 @@
 #endif
 static void vortex_XtalkHw_Enable(vortex_t * vortex)
 {
-	int temp;
+	u32 temp;
 
 	temp = (hwread(vortex->mmio, 0x24660) & 0x1FFFFFFF) | 0xC0000000;
 	temp |= 1;
@@ -669,7 +669,7 @@
 
 static void vortex_XtalkHw_Disable(vortex_t * vortex)
 {
-	int temp;
+	u32 temp;
 
 	temp = (hwread(vortex->mmio, 0x24660) & 0x1FFFFFFF) | 0xC0000000;
 	temp &= 0xfffffffe;
Index: alsa-kernel/pci/au88x0/au88x0_xtalk.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_xtalk.h,v
retrieving revision 1.3
diff -u -r1.3 au88x0_xtalk.h
--- alsa-kernel/pci/au88x0/au88x0_xtalk.h	6 Aug 2004 09:44:58 -0000	1.3
+++ alsa-kernel/pci/au88x0/au88x0_xtalk.h	7 Jun 2005 17:56:38 -0000
@@ -39,16 +39,16 @@
 #define XT_SPEAKER1		3
 #define XT_DIAMOND		4
 
-typedef long xtalk_dline_t[XTDLINE_SZ];
-typedef short xtalk_gains_t[XTGAINS_SZ];
-typedef short xtalk_instate_t[XTINST_SZ];
-typedef short xtalk_coefs_t[5][5];
-typedef short xtalk_state_t[5][4];
+typedef u32 xtalk_dline_t[XTDLINE_SZ];
+typedef u16 xtalk_gains_t[XTGAINS_SZ];
+typedef u16 xtalk_instate_t[XTINST_SZ];
+typedef u16 xtalk_coefs_t[5][5];
+typedef u16 xtalk_state_t[5][4];
 
 static void vortex_XtalkHw_SetGains(vortex_t * vortex,
 				    xtalk_gains_t const gains);
 static void vortex_XtalkHw_SetGainsAllChan(vortex_t * vortex);
-static void vortex_XtalkHw_SetSampleRate(vortex_t * vortex, int sr);
+static void vortex_XtalkHw_SetSampleRate(vortex_t * vortex, u32 sr);
 static void vortex_XtalkHw_ProgramPipe(vortex_t * vortex);
 static void vortex_XtalkHw_ProgramPipe(vortex_t * vortex);
 static void vortex_XtalkHw_ProgramXtalkWide(vortex_t * vortex);

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Tue, 7 Jun 2005 20:02:47 +0200,
Alien wrote:
> 
> this is a patch against some CVS version of a few weeks ago not more than 3 
> weeks i think...

The patch looks almost fine to me.
Just subtle things:

> @@ -202,6 +205,10 @@
>  		goto alloc_out;
>  	}
>  
> +	snd_card_set_dev(card, &pci->dev);
> +
> +	snd_card_set_dev(card, &pci->dev);
> +
>  	*rchip = chip;

Too much :)


> Index: alsa-kernel/pci/au88x0/au88x0_eqdata.c
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eqdata.c,v
> retrieving revision 1.1
> diff -u -r1.1 au88x0_eqdata.c
> --- alsa-kernel/pci/au88x0/au88x0_eqdata.c	9 Mar 2004 11:52:13 -0000	1.1
> +++ alsa-kernel/pci/au88x0/au88x0_eqdata.c	7 Jun 2005 17:56:37 -0000
> @@ -104,7 +104,11 @@
>  };
>  
>  /*_rodataba0:*/
> -static long eq_levels[32] = {
> +static u16 eq_levels[64] = {
> +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,

You don't need to define values if the static array is initialize to
zero.  In this case,

	static u16 eq_levels[64];

would be better.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op woensdag 8 juni 2005 12:18, schreef Takashi Iwai:
> At Tue, 7 Jun 2005 20:02:47 +0200,
>
> Alien wrote:
> > this is a patch against some CVS version of a few weeks ago not more than
> > 3 weeks i think...
>
> The patch looks almost fine to me.
>
> Just subtle things:
> > @@ -202,6 +205,10 @@
> >  		goto alloc_out;
> >  	}
> >
> > +	snd_card_set_dev(card, &pci->dev);
> > +
> > +	snd_card_set_dev(card, &pci->dev);
> > +
> >  	*rchip = chip;
>
> Too much :)
>
> > Index: alsa-kernel/pci/au88x0/au88x0_eqdata.c
> > ===================================================================
> > RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eqdata.c,v
> > retrieving revision 1.1
> > diff -u -r1.1 au88x0_eqdata.c
> > --- alsa-kernel/pci/au88x0/au88x0_eqdata.c	9 Mar 2004 11:52:13 -0000	1.1
> > +++ alsa-kernel/pci/au88x0/au88x0_eqdata.c	7 Jun 2005 17:56:37 -0000
> > @@ -104,7 +104,11 @@
> >  };
> >
> >  /*_rodataba0:*/
> > -static long eq_levels[32] = {
> > +static u16 eq_levels[64] = {
> > +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> > +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> > +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> > +	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> >  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> >  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> >  	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>
> You don't need to define values if the static array is initialize to
> zero.  In this case,
>
> 	static u16 eq_levels[64];
>
> would be better.
>
>
> Takashi

you sure that this will initialize to 0 ? i seem to remember that C doesn't 
init arrays to 0... unless there's a memset somewhere, of course, i never 
wrote kernel stuff...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Wed, 8 Jun 2005 13:13:46 +0200,
Alien wrote:
> 
> >
> > You don't need to define values if the static array is initialize to
> > zero.  In this case,
> >
> > 	static u16 eq_levels[64];
> >
> > would be better.
> >
> >
> > Takashi
> 
> you sure that this will initialize to 0 ? i seem to remember that C doesn't 
> init arrays to 0... unless there's a memset somewhere, of course, i never 
> wrote kernel stuff...

It's sure.  Remeber that I mentioned "static" arrray.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op woensdag 8 juni 2005 14:12, schreef Takashi Iwai:
> At Wed, 8 Jun 2005 13:13:46 +0200,
>
> Alien wrote:
> > > You don't need to define values if the static array is initialize to
> > > zero.  In this case,
> > >
> > > 	static u16 eq_levels[64];
> > >
> > > would be better.
> > >
> > >
> > > Takashi
> >
> > you sure that this will initialize to 0 ? i seem to remember that C
> > doesn't init arrays to 0... unless there's a memset somewhere, of course,
> > i never wrote kernel stuff...
>
> It's sure.  Remeber that I mentioned "static" arrray.
>
>
> Takashi

hmm, i never knew static arrays were initialized to 0...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Wed, 8 Jun 2005 15:29:50 +0200,
Alien wrote:
> 
> Op woensdag 8 juni 2005 14:12, schreef Takashi Iwai:
> > At Wed, 8 Jun 2005 13:13:46 +0200,
> >
> > Alien wrote:
> > > > You don't need to define values if the static array is initialize to
> > > > zero.  In this case,
> > > >
> > > > 	static u16 eq_levels[64];
> > > >
> > > > would be better.
> > > >
> > > >
> > > > Takashi
> > >
> > > you sure that this will initialize to 0 ? i seem to remember that C
> > > doesn't init arrays to 0... unless there's a memset somewhere, of course,
> > > i never wrote kernel stuff...
> >
> > It's sure.  Remeber that I mentioned "static" arrray.
> >
> >
> > Takashi
> 
> hmm, i never knew static arrays were initialized to 0...

Always good to learn something new ;)

In practice, kernel hackers prefers to get rid of unnecessary zero
initialization from the kernel code since it reduces the resultant
binary size, too.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Takashi Iwai wrote:
> At Wed, 8 Jun 2005 15:29:50 +0200,
> Alien wrote:
> 
>>Op woensdag 8 juni 2005 14:12, schreef Takashi Iwai:
>>
>>>At Wed, 8 Jun 2005 13:13:46 +0200,
>>>
>>>Alien wrote:
>>>
>>>>>You don't need to define values if the static array is initialize to
>>>>>zero.  In this case,
>>>>>
>>>>>	static u16 eq_levels[64];
>>>>>
>>>>>would be better.
>>>>>
>>>>>
>>>>>Takashi
>>>>
>>>>you sure that this will initialize to 0 ? i seem to remember that C
>>>>doesn't init arrays to 0... unless there's a memset somewhere, of course,
>>>>i never wrote kernel stuff...
>>>
>>>It's sure.  Remeber that I mentioned "static" arrray.
>>>
>>>
>>>Takashi
>>
>>hmm, i never knew static arrays were initialized to 0...
> 
> 
> Always good to learn something new ;)
> 
> In practice, kernel hackers prefers to get rid of unnecessary zero
> initialization from the kernel code since it reduces the resultant
> binary size, too.
> 
> 
> Takashi
> 
> 
Actualy this is the result of kernel loader - it maps zeroed pages for static data section.

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

typedef struct {
	unsigned int *this00;	/*CAsp4HwIO */
	long this04;		/* How many filters for each side (default = 10) */
	long this08;		/* inited to cero. Stereo flag? */
} eqhw_t;

static void vortex_EqHw_SetLevels(vortex_t * vortex, u16 peaks[])
{
	eqhw_t *eqhw = &(vortex->eq.this04);
	int i;

	/* set left peaks */
	for (i = 0; i < eqhw->this04; i++) {
		hwwrite(vortex->mmio, 0x2b024 + i * VORTEX_BAND_COEFF_SIZE, peaks[i]);
	}

	hwwrite(vortex->mmio, 0x2b3cc, peaks[eqhw->this04]);
	hwwrite(vortex->mmio, 0x2b3d8, peaks[eqhw->this04 + 1]);

	/* set right peaks */
	for (i = 0; i < eqhw->this04; i++) {
		hwwrite(vortex->mmio, 0x2b204 + i * VORTEX_BAND_COEFF_SIZE,
			peaks[i + (eqhw->this04 + 2)]);
	}

	hwwrite(vortex->mmio, 0x2b3e4, peaks[2 + (eqhw->this04 * 2)]);
	hwwrite(vortex->mmio, 0x2b3f0, peaks[3 + (eqhw->this04 * 2)]);
}


	vortex_EqHw_SetLevels(vortex, (u16 *) eq_levels);




What is the reason to increase the size of the array eq_levels from 32 
to 64 ?  ( eqhw->this04 seem to be 10 )


Takashi Iwai wrote:

> 
> 
>>Index: alsa-kernel/pci/au88x0/au88x0_eqdata.c
>>===================================================================
>>RCS file: /cvsroot/alsa/alsa-kernel/pci/au88x0/au88x0_eqdata.c,v
>>retrieving revision 1.1
>>diff -u -r1.1 au88x0_eqdata.c
>>--- alsa-kernel/pci/au88x0/au88x0_eqdata.c	9 Mar 2004 11:52:13 -0000	1.1
>>+++ alsa-kernel/pci/au88x0/au88x0_eqdata.c	7 Jun 2005 17:56:37 -0000
>>@@ -104,7 +104,11 @@
>> };
>> 
>> /*_rodataba0:*/
>>-static long eq_levels[32] = {
>>+static u16 eq_levels[64] = {
>>+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>>+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>>+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>>+	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>> 	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> 
> 
> You don't need to define values if the static array is initialize to
> zero.  In this case,
> 
> 	static u16 eq_levels[64];
> 
> would be better.
> 



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Wed, 08 Jun 2005 19:40:38 +0800,
Raymond wrote:
> 
> 
> typedef struct {
> 	unsigned int *this00;	/*CAsp4HwIO */
> 	long this04;		/* How many filters for each side (default = 10) */
> 	long this08;		/* inited to cero. Stereo flag? */
> } eqhw_t;
> 
> static void vortex_EqHw_SetLevels(vortex_t * vortex, u16 peaks[])
> {
> 	eqhw_t *eqhw = &(vortex->eq.this04);
> 	int i;
> 
> 	/* set left peaks */
> 	for (i = 0; i < eqhw->this04; i++) {
> 		hwwrite(vortex->mmio, 0x2b024 + i * VORTEX_BAND_COEFF_SIZE, peaks[i]);
> 	}
> 
> 	hwwrite(vortex->mmio, 0x2b3cc, peaks[eqhw->this04]);
> 	hwwrite(vortex->mmio, 0x2b3d8, peaks[eqhw->this04 + 1]);
> 
> 	/* set right peaks */
> 	for (i = 0; i < eqhw->this04; i++) {
> 		hwwrite(vortex->mmio, 0x2b204 + i * VORTEX_BAND_COEFF_SIZE,
> 			peaks[i + (eqhw->this04 + 2)]);
> 	}
> 
> 	hwwrite(vortex->mmio, 0x2b3e4, peaks[2 + (eqhw->this04 * 2)]);
> 	hwwrite(vortex->mmio, 0x2b3f0, peaks[3 + (eqhw->this04 * 2)]);
> }
> 
> 
> 	vortex_EqHw_SetLevels(vortex, (u16 *) eq_levels);
> 
> 
> 
> 
> What is the reason to increase the size of the array eq_levels from 32 
> to 64 ?  ( eqhw->this04 seem to be 10 )

I guess he wants to keep the total array size just to be sure.
But it seems not necessary.
(Oh, and the cast above is evil.  Let's remove it.)

Above all, any chance to rename the mysterious this* fields to more
understandable ones?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Takashi Iwai wrote:
> At Wed, 08 Jun 2005 19:40:38 +0800,
> Raymond wrote:
> 
>>
>>typedef struct {
>>	unsigned int *this00;	/*CAsp4HwIO */
>>	long this04;		/* How many filters for each side (default = 10) */
>>	long this08;		/* inited to cero. Stereo flag? */
>>} eqhw_t;
>>
>>static void vortex_EqHw_SetLevels(vortex_t * vortex, u16 peaks[])
>>{
>>	eqhw_t *eqhw = &(vortex->eq.this04);
>>	int i;
>>
>>	/* set left peaks */
>>	for (i = 0; i < eqhw->this04; i++) {
>>		hwwrite(vortex->mmio, 0x2b024 + i * VORTEX_BAND_COEFF_SIZE, peaks[i]);
>>	}
>>
>>	hwwrite(vortex->mmio, 0x2b3cc, peaks[eqhw->this04]);
>>	hwwrite(vortex->mmio, 0x2b3d8, peaks[eqhw->this04 + 1]);
>>
>>	/* set right peaks */
>>	for (i = 0; i < eqhw->this04; i++) {
>>		hwwrite(vortex->mmio, 0x2b204 + i * VORTEX_BAND_COEFF_SIZE,
>>			peaks[i + (eqhw->this04 + 2)]);
>>	}
>>
>>	hwwrite(vortex->mmio, 0x2b3e4, peaks[2 + (eqhw->this04 * 2)]);
>>	hwwrite(vortex->mmio, 0x2b3f0, peaks[3 + (eqhw->this04 * 2)]);
>>}
>>
>>
>>	vortex_EqHw_SetLevels(vortex, (u16 *) eq_levels);
>>
>>
>>
>>
>>What is the reason to increase the size of the array eq_levels from 32 
>>to 64 ?  ( eqhw->this04 seem to be 10 )
> 
> 
> I guess he wants to keep the total array size just to be sure.
> But it seems not necessary.

Exactly for that purpose. I do not know if other (au8810 or au8830) use more
than au8820 in that array.

> (Oh, and the cast above is evil.  Let's remove it.)
> 
> Above all, any chance to rename the mysterious this* fields to more
> understandable ones?
> 
I believe original author can tell us more :) Actually that this04 seems to
be not needed at all (I preferred to keep all struct sizes the same in 64bit
to not bother with hardware formats etc.)

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Igor Kovalenko wrote:
> Takashi Iwai wrote:
> 
>>Raymond wrote:
>>
>>
>>>typedef struct {
>>>	unsigned int *this00;	/*CAsp4HwIO */
>>>	long this04;		/* How many filters for each side (default = 10) */
>>>	long this08;		/* inited to cero. Stereo flag? */
>>>} eqhw_t;
>>>
>>>static void vortex_EqHw_SetLevels(vortex_t * vortex, u16 peaks[])
>>>{
>>>	eqhw_t *eqhw = &(vortex->eq.this04);
>>>	int i;
>>>
>>>	/* set left peaks */
>>>	for (i = 0; i < eqhw->this04; i++) {
>>>		hwwrite(vortex->mmio, 0x2b024 + i * VORTEX_BAND_COEFF_SIZE, peaks[i]);
>>>	}
>>>
>>>	hwwrite(vortex->mmio, 0x2b3cc, peaks[eqhw->this04]);
>>>	hwwrite(vortex->mmio, 0x2b3d8, peaks[eqhw->this04 + 1]);
>>>
>>>	/* set right peaks */
>>>	for (i = 0; i < eqhw->this04; i++) {
>>>		hwwrite(vortex->mmio, 0x2b204 + i * VORTEX_BAND_COEFF_SIZE,
>>>			peaks[i + (eqhw->this04 + 2)]);
>>>	}
>>>
>>>	hwwrite(vortex->mmio, 0x2b3e4, peaks[2 + (eqhw->this04 * 2)]);
>>>	hwwrite(vortex->mmio, 0x2b3f0, peaks[3 + (eqhw->this04 * 2)]);
>>>}
>>>
>>>
>>>	vortex_EqHw_SetLevels(vortex, (u16 *) eq_levels);
>>>
>>>
>>>
>>>
>>>What is the reason to increase the size of the array eq_levels from 32 
>>>to 64 ?  ( eqhw->this04 seem to be 10 )
>>
>>
>>I guess he wants to keep the total array size just to be sure.
>>But it seems not necessary.
> 
> 
> Exactly for that purpose. I do not know if other (au8810 or au8830) use more
> than au8820 in that array.
> 
> 


AFAIK au8820 do not has any Equalizer, only au8810 and au8830 have the
Equalizer.

Those Equalizer offsets 0x2b??? are out of the 128K MMIO of au8820.

Most of the changes related to Equalizer are seem to be WRONG.

Please ask the alsa-team to add your Diamond Sonic Impact S90 (au8820)
to the soundmatrix

http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Diamond_Multimedia#matrix


au8820 do not support SPDIF too.

Is  IEC-60958 RCA Output equal to Coaxial SPDIF ?
Is  IEC-60958 TOSLINK Output equal to Optical SPDIF ?
Is  MIDIio both equal to MPU401 ?


#include "au8820.h"
#include "au88x0.h"
static struct pci_device_id snd_vortex_ids[] = {
         {PCI_VENDOR_ID_AUREAL, PCI_DEVICE_ID_AUREAL_VORTEX_1,
          PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0,},
         {0,}
};

#include "au88x0_synth.c"
#include "au88x0_core.c"
#include "au88x0_pcm.c"
#include "au88x0_mpu401.c"
#include "au88x0_game.c"
#include "au88x0_mixer.c"
#include "au88x0.c"


Do anyone know why amixer display 10-bands EQ stereo controls as mono 
controls ( snd_mixer_selem_has_capture_channel(elem, 
SND_MIXER_SCHN_MONO) = 1 ) ?


amixer

Simple mixer control 'Master',0
   Capabilities: pvolume pswitch pswitch-joined
   Playback channels: Front Left - Front Right
   Limits: Playback 0 - 31
pmono = 0, cmono = 0 (0, 0, 0, 0)
   Front Left: Playback 22 [71%] [on]
   Front Right: Playback 22 [71%] [on]


Simple mixer control 'EQ0 31Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 32767 [100%]
   Front Left:
   Front Right:
Simple mixer control 'EQ1 63Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ2 125Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ3 250Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ4 500Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ5 1KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ6 2KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ7 4KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ8 8KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:
Simple mixer control 'EQ9 16KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:



amixer contents

numid=16,iface=MIXER,name='Master Playback Volume'
   ; type=INTEGER,access=rw---,values=2,min=0,max=31,step=0
   : values=22,22

numid=2,iface=MIXER,name='EQ0 31Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=32767,16022
numid=3,iface=MIXER,name='EQ1 63Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=4,iface=MIXER,name='EQ2 125Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=5,iface=MIXER,name='EQ3 250Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=6,iface=MIXER,name='EQ4 500Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=7,iface=MIXER,name='EQ5 1KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=8,iface=MIXER,name='EQ6 2KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=9,iface=MIXER,name='EQ7 4KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=10,iface=MIXER,name='EQ8 8KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,16022
numid=11,iface=MIXER,name='EQ9 16KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,32767






-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Is there any way to remove this warning for the change from "0x%08lx" to
"0x%08x" in 32-bits compiler ?

  warning: unsigned int format, long unsigned int arg (arg 2)

There is no warning before this change.


alsa-kernel/pci/au88x0/au88x0_core.c

@@ -1054,7 +1054,7 @@
                 hwwrite(vortex->mmio, addr, FIFO_U0);
                 if (hwread(vortex->mmio, addr) != FIFO_U0)
                         printk(KERN_ERR
-                              "bad wt fifo reset (0x%08lx, 0x%08x)!\n",
+                              "bad wt fifo reset (0x%08x, 0x%08x)!\n",
                                addr, hwread(vortex->mmio, addr));
                 vortex_fifo_clearwtdata(vortex, x, FIFO_SIZE);
                 addr -= 4;


>
> Well, I've not stated the problem clearly enough.
> Once set, volume stays as it should. The problem is that
> PCM volume is:
> 1% - at lowest audible level
> 25% - at about 50% audible level
> 49% - at about max audible level
> 51% - at lowest audible level
> 75% - at about 50% audible level
> 99% - at about max audible level
> - that is what I described as low-high-low-high.
> On the other hand, Master volume behaves as expected.


What is the value of comment.range of 'PCM Playback Volume' in
/etc/asound.state for your STAC9704 (au8820) ?


According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704 
PCM Out volume.

or check the values *low_max and *high_max return by 
check_volume_resolution()

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_codec.c?r1=1.163&r2=1.164


Igor Kovalenko wrote:
> Takashi Iwai wrote:
> 
>>At Tue, 7 Jun 2005 17:16:02 +0200,
>>Alien wrote:
>>
>>
>>>[1  <text/plain; iso-8859-1 (quoted-printable)>]
>>>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
>>>
>>>
>>>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
>>>>during /etc/init.d/alsasound start
>>>>
>>>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>>>>
>>>>Do anyone know why readl() and writel() behave different in i386
>>>>(32bits) and AMD64 (64bits) ?
>>>>
>>>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>>>>
>>>>
>>>>#ifndef CONFIG_X86_64
>>>>
>>>>#define        hwread(x,y) readl((x)+((y)>>2))
>>>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>>>
>>>>#else
>>>>
>>>>#define        hwread(x,y) readl((x)+(y))
>>>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
>>>>
>>>>#endif
>>>
>>>that doesn't look good, unless the mmio is void* in 32bit and unsigned long* 
>>>in x86_64...
>>>
>>>'unsigned long* mmio' should be preferred and together with '#define        
>>>hwread(x,y) readl((x)+(y))' , this works for both platforms
>>
>>
>>I guess using "unsigned long" for both architectures is broken, too.
>>Should be "u32" to be arch-independent.
>>
> 
> 
> I strongly believe readl() and writel() on x86_64 does 32 bit reads/writes.
> (checked linux-2.6.12-rc5). Therefore reads/writes are of correct size with
> that patch - should be something different.
> 





-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Wed, 08 Jun 2005 20:34:06 +0800,
Raymond wrote:
> 
> Is there any way to remove this warning for the change from "0x%08lx" to
> "0x%08x" in 32-bits compiler ?
> 
>   warning: unsigned int format, long unsigned int arg (arg 2)
> 
> There is no warning before this change.

It means that you forgot to change the type of variable "addr".


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Raymond wrote:
> Is there any way to remove this warning for the change from "0x%08lx" to
> "0x%08x" in 32-bits compiler ?
> 
>  warning: unsigned int format, long unsigned int arg (arg 2)
> 
> There is no warning before this change.
> 
> 
> alsa-kernel/pci/au88x0/au88x0_core.c
> 
> @@ -1054,7 +1054,7 @@
>                 hwwrite(vortex->mmio, addr, FIFO_U0);
>                 if (hwread(vortex->mmio, addr) != FIFO_U0)
>                         printk(KERN_ERR
> -                              "bad wt fifo reset (0x%08lx, 0x%08x)!\n",
> +                              "bad wt fifo reset (0x%08x, 0x%08x)!\n",
>                                addr, hwread(vortex->mmio, addr));
>                 vortex_fifo_clearwtdata(vortex, x, FIFO_SIZE);
>                 addr -= 4;
> 
> 
>>
>> Well, I've not stated the problem clearly enough.
>> Once set, volume stays as it should. The problem is that
>> PCM volume is:
>> 1% - at lowest audible level
>> 25% - at about 50% audible level
>> 49% - at about max audible level
>> 51% - at lowest audible level
>> 75% - at about 50% audible level
>> 99% - at about max audible level
>> - that is what I described as low-high-low-high.
>> On the other hand, Master volume behaves as expected.
> 
> 
> 
> What is the value of comment.range of 'PCM Playback Volume' in
> /etc/asound.state for your STAC9704 (au8820) ?
> 
> 
> According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
> PCM Out volume.
> 

        control.21 {
                comment.access 'read write'
                comment.type INTEGER
                comment.count 2
                comment.range '0 - 63'
                iface MIXER
                name 'PCM Playback Volume'
                value.0 21
                value.1 21
        }

Do you mean AC97 is incorrectly reporting 0...63 range?

> or check the values *low_max and *high_max return by
> check_volume_resolution()
> 
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_codec.c?r1=1.163&r2=1.164
> 
> 
> 
> Igor Kovalenko wrote:
> 
>> Takashi Iwai wrote:
>>
>>> At Tue, 7 Jun 2005 17:16:02 +0200,
>>> Alien wrote:
>>>
>>>
>>>> [1  <text/plain; iso-8859-1 (quoted-printable)>]
>>>> Op dinsdag 7 juni 2005 17:05, schreef Raymond:
>>>>
>>>>
>>>>> The patch (diff11.diff) cause segmenation fault on my 32bit machine
>>>>> during /etc/init.d/alsasound start
>>>>>
>>>>> http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>>>>>
>>>>> Do anyone know why readl() and writel() behave different in i386
>>>>> (32bits) and AMD64 (64bits) ?
>>>>>
>>>>> http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>>>>>
>>>>>
>>>>> #ifndef CONFIG_X86_64
>>>>>
>>>>> #define        hwread(x,y) readl((x)+((y)>>2))
>>>>> #define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>>>>
>>>>> #else
>>>>>
>>>>> #define        hwread(x,y) readl((x)+(y))
>>>>> #define        hwwrite(x,y,z) writel((z),(x)+(y))
>>>>>
>>>>> #endif
>>>>
>>>>
>>>> that doesn't look good, unless the mmio is void* in 32bit and
>>>> unsigned long* in x86_64...
>>>>
>>>> 'unsigned long* mmio' should be preferred and together with
>>>> '#define        hwread(x,y) readl((x)+(y))' , this works for both
>>>> platforms
>>>
>>>
>>>
>>> I guess using "unsigned long" for both architectures is broken, too.
>>> Should be "u32" to be arch-independent.
>>>
>>
>>
>> I strongly believe readl() and writel() on x86_64 does 32 bit
>> reads/writes.
>> (checked linux-2.6.12-rc5). Therefore reads/writes are of correct size
>> with
>> that patch - should be something different.
>>
> 
> 
> 
> 
> 
> _______________________________________________
> Openvortex-dev mailing list
> Openvortex-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openvortex-dev
> 
> 


-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Igor Kovalenko wrote:
> Raymond wrote:
> 
>>
>>>Well, I've not stated the problem clearly enough.
>>>Once set, volume stays as it should. The problem is that
>>>PCM volume is:
>>>1% - at lowest audible level
>>>25% - at about 50% audible level
>>>49% - at about max audible level
>>>51% - at lowest audible level
>>>75% - at about 50% audible level
>>>99% - at about max audible level
>>>- that is what I described as low-high-low-high.
>>>On the other hand, Master volume behaves as expected.
>>
>>
>>
>>What is the value of comment.range of 'PCM Playback Volume' in
>>/etc/asound.state for your STAC9704 (au8820) ?
>>
>>
>>According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
>>PCM Out volume.
>>
> 
> 
>         control.21 {
>                 comment.access 'read write'
>                 comment.type INTEGER
>                 comment.count 2
>                 comment.range '0 - 63'
>                 iface MIXER
>                 name 'PCM Playback Volume'
>                 value.0 21
>                 value.1 21
>         }
> 
> Do you mean AC97 is incorrectly reporting 0...63 range?
> 

Refer to notes in page 25 of 9704SPEC.pdf

1) All registers not shown and bits contain an X are resserved.
2) Any reserved bits, marked X, can be written to but are don't care
upon read back.

Bits 14,13,7,6,5 of PCM Out Volume of STAC9704 are marked X.


> $ cat /proc/asound/au8820/codec97#0/ac97#0-0+regs
> 0:00 = 6940
> 0:02 = 1414
> 0:04 = 8000
> 0:06 = 801f
> 0:08 = ffff
> 0:0a = 9f1f
> 0:0c = 801f
> 0:0e = 841f
> 0:10 = 9f1f
> 0:12 = 1414
> 0:14 = 9f1f
> 0:16 = 9f1f
> 0:18 = 0f0f
> 0:1a = 1010
> 0:1c = 0000
> 0:1e = 0000
> 0:20 = 0200
> 0:22 = 0402
> 0:24 = 0000
> 0:26 = 800f
> 0:28 = ffff                <---- ext_id
> 0:2a = ffff
> 0:2c = ffff
> 0:2e = ffff
> 0:30 = ffff
> 0:32 = ffff
> 0:34 = ffff
> 0:36 = ffff
> 0:38 = ffff
> 0:3a = ffff
> 0:3c = 0000
> 0:3e = 0000
> 0:40 = 0000
> 0:42 = 0000
> 0:44 = 0000
> 0:46 = 0000
> 0:48 = 0000
> 0:4a = 0000
> 0:4c = 0000
> 0:4e = 0000
> 0:50 = 0000
> 0:52 = 0000
> 0:54 = 0000
> 0:56 = 0000
> 0:58 = 0000
> 0:5a = 0000
> 0:5c = 0000
> 0:5e = 0000
> 0:60 = 0000
> 0:62 = 0000
> 0:64 = 0000
> 0:66 = 0000
> 0:68 = 0000
> 0:6a = 0000
> 0:6c = 0000
> 0:6e = 0000
> 0:70 = 0000
> 0:72 = 0000
> 0:74 = 0000
> 0:76 = 0000
> 0:78 = 0000
> 0:7a = 0000
> 0:7c = 8384
> 0:7e = 7605

> Result is:
> vortex codec=ffff8100286df600 ext_id=00000000 isquad=00000000

> I conquer isquad is false.


It is quite strange that vortex->isquad is false

Does it mean that ac97 registers are cached ?

> 
>>or check the values *low_max and *high_max return by
>>check_volume_resolution()
>>
>>http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_codec.c?r1=1.163&r2=1.164
>>
>>
>>

Do this problem also exist in ALSA 1.0.8 ?







-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Igor Kovalenko wrote:
> Raymond wrote:
>>Igor Kovalenko wrote:
>>
>>>Well, I've not stated the problem clearly enough.
>>>Once set, volume stays as it should. The problem is that
>>>PCM volume is:
>>>1% - at lowest audible level
>>>25% - at about 50% audible level
>>>49% - at about max audible level
>>>51% - at lowest audible level
>>>75% - at about 50% audible level
>>>99% - at about max audible level
>>>- that is what I described as low-high-low-high.
>>>On the other hand, Master volume behaves as expected.
>>
>>
>>
>>What is the value of comment.range of 'PCM Playback Volume' in
>>/etc/asound.state for your STAC9704 (au8820) ?
>>
>>
>>According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
>>PCM Out volume.
>>
> 
> 
>         control.21 {
>                 comment.access 'read write'
>                 comment.type INTEGER
>                 comment.count 2
>                 comment.range '0 - 63'
>                 iface MIXER
>                 name 'PCM Playback Volume'
>                 value.0 21
>                 value.1 21
>         }
> 
> Do you mean AC97 is incorrectly reporting 0...63 range?
> 
> 

Try the following patch to log the read/write of ac97 and post the
system log using dmesg. (loading au8820 and alsactl restore)


alsa-driver-1.0.9b/alsa-kernel/pci/au88x0/au88x0_core.c
@@ -2520,6 +2515,7 @@
  	vortex_t *card = (vortex_t *) codec->private_data;
  	unsigned int lifeboat = 0;

+	printk(KERN_INFO "ac97 write %.2x : %.4x\n",addr,data);
  	/* wait for transactions to clear */
  	while (!(hwread(card->mmio, VORTEX_CODEC_CTRL) & 0x100)) {
  		udelay(100);
@@ -2567,6 +2563,7 @@
  		}
  	} while ((data & VORTEX_CODEC_ADDMASK) !=
  		 (addr << VORTEX_CODEC_ADDSHIFT));
+	printk(KERN_INFO "ac97 read  %.2x : %.4x\n",addr,data &
VORTEX_CODEC_DATMASK);

  	/* return data. */
  	return (u16) (data & VORTEX_CODEC_DATMASK);



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Raymond wrote:
> Igor Kovalenko wrote:
>> Raymond wrote:
>>> Igor Kovalenko wrote:
>>>
>>>> Well, I've not stated the problem clearly enough.
>>>> Once set, volume stays as it should. The problem is that
>>>> PCM volume is:
>>>> 1% - at lowest audible level
>>>> 25% - at about 50% audible level
>>>> 49% - at about max audible level
>>>> 51% - at lowest audible level
>>>> 75% - at about 50% audible level
>>>> 99% - at about max audible level
>>>> - that is what I described as low-high-low-high.
>>>> On the other hand, Master volume behaves as expected.
>>>
>>>
>>>
>>> What is the value of comment.range of 'PCM Playback Volume' in
>>> /etc/asound.state for your STAC9704 (au8820) ?
>>>
>>>
>>> According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
>>> PCM Out volume.
>>>
>>
>>
>>         control.21 {
>>                 comment.access 'read write'
>>                 comment.type INTEGER
>>                 comment.count 2
>>                 comment.range '0 - 63'
>>                 iface MIXER
>>                 name 'PCM Playback Volume'
>>                 value.0 21
>>                 value.1 21
>>         }
>>
>> Do you mean AC97 is incorrectly reporting 0...63 range?
>>
>>
> 
> Try the following patch to log the read/write of ac97 and post the
> system log using dmesg. (loading au8820 and alsactl restore)
> 
> 
> alsa-driver-1.0.9b/alsa-kernel/pci/au88x0/au88x0_core.c
> @@ -2520,6 +2515,7 @@
>      vortex_t *card = (vortex_t *) codec->private_data;
>      unsigned int lifeboat = 0;
> 
> +    printk(KERN_INFO "ac97 write %.2x : %.4x\n",addr,data);
>      /* wait for transactions to clear */
>      while (!(hwread(card->mmio, VORTEX_CODEC_CTRL) & 0x100)) {
>          udelay(100);
> @@ -2567,6 +2563,7 @@
>          }
>      } while ((data & VORTEX_CODEC_ADDMASK) !=
>           (addr << VORTEX_CODEC_ADDSHIFT));
> +    printk(KERN_INFO "ac97 read  %.2x : %.4x\n",addr,data &
> VORTEX_CODEC_DATMASK);
> 
>      /* return data. */
>      return (u16) (data & VORTEX_CODEC_DATMASK);
> 

Here is the dmesg excerpt:

Vortex: shutdown...<6>done.
ACPI: PCI Interrupt 0000:02:06.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 185
Vortex: init.... <6>done.
ac97 read  7c : 8384
ac97 read  7e : 7605
ac97 write 00 : 0000
ac97 read  00 : 6940
ac97 read  7c : 8384
ac97 read  7e : 7605
ac97 write 1c : 8a05
ac97 read  1c : 8a05
ac97 read  7c : 8384
ac97 read  7e : 7605
ac97 write 1c : 8a06
ac97 read  1c : 8a06
ac97 read  00 : 6940
ac97 read  28 : 0000
ac97 write 26 : 0000
ac97 write 00 : 0000
ac97 write 26 : 0000
ac97 write 20 : 0000
ac97 read  26 : 000f
ac97 read  02 : 8000
ac97 read  02 : 8000
ac97 write 02 : 0000
ac97 read  02 : 0000
ac97 write 02 : 8000
ac97 read  02 : 8000
ac97 write 02 : 8000
ac97 write 02 : a0a0
ac97 read  02 : 9f9f
ac97 write 02 : 9090
ac97 read  02 : 9090
ac97 read  02 : 9010
ac97 write 02 : 9f1f
ac97 read  06 : 9f00
ac97 read  06 : 8000
ac97 write 06 : 0000
ac97 read  06 : 0000
ac97 write 06 : 8000
ac97 read  06 : 8000
ac97 write 06 : 8000
ac97 write 06 : a0a0
ac97 read  06 : a09f
ac97 write 06 : 9090
ac97 read  06 : 9090
ac97 read  06 : 8010
ac97 write 06 : bf1f
ac97 read  0a : 0000
ac97 write 0a : 8000
ac97 read  0a : 8000
ac97 read  0a : 8000
ac97 write 0a : 801e
ac97 read  0c : 8008
ac97 read  0c : 8008
ac97 write 0c : 0008
ac97 read  0c : 0008
ac97 write 0c : 8008
ac97 read  0c : 8008
ac97 write 0c : 8008
ac97 write 0c : a0a0
ac97 read  0c : 8000
ac97 write 0c : 9090
ac97 read  0c : 8010
ac97 write 0c : 8181
ac97 read  0c : 8001
ac97 read  0c : 8001
ac97 write 0c : 801f
ac97 read  0e : 8008
ac97 read  0e : 8008
ac97 write 0e : 0008
ac97 read  0e : 0008
ac97 write 0e : 8008
ac97 read  0e : 8008
ac97 write 0e : 8008
ac97 write 0e : a0a0
ac97 read  0e : a0a0
ac97 read  0e : 8000
ac97 write 0e : bf3f
ac97 read  10 : a828
ac97 read  10 : 8808
ac97 write 10 : 0808
ac97 read  10 : 0808
ac97 write 10 : 8808
ac97 read  10 : 8808
ac97 write 10 : 8808
ac97 write 10 : a0a0
ac97 read  10 : a0a0
ac97 read  10 : 8000
ac97 write 10 : bf3f
ac97 read  12 : a828
ac97 read  12 : 8808
ac97 write 12 : 0808
ac97 read  12 : 0808
ac97 write 12 : 8808
ac97 read  12 : 8808
ac97 write 12 : 8808
ac97 write 12 : a0a0
ac97 read  12 : a0a0
ac97 read  12 : 8000
ac97 write 12 : bf3f
ac97 read  14 : a828
ac97 read  14 : 8808
ac97 write 14 : 0808
ac97 read  14 : 0808
ac97 write 14 : 8808
ac97 read  14 : 8808
ac97 write 14 : 8808
ac97 write 14 : a0a0
ac97 read  14 : a0a0
ac97 read  14 : 8000
ac97 write 14 : bf3f
ac97 read  16 : a828
ac97 read  16 : 8808
ac97 write 16 : 0808
ac97 read  16 : 0808
ac97 write 16 : 8808
ac97 read  16 : 8808
ac97 write 16 : 8808
ac97 write 16 : a0a0
ac97 read  16 : a0a0
ac97 read  16 : 8000
ac97 write 16 : bf3f
ac97 read  18 : 8808
ac97 write 18 : 0808
ac97 read  18 : 0808
ac97 write 18 : 8808
ac97 read  18 : 8808
ac97 write 18 : 8808
ac97 write 18 : a0a0
ac97 read  18 : a0a0
ac97 read  18 : 8000
ac97 write 18 : bf3f
ac97 read  1c : b030
ac97 write 1c : 3030
ac97 read  1c : 3030
ac97 write 1c : b030
ac97 read  1c : b030
ac97 write 1c : b030
ac97 write 1a : 0000
ac97 write 1c : 0000
ac97 read  20 : 0000
ac97 write 20 : 8000
ac97 read  20 : 8000
ac97 write 20 : 0000
ac97 read  20 : 0000
ac97 write 20 : 2000
ac97 read  20 : 2000
ac97 write 20 : 0000
ac97 read  20 : 0000
ac97 write 20 : 0200
ac97 read  20 : 0200
ac97 write 20 : 0000
ac97 read  20 : 0000
ac97 write 20 : 0100
ac97 read  20 : 0100
ac97 write 20 : 0000
ac97 read  22 : 0000
ac97 write 22 : 0707
ac97 read  22 : 0707
ac97 write 22 : 0000
ac97 read  26 : 000f
ac97 write 26 : 800f
ac97 read  26 : 800f
ac97 write 26 : 000f
ac97 read  2a : ffff
ac97 write 2a : ffff
ac97 write 02 : 1f1f
ac97 write 02 : 1313
ac97 write 12 : 3f3f
ac97 write 12 : 3434
ac97 write 18 : 3f3f
ac97 write 18 : 2828
ac97 write 20 : 0200
ac97 write 22 : 0400
ac97 write 22 : 0402
ac97 write 26 : 800f

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Igor Kovalenko wrote:
> Raymond wrote:
> 
>>Igor Kovalenko wrote:
>>
>>>Raymond wrote:
>>>
>>>>Igor Kovalenko wrote:
>>>>
>>>>
>>>>>Well, I've not stated the problem clearly enough.
>>>>>Once set, volume stays as it should. The problem is that
>>>>>PCM volume is:
>>>>>1% - at lowest audible level
>>>>>25% - at about 50% audible level
>>>>>49% - at about max audible level
>>>>>51% - at lowest audible level
>>>>>75% - at about 50% audible level
>>>>>99% - at about max audible level
>>>>>- that is what I described as low-high-low-high.
>>>>>On the other hand, Master volume behaves as expected.
>>>>
>>>>
>>>>
>>>>What is the value of comment.range of 'PCM Playback Volume' in
>>>>/etc/asound.state for your STAC9704 (au8820) ?
>>>>
>>>>
>>>>According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
>>>>PCM Out volume.
>>>>
>>>
>>>
>>>        control.21 {
>>>                comment.access 'read write'
>>>                comment.type INTEGER
>>>                comment.count 2
>>>                comment.range '0 - 63'
>>>                iface MIXER
>>>                name 'PCM Playback Volume'
>>>                value.0 21
>>>                value.1 21
>>>        }
>>>
>>>Do you mean AC97 is incorrectly reporting 0...63 range?
>>>
>>>
>>
>>Try the following patch to log the read/write of ac97 and post the
>>system log using dmesg. (loading au8820 and alsactl restore)
>>
>>
>>alsa-driver-1.0.9b/alsa-kernel/pci/au88x0/au88x0_core.c
>>@@ -2520,6 +2515,7 @@
>>     vortex_t *card = (vortex_t *) codec->private_data;
>>     unsigned int lifeboat = 0;
>>
>>+    printk(KERN_INFO "ac97 write %.2x : %.4x\n",addr,data);
>>     /* wait for transactions to clear */
>>     while (!(hwread(card->mmio, VORTEX_CODEC_CTRL) & 0x100)) {
>>         udelay(100);
>>@@ -2567,6 +2563,7 @@
>>         }
>>     } while ((data & VORTEX_CODEC_ADDMASK) !=
>>          (addr << VORTEX_CODEC_ADDSHIFT));
>>+    printk(KERN_INFO "ac97 read  %.2x : %.4x\n",addr,data &
>>VORTEX_CODEC_DATMASK);
>>
>>     /* return data. */
>>     return (u16) (data & VORTEX_CODEC_DATMASK);
>>
> 
> 
> Here is the dmesg excerpt:
> 
> Vortex: shutdown...<6>done.
> ACPI: PCI Interrupt 0000:02:06.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 185
> Vortex: init.... <6>done.
> ac97 read  7c : 8384
> ac97 read  7e : 7605
> ac97 write 00 : 0000
> ac97 read  00 : 6940
> ac97 read  7c : 8384
> ac97 read  7e : 7605
> ac97 write 1c : 8a05
> ac97 read  1c : 8a05
> ac97 read  7c : 8384
> ac97 read  7e : 7605
> ac97 write 1c : 8a06
> ac97 read  1c : 8a06
> ac97 read  00 : 6940
> ac97 read  28 : 0000
> ac97 write 26 : 0000
> ac97 write 00 : 0000
> ac97 write 26 : 0000
> ac97 write 20 : 0000
> ac97 read  26 : 000f
> ac97 read  02 : 8000
> ac97 read  02 : 8000
> ac97 write 02 : 0000
> ac97 read  02 : 0000
> ac97 write 02 : 8000
> ac97 read  02 : 8000
> ac97 write 02 : 8000
> ac97 write 02 : a0a0
> ac97 read  02 : 9f9f
> ac97 write 02 : 9090
> ac97 read  02 : 9090
> ac97 read  02 : 9010
> ac97 write 02 : 9f1f
> ac97 read  06 : 9f00
> ac97 read  06 : 8000
> ac97 write 06 : 0000
> ac97 read  06 : 0000
> ac97 write 06 : 8000
> ac97 read  06 : 8000
> ac97 write 06 : 8000
> ac97 write 06 : a0a0
> ac97 read  06 : a09f
> ac97 write 06 : 9090
> ac97 read  06 : 9090
> ac97 read  06 : 8010
> ac97 write 06 : bf1f
> ac97 read  0a : 0000
> ac97 write 0a : 8000
> ac97 read  0a : 8000
> ac97 read  0a : 8000
> ac97 write 0a : 801e
> ac97 read  0c : 8008
> ac97 read  0c : 8008
> ac97 write 0c : 0008
> ac97 read  0c : 0008
> ac97 write 0c : 8008
> ac97 read  0c : 8008
> ac97 write 0c : 8008
> ac97 write 0c : a0a0
> ac97 read  0c : 8000
> ac97 write 0c : 9090
> ac97 read  0c : 8010
> ac97 write 0c : 8181
> ac97 read  0c : 8001
> ac97 read  0c : 8001
> ac97 write 0c : 801f
> ac97 read  0e : 8008
> ac97 read  0e : 8008
> ac97 write 0e : 0008
> ac97 read  0e : 0008
> ac97 write 0e : 8008
> ac97 read  0e : 8008
> ac97 write 0e : 8008
> ac97 write 0e : a0a0
> ac97 read  0e : a0a0
> ac97 read  0e : 8000
> ac97 write 0e : bf3f
> ac97 read  10 : a828
> ac97 read  10 : 8808
> ac97 write 10 : 0808
> ac97 read  10 : 0808
> ac97 write 10 : 8808
> ac97 read  10 : 8808
> ac97 write 10 : 8808
> ac97 write 10 : a0a0
> ac97 read  10 : a0a0
> ac97 read  10 : 8000
> ac97 write 10 : bf3f
> ac97 read  12 : a828
> ac97 read  12 : 8808
> ac97 write 12 : 0808
> ac97 read  12 : 0808
> ac97 write 12 : 8808
> ac97 read  12 : 8808
> ac97 write 12 : 8808
> ac97 write 12 : a0a0
> ac97 read  12 : a0a0
> ac97 read  12 : 8000
> ac97 write 12 : bf3f
> ac97 read  14 : a828
> ac97 read  14 : 8808
> ac97 write 14 : 0808
> ac97 read  14 : 0808
> ac97 write 14 : 8808
> ac97 read  14 : 8808
> ac97 write 14 : 8808
> ac97 write 14 : a0a0
> ac97 read  14 : a0a0
> ac97 read  14 : 8000
> ac97 write 14 : bf3f
> ac97 read  16 : a828
> ac97 read  16 : 8808
> ac97 write 16 : 0808
> ac97 read  16 : 0808
> ac97 write 16 : 8808
> ac97 read  16 : 8808
> ac97 write 16 : 8808
> ac97 write 16 : a0a0
> ac97 read  16 : a0a0
> ac97 read  16 : 8000
> ac97 write 16 : bf3f
> ac97 read  18 : 8808
> ac97 write 18 : 0808
> ac97 read  18 : 0808
> ac97 write 18 : 8808
> ac97 read  18 : 8808
> ac97 write 18 : 8808
> ac97 write 18 : a0a0
> ac97 read  18 : a0a0
> ac97 read  18 : 8000
> ac97 write 18 : bf3f
> ac97 read  1c : b030
> ac97 write 1c : 3030
> ac97 read  1c : 3030
> ac97 write 1c : b030
> ac97 read  1c : b030
> ac97 write 1c : b030
> ac97 write 1a : 0000
> ac97 write 1c : 0000
> ac97 read  20 : 0000
> ac97 write 20 : 8000
> ac97 read  20 : 8000
> ac97 write 20 : 0000
> ac97 read  20 : 0000
> ac97 write 20 : 2000
> ac97 read  20 : 2000
> ac97 write 20 : 0000
> ac97 read  20 : 0000
> ac97 write 20 : 0200
> ac97 read  20 : 0200
> ac97 write 20 : 0000
> ac97 read  20 : 0000
> ac97 write 20 : 0100
> ac97 read  20 : 0100
> ac97 write 20 : 0000
> ac97 read  22 : 0000
> ac97 write 22 : 0707
> ac97 read  22 : 0707
> ac97 write 22 : 0000
> ac97 read  26 : 000f
> ac97 write 26 : 800f
> ac97 read  26 : 800f
> ac97 write 26 : 000f
> ac97 read  2a : ffff
> ac97 write 2a : ffff
> ac97 write 02 : 1f1f
> ac97 write 02 : 1313
> ac97 write 12 : 3f3f
> ac97 write 12 : 3434
> ac97 write 18 : 3f3f
> ac97 write 18 : 2828
> ac97 write 20 : 0200
> ac97 write 22 : 0400
> ac97 write 22 : 0402
> ac97 write 26 : 800f
> 

Since there is no error message "vortex: ac97 codec stuck busy" or
"vortex: ac97 address never arrived" appear in your system log.

It seem to me that your problem is due to the routine
check_volume_resolution() do not take care of the difference between
STAC9704 (AC97 2.0) and AC97 2.1 Specification. ( "reserved bits are
don't care upon read back" in AC97 2.0 and "reserved bits must return 0
upon read back" in AC97 2.1)

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_codec.c?r1=1.163&r2=1.164

You will need to open another bug report with category "AC97" in ALSA
Bug Tracking System.


STAC9704 specification

1) All registers not shown and bits contain an X are resserved.
2) Any reserved bits, marked X, can be written to but are don't care
upon read back.

AC97 2.1 specification

1) Italian underline indicate optional feature registers or optional
bits within a register. Whether implemented or not, these may be written
to but must return 0 if there is no support for this feature.
2) Any reserved bits, marked X, can be written to but must return 0 on
read back.


Master Volume

ac97 read  02 : 8000
ac97 read  02 : 8000
ac97 write 02 : 0000
ac97 read  02 : 0000
ac97 write 02 : 8000
ac97 read  02 : 8000
ac97 write 02 : 8000
ac97 write 02 : a0a0
ac97 read  02 : 9f9f
ac97 write 02 : 9090
ac97 read  02 : 9090
ac97 read  02 : 9010
ac97 write 02 : 9f1f  ( 5-bits )

Master Volume Mono

ac97 read  06 : 9f00
ac97 read  06 : 8000
ac97 write 06 : 0000
ac97 read  06 : 0000
ac97 write 06 : 8000
ac97 read  06 : 8000
ac97 write 06 : 8000
ac97 write 06 : a0a0
ac97 read  06 : a09f <--- ???
ac97 write 06 : 9090
ac97 read  06 : 9090
ac97 read  06 : 8010
ac97 write 06 : bf1f ( 6-bits )

Mic Volume

ac97 read  0e : 8008
ac97 read  0e : 8008
ac97 write 0e : 0008
ac97 read  0e : 0008
ac97 write 0e : 8008
ac97 read  0e : 8008
ac97 write 0e : 8008
ac97 write 0e : a0a0
ac97 read  0e : a0a0 <--- ???
ac97 read  0e : 8000
ac97 write 0e : bf3f ( 6-bits )

CD Volume

ac97 read  12 : a828
ac97 read  12 : 8808
ac97 write 12 : 0808
ac97 read  12 : 0808
ac97 write 12 : 8808
ac97 read  12 : 8808
ac97 write 12 : 8808
ac97 write 12 : a0a0
ac97 read  12 : a0a0  <--- ???
ac97 read  12 : 8000
ac97 write 12 : bf3f ( 6-bits )

PCM Volume

ac97 read  18 : 8808
ac97 write 18 : 0808
ac97 read  18 : 0808
ac97 write 18 : 8808
ac97 read  18 : 8808
ac97 write 18 : 8808
ac97 write 18 : a0a0
ac97 read  18 : a0a0 <--- ???
ac97 read  18 : 8000
ac97 write 18 : bf3f ( 6-bits )

Record Gain

ac97 read  1c : b030 <--- ???
ac97 write 1c : 3030 <--- ???
ac97 read  1c : 3030 <--- ???
ac97 write 1c : b030 <--- ???
ac97 read  1c : b030 <--- ???
ac97 write 1c : b030 <--- ???



alsactl restore

ac97 write 02 : 1f1f
ac97 write 02 : 1313
ac97 write 12 : 3f3f  <--- ???
ac97 write 12 : 3434  <--- ???
ac97 write 18 : 3f3f  <--- ???
ac97 write 18 : 2828  <--- ???
ac97 write 20 : 0200
ac97 write 22 : 0400
ac97 write 22 : 0402
ac97 write 26 : 800f















-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [Openvortex-dev] Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Raymond wrote:
> Igor Kovalenko wrote:
>> Raymond wrote:
>>
>>> Igor Kovalenko wrote:
>>>
>>>> Raymond wrote:
>>>>
>>>>> Igor Kovalenko wrote:
>>>>>
>>>>>
>>>>>> Well, I've not stated the problem clearly enough.
>>>>>> Once set, volume stays as it should. The problem is that
>>>>>> PCM volume is:
>>>>>> 1% - at lowest audible level
>>>>>> 25% - at about 50% audible level
>>>>>> 49% - at about max audible level
>>>>>> 51% - at lowest audible level
>>>>>> 75% - at about 50% audible level
>>>>>> 99% - at about max audible level
>>>>>> - that is what I described as low-high-low-high.
>>>>>> On the other hand, Master volume behaves as expected.
>>>>>
>>>>>
>>>>>
>>>>> What is the value of comment.range of 'PCM Playback Volume' in
>>>>> /etc/asound.state for your STAC9704 (au8820) ?
>>>>>
>>>>>
>>>>> According to 9704SPEC.pdf, it should be '0-31' ( 5 bits ) for STAC9704
>>>>> PCM Out volume.
>>>>>
>>>>
>>>>
>>>>        control.21 {
>>>>                comment.access 'read write'
>>>>                comment.type INTEGER
>>>>                comment.count 2
>>>>                comment.range '0 - 63'
>>>>                iface MIXER
>>>>                name 'PCM Playback Volume'
>>>>                value.0 21
>>>>                value.1 21
>>>>        }
>>>>
>>>> Do you mean AC97 is incorrectly reporting 0...63 range?
>>>>
>>>>
>>>
>>> Try the following patch to log the read/write of ac97 and post the
>>> system log using dmesg. (loading au8820 and alsactl restore)
>>>
>>>
>>> alsa-driver-1.0.9b/alsa-kernel/pci/au88x0/au88x0_core.c
>>> @@ -2520,6 +2515,7 @@
>>>     vortex_t *card = (vortex_t *) codec->private_data;
>>>     unsigned int lifeboat = 0;
>>>
>>> +    printk(KERN_INFO "ac97 write %.2x : %.4x\n",addr,data);
>>>     /* wait for transactions to clear */
>>>     while (!(hwread(card->mmio, VORTEX_CODEC_CTRL) & 0x100)) {
>>>         udelay(100);
>>> @@ -2567,6 +2563,7 @@
>>>         }
>>>     } while ((data & VORTEX_CODEC_ADDMASK) !=
>>>          (addr << VORTEX_CODEC_ADDSHIFT));
>>> +    printk(KERN_INFO "ac97 read  %.2x : %.4x\n",addr,data &
>>> VORTEX_CODEC_DATMASK);
>>>
>>>     /* return data. */
>>>     return (u16) (data & VORTEX_CODEC_DATMASK);
>>>
>>
>>
>> Here is the dmesg excerpt:
>>
>> Vortex: shutdown...<6>done.
>> ACPI: PCI Interrupt 0000:02:06.0[A] -> Link [APC3] -> GSI 18 (level,
>> low) -> IRQ 185
>> Vortex: init.... <6>done.
>> ac97 read  7c : 8384
>> ac97 read  7e : 7605
>> ac97 write 00 : 0000
>> ac97 read  00 : 6940
>> ac97 read  7c : 8384
>> ac97 read  7e : 7605
>> ac97 write 1c : 8a05
>> ac97 read  1c : 8a05
>> ac97 read  7c : 8384
>> ac97 read  7e : 7605
>> ac97 write 1c : 8a06
>> ac97 read  1c : 8a06
>> ac97 read  00 : 6940
>> ac97 read  28 : 0000
>> ac97 write 26 : 0000
>> ac97 write 00 : 0000
>> ac97 write 26 : 0000
>> ac97 write 20 : 0000
>> ac97 read  26 : 000f
>> ac97 read  02 : 8000
>> ac97 read  02 : 8000
>> ac97 write 02 : 0000
>> ac97 read  02 : 0000
>> ac97 write 02 : 8000
>> ac97 read  02 : 8000
>> ac97 write 02 : 8000
>> ac97 write 02 : a0a0
>> ac97 read  02 : 9f9f
>> ac97 write 02 : 9090
>> ac97 read  02 : 9090
>> ac97 read  02 : 9010
>> ac97 write 02 : 9f1f
>> ac97 read  06 : 9f00
>> ac97 read  06 : 8000
>> ac97 write 06 : 0000
>> ac97 read  06 : 0000
>> ac97 write 06 : 8000
>> ac97 read  06 : 8000
>> ac97 write 06 : 8000
>> ac97 write 06 : a0a0
>> ac97 read  06 : a09f
>> ac97 write 06 : 9090
>> ac97 read  06 : 9090
>> ac97 read  06 : 8010
>> ac97 write 06 : bf1f
>> ac97 read  0a : 0000
>> ac97 write 0a : 8000
>> ac97 read  0a : 8000
>> ac97 read  0a : 8000
>> ac97 write 0a : 801e
>> ac97 read  0c : 8008
>> ac97 read  0c : 8008
>> ac97 write 0c : 0008
>> ac97 read  0c : 0008
>> ac97 write 0c : 8008
>> ac97 read  0c : 8008
>> ac97 write 0c : 8008
>> ac97 write 0c : a0a0
>> ac97 read  0c : 8000
>> ac97 write 0c : 9090
>> ac97 read  0c : 8010
>> ac97 write 0c : 8181
>> ac97 read  0c : 8001
>> ac97 read  0c : 8001
>> ac97 write 0c : 801f
>> ac97 read  0e : 8008
>> ac97 read  0e : 8008
>> ac97 write 0e : 0008
>> ac97 read  0e : 0008
>> ac97 write 0e : 8008
>> ac97 read  0e : 8008
>> ac97 write 0e : 8008
>> ac97 write 0e : a0a0
>> ac97 read  0e : a0a0
>> ac97 read  0e : 8000
>> ac97 write 0e : bf3f
>> ac97 read  10 : a828
>> ac97 read  10 : 8808
>> ac97 write 10 : 0808
>> ac97 read  10 : 0808
>> ac97 write 10 : 8808
>> ac97 read  10 : 8808
>> ac97 write 10 : 8808
>> ac97 write 10 : a0a0
>> ac97 read  10 : a0a0
>> ac97 read  10 : 8000
>> ac97 write 10 : bf3f
>> ac97 read  12 : a828
>> ac97 read  12 : 8808
>> ac97 write 12 : 0808
>> ac97 read  12 : 0808
>> ac97 write 12 : 8808
>> ac97 read  12 : 8808
>> ac97 write 12 : 8808
>> ac97 write 12 : a0a0
>> ac97 read  12 : a0a0
>> ac97 read  12 : 8000
>> ac97 write 12 : bf3f
>> ac97 read  14 : a828
>> ac97 read  14 : 8808
>> ac97 write 14 : 0808
>> ac97 read  14 : 0808
>> ac97 write 14 : 8808
>> ac97 read  14 : 8808
>> ac97 write 14 : 8808
>> ac97 write 14 : a0a0
>> ac97 read  14 : a0a0
>> ac97 read  14 : 8000
>> ac97 write 14 : bf3f
>> ac97 read  16 : a828
>> ac97 read  16 : 8808
>> ac97 write 16 : 0808
>> ac97 read  16 : 0808
>> ac97 write 16 : 8808
>> ac97 read  16 : 8808
>> ac97 write 16 : 8808
>> ac97 write 16 : a0a0
>> ac97 read  16 : a0a0
>> ac97 read  16 : 8000
>> ac97 write 16 : bf3f
>> ac97 read  18 : 8808
>> ac97 write 18 : 0808
>> ac97 read  18 : 0808
>> ac97 write 18 : 8808
>> ac97 read  18 : 8808
>> ac97 write 18 : 8808
>> ac97 write 18 : a0a0
>> ac97 read  18 : a0a0
>> ac97 read  18 : 8000
>> ac97 write 18 : bf3f
>> ac97 read  1c : b030
>> ac97 write 1c : 3030
>> ac97 read  1c : 3030
>> ac97 write 1c : b030
>> ac97 read  1c : b030
>> ac97 write 1c : b030
>> ac97 write 1a : 0000
>> ac97 write 1c : 0000
>> ac97 read  20 : 0000
>> ac97 write 20 : 8000
>> ac97 read  20 : 8000
>> ac97 write 20 : 0000
>> ac97 read  20 : 0000
>> ac97 write 20 : 2000
>> ac97 read  20 : 2000
>> ac97 write 20 : 0000
>> ac97 read  20 : 0000
>> ac97 write 20 : 0200
>> ac97 read  20 : 0200
>> ac97 write 20 : 0000
>> ac97 read  20 : 0000
>> ac97 write 20 : 0100
>> ac97 read  20 : 0100
>> ac97 write 20 : 0000
>> ac97 read  22 : 0000
>> ac97 write 22 : 0707
>> ac97 read  22 : 0707
>> ac97 write 22 : 0000
>> ac97 read  26 : 000f
>> ac97 write 26 : 800f
>> ac97 read  26 : 800f
>> ac97 write 26 : 000f
>> ac97 read  2a : ffff
>> ac97 write 2a : ffff
>> ac97 write 02 : 1f1f
>> ac97 write 02 : 1313
>> ac97 write 12 : 3f3f
>> ac97 write 12 : 3434
>> ac97 write 18 : 3f3f
>> ac97 write 18 : 2828
>> ac97 write 20 : 0200
>> ac97 write 22 : 0400
>> ac97 write 22 : 0402
>> ac97 write 26 : 800f
>>
> 
> Since there is no error message "vortex: ac97 codec stuck busy" or
> "vortex: ac97 address never arrived" appear in your system log.
> 
> It seem to me that your problem is due to the routine
> check_volume_resolution() do not take care of the difference between
> STAC9704 (AC97 2.0) and AC97 2.1 Specification. ( "reserved bits are
> don't care upon read back" in AC97 2.0 and "reserved bits must return 0
> upon read back" in AC97 2.1)
> 
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_codec.c?r1=1.163&r2=1.164
> 
> 
> You will need to open another bug report with category "AC97" in ALSA
> Bug Tracking System.
> 
> 
> STAC9704 specification
> 
> 1) All registers not shown and bits contain an X are resserved.
> 2) Any reserved bits, marked X, can be written to but are don't care
> upon read back.
> 
> AC97 2.1 specification
> 
> 1) Italian underline indicate optional feature registers or optional
> bits within a register. Whether implemented or not, these may be written
> to but must return 0 if there is no support for this feature.
> 2) Any reserved bits, marked X, can be written to but must return 0 on
> read back.
> 
> 
> Master Volume
> 
> ac97 read  02 : 8000
> ac97 read  02 : 8000
> ac97 write 02 : 0000
> ac97 read  02 : 0000
> ac97 write 02 : 8000
> ac97 read  02 : 8000
> ac97 write 02 : 8000
> ac97 write 02 : a0a0
> ac97 read  02 : 9f9f
> ac97 write 02 : 9090
> ac97 read  02 : 9090
> ac97 read  02 : 9010
> ac97 write 02 : 9f1f  ( 5-bits )
> 
> Master Volume Mono
> 
> ac97 read  06 : 9f00
> ac97 read  06 : 8000
> ac97 write 06 : 0000
> ac97 read  06 : 0000
> ac97 write 06 : 8000
> ac97 read  06 : 8000
> ac97 write 06 : 8000
> ac97 write 06 : a0a0
> ac97 read  06 : a09f <--- ???
> ac97 write 06 : 9090
> ac97 read  06 : 9090
> ac97 read  06 : 8010
> ac97 write 06 : bf1f ( 6-bits )
> 
> Mic Volume
> 
> ac97 read  0e : 8008
> ac97 read  0e : 8008
> ac97 write 0e : 0008
> ac97 read  0e : 0008
> ac97 write 0e : 8008
> ac97 read  0e : 8008
> ac97 write 0e : 8008
> ac97 write 0e : a0a0
> ac97 read  0e : a0a0 <--- ???
> ac97 read  0e : 8000
> ac97 write 0e : bf3f ( 6-bits )
> 
> CD Volume
> 
> ac97 read  12 : a828
> ac97 read  12 : 8808
> ac97 write 12 : 0808
> ac97 read  12 : 0808
> ac97 write 12 : 8808
> ac97 read  12 : 8808
> ac97 write 12 : 8808
> ac97 write 12 : a0a0
> ac97 read  12 : a0a0  <--- ???
> ac97 read  12 : 8000
> ac97 write 12 : bf3f ( 6-bits )
> 
> PCM Volume
> 
> ac97 read  18 : 8808
> ac97 write 18 : 0808
> ac97 read  18 : 0808
> ac97 write 18 : 8808
> ac97 read  18 : 8808
> ac97 write 18 : 8808
> ac97 write 18 : a0a0
> ac97 read  18 : a0a0 <--- ???
> ac97 read  18 : 8000
> ac97 write 18 : bf3f ( 6-bits )
> 
> Record Gain
> 
> ac97 read  1c : b030 <--- ???
> ac97 write 1c : 3030 <--- ???
> ac97 read  1c : 3030 <--- ???
> ac97 write 1c : b030 <--- ???
> ac97 read  1c : b030 <--- ???
> ac97 write 1c : b030 <--- ???
> 
> 
> 
> alsactl restore
> 
> ac97 write 02 : 1f1f
> ac97 write 02 : 1313
> ac97 write 12 : 3f3f  <--- ???
> ac97 write 12 : 3434  <--- ???
> ac97 write 18 : 3f3f  <--- ???
> ac97 write 18 : 2828  <--- ???
> ac97 write 20 : 0200
> ac97 write 22 : 0400
> ac97 write 22 : 0402
> ac97 write 26 : 800f
> 

The patch at Follow-up Comment #42, patch #3948 (project openvortex):
http://sourceforge.net/mailarchive/forum.php?thread_id=7699552&forum_id=33141
which adds extra read after ac97 codec write seem to cure abnormal volume problem,
so I did not look further.

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

au8830 can be loaded after I change "unsigned long __iomem *mmio" to
"void __iomem *mmio" on my 32 bits machine.

How can I obtain the disassembly of snd-au8830.o to prove that it run 
faster than before ( without bitshift ) ?

alsa-kernel/pci/au88x0/au88x0.h

@@ -41,8 +41,8 @@

  #define        VORTEX_DMA_MASK 0xffffffff


-#define        hwread(x,y) readl((x)+((y)>>2))
-#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
+#define        hwread(x,y) readl((x)+(y))
+#define        hwwrite(x,y,z) writel((z),(x)+(y))

@@ -172,7 +172,7 @@

         /* PCI hardware resources */
         unsigned long io;
-       unsigned long __iomem *mmio;
+       void __iomem *mmio;
         unsigned int irq;
         spinlock_t lock;



I don't have any MPU401 device to test this change.


alsa-kernel/pci/au88x0/au88x0_mpu401.c
@@ -95,7 +95,7 @@
                 return temp;
         }
  #else
-       port = (unsigned long)(vortex->mmio + (VORTEX_MIDI_DATA >> 2));
+       port = (unsigned long)(vortex->mmio + VORTEX_MIDI_DATA);
         if ((temp =
              snd_mpu401_uart_new(vortex->card, 0, MPU401_HW_AUREAL, port,
                                  1, 0, 0, &rmidi)) != 0) {
@@ -105,7 +105,7 @@
                 return temp;
         }
         mpu = rmidi->private_data;
-       mpu->cport = (unsigned long)(vortex->mmio + (VORTEX_MIDI_CMD >> 2));
+       mpu->cport = (unsigned long)(vortex->mmio + VORTEX_MIDI_CMD);
  #endif
         vortex->rmidi = rmidi;
         return 0;


Is there any reason to make this change ?

alsa-kernel/pci/au88x0/au88x0.c
@@ -144,15 +144,18 @@
         // check PCI availability (DMA).
         if ((err = pci_enable_device(pci)) < 0)
                 return err;
-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
                 printk(KERN_ERR "error to set DMA mask\n");
+               pci_disable_device(pci);
                 return -ENXIO;
         }
-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);

         chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
-       if (chip == NULL)
+       if (chip == NULL) {
+               pci_disable_device(pci);
                 return -ENOMEM;
+       }

         chip->card = card;

@@ -202,6 +205,8 @@
                 goto alloc_out;
         }

+       snd_card_set_dev(card, &pci->dev);
+
         *rchip = chip;

         return 0;

Those changes in au88x0_eq.h and au88x0_eqdata.c seem WRONG.

-       unsigned int *this00;   /*CAsp4HwIO */
+       u32 ptr_this00;         /*CAsp4HwIO */


2 * 10 seem related to the 10-bands stereo EQ.


-       u16 this14[32];         /* SetLeftGainsTarget: Left (and right?)
+       u16 this14_array[32];   /* SetLeftGainsTarget: Left (and right?)

         /* Set gains. */
-       memset(eq->this14, 0, 2 * 10);
+       memset(eq->this14_array, 0, sizeof(eq->this14_array));




-static long eq_levels[32] = {
+static u16 eq_levels[64] = {
+       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
+       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,


http://lists.nongnu.org/archive/html/openvortex-dev/2003-12/msg00007.html

There is no kcontrol to change vortex->xt_mode for speaker wide, speaker
narrow, speaker Diamond , headphones to test the Crosstalk canceler

long -> s32
short -> s16

alsa-kernel/pci/au88x0/au88x0_xtalk.h
@@ -39,11 +39,11 @@
  #define XT_SPEAKER1            3
  #define XT_DIAMOND             4

-typedef long xtalk_dline_t[XTDLINE_SZ];
-typedef short xtalk_gains_t[XTGAINS_SZ];
-typedef short xtalk_instate_t[XTINST_SZ];
-typedef short xtalk_coefs_t[5][5];
-typedef short xtalk_state_t[5][4];
+typedef u32 xtalk_dline_t[XTDLINE_SZ];
+typedef u16 xtalk_gains_t[XTGAINS_SZ];
+typedef u16 xtalk_instate_t[XTINST_SZ];
+typedef u16 xtalk_coefs_t[5][5];
+typedef u16 xtalk_state_t[5][4];



Takashi Iwai wrote:
> At Tue, 7 Jun 2005 17:16:02 +0200,
> Alien wrote:
> 
>>[1  <text/plain; iso-8859-1 (quoted-printable)>]
>>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
>>
>>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
>>>during /etc/init.d/alsasound start
>>>
>>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
>>>
>>>Do anyone know why readl() and writel() behave different in i386
>>>(32bits) and AMD64 (64bits) ?
>>>
>>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
>>>
>>>
>>>#ifndef CONFIG_X86_64
>>>
>>>#define        hwread(x,y) readl((x)+((y)>>2))
>>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>>
>>>#else
>>>
>>>#define        hwread(x,y) readl((x)+(y))
>>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
>>>
>>>#endif
>>
>>that doesn't look good, unless the mmio is void* in 32bit and unsigned long* 
>>in x86_64...
>>
>>'unsigned long* mmio' should be preferred and together with '#define        
>>hwread(x,y) readl((x)+(y))' , this works for both platforms
> 
> 
> I guess using "unsigned long" for both architectures is broken, too.
> Should be "u32" to be arch-independent.
> 
> 







-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Wed, 08 Jun 2005 17:06:39 +0800,
Raymond wrote:
> 
> au8830 can be loaded after I change "unsigned long __iomem *mmio" to
> "void __iomem *mmio" on my 32 bits machine.
> 
> How can I obtain the disassembly of snd-au8830.o to prove that it run 
> faster than before ( without bitshift ) ?

Faster?  Not measurable at all :)

> Is there any reason to make this change ?
> 
> alsa-kernel/pci/au88x0/au88x0.c
> @@ -144,15 +144,18 @@
>          // check PCI availability (DMA).
>          if ((err = pci_enable_device(pci)) < 0)
>                  return err;
> -       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> +        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> +               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>                  printk(KERN_ERR "error to set DMA mask\n");
> +               pci_disable_device(pci);
>                  return -ENXIO;
>          }
> -       pci_set_dma_mask(pci, VORTEX_DMA_MASK);

This is clean up.

>          chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> -       if (chip == NULL)
> +       if (chip == NULL) {
> +               pci_disable_device(pci);
>                  return -ENOMEM;
> +       }

This fixes the PCI state in the error path.

> 
>          chip->card = card;
> 
> @@ -202,6 +205,8 @@
>                  goto alloc_out;
>          }
> 
> +       snd_card_set_dev(card, &pci->dev);
> +
>          *rchip = chip;

And this sets up the missing sysfs stuff.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Takashi Iwai wrote:
> At Wed, 08 Jun 2005 17:06:39 +0800,
> Raymond wrote:
> 

> 
>>Is there any reason to make this change ?
>>
>>alsa-kernel/pci/au88x0/au88x0.c
>>@@ -144,15 +144,18 @@
>>         // check PCI availability (DMA).
>>         if ((err = pci_enable_device(pci)) < 0)
>>                 return err;
>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>>                 printk(KERN_ERR "error to set DMA mask\n");
>>+               pci_disable_device(pci);
>>                 return -ENXIO;
>>         }
>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> 
> 
> This is clean up.
> 
> 
>>         chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
>>-       if (chip == NULL)
>>+       if (chip == NULL) {
>>+               pci_disable_device(pci);
>>                 return -ENOMEM;
>>+       }
> 
> 
> This fixes the PCI state in the error path.
> 
> 
>>         chip->card = card;
>>
>>@@ -202,6 +205,8 @@
>>                 goto alloc_out;
>>         }
>>
>>+       snd_card_set_dev(card, &pci->dev);
>>+
>>         *rchip = chip;
> 
> 
> And this sets up the missing sysfs stuff.
> 
> 

So these changes are not neccesary(critical) for 
au88x0_64_bits_compatible.patch  (AMD64 and X86_64 ) , just normal ALSA 
cleanup.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Igor Kovalenko]

Raymond wrote:
> Takashi Iwai wrote:
> 
>> At Wed, 08 Jun 2005 17:06:39 +0800,
>> Raymond wrote:
>>
> 
>>
>>> Is there any reason to make this change ?
>>>
>>> alsa-kernel/pci/au88x0/au88x0.c
>>> @@ -144,15 +144,18 @@
>>>         // check PCI availability (DMA).
>>>         if ((err = pci_enable_device(pci)) < 0)
>>>                 return err;
>>> -       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
>>> +        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
>>> +               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>>>                 printk(KERN_ERR "error to set DMA mask\n");
>>> +               pci_disable_device(pci);
>>>                 return -ENXIO;
>>>         }
>>> -       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
>>
>>
>>
>> This is clean up.
>>
>>
>>>         chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
>>> -       if (chip == NULL)
>>> +       if (chip == NULL) {
>>> +               pci_disable_device(pci);
>>>                 return -ENOMEM;
>>> +       }
>>
>>
>>
>> This fixes the PCI state in the error path.
>>
>>
>>>         chip->card = card;
>>>
>>> @@ -202,6 +205,8 @@
>>>                 goto alloc_out;
>>>         }
>>>
>>> +       snd_card_set_dev(card, &pci->dev);
>>> +
>>>         *rchip = chip;
>>
>>
>>
>> And this sets up the missing sysfs stuff.
>>
>>
> 
> So these changes are not neccesary(critical) for
> au88x0_64_bits_compatible.patch  (AMD64 and X86_64 ) , just normal ALSA
> cleanup.
> 

Actually without snd_card_set_dev() you will get oops shortly because device
pointer won't be available to driver.
DMA mask cleanup is to follow general guidelines about consistent mapping.

-- 
Kind regards,
Igor V. Kovalenko


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Openvortex-dev] Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Igor Kovalenko wrote:
> Raymond wrote:
> 
>>Takashi Iwai wrote:
>>>Raymond wrote:
>>>>Is there any reason to make this change ?
>>>>
>>>>alsa-kernel/pci/au88x0/au88x0.c
>>>>@@ -144,15 +144,18 @@
>>>>        // check PCI availability (DMA).
>>>>        if ((err = pci_enable_device(pci)) < 0)
>>>>                return err;
>>>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
>>>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
>>>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>>>>                printk(KERN_ERR "error to set DMA mask\n");
>>>>+               pci_disable_device(pci);
>>>>                return -ENXIO;
>>>>        }
>>>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
>>>
>>>
>>>
>>>This is clean up.
>>>
>>>
>>>
>>>>        chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
>>>>-       if (chip == NULL)
>>>>+       if (chip == NULL) {
>>>>+               pci_disable_device(pci);
>>>>                return -ENOMEM;
>>>>+       }
>>>
>>>
>>>
>>>This fixes the PCI state in the error path.
>>>
>>>
>>>
>>>>        chip->card = card;
>>>>
>>>>@@ -202,6 +205,8 @@
>>>>                goto alloc_out;
>>>>        }
>>>>
>>>>+       snd_card_set_dev(card, &pci->dev);
>>>>+
>>>>        *rchip = chip;
>>>
>>>
>>>
>>>And this sets up the missing sysfs stuff.
>>>
>>>
>>
>>So these changes are not neccesary(critical) for
>>au88x0_64_bits_compatible.patch  (AMD64 and X86_64 ) , just normal ALSA
>>cleanup.
>>
> 
> 
> Actually without snd_card_set_dev() you will get oops shortly because device
> pointer won't be available to driver.
> DMA mask cleanup is to follow general guidelines about consistent mapping.
> 

This patch (ALSA 1.0.2c, Kernel 2.6) had been posted on the 
openvortex-devel mailing list since Feb, 2004.

http://lists.nongnu.org/archive/html/openvortex-dev/2004-02/msg00010.html


Does it mean that 32bits machines will also get oops on Kernel 2.6 ?

Any unresolved bugs in ALSA BTS are related to the missing of 
"snd_card_set_dev(card, &pci->dev);" ?





-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Do the au88x0 driver need to free those kcontrols for EQ peak and 
10-bands EQ gain kcontrol  ?

Any method to detect memory leak ? ( THere are other kcontrol such as 
HRTF,ITD,ILD,...)


/* ALSA driver entry points. Init and exit. */
static int vortex_eq_init(vortex_t * vortex)
{
	snd_kcontrol_t *kcontrol;
	int err, i;

	vortex_Eqlzr_init(vortex);

	if ((kcontrol =
	     snd_ctl_new1(&vortex_eqtoggle_kcontrol, vortex)) == NULL)
		return -ENOMEM;
	kcontrol->private_value = 0;
	if ((err = snd_ctl_add(vortex->card, kcontrol)) < 0)
		return err;

	/* EQ gain controls */
	for (i = 0; i < 10; i++) {
		if ((kcontrol =
		     snd_ctl_new1(&vortex_eq_kcontrol, vortex)) == NULL)
			return -ENOMEM;
		strcpy(kcontrol->id.name, EqBandLabels[i]);
		kcontrol->private_value = i;
		if ((err = snd_ctl_add(vortex->card, kcontrol)) < 0)
			return err;
		//vortex->eqctrl[i] = kcontrol;
	}
	/* EQ band levels */
	if ((kcontrol = snd_ctl_new1(&vortex_levels_kcontrol, vortex)) == NULL)
		return -ENOMEM;
	if ((err = snd_ctl_add(vortex->card, kcontrol)) < 0)
		return err;

	return 0;
}

static int vortex_eq_free(vortex_t * vortex)
{
	/*
	   //FIXME: segfault because vortex->eqctrl[i] == 4
	   int i;
	   for (i=0; i<10; i++) {
	   if (vortex->eqctrl[i])
	   snd_ctl_remove(vortex->card, vortex->eqctrl[i]);
	   }
	 */
	vortex_Eqlzr_shutdown(vortex);
	return 0;
}


Takashi Iwai wrote:
> At Wed, 08 Jun 2005 17:06:39 +0800,
> Raymond wrote:
> 
>>au8830 can be loaded after I change "unsigned long __iomem *mmio" to
>>"void __iomem *mmio" on my 32 bits machine.
>>
>>How can I obtain the disassembly of snd-au8830.o to prove that it run 
>>faster than before ( without bitshift ) ?
> 
> 
> Faster?  Not measurable at all :)
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Fri, 10 Jun 2005 15:35:41 +0800,
Raymond wrote:
> 
> 
> Do the au88x0 driver need to free those kcontrols for EQ peak and 
> 10-bands EQ gain kcontrol  ?

No.  The added controls are released automatically.

> Any method to detect memory leak ? ( THere are other kcontrol such as 
> HRTF,ITD,ILD,...)

Compild alsa-driver with debug option (--with-debug=full).
Then bookkeeping of the kmalloc/vmalloc chunks is enabled.
You'll be warned if any of them are not released after removing ALSA
modules.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

The amixer display 10-bands EQ stereo controls as mono controls.

The function of the equalizer is similar to bass, treble but equalizer 
has 10-bands instead of 2-bands ( bass & treble )

Why do snd_mixer_selem_has_capture_channel(elem, SND_MIXER_SCHN_MONO) = 
1 for those equalizer gain control ?


amixer

Simple mixer control 'Master',0
   Capabilities: pvolume pswitch pswitch-joined
   Playback channels: Front Left - Front Right
   Limits: Playback 0 - 31
pmono = 0, cmono = 0 (0, 0, 0, 0)
   Front Left: Playback 22 [71%] [on]
   Front Right: Playback 22 [71%] [on]


Simple mixer control 'EQ0 31Hz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 32767 [100%]
   Front Left:
   Front Right:

...

Simple mixer control 'EQ9 16KHz',0
   Capabilities: volume
   Playback channels: Front Left - Front Right
   Limits: 0 - 32767
pmono = 0, cmono = 1 (1, 0, 0, 0)
   Mono: 16022 [49%]
   Front Left:
   Front Right:



amixer contents

numid=16,iface=MIXER,name='Master Playback Volume'
   ; type=INTEGER,access=rw---,values=2,min=0,max=31,step=0
   : values=22,22

numid=2,iface=MIXER,name='EQ0 31Hz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=32767,16022

...

numid=11,iface=MIXER,name='EQ9 16KHz'
   ; type=INTEGER,access=rw---,values=2,min=0,max=32767,step=0
   : values=16022,32767


Takashi Iwai wrote:
> At Fri, 10 Jun 2005 15:35:41 +0800,
> Raymond wrote:
> 
>>
>>Do the au88x0 driver need to free those kcontrols for EQ peak and 
>>10-bands EQ gain kcontrol  ?
> 
> 
> No.  The added controls are released automatically.
> 
> 
>>Any method to detect memory leak ? ( THere are other kcontrol such as 
>>HRTF,ITD,ILD,...)
> 
> 
> Compild alsa-driver with debug option (--with-debug=full).
> Then bookkeeping of the kmalloc/vmalloc chunks is enabled.
> You'll be warned if any of them are not released after removing ALSA
> modules.
> 




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Takashi Iwai wrote:
> At Wed, 08 Jun 2005 17:06:39 +0800,
> Raymond wrote:
> 
> 
>>Is there any reason to make this change ?
>>
>>alsa-kernel/pci/au88x0/au88x0.c
>>@@ -144,15 +144,18 @@
>>         // check PCI availability (DMA).
>>         if ((err = pci_enable_device(pci)) < 0)
>>                 return err;
>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>>                 printk(KERN_ERR "error to set DMA mask\n");
>>+               pci_disable_device(pci);
>>                 return -ENXIO;
>>         }
>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> 
> 
> This is clean up.
> 
> 
>>         chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
>>-       if (chip == NULL)
>>+       if (chip == NULL) {
>>+               pci_disable_device(pci);
>>                 return -ENOMEM;
>>+       }
> 
> 
> This fixes the PCI state in the error path.
> 
> 
>>         chip->card = card;
>>
>>@@ -202,6 +205,8 @@
>>                 goto alloc_out;
>>         }
>>
>>+       snd_card_set_dev(card, &pci->dev);
>>+
>>         *rchip = chip;
> 
> 
> And this sets up the missing sysfs stuff.
> 
> 

It seem that these two patches for Kernel 2.6 were lost when au88x0 
migrate from alsa-driver to alsa-kernel.


http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-driver/pci/au88x0/au88x0.c?r1=1.6&r2=1.7
* fixed the DMA allocation.
   pci_set_dma_mask() is called together with pci_set_consistent_dma_mask().
   also clean up the double check of mask.

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-driver/pci/au88x0/au88x0.c?r1=1.8&r2=1.9
* added snd_card_set_dev() macro.
* sysfsfied more pci, isapnp and usb drivers.






-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Fri, 29 Jul 2005 22:43:18 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 08 Jun 2005 17:06:39 +0800,
> > Raymond wrote:
> > 
> > 
> >>Is there any reason to make this change ?
> >>
> >>alsa-kernel/pci/au88x0/au88x0.c
> >>@@ -144,15 +144,18 @@
> >>         // check PCI availability (DMA).
> >>         if ((err = pci_enable_device(pci)) < 0)
> >>                 return err;
> >>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> >>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> >>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
> >>                 printk(KERN_ERR "error to set DMA mask\n");
> >>+               pci_disable_device(pci);
> >>                 return -ENXIO;
> >>         }
> >>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> > 
> > 
> > This is clean up.
> > 
> > 
> >>         chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> >>-       if (chip == NULL)
> >>+       if (chip == NULL) {
> >>+               pci_disable_device(pci);
> >>                 return -ENOMEM;
> >>+       }
> > 
> > 
> > This fixes the PCI state in the error path.
> > 
> > 
> >>         chip->card = card;
> >>
> >>@@ -202,6 +205,8 @@
> >>                 goto alloc_out;
> >>         }
> >>
> >>+       snd_card_set_dev(card, &pci->dev);
> >>+
> >>         *rchip = chip;
> > 
> > 
> > And this sets up the missing sysfs stuff.
> > 
> > 
> 
> It seem that these two patches for Kernel 2.6 were lost when au88x0 
> migrate from alsa-driver to alsa-kernel.

You're right.  It seems dropped at that time accidentally.

Could you care to post a patch to fix them?


thanks,

Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Takashi Iwai wrote:
> At Fri, 29 Jul 2005 22:43:18 +0800,
> Raymond wrote:
> 
>>Takashi Iwai wrote:
>>
>>>At Wed, 08 Jun 2005 17:06:39 +0800,
>>>Raymond wrote:
>>>
>>>
>>>
>>>>Is there any reason to make this change ?
>>>>
>>>>alsa-kernel/pci/au88x0/au88x0.c
>>>>@@ -144,15 +144,18 @@
>>>>        // check PCI availability (DMA).
>>>>        if ((err = pci_enable_device(pci)) < 0)
>>>>                return err;
>>>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
>>>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
>>>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>>>>                printk(KERN_ERR "error to set DMA mask\n");
>>>>+               pci_disable_device(pci);
>>>>                return -ENXIO;
>>>>        }
>>>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
>>>
>>>
>>>This is clean up.
>>>
>>>
>>>
>>>>        chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
>>>>-       if (chip == NULL)
>>>>+       if (chip == NULL) {
>>>>+               pci_disable_device(pci);
>>>>                return -ENOMEM;
>>>>+       }
>>>
>>>
>>>This fixes the PCI state in the error path.
>>>
>>>
>>>
>>>>        chip->card = card;
>>>>
>>>>@@ -202,6 +205,8 @@
>>>>                goto alloc_out;
>>>>        }
>>>>
>>>>+       snd_card_set_dev(card, &pci->dev);
>>>>+
>>>>        *rchip = chip;
>>>
>>>
>>>And this sets up the missing sysfs stuff.
>>>
>>>
>>
>>It seem that these two patches for Kernel 2.6 were lost when au88x0 
>>migrate from alsa-driver to alsa-kernel.
> 
> 
> You're right.  It seems dropped at that time accidentally.
> 
> Could you care to post a patch to fix them?
> 
> 


au88x0_fix_fc4.patch (file# 4739)

http://savannah.nongnu.org/patch/?func=detailitem&item_id=4107

posted in the open vortex project patch manager (item id #4107) add back 
the two patches lost during au88x0 migrate from alsa-driver to alsa-kernel.

http://savannah.nongnu.org/patch/download.php?item_id=4107&item_file_id=4739



These are the two patches lost during au88x0 migrate from alsa-driver to 
alsa-kernel.

http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03580.html

* fixed the DMA allocation.
   pci_set_dma_mask() is called together with pci_set_consistent_dma_mask().
   also clean up the double check of mask.

http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03642.html

* added snd_card_set_dev() macro.
* sysfsfied more pci, isapnp and usb drivers.









-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Fri, 05 Aug 2005 20:46:07 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 29 Jul 2005 22:43:18 +0800,
> > Raymond wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >>>At Wed, 08 Jun 2005 17:06:39 +0800,
> >>>Raymond wrote:
> >>>
> >>>
> >>>
> >>>>Is there any reason to make this change ?
> >>>>
> >>>>alsa-kernel/pci/au88x0/au88x0.c
> >>>>@@ -144,15 +144,18 @@
> >>>>        // check PCI availability (DMA).
> >>>>        if ((err = pci_enable_device(pci)) < 0)
> >>>>                return err;
> >>>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> >>>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> >>>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
> >>>>                printk(KERN_ERR "error to set DMA mask\n");
> >>>>+               pci_disable_device(pci);
> >>>>                return -ENXIO;
> >>>>        }
> >>>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> >>>
> >>>
> >>>This is clean up.
> >>>
> >>>
> >>>
> >>>>        chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> >>>>-       if (chip == NULL)
> >>>>+       if (chip == NULL) {
> >>>>+               pci_disable_device(pci);
> >>>>                return -ENOMEM;
> >>>>+       }
> >>>
> >>>
> >>>This fixes the PCI state in the error path.
> >>>
> >>>
> >>>
> >>>>        chip->card = card;
> >>>>
> >>>>@@ -202,6 +205,8 @@
> >>>>                goto alloc_out;
> >>>>        }
> >>>>
> >>>>+       snd_card_set_dev(card, &pci->dev);
> >>>>+
> >>>>        *rchip = chip;
> >>>
> >>>
> >>>And this sets up the missing sysfs stuff.
> >>>
> >>>
> >>
> >>It seem that these two patches for Kernel 2.6 were lost when au88x0 
> >>migrate from alsa-driver to alsa-kernel.
> > 
> > 
> > You're right.  It seems dropped at that time accidentally.
> > 
> > Could you care to post a patch to fix them?
> > 
> > 
> 
> 
> au88x0_fix_fc4.patch (file# 4739)
> 
> http://savannah.nongnu.org/patch/?func=detailitem&item_id=4107
> 
> posted in the open vortex project patch manager (item id #4107) add back 
> the two patches lost during au88x0 migrate from alsa-driver to alsa-kernel.
> 
> http://savannah.nongnu.org/patch/download.php?item_id=4107&item_file_id=4739
> 
> 
> 
> These are the two patches lost during au88x0 migrate from alsa-driver to 
> alsa-kernel.
> 
> http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03580.html
> 
> * fixed the DMA allocation.
>    pci_set_dma_mask() is called together with pci_set_consistent_dma_mask().
>    also clean up the double check of mask.
> 
> http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03642.html
> 
> * added snd_card_set_dev() macro.
> * sysfsfied more pci, isapnp and usb drivers.

Fine, then could you make patches applicable to alsa-kernel tree and 
post them to the list?
Also, please give signed-off-by for each patch.


thanks,

Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Sat, 20 Aug 2005 08:45:47 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 05 Aug 2005 20:46:07 +0800,
> > Raymond wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >>>At Fri, 29 Jul 2005 22:43:18 +0800,
> >>>Raymond wrote:
> >>>
> >>>
> >>>>Takashi Iwai wrote:
> >>>>
> >>>>
> >>>>>At Wed, 08 Jun 2005 17:06:39 +0800,
> >>>>>Raymond wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Is there any reason to make this change ?
> >>>>>>
> >>>>>>alsa-kernel/pci/au88x0/au88x0.c
> >>>>>>@@ -144,15 +144,18 @@
> >>>>>>       // check PCI availability (DMA).
> >>>>>>       if ((err = pci_enable_device(pci)) < 0)
> >>>>>>               return err;
> >>>>>>-       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> >>>>>>+        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> >>>>>>+               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
> >>>>>>               printk(KERN_ERR "error to set DMA mask\n");
> >>>>>>+               pci_disable_device(pci);
> >>>>>>               return -ENXIO;
> >>>>>>       }
> >>>>>>-       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> >>>>>
> >>>>>
> >>>>>This is clean up.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>       chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> >>>>>>-       if (chip == NULL)
> >>>>>>+       if (chip == NULL) {
> >>>>>>+               pci_disable_device(pci);
> >>>>>>               return -ENOMEM;
> >>>>>>+       }
> >>>>>
> >>>>>
> >>>>>This fixes the PCI state in the error path.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>       chip->card = card;
> >>>>>>
> >>>>>>@@ -202,6 +205,8 @@
> >>>>>>               goto alloc_out;
> >>>>>>       }
> >>>>>>
> >>>>>>+       snd_card_set_dev(card, &pci->dev);
> >>>>>>+
> >>>>>>       *rchip = chip;
> >>>>>
> >>>>>
> >>>>>And this sets up the missing sysfs stuff.
> >>>>>
> >>>>>
> >>>>
> >>>>It seem that these two patches for Kernel 2.6 were lost when au88x0 
> >>>>migrate from alsa-driver to alsa-kernel.
> >>>
> >>>
> >>>You're right.  It seems dropped at that time accidentally.
> >>>
> >>>Could you care to post a patch to fix them?
> >>>
> >>>
> >>
> >>
> >>au88x0_fix_fc4.patch (file# 4739)
> >>
> >>http://savannah.nongnu.org/patch/?func=detailitem&item_id=4107
> >>
> >>posted in the open vortex project patch manager (item id #4107) add back 
> >>the two patches lost during au88x0 migrate from alsa-driver to alsa-kernel.
> >>
> >>http://savannah.nongnu.org/patch/download.php?item_id=4107&item_file_id=4739
> >>
> >>
> >>
> >>These are the two patches lost during au88x0 migrate from alsa-driver to 
> >>alsa-kernel.
> >>
> >>http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03580.html
> >>
> >>* fixed the DMA allocation.
> >>   pci_set_dma_mask() is called together with pci_set_consistent_dma_mask().
> >>   also clean up the double check of mask.
> >>
> >>http://www.mail-archive.com/alsa-cvslog@lists.sourceforge.net/msg03642.html
> >>
> >>* added snd_card_set_dev() macro.
> >>* sysfsfied more pci, isapnp and usb drivers.
> > 
> > 
> > Fine, then could you make patches applicable to alsa-kernel tree and 
> > post them to the list?
> > Also, please give signed-off-by for each patch.
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> 
> I am still using Kernel 2.4 which is not affected by the missing of 
> these two patches.
> 
> Is the missing of "snd_card_set_dev(card, &pci->dev);" affected only 
> some distrubtion of Kernel 2.6 (32-bits platform) ?
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=299

Sure, it's only for 2.6, and it can't be critical.
It just adds the sysfs entry for udev/hal.  It must work fine without
it.

> The reporter of bug 216 using Kernel 2.4 and the reporter of bug 299 
> using Kernel 2.6

Then this will fix that bug very unlikely.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Takashi Iwai wrote:
> At Sat, 20 Aug 2005 08:45:47 +0800,
> Raymond wrote:
> 
>>
>>I am still using Kernel 2.4 which is not affected by the missing of 
>>these two patches.
>>
>>Is the missing of "snd_card_set_dev(card, &pci->dev);" affected only 
>>some distrubtion of Kernel 2.6 (32-bits platform) ?
>>
>>https://bugtrack.alsa-project.org/alsa-bug/view.php?id=299
> 
> 
> Sure, it's only for 2.6, and it can't be critical.
> It just adds the sysfs entry for udev/hal.  It must work fine without
> it.
> 
> 
>>The reporter of bug 216 using Kernel 2.4 and the reporter of bug 299 
>>using Kernel 2.6
> 
> 
> Then this will fix that bug very unlikely.
> 
> 
> Takashi
> 

For au88x0 on AMD64

One of the au8810 user still experience hangs when using GAIM.

Igor V. Kovalenko reported his patch is OK for his au8820

http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948#comment43

There are no feed back from the reporters of ALSA BTS and another au8830 
user in the alsa.user mailing list.

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047  au8810
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138  au8820
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1025  au8830

Would you related this three bugs report ?

They can try Igor V. Kovalenko's patch at the openvortex project.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Tue, 23 Aug 2005 23:20:00 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Sat, 20 Aug 2005 08:45:47 +0800,
> > Raymond wrote:
> > 
> >>
> >>I am still using Kernel 2.4 which is not affected by the missing of 
> >>these two patches.
> >>
> >>Is the missing of "snd_card_set_dev(card, &pci->dev);" affected only 
> >>some distrubtion of Kernel 2.6 (32-bits platform) ?
> >>
> >>https://bugtrack.alsa-project.org/alsa-bug/view.php?id=299
> > 
> > 
> > Sure, it's only for 2.6, and it can't be critical.
> > It just adds the sysfs entry for udev/hal.  It must work fine without
> > it.
> > 
> > 
> >>The reporter of bug 216 using Kernel 2.4 and the reporter of bug 299 
> >>using Kernel 2.6
> > 
> > 
> > Then this will fix that bug very unlikely.
> > 
> > 
> > Takashi
> > 
> 
> For au88x0 on AMD64
> 
> One of the au8810 user still experience hangs when using GAIM.
> 
> Igor V. Kovalenko reported his patch is OK for his au8820
> 
> http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948#comment43
> 
> There are no feed back from the reporters of ALSA BTS and another au8830 
> user in the alsa.user mailing list.
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047  au8810
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138  au8820
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1025  au8830
> 
> Would you related this three bugs report ?
> 
> They can try Igor V. Kovalenko's patch at the openvortex project.

The current code can't work obviously on 64bit architecture because
of the following definition:

struct snd_vortex {
	...
	unsigned long __iomem *mmio;
	...
};

It must be u32 if you want to be architecture independent.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op dinsdag 23 augustus 2005 19:18, schreef Takashi Iwai:
> At Tue, 23 Aug 2005 23:20:00 +0800,
>
> Raymond wrote:
> > Takashi Iwai wrote:
> > > At Sat, 20 Aug 2005 08:45:47 +0800,
> > >
> > > Raymond wrote:
> > >>I am still using Kernel 2.4 which is not affected by the missing of
> > >>these two patches.
> > >>
> > >>Is the missing of "snd_card_set_dev(card, &pci->dev);" affected only
> > >>some distrubtion of Kernel 2.6 (32-bits platform) ?
> > >>
> > >>https://bugtrack.alsa-project.org/alsa-bug/view.php?id=299
> > >
> > > Sure, it's only for 2.6, and it can't be critical.
> > > It just adds the sysfs entry for udev/hal.  It must work fine without
> > > it.
> > >
> > >>The reporter of bug 216 using Kernel 2.4 and the reporter of bug 299
> > >>using Kernel 2.6
> > >
> > > Then this will fix that bug very unlikely.
> > >
> > >
> > > Takashi
> >
> > For au88x0 on AMD64
> >
> > One of the au8810 user still experience hangs when using GAIM.
> >
> > Igor V. Kovalenko reported his patch is OK for his au8820
> >
> > http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948#comment43
> >
> > There are no feed back from the reporters of ALSA BTS and another au8830
> > user in the alsa.user mailing list.
> >
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047  au8810
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138  au8820
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1025  au8830
> >
> > Would you related this three bugs report ?
> >
> > They can try Igor V. Kovalenko's patch at the openvortex project.
>
> The current code can't work obviously on 64bit architecture because
> of the following definition:
>
> struct snd_vortex {
> 	...
> 	unsigned long __iomem *mmio;
> 	...
> };
>
> It must be u32 if you want to be architecture independent.

that doesn't mean much, you need to see how it handles adding to it, with all 
the typecasts...

the one i'm running has: (this IS architecture independent)

...
        struct gameport *gameport;

        /* PCI hardware resources */
        unsigned long io;
        void __iomem *mmio;
        unsigned int irq;
        spinlock_t lock;
...


anyway, i really need to do the latest tests, i have way too many adb failures 
lately.

it mostly happens, when watching a movie and gaim starts a little sound.

i've determined that it's not likely to be the max available sounds, but more 
likely to be the weird scheduling of sounds at the same time

i urge you people to chat more using some program that starts little sounds 
so, you have lots of short start and stops at the same time, maybe use gaim 
for ICQ and IRCing, that always gives me plenty of sounds...

PS: i forgot the latest patch i had to try out.

I'll do one patch to try out, and hope it doesn't require me to reboot this 
machine...

i'm using alsa CVS from some weeks ago, i think

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Takashi Iwai]

At Tue, 23 Aug 2005 23:40:44 +0200,
Alien wrote:
> 
> Op dinsdag 23 augustus 2005 19:18, schreef Takashi Iwai:
> > At Tue, 23 Aug 2005 23:20:00 +0800,
> >
> > Raymond wrote:
> > > Takashi Iwai wrote:
> > > > At Sat, 20 Aug 2005 08:45:47 +0800,
> > > >
> > > > Raymond wrote:
> > > >>I am still using Kernel 2.4 which is not affected by the missing of
> > > >>these two patches.
> > > >>
> > > >>Is the missing of "snd_card_set_dev(card, &pci->dev);" affected only
> > > >>some distrubtion of Kernel 2.6 (32-bits platform) ?
> > > >>
> > > >>https://bugtrack.alsa-project.org/alsa-bug/view.php?id=299
> > > >
> > > > Sure, it's only for 2.6, and it can't be critical.
> > > > It just adds the sysfs entry for udev/hal.  It must work fine without
> > > > it.
> > > >
> > > >>The reporter of bug 216 using Kernel 2.4 and the reporter of bug 299
> > > >>using Kernel 2.6
> > > >
> > > > Then this will fix that bug very unlikely.
> > > >
> > > >
> > > > Takashi
> > >
> > > For au88x0 on AMD64
> > >
> > > One of the au8810 user still experience hangs when using GAIM.
> > >
> > > Igor V. Kovalenko reported his patch is OK for his au8820
> > >
> > > http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948#comment43
> > >
> > > There are no feed back from the reporters of ALSA BTS and another au8830
> > > user in the alsa.user mailing list.
> > >
> > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047  au8810
> > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138  au8820
> > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1025  au8830
> > >
> > > Would you related this three bugs report ?
> > >
> > > They can try Igor V. Kovalenko's patch at the openvortex project.
> >
> > The current code can't work obviously on 64bit architecture because
> > of the following definition:
> >
> > struct snd_vortex {
> > 	...
> > 	unsigned long __iomem *mmio;
> > 	...
> > };
> >
> > It must be u32 if you want to be architecture independent.
> 
> that doesn't mean much, you need to see how it handles adding to it, with all 
> the typecasts...

It's definitely a part of the problems.
You can find that the driver doesn't cast in hwread/hwwrite at all in
the current CVS code (I don't mention about the modified codes).

Most likely there are other problems incompatible with 64bit
architectures, too.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Alien wrote:

> 
> anyway, i really need to do the latest tests, i have way too many adb failures 
> lately.

What do you means when you say "adb failures" ? ( any message in system
log )

> 
> it mostly happens, when watching a movie and gaim starts a little sound.
> 
> i've determined that it's not likely to be the max available sounds, but more 
> likely to be the weird scheduling of sounds at the same time
> 
> i urge you people to chat more using some program that starts little sounds 
> so, you have lots of short start and stops at the same time, maybe use gaim 
> for ICQ and IRCing, that always gives me plenty of sounds...
> 
> PS: i forgot the latest patch i had to try out.

Don't forget the latest patch "Fixed missing spin_unlock" on CVS .

> 
> I'll do one patch to try out, and hope it doesn't require me to reboot this 
> machine...
> 
> i'm using alsa CVS from some weeks ago, i think

Although I can play multiple mono sound streams on device 2 on my au8830.

I don't know why the connection routine of device 2 is disabled only on
au8810 driver.

If you have any application using device 2 to playback (e.g. 3D demo in 
vortexcontrol), wierd things may happen on au8810 since some of the 
route and mixer of device 2 playback stream has not been assigned.








-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op donderdag 25 augustus 2005 19:12, schreef Raymond:
> Alien wrote:
> > anyway, i really need to do the latest tests, i have way too many adb
> > failures lately.
>
> What do you means when you say "adb failures" ? ( any message in system
> log )

found one:
Aug 22 21:55:45 queen kernel: Vortex: vortex_fifo_setadbctrl fail

after that, i have to restart alsa

but this is only partly the problem, it's only lately that i see that error 
when there are problems, before i never saw anything in logs and it still had 
the same problem

there is one thing though, i haven't gotten the error where snd-au8810 has 210 
dependencies anymore.

if i now have an error with sound, i only have to kill all appl using alsa, 
and restart alsa (when that dep error was there, i had to reboot to have 
sound + ps aux crashed the console and lotsa other things, applications using 
alsa had weird statusses etc...)

> > it mostly happens, when watching a movie and gaim starts a little sound.
> >
> > i've determined that it's not likely to be the max available sounds, but
> > more likely to be the weird scheduling of sounds at the same time
> >
> > i urge you people to chat more using some program that starts little
> > sounds so, you have lots of short start and stops at the same time, maybe
> > use gaim for ICQ and IRCing, that always gives me plenty of sounds...
> >
> > PS: i forgot the latest patch i had to try out.
>
> Don't forget the latest patch "Fixed missing spin_unlock" on CVS .

i'll definately try that one sometime later tonight, it seems it might fit the 
problem

> > I'll do one patch to try out, and hope it doesn't require me to reboot
> > this machine...
> >
> > i'm using alsa CVS from some weeks ago, i think
>
> Although I can play multiple mono sound streams on device 2 on my au8830.
>
> I don't know why the connection routine of device 2 is disabled only on
> au8810 driver.
>
> If you have any application using device 2 to playback (e.g. 3D demo in
> vortexcontrol), wierd things may happen on au8810 since some of the
> route and mixer of device 2 playback stream has not been assigned.

that's odd ...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

Alien wrote:
> Op donderdag 25 augustus 2005 19:12, schreef Raymond:
> 
>>Alien wrote:
>>
>>>anyway, i really need to do the latest tests, i have way too many adb
>>>failures lately.
>>
>>What do you means when you say "adb failures" ? ( any message in system
>>log )
> 
> 
> found one:
> Aug 22 21:55:45 queen kernel: Vortex: vortex_fifo_setadbctrl fail
> 
> after that, i have to restart alsa
> 
> but this is only partly the problem, it's only lately that i see that error 
> when there are problems, before i never saw anything in logs and it still had 
> the same problem
> 
> there is one thing though, i haven't gotten the error where snd-au8810 has 210 
> dependencies anymore.
> 
> if i now have an error with sound, i only have to kill all appl using alsa, 
> and restart alsa (when that dep error was there, i had to reboot to have 
> sound + ps aux crashed the console and lotsa other things, applications using 
> alsa had weird statusses etc...)
> 
> 

We cannot change NR_ADB of au8810 from 16 to 32 or change NR_ADB of 
au8830 from 32 to 16.

http://savannah.nongnu.org/support/?func=detailitem&item_id=102951

This means hw:0,0 of au8810, au8820, au8830 behave differently even they 
have 16 SRC



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Manuel Jander]

Hi,

On Fri, 2005-08-26 at 01:12 +0800, Raymond wrote:
> Alien wrote:
> > 
> > PS: i forgot the latest patch i had to try out.
> 
> Don't forget the latest patch "Fixed missing spin_unlock" on CVS .
> 
> > 
> > I'll do one patch to try out, and hope it doesn't require me to reboot this 
> > machine...
> > 
> > i'm using alsa CVS from some weeks ago, i think
> 
> Although I can play multiple mono sound streams on device 2 on my au8830.
> 
> I don't know why the connection routine of device 2 is disabled only on
> au8810 driver.
> 
> If you have any application using device 2 to playback (e.g. 3D demo in 
> vortexcontrol), wierd things may happen on au8810 since some of the 
> route and mixer of device 2 playback stream has not been assigned.

The WT and A3D subsystems for AU8810 are disabled, because:

- The AU8810 does not has any WT engine.
- The AU8810 A3D slices/sources register addresses have not been
confirmed and seem to be wrong. It looks like the AU8810 has 8 3D
sources instead of the 16 that the AU8830 has, but further work is
required, starting with the disassemble of a AU8810 WDM driver, in order
to find out/conform the 3D slices/sources register addresses.


Best Regards
Manuel




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

Op donderdag 25 augustus 2005 20:58, schreef Manuel Jander:
> Hi,
>
> On Fri, 2005-08-26 at 01:12 +0800, Raymond wrote:
> > Alien wrote:
> > > PS: i forgot the latest patch i had to try out.
> >
> > Don't forget the latest patch "Fixed missing spin_unlock" on CVS .
> >
> > > I'll do one patch to try out, and hope it doesn't require me to reboot
> > > this machine...
> > >
> > > i'm using alsa CVS from some weeks ago, i think
> >
> > Although I can play multiple mono sound streams on device 2 on my au8830.
> >
> > I don't know why the connection routine of device 2 is disabled only on
> > au8810 driver.
> >
> > If you have any application using device 2 to playback (e.g. 3D demo in
> > vortexcontrol), wierd things may happen on au8810 since some of the
> > route and mixer of device 2 playback stream has not been assigned.
>
> The WT and A3D subsystems for AU8810 are disabled, because:
>
> - The AU8810 does not has any WT engine.
> - The AU8810 A3D slices/sources register addresses have not been
> confirmed and seem to be wrong. It looks like the AU8810 has 8 3D
> sources instead of the 16 that the AU8830 has, but further work is
> required, starting with the disassemble of a AU8810 WDM driver, in order
> to find out/conform the 3D slices/sources register addresses.

is it possible that this could have some negative outcome on the driver? in 
particular, that it's not initialized and might be trying to be used at some 
point?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Alien]

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

I don't think it'll be faster, gcc -O2 will have changed it accordingly 
anyway, without optimization it might be faster, but the thing is that it 
just looks cleaner...

Op woensdag 8 juni 2005 11:06, schreef Raymond:
> au8830 can be loaded after I change "unsigned long __iomem *mmio" to
> "void __iomem *mmio" on my 32 bits machine.
>
> How can I obtain the disassembly of snd-au8830.o to prove that it run
> faster than before ( without bitshift ) ?
>
> alsa-kernel/pci/au88x0/au88x0.h
>
> @@ -41,8 +41,8 @@
>
>   #define        VORTEX_DMA_MASK 0xffffffff
>
>
> -#define        hwread(x,y) readl((x)+((y)>>2))
> -#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
> +#define        hwread(x,y) readl((x)+(y))
> +#define        hwwrite(x,y,z) writel((z),(x)+(y))
>
> @@ -172,7 +172,7 @@
>
>          /* PCI hardware resources */
>          unsigned long io;
> -       unsigned long __iomem *mmio;
> +       void __iomem *mmio;
>          unsigned int irq;
>          spinlock_t lock;
>
>
>
> I don't have any MPU401 device to test this change.
>
>
> alsa-kernel/pci/au88x0/au88x0_mpu401.c
> @@ -95,7 +95,7 @@
>                  return temp;
>          }
>   #else
> -       port = (unsigned long)(vortex->mmio + (VORTEX_MIDI_DATA >> 2));
> +       port = (unsigned long)(vortex->mmio + VORTEX_MIDI_DATA);
>          if ((temp =
>               snd_mpu401_uart_new(vortex->card, 0, MPU401_HW_AUREAL, port,
>                                   1, 0, 0, &rmidi)) != 0) {
> @@ -105,7 +105,7 @@
>                  return temp;
>          }
>          mpu = rmidi->private_data;
> -       mpu->cport = (unsigned long)(vortex->mmio + (VORTEX_MIDI_CMD >>
> 2)); +       mpu->cport = (unsigned long)(vortex->mmio + VORTEX_MIDI_CMD);
> #endif
>          vortex->rmidi = rmidi;
>          return 0;
>
>
> Is there any reason to make this change ?
>
> alsa-kernel/pci/au88x0/au88x0.c
> @@ -144,15 +144,18 @@
>          // check PCI availability (DMA).
>          if ((err = pci_enable_device(pci)) < 0)
>                  return err;
> -       if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> +        if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> +               pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
>                  printk(KERN_ERR "error to set DMA mask\n");
> +               pci_disable_device(pci);
>                  return -ENXIO;
>          }
> -       pci_set_dma_mask(pci, VORTEX_DMA_MASK);
>
>          chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> -       if (chip == NULL)
> +       if (chip == NULL) {
> +               pci_disable_device(pci);
>                  return -ENOMEM;
> +       }
>
>          chip->card = card;
>
> @@ -202,6 +205,8 @@
>                  goto alloc_out;
>          }
>
> +       snd_card_set_dev(card, &pci->dev);
> +
>          *rchip = chip;
>
>          return 0;
>
> Those changes in au88x0_eq.h and au88x0_eqdata.c seem WRONG.
>
> -       unsigned int *this00;   /*CAsp4HwIO */
> +       u32 ptr_this00;         /*CAsp4HwIO */
>
>
> 2 * 10 seem related to the 10-bands stereo EQ.
>
>
> -       u16 this14[32];         /* SetLeftGainsTarget: Left (and right?)
> +       u16 this14_array[32];   /* SetLeftGainsTarget: Left (and right?)
>
>          /* Set gains. */
> -       memset(eq->this14, 0, 2 * 10);
> +       memset(eq->this14_array, 0, sizeof(eq->this14_array));
>
>
>
>
> -static long eq_levels[32] = {
> +static u16 eq_levels[64] = {
> +       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +       0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>
>
> http://lists.nongnu.org/archive/html/openvortex-dev/2003-12/msg00007.html
>
> There is no kcontrol to change vortex->xt_mode for speaker wide, speaker
> narrow, speaker Diamond , headphones to test the Crosstalk canceler
>
> long -> s32
> short -> s16
>
> alsa-kernel/pci/au88x0/au88x0_xtalk.h
> @@ -39,11 +39,11 @@
>   #define XT_SPEAKER1            3
>   #define XT_DIAMOND             4
>
> -typedef long xtalk_dline_t[XTDLINE_SZ];
> -typedef short xtalk_gains_t[XTGAINS_SZ];
> -typedef short xtalk_instate_t[XTINST_SZ];
> -typedef short xtalk_coefs_t[5][5];
> -typedef short xtalk_state_t[5][4];
> +typedef u32 xtalk_dline_t[XTDLINE_SZ];
> +typedef u16 xtalk_gains_t[XTGAINS_SZ];
> +typedef u16 xtalk_instate_t[XTINST_SZ];
> +typedef u16 xtalk_coefs_t[5][5];
> +typedef u16 xtalk_state_t[5][4];
>
> Takashi Iwai wrote:
> > At Tue, 7 Jun 2005 17:16:02 +0200,
> >
> > Alien wrote:
> >>[1  <text/plain; iso-8859-1 (quoted-printable)>]
> >>
> >>Op dinsdag 7 juni 2005 17:05, schreef Raymond:
> >>>The patch (diff11.diff) cause segmenation fault on my 32bit machine
> >>>during /etc/init.d/alsasound start
> >>>
> >>>http://savannah.nongnu.org/patch/?func=detailitem&item_id=3948
> >>>
> >>>Do anyone know why readl() and writel() behave different in i386
> >>>(32bits) and AMD64 (64bits) ?
> >>>
> >>>http://sourceforge.net/mailarchive/message.php?msg_id=10773530
> >>>
> >>>
> >>>#ifndef CONFIG_X86_64
> >>>
> >>>#define        hwread(x,y) readl((x)+((y)>>2))
> >>>#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
> >>>
> >>>#else
> >>>
> >>>#define        hwread(x,y) readl((x)+(y))
> >>>#define        hwwrite(x,y,z) writel((z),(x)+(y))
> >>>
> >>>#endif
> >>
> >>that doesn't look good, unless the mmio is void* in 32bit and unsigned
> >> long* in x86_64...
> >>
> >>'unsigned long* mmio' should be preferred and together with '#define
> >>hwread(x,y) readl((x)+(y))' , this works for both platforms
> >
> > I guess using "unsigned long" for both architectures is broken, too.
> > Should be "u32" to be arch-independent.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the office
> luge track? If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ALSA - driver 0001138]: errors when installing au8820 modules

[Raymond]

It seem that no one has informed the bug reporter about the patch and he 
is using Intel X86_64 instead of your AMD 64

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1138

Alien wrote:
> I don't think it'll be faster, gcc -O2 will have changed it accordingly 
> anyway, without optimization it might be faster, but the thing is that it 
> just looks cleaner...
> 
> Op woensdag 8 juni 2005 11:06, schreef Raymond:
> 
>>au8830 can be loaded after I change "unsigned long __iomem *mmio" to
>>"void __iomem *mmio" on my 32 bits machine.
>>
>>How can I obtain the disassembly of snd-au8830.o to prove that it run
>>faster than before ( without bitshift ) ?
>>
>>alsa-kernel/pci/au88x0/au88x0.h
>>
>>@@ -41,8 +41,8 @@
>>
>>  #define        VORTEX_DMA_MASK 0xffffffff
>>
>>
>>-#define        hwread(x,y) readl((x)+((y)>>2))
>>-#define        hwwrite(x,y,z) writel((z),(x)+((y)>>2))
>>+#define        hwread(x,y) readl((x)+(y))
>>+#define        hwwrite(x,y,z) writel((z),(x)+(y))
>>
>>@@ -172,7 +172,7 @@
>>
>>         /* PCI hardware resources */
>>         unsigned long io;
>>-       unsigned long __iomem *mmio;
>>+       void __iomem *mmio;
>>         unsigned int irq;
>>         spinlock_t lock;
>>
>>
>>
>>I don't have any MPU401 device to test this change.
>>
>>
>>alsa-kernel/pci/au88x0/au88x0_mpu401.c
>>@@ -95,7 +95,7 @@
>>                 return temp;
>>         }
>>  #else
>>-       port = (unsigned long)(vortex->mmio + (VORTEX_MIDI_DATA >> 2));
>>+       port = (unsigned long)(vortex->mmio + VORTEX_MIDI_DATA);
>>         if ((temp =
>>              snd_mpu401_uart_new(vortex->card, 0, MPU401_HW_AUREAL, port,
>>                                  1, 0, 0, &rmidi)) != 0) {
>>@@ -105,7 +105,7 @@
>>                 return temp;
>>         }
>>         mpu = rmidi->private_data;
>>-       mpu->cport = (unsigned long)(vortex->mmio + (VORTEX_MIDI_CMD >>
>>2)); +       mpu->cport = (unsigned long)(vortex->mmio + VORTEX_MIDI_CMD);
>>#endif
>>         vortex->rmidi = rmidi;
>>         return 0;
>>
>>



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20