AW: drivers/sound/i810_audio.c bug and patch

["Mehmet Ceyran" <mceyran@web.de>]

Hi Mike,

>> Well, why not? The loop will only go through it's body 100 times if 
>> the hardware is actually not available or corrupt and even in this 
>> case the whole block won't take much time. It works for me and it 
>> should work for all the other people using this driver too:
> Why busy wait especially when you can sleep 1ms each time and poll
less?

Well, I can tell you why I chose "busy wait" (kind of brainstorming):

- Why did the originator of the driver made the loop with 10 turns,
which is "busy wait" in your definition too?

- Imagine you have workers and you give them a job that's supposed to be
finished in six minutes. But these workers actually need seven minutes,
which you don't know. If that job is urgent, would you rather look if
it's done yet every 60 minutes or every six minutes? In the first case
(that's your model), you would get your positive result in one hour, in
the second case (my model), you'd get it in 12 minutes.

- Seeing the constant of HZ/20 in "schedule_timeout(HZ/20);" gives me
the feeling that this value is taken from some specification. Perhaps
it's from a i810 datasheet (I will look at that later because it's very
late now), but my fix is for SiS 7012 which could have slightly
different characteristics. In this case, by doing my "busy wait", you
don't modify the existing code which will initialize the chip in less
than or equal to 10 turns.

- When the driver is loaded at boot time I think it's the only piece of
code which is running at that moment, I don't think there are any other
threads working during driver init. If it's loaded as a module, the one
who loads it waits for its results anyway. It's almost impossible that
doing this "busy wait" will affect a running system with many
concurrently running processes at a high system load _noticeably_. It
will instead come to a result faster if the hardware is available (see
point 1).

Best Regards,
Mehmet