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

[David Hawkins <dwh@ovro.caltech.edu>]

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?

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?

> 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.

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?

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?

I'm planning on putting the 440EP on custom boards with a
number of Altera FPGAs located in the peripheral bus. I'll
post results and code as I go. Ulimately I'll open-source
the lot (hardware and all).

Here's the existing hardware I'm revising:
http://www.ovro.caltech.edu/~dwh/correlator

Cheers
Dave