On Wednesday 21 March 2007 23:03, Arjan van de Ven wrote: > On Thu, 2007-03-22 at 00:29 +0530, anubhav rakshit wrote: > > On 3/21/07, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote: > > > On Wed, 2007-03-21 at 09:23 +0530, Rajat Jain wrote: > > > > Hi, > > > > > > > > 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. > > > > how is it optimal,when all you require is to disable just one particular > > IRQ? > > because if you don't disable all you increase hold times, which > increases contention. Contention is BAD. Newbie advice: Well, looking at LDD3 -> interrupt handling, there are a few functions void disable_irq(int irq); void disable_irq_nosync(int irq); void enable_irq(int irq); But you cannot use them if you share an irq and your hardware must not generate another interrupt while you are handling this one. This is usually the case (i think) since many devices have some kind of "handled" register. -- Regards, Tzahi. -- Tzahi Fadida Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info WARNING TO SPAMMERS: see at http://members.lycos.co.uk/my2nis/spamwarning.html - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs
