Design of interrupt controller driver
Thomas Gleixner
tglx at linutronix.de
Tue Jun 6 00:39:25 PDT 2017
On Mon, 5 Jun 2017, Mason wrote:
> Is it possible to call the interrupt controller's mask callback
> from the DMA engine driver ISR, or is that reserved for the IRQ
> framework? Because that's what the HW designers had in mind,
> thus they didn't provide a way to mask the interrupt in the
> device. It just outputs the signal to the interrupt router.
No, it's not and we are not going to provide an interface for that because
that violates any form of layering and abstractions. The DMA device driver
has to be oblivious of the underlying interrupt handling machinery.
> So their proposed setup is as follows:
>
> Start the system with the DMA interrupt masked in the intc.
> When SW needs to perform a DMA op, the DMA driver starts
> the op (thus the interrupt signal goes low), then unmasks
> the interrupt in the intc. Interrupt triggers when signal
> goes high (level high). Driver masks interrupt in ISR,
> until next op is available.
>
> Is that possible in the Linux framework?
You can do that, but not for shared interrupts:
isr()
{
disable_irq_nosync();
.....
}
submit()
{
....
enable_irq();
}
init()
{
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(irq, ....);
}
This affects the whole interrupt line, so if you share that interrupt at
the CPU interrupt controller level this wont work.
If your 'router' IP has a mechanism to mask input lines individually, then
you can do something about this.
Each group of inputs which shares an output becomes it's own demultiplexing
interrupt domain with it's own interrupt chip which controls the input
lines. The output is handled by a chained interrupt handler which checks
the status of the input lines and invokes the handlers for the devices with
an active input.
Then the above example will disable the interrupt at the 'router' level
which will not affect the other device which shares the underlying output
to the GIC (or whatever interrupt controller your CPU has).
Thanks,
tglx
More information about the linux-arm-kernel
mailing list