Re: Flash chip locking

[Philipp Rumpf <prumpf@uzix.org>]

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


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