On 4/4/07, Rajat Jain <rajat.noida.india@xxxxxxxxx> wrote:
> > > We often have a case where a driver wants to access its data structure
> > > in process context as well as in interrupt context (in its ISR). In
> > > such scenarios, we generally use spin_lock_irqsave() to grab the lock
> > > as well as disable all the local interrupts. AFAIK, disabling of local
> > > interrupts is required so as to avoid running your ISR (which needs
> > > the lock) while process context is holding the lock. However, this
> > > also disables any other ISRs (which DO NOT need the lock) on the local
> > > processor.
> > >
> > > Isn't this sub-optimal? Shouldn't there be a finer grained locking?
> >
> > actually it's optimal.
> > It's fastest to delay the interrupts a little and be done with what you
> > want to do under the lock quickly, and THEN take the interrupt. This
> > means the lock hold time is short, which significantly reduces
> > contention on this lock...
>
> So on the same lines, if a data structure is accessed in both process
> context and in a (single) driver ISR, should a driver use
> spin_lock_irqsave() to get the lock in ISR? Or will a simple
> spin_lock() suffice?