[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
