Re: Flash chip locking

[David Woodhouse <dwmw2@infradead.org>]

brendan.simon@ctam.com.au said:
> Or to avoid ugly "goto" statements.
>   spin_lock_bh();
>   while (!ready)
>   {
>       spin_unlock()
>       udelay(a_little_while);
>       spin_lock_bh();
>   }

Personally, I prefer the goto version. I think it's clearer. We're 
releasing the lock and going back to exactly the state we were in at the 
'retry:' label. It doesn't really matter though. 



> 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. 

It's a long time to disable interrupts or bottom halves. If we didn't have 
to disable bottom halves, I wouldn't worry about it.


> Does the udelay() imply that the scheduler  can switch to another process? 

No. We'd use schedule_timeout() to allow the scheduler to switch.

> If so, I would have thought that the  scheduling process would take a lot
> longer that 128us, but I could be  wrong !!! 

I agree - that's why I used udelay() which is a busy-wait rather than 
scheduling. 

> If no scheduling is performed  then then there would be no difference to
> the naive "foreach" loop that you mention.

The difference is that in the latter version we are allowing interrupts
while we're doing the delay, while in the former they're disabled. There 
are in fact _two_ major differences between the two - the presence of the 
delay, and the place at which we actually wait for the chip to be ready.

The delay is just an optimisation - there's no a lot of point in beating on 
the chip's READY line until there's at least a chance that it'll be done, 
whether we're busy-waiting with IRQs disabled or not.

The important bit is that we let the interrupts run while we're waiting for 
the chip.




--
dwmw2




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