* Re: irqchip: Figuring out utility of hierarchy irqdomain
2020-01-16 15:50 irqchip: Figuring out utility of hierarchy irqdomain Olga Kitaina
@ 2020-01-25 12:02 ` Marc Zyngier
0 siblings, 0 replies; 2+ messages in thread
From: Marc Zyngier @ 2020-01-25 12:02 UTC (permalink / raw)
To: okitain; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel
On Thu, 16 Jan 2020 15:50:55 +0000,
Olga Kitaina <okitain@elvees.com> wrote:
Hi Olga,
>
> Hi, I'm looking to implement an interrupt controller (referred to here
> as QLIC) that is based on the RISC-V PLIC (see
> drivers/irqchip/irq-sifive-plic.c), with the difference that it's not
> the root interrupt controller, but instead it is connected to a GIC.
Mixing architectures, always a fun thing! WHat could possibly go
wrong? ;-)
> The features of the controller are as follows:
>
> * A cluster of DSPs serve as interrupt sources to QLIC, each DSP
> with several interrupt lines going to QLIC.
I don't think they are relevant to the problem. For the rest of the
system, these DSPs are just another interrupt source.
> * Several interrupt lines (documented as TARGET_x) go from QLIC to
> * the GIC.
I suppose each of these lines are what would normally connect to
RISC-V CPUs, each line targeting a hart, right?
> * Sources are mapped to targets by way of writing a mask of allowed
> sources in the TARG_x_ENABLE register.
OK, so that's both your internal routing and the enabling. I expect
this to be fairly static.
> * The source of an interrupt mapped to TARGET_x can be determined by
> reading from register TARG_x_CC. Writing the number of the source to
> TARG_x_CC masks the interrupt.
This doesn't match my reading the PLIC driver. Writing back to the
CONTEXT_CLAIM register *EOIs* the interrupt. It is *reading* from it
that has the side effect of masking it, by virtue of being an Ack
operation that progresses the interrupt state machine.
Masking/unmasking the interrupt seems to be done by writing to an
offset from CONTEXT_BASE, which is both per hart and per interrupt.
> * To mask all interrupts corresponding to TARGET_x, TARG_x_CC must be
> read repeatedly, with the values written back after the source
> interrupt is handled.
See above. You seem to have based your understanding of the PLIC on an
older version of the driver (before it was fixed), instead of the
documentation. This is of course assuming your QLIC is actually a
PLIC. If not, please point me to some documentation.
> * Source numbers start from 1, 0 is a special case in TARG_x_CC - it
> corresponds to "no interrupt", and writing 0 to the register does
> nothing.
That's just a spurious interrupt, which can happen at any time. A
number of interrupt architectures have similar concept (1023 on the
ARM GIC).
> I am not yet well-acquainted with the irq subsystem, which means I
> am not sure what kind of APIs I need to use. This is why I have a
> couple of questions:
> 1. Do I understand correctly that using hierarchy irqdomain means that
> the interrupt controller has to have a 1:1 mapping between inputs and
> outputs?
Yes. The typical use case is stacks of controllers that will never
multiplex signals along the way. In your case, you have a bunch of
interrupts that can be mux'ed onto a single output, so a hierarchical
setup wouldn't work.
> 2. Is a chained handler necessary for this setup, e.g. handling 0 in
> TARG_x_CC?
It is required (see above), but 0 isn't the reason why. Your QLIC, if
it is anything like the PLIC, looks like *multiple* chained
controllers, each one having a *single* output, each one connected to
a GIC line.
Hope this helps,
M.
--
Jazz is not dead, it just smells funny.
^ permalink raw reply [flat|nested] 2+ messages in thread