Re: Flash chip locking

David Woodhouse
2000-06-28T11:22:12Z

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