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

David Woodhouse
2001-01-30T15:10:16Z

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