Hi Marco, 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 2.6.17.14 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 me. 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 <freddy@xxxxxxxxxxxxxxx> 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
