After a lot of cleanups and coding style changes, my driver still has some
things that must be fixed properly. Busy-waits are one of those.
The most used busy-waits have a timeout of 10ms and 100ms and they are
called with a spinlock_irq held or from the irq handler. With my card
the longest wait I measured was 190us, so I guess it's ok.
But two functions, read_dsp() and write_dsp() have a timeout of 10s. They
are used exclusively for loading the DSP firmware and the ASICs. They are
very fast on my card, but other cards (the driver supports 8 cards) may be
slower. I was thinking about calling the scheduler in case of a long wait,
but two cards need to reload the ASICs in order to switch between S/PDIF and
ADAT and one card also has to reload the ASICs when the sample rate crosses
the 50KHz boundary. Since those operations are protected by a spinlock, it's
not a great idea to call the scheduler. Any hint ? Perhaps we could just
live with it, since the reload is not required very often...
While looking for examples I noticed that all busy waits in the ens1370
driver have this form:
for (t = 0; t < POLL_COUNT; t++) {
if (inl(xxxx))
break;
}
IMHO it isn's correct because it waits for an amout of time that depends on
the processor speed.
--
Giuliano.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
