On Thu, Dec 22, 2016 at 10:30 PM, Mike Looijmans <[email protected]> wrote: > The devicetree only guards that other drivers won't steal your interrupts > away. It does not cause the remoteproc driver to activate or assign them. > > Your firmware has to register and activate the interrupt by itself. If Linux > complains about your interrupt, you probably routed it to the wrong CPU.
Yes, my firmware does register and activate the interrupt. I was under the (apparently mistaken) impression that specifying the interrupts in the remoteproc devicetree entry does the routing somehow. If it doesn't, then I'm not sure how/where the interrupt routing is being accomplished in my system. I'm not aware of doing anything else that might route the interrupt. Where are the typical place(s) where interrupt routing is done in a Linux AMP system using Yocto and meta-xilinx? Aside from not knowing precisely how interrupt routing is occurring, all the FPGA interrupts are working fine (being serviced by the RTOS on CPU1 and Linux on CPU0 has no issues with them), but only as long as the interrupt line idles low and triggered by the leading rising edge of a pulse. For reasons, there was one of these interrupts that I wanted to idle high and triggered by the trailing rising edge of a negative pulse, but that has not been cooperating. Something really doesn't like the interrupt line to be idling high. When I make this interrupt like the others, things are fine. Thanks for your help. -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
