linux-mips
[Top] [All Lists]

Trouble with sound/mips/au1x00.c AC97 driver

To: Charles Eidsness <charles@cooper-street.com>
Subject: Trouble with sound/mips/au1x00.c AC97 driver
From: Freddy Spierenburg <freddy@dusktilldawn.nl>
Date: Wed, 7 Mar 2007 11:49:30 +0100
Cc: linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.13 (2006-08-11)
Hi Charles,

I'm experiencing strange behaviour with the sound/mips/au1x00.c
AC97 driver. I'm using kernel 2.6.16, but 2.6.20 gives me the
same results.

When I load the driver sometimes (frequently enough that it's a
serious problem) I do not get all 38 simple mixer controls.
Sometimes I'm missing one or more controls, but in a more rare
situation it also happens that a control holds the wrong min/max
values. And in an even more rare situation I get the error below
while loading the driver:

        AC'97 0 access error (not audio or modem codec)

I have tried to track it down and it all boils down to the
snd_au1000_ac97_read() routine, I think. When I try to debug the
problem, I see that most of the time the res and val variables
compared in snd_ac97_try_bit() from sound/pci/ac97/ac97_codec.c
do not appear to be equal. Hence the missing controls. It looks
to me that snd_au1000_ac97_read() is not returning a value
expected.

When I look at the snd_au1000_ac97_read() implementation it looks
good to me. I've read the AU1100 Processor Data Book and your
routine does exactly the thing needed to read data from the AC97
controller. I've also inspected the whole thing a little bit and
I never receive a 'au1000 AC97: AC97 command read timeout'. Never
is a command still pending before you stop try to poll for the
sane situation and never is an answer not yet received from the
codec before you stop polling for it. And the poll values are
never close to the 0x5000 max you specify. For the latter test
(the test if the data is available) I have also checked if the
data is available right away (i==0). This happens rarely and does
not cause trouble if it happens.

So there is not much that I understand that goes wrong in this
routine. I might be wrong of course. Any insight from real kernel
hackers?

I really do get the feeling that it's a hardware thing. But my
hardware engineer doesn't yet believe that. And I'm afraid he has
sound (sic :) reasoning. I've tested this code on two different platforms.
The first is an official AMD SYRAH DbAu1100 board with a Sigmatel
STAC9752T audio codec and the second is our own Balvenie board
(based on the DbAu1100 design) with an Wolfson WM9705 audio
codec. Both platforms experience the same problems.

We have also checked all the timings to and from the codec with
an oscilloscope and they are up to spec. Nothing strange
happening over there.

What I've also done is play a sound file constantly over the
course of several days. During that playing I constantly did some
muting/unmuting of the 'Master', 'Master Mono' and 'Headphone'
output. I connected some speakers and the small shell-script I
wrote rotated the audio in a nice loop around the speakers. This
happened like every second or so. No error messages from the
amixer utility over that course of days and no error message from
aplay whatsoever. I have also never heard any strange glitch in
the playing of audio, but if only a few samples are missing or
tampered it might be impossible to hear.

Anyway, does anyone have ever experienced this trouble and have
any clue what might causes it?


-- 
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl>  http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1  E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>