Why timer interrupt is disabled?
andreev at niisi.msk.ru
Fri May 25 20:17:50 EDT 2001
David Woodhouse wrote:
>andreev at niisi.msk.ru said:
>>I know that JFFS is the better choice, but
>>I must use the FTL driver, because there is installed X-server on my
>I don't see the logic. The Compaq iPAQ works quite well with the X-server
>in the JFFS2 filesystem.
I don`t want to format my flash partition write now. Besides it doesn`t
matter. Of course i`ll use JFFS in the future.
>>I think that unlocking of the io_request_lock inside ftl driver
>>is not a good idea, because the do_ftl_request must be atomic.
>My understanding is that it's perfectly safe to drop the io_request_lock as long as we only look at the request at the head of the queue. There's no
>need for do_ftl_request to be atomic - and in fact it cannot be atomic
>because the flash read and write calls may sleep.
I think, if write call sleeps, than we must return. Do i wrong?
Locking of io_request_lock and disabling interrupts, are mading in
block devices common driver. I read the kernel-api documentation in
Documentation/DocBook/kernel-api/r10011.html: " A global spin lock
$io_request_lock must be held while manipulating the requests on the
Besides, if we unlock the io_request_lock and enable all interrupts
it might to occur this thing:
While we are reading or writing data to the flash, the timer interrupt
is happens. Next, the schedule() called, and an other process begins to
write or read data to the flash. Can you guarantee, that flash is
protected by locks and "chips->state" inside the CFI driver? I mean: if
we write the READ_STATUS command to flash inside context of first
process, and trying to read data inside context of second process, than
we read status, but not data.
In all cases we need to enable timer ticks, anywhere in flash. It is
the simplies way i think...
More information about the linux-mtd