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

David Woodhouse (dwmw2@infradead.org)
Tue, 30 Jan 2001 15:08:04 +0000


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/