Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

From: Marc Zyngier
Date: Wed Sep 02 2015 - 10:15:12 EST


On 02/09/15 14:25, Qais Yousef wrote:
> On 09/02/2015 12:53 PM, Marc Zyngier wrote:
>> On 02/09/15 11:48, Qais Yousef wrote:
>>> It's worth noting in the light of this that INT_SPEC should be optional
>>> since for hardware similar to mine there's not much to tell the
>>> controller if it's all dynamic except where we want the IPI to be routed
>>> to - the INT_SPEC is implicitly defined by the notion it's an IPI.
>> Well, I'd think that the INT_SPEC should say that it is an IPI, and I
>> don't believe we should omit it. On the ARM GIC side, our interrupts are
>> typed (type 0 is a normal wired interrupt, type 1 a per-cpu interrupt,
>> and we could allocate type 2 to identify an IPI).
>
> I didn't mean to omit it completely, but just being optional so it's
> specified if the intc needs this info only. I'm assuming that INT_SPEC
> is interrupt controller specific. If not, then ignore me :-)

It is, but I don't think it can really be made optional.

>>
>> But we do need to identify it properly, as we should be able to cover
>> both IPIs and normal wired interrupts.
>
> I'm a bit confused here. What do you mean by normal wired interrupts? I
> thought this DT binding is only to describe IPIs that needs reserving
> and routing. What am I missing?

Look at my initial proposal, and the way I was describing a device
having an interrupt source, and two possible interrupt sinks, one being
a CPU and the other being another device.

I'm looking at solving that case as well, possibly with the same
infrastructure (the routing bit should be the same).

Thanks,

M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/