lkml.org 
[lkml]   [2015]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi
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...


\
 
 \ /
  Last update: 2015-09-02 16:21    [W:0.140 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site