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