On Fri, 28 Aug 2015, Qais Yousef wrote:
Thanks a lot for the detailed explanation. I wasn't looking for a quick and dirty solution but my view of the problem is much simpler than yours so my idea of a solution would look quick and dirty. I have a better appreciation of the problem now and a way to approach it :-)
From DT point of view are we OK with this form then
coprocessor { interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>; }and if the root controller sends normal IPI as it sends normal device interrupts then interrupt-sink can be a standard interrupts property (like in my case)
coprocessor { interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; interrupts = <INT_SPEC>; }Does this look right to you? Is there something else that needs to be covered still?
I'm not an DT wizard. I leave that to the DT experts.
One more thing I can think of now is that the coprocessor will need the raw irq numbers that are picked by linux so that it can use them to trigger the IPI. Are we ok to add a function that returns this raw irq number (as opposed to linux irq number) directly from DT? The way this is communicated to the coprocessor will be platform specific.
Why do you want that to be hacked into DT?
To configure your coprocessor proper, we need a translation mechanism from the linux interrupt number to the magic value which needs to be written into the trigger register when the coprocessor wants to send an interrupt or an IPI. int irq_get_irq_hwcfg(unsigned int irq, struct irq_hwcfg *cfg); struct irq_hwcfg needs to be defined, but it might look like this: {/* Generic fields */ x; ... union { mips_gic; ... }; };
That function provides you the information which you have to hand over to your coprocessor firmware.
Thanks,
tglx