Yosemite/440EP is there a global interrupt enable mask?

[Eugene Surovegin]

On Wed, Jan 25, 2006 at 11:46:41AM -0800, David Hawkins wrote:
> Hi Eugene,
> 
> >>Now while looking at some of the other drivers, I noticed the use
> >>of the following syntax:
> >>
> >>  unsigned long flags;
> >>  local_irq_save(flags);
> >>
> >>  ... mfdcr, mtdcr, etc operations ...
> >>
> >>  local_irq_restore(flags);
> >>
> >>which is treating the operations on the DCRs as a critical section.
> >>
> >>I should probably be doing the same when I enable the external IRQs
> >>and modify the GPIO registers.
> >
> >You have to use locks if you access GPIO registers, because other bits 
> >can be used by other device drivers, although there is no drivers in 
> >the official tree which use GPIO (I have tons of them in my private 
> >tree and I added global "gpio_lock" to serialize GPIO access).
> 
> What kind of global lock; a spinlock?

yes, spinlock.

> What is the advantage of say using the gpio_lock, rather than
> the irq_save/restore sequence above - which is what is used in
> the emac and usb code?

emac doesn't use GPIO registers :). Also, if there is no IRQ code 
accesses GPIO registers, you don't need IRQ disabling lock, and 
spin_lock effectively becomes just a preemption lock. Personally, I use 
spinlocks just out of habit, I think it's a good style, even if you 
know your chip doesn't support SMP (but some day might :).

> >DCRs are a little different, there are separate DCR for different 
> >peripherals, so generally, you don't have to use locks, because those 
> >DCR accesses are implicitly bound to particular device anyway and 
> >device "owns" them.
> 
> Right, but I was accessing the DCR for the UIC status register,
> which, I assume, is also used by the Linux IRQ handling subsystem.

DO NOT access UIC registers directly. DO NOT.

> Well, ok perhaps that is not a good example, I have not tested
> whether the IRQ handler in the example code I posted needs to
> clear the UIC1_SR bit, or whether the Linux IRQ handling code
> already takes care of it. I suspect the latter, since the IRQ
> could be shared, and Linux needs to go through and call all
> handlers on that IRQ line.
> 
> But in a debug context of reading those registers, I would
> expect some form of lock holding would be recommended.
> Do you happen to know if the Linux IRQ handling code uses a
> lock?

4xx IRQ code takes care of all this. You don't need to mess with UIC 
registers. 4xx PIC code doesn't use locks because it's being called 
from special context (IRQs disabled), 4xx doesn't support SMP and PIC 
code "owns" those DCRs.

> I'm just learning, so feel free to enlighten me.
> 
> What drivers do you have in your 'private' tree that you might
> be willing to share?

Nothing that can be of interest for a general public. They are 
board-specific (lots of bit-banging SPI stuff). All other drivers I 
wrote are already in public tree.

-- 
Eugene