On Fri, 27 Mar 2009, Russell King - ARM Linux wrote: > On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote: > > > You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they > > > only disable IRQs and not FIQs? But it seems your FIQ cannot cause any > > > trouble, so, it should be fine. Do you really need an FIQ? > > This is precisely the area where FIQs can't be used. You can't take > spinlocks (even IRQ-safe spinlocks) from FIQs. Why? You'll deadlock. > > Consider: > > spin_lock_irqsave(lock, flags); > ... > FIQ happens > FIQ: spin_lock_irqsave(lock, flags); <=== deadlock > > And there's nothing you can do about that. And no, converting this > locking primitive to also disable FIQs means that then FIQs will be > subject to the same latency as normal IRQs. > > In fact, in uniprocessor mode, you might as well completely forget the > spinlock, because the lock part is a no-op, and the IRQ disable has no > effect on FIQs. > > If you're going to be using FIQs in C code, you need to be _very_ _very_ > careful about what you do. Calling normal kernel functions is generally > not going to be safe in any way. No, they are not calling C from FIQs and they are not protecting against FIQs with a spinlock_irq*, that was my misinterpretation, sorry. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
