From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: Design of interrupt controller driver
Date: Tue, 6 Jun 2017 09:39:25 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1706060922220.1885@nanos> (raw)
In-Reply-To: <77a6e423-5c6a-9e5a-d679-c2576074fe6d@free.fr>
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
next prev parent reply other threads:[~2017-06-06 7:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-03 16:49 Design of interrupt controller driver Mason
2017-06-03 18:20 ` Mason
2017-06-04 13:55 ` Thomas Gleixner
2017-06-04 17:18 ` Mason
2017-06-04 20:13 ` Thomas Gleixner
2017-06-04 23:40 ` Mason
2017-06-05 8:23 ` Thomas Gleixner
2017-06-05 11:57 ` Mason
2017-06-06 7:39 ` Thomas Gleixner [this message]
2017-06-06 9:35 ` Mason
2017-06-06 10:29 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1706060922220.1885@nanos \
--to=tglx@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox