Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[David Woodhouse <dwmw2@infradead.org>]

jadb@redhat.com said:
> A recent example I came across is in the MTD code which invokes the
> erase algorithm for CFI memory. This algorithm spews a command
> sequence  to the flash chips followed by a list of sectors to erase.
> Following  each sector adress, the chip will wait for 50usec for
> another address,  after which timeout it begins the erase cycle. With
> a RTLinux-style  approach the driver is eventually going to fail to
> issue the command in  time.

That code is within spin_lock_bh(), isn't it? So with the current 
preemption approach, it's not going to get interrupted except by a real 
interrupt, which hopefully won't take too long anyway. 

spin_lock_bh() is used because eventually we're intending to stop the erase 
routine from waiting for completion, and make it poll for completion from a 
timer routine. We need protection against concurrent access to the chip 
from that timer routine. 

But perhaps we could be using spin_lock_irq() to prevent us from being
interrupted and failing to meet the timing requirements for subsequent 
commands to the chip if IRQ handlers really do take too long. 

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/