Re: Flash chip locking

[Brendan Simon <brendan.simon@ctam.com.au>]

David Woodhouse wrote:
> 
> So we try to keep the latency down to a minimum. Rather than the naïve 
> inner loop which looked like this:
> 
> foreach(word to write) {
> 	spin_lock_bh();
> 	writeb(WRITE_COMMAND);
> 	writeb(datum);
> 	while (!done)
> 		;
> 	spin_unlock_bh();
> }
> 
> .... we do something more like
> 
> foreach(word to write) {
> 
> retry:
> 	spin_lock_bh();
> 	if (!ready) {
> 		spin_unlock()
> 		udelay(a little while);
> 		goto retry;
> 	}
> 	writeb(WRITE_COMMAND);
> 	writeb(datum);
> 	spin_unlock_bh();
> 	udelay(expected time for the write we just started);
> 	spin_lock_bh();
> 	check final status, loop or whatever
> 	spin_unlock_bh();
Or to avoid ugly "goto" statements.
   spin_lock_bh();
   while (!ready)
   {
       spin_unlock()
       udelay(a_little_while);
       spin_lock_bh();
   }

You are implying that 128us is a large amount of time to wait.  Maybe 
with todays processors it is, I don't really know if it is or isn't for 
the average processor speed.  Does the udelay() imply that the scheduler 
can switch to another process ?  If so, I would have thought that the 
scheduling process would take a lot longer that 128us, but I could be 
wrong !!!
If no scheduling is performed then then there would be no difference to 
the naive "foreach" loop that you mention.

Are my assumptions reasonable ?

Brendan Simon.




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