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

[Marc Zyngier <marc.zyngier@arm.com>]

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...