Re: Flash chip locking

Brendan Simon
2000-06-28T22:47:28Z

David Woodhouse wrote:
>
> 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();
> >   }

Maybe this is a better so that the spin_lock_bh() call is not repeated.
while(1)
{
spin_lock_bh();
if (ready)
{
break;
}
spin_unlock();
udelay(some_period);
}

> 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 right.  At the end of the day I guess it doesn't really matter.
I just think that using labels and gotos is not a scalable technique, so
I try to avoid them.

Thanks for the explanations below.  It is much clearer now.  I am still
green when it comes to linux internals.  Hopefully that will change in
the next 6 months when I have to write drivers and apps for a powerpc
embedded product with DOC and some custom hardware.

Thanks,
Brendan Simon.

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