On Fri, Mar 09, 2007 at 08:22:22AM +0100, Marco Braga wrote:
> I have exactly the same problem with a custom board based on an Alchemy
> Au1500, kernel 184.108.40.206 from linux-mips.org
> No solution at the moment.
The only solution I have yet is a small shell-script to load the
kernel driver and checks if all 38 controls are available. If not
it removes the driver and loads it again. Most of the times it
works right away and it's a very rare case that it takes the
script 8 loads to get all controls. I did around 143.000 tests
and 120.000 times it loaded correctly the first time, 20.000 the
seconds time, it faded gradually after that and only one time it
took 8 times.
But unfortunately, this work-around is far from perfect. It's
possible for the driver to load with all 38 controls, but wrong
control data. Let's say the CD volume control has a normal range
that is 0 - 31, and it happens sometimes the range is fucked up.
Let's say 0 - 15. Again snd_au1000_ac97_read() to blame.
Anyway, you don't want that, for obvious reason!
So as a more robust work-around, I'm almost finished with a small
Python program that reads /var/lib/alsa/asound.state (the saved
mixer values) and checks these against the values received from
the ALSA layer. I've patched pyalsaaudio-0.2 (the most usable
Python ALSA bindings IMHO) a little bit, and can now ask the
ALSA layer all relevant information needed. When it's completely
finished I shall mail the patches to the maintainer in the hope
he'll include them. And if finished I'm willing to share the
small Python program too, if anyone asks.
But what does this gives us? In the long run not much, to be
honoust! Like I told in my first email, I did also do a lot of
other tests and if the driver is loaded correctly things do work
well. So in the short run this is a good workable solution for
But in the long run the kernel driver needs te be fixed of
course. And unfortunately I still consider myself a fool when it
comes to kernel programming. I have already decided to dive into
this a little bit in my spare time, but I'm afraid I lack the
right kernel knowledge when it comes to solve this issue. Charles
Eidsnes nicely answered my email with some tips, but also told me
he has other priorities than to dive into this. If one is up to
the challange to fix this he is willing to answer some questions,
but he's not actively involved with mips-linux anymore. Anyway,
here is his tip to look into:
On Wed, Mar 07, 2007 at 06:48:05PM -0500, Charles Eidsness wrote:
> I'm not sure what could cause this issue. Given your results on
> different hardware I think you're right in assuming that it's
> not a hardware issue (at least not with your AC'97 Codec). It
> kind of seems like a S/W timing issue. All that I can think of
> to suggest it to try adding some delays during the read cycle
> and see if that helps. It may be that there is some lag between
> when the processor says the data register has data, and when it
> really has data. You could also try to implement an interrupt
> based read, you may have better luck with it than I did. I gave
> up because it was taking me too long to get it to work, and I
> didn't mind the extra over-head of a polled read.
Sounds like some good advice to look into. Althought I'm a little
bit confused about why the AC97 controller would state that
information is available, when it is really not yet available.
Sounds like plain wrong to me. But then again, do not forget that
I'm the fool without a lot of knowledge on the subject again. :)
Anyway, to end up this long, long writing. Within a couple of
hours I'm of to the south of France to do some serious
snowboarding, so I will not look into this for like a little more
than a week. After that I will finish the Python work-around and
in my spare time shall dive into a real solution, but not with
much hope of fixing it for real.
Thanks for your reply and maybe with this little bit of extra
information some kernel hacker has his druthers and fixes the
bloody thing. If not just wait what I come up with, but please
don't hold your breath to it.
$ cat ~/.signature
Freddy Spierenburg <email@example.com> 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!
Description: Digital signature