At Wed, 28 Apr 2004 23:09:36 +0200,
Giuliano Pochini wrote:
>
>
>
> 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...
the question is whether you really need spinlock to protect the
context with such a delay. if the interrupt handler doesn't touch
with this data concurrently, you can protect it with mutex and do
schedule().
> 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.
yes, it'd be better. but it won't make big difference between
machines because the PCI bus speed is limited, and the loop count
above is big enough...
Takashi
-------------------------------------------------------
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
