Folks,
I have a few questions about an interrupt controller IP block
that I would like to support in an ARM SoC port.
My IP block provides software-assignable interrupts. That
is, I have a large pool of interrupt sources, and a large pool
of interrupt bits in the controller, but they are not physically
tied together. Instead they are assigned by some driver as it
initializes and allocates resources. This, I think, means that
I can not describe the interrupt bindings in the DTS file.
So, my first question is: Should I still write an irqchip device
for this IP block and represent it in the device tree, even
though I will not be able to use it as the referee of an
interrupt = < ... > binding? I think I should primarily because
other drivers will still need to set up IRQ handling through
this device.
Another question: This device has a muti-32-bit-word
bit-field representation for the interrupt lines. It has a
parallel array of words for clearing the interrupt. Is there
an existing irqchip that I can directly leverage that fits
that description?
Thank you,
jdl
Jon,
On Tue, Jul 08, 2014 at 09:02:14AM -0500, Jon Loeliger wrote:
> My IP block provides software-assignable interrupts. That
> is, I have a large pool of interrupt sources, and a large pool
> of interrupt bits in the controller, but they are not physically
> tied together. Instead they are assigned by some driver as it
> initializes and allocates resources. This, I think, means that
> I can not describe the interrupt bindings in the DTS file.
Please take a look at the crossbar driver. It's had quite a bit of
cleanup this cycle, so you may way to look at
git://git.infradead.org/users/jcooper/linux.git irqchip/crossbar
It sounds very similar.
thx,
Jason.