sharp driver dissimilarities

[David Woodhouse]

ds at schleef.org said:
>  The write process uses word_write_time and adjusts it so that it
> settles at the average write time.  The problem with that method is
> that half the time, you will be sleeping for 10 ms on something that
> may finish in 1 more usec of waiting.

We only sleep for that long if current->need_resched.

But you're right that udelay() is fairly pointless - we should just spin 
polling the flash. Assuming there aren't power consumption issues - but as 
udelay is always a CPU spin anyway, I think that's OK.


ds at schleef.org said:
>  A similar thing is true about block erase -- the schedule_timeout(HZ)
> means that the earliest time the driver will notice that the chip is
> done erasing is 1 s. 

There's a tradeoff here between performance of the flash driver and 
performance of the rest of the system. We should probably sleep only if 
current->need_resched, I suppose.


ds at schleef.org said:
>  I also didn't understand how the locking was supposed to work, so I
> rewrote it in the sharp driver.  I like it better. 

The problem with having a single generic _wait function is that they're not 
actually the same. When you want to read, you can interrupt erases or 
writes. When you want to write, you can interrupt erases.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org