Re: Flash chip locking

Philipp Rumpf
2000-06-28T20:02:44Z

On Wed, Jun 28, 2000 at 11:36:03AM +0100, David Woodhouse wrote:
> OK. After some deliberation, this is the arrangement I'm about to code up
> for preventing concurrent access to flash chips. If you don't like it,
> feel free to present a better alternative.
>
> Each chip is protected by a spinlock, which prevents it from being accessed
> concurrently by different CPUs. Lovely, simple, and even free on UP
> machines.

on UP machines with recent compilers, at least.

> This means that bottom halves are disabled for the entire time that we're
> talking to the flash chip. Not good if we hold them for a long time, like
> for example the 128µs that we expect a typical write cycle to take.

Not good, but shouldn't be fatal either.

> 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) {

Just to be sure, ready is really a complicated writeb/readb sequence ?

> spin_unlock()
> udelay(a little while);

udelay(1); should be sufficient here.

> 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();
> }
>
> We'll need to keep a 'state' variable in the per-chip data structure, so
> that if anything else grabs the lock while we're waiting for an operation
> to complete, it knows that there's an operation in progress and that it
> should either suspend it and do its thing before resuming the operation,
> or just go away and wait for the operation to finish.

Sounds like yucky hardware to me .. otoh, a state variable shouldn't be a
problem.

> We may add a wait queue to handle the latter case - so the write call can
> wake_up the waiting processes when it's completely finished. This will be
> come more clear as I code it up.

That'd benefit SMP only, wouldn't it ?

Philipp Rumpf