Flash chip locking

[Brendan Simon]

David Woodhouse wrote:
> 
> brendan.simon at 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.




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