Re: Flash chip locking

Brendan Simon
2000-06-28T11:09:31Z

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.