On Wed, Dec 09, 2015 at 10:50:35AM -0600, Rob Herring wrote: > On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote: > > Hi, > > > > On 10/22/2015 12:55 PM, Jason Cooper wrote: > >> > >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote: > >>> > >>> Is there anything more I can do to get more attention about this? I > >>> think Marc's suggestion is more generic and future proof, if I send > >>> RFC patches for that would this be better? > >> > >> Please do. > > > > > > Unfortunately I haven't had a chance to get around writing the patches yet. > > I came up with a different description though that I thought maybe worth > > sharing > > to see if there's any opinion about it before the actual work being done. > > I've not given this too much thought, but here's my initial thoughts. > > > > > To summarise, the problem I am trying to solve is that we have a type of > > coprocessors which share the interrupt controller with Linux, hence the IPI > > mechanism this controller uses. I've been working with Thomas on > > implementing > > a generic API to allocate IPIs for coprocesors and a way for drivers to send > > these IPIs [1]. > > > > To complement this new API, we need a mechanism to describe this in > > device tree so a driver that wants to allocate an IPI can have this done > > automatically for it like we handle interrupts. > > > > What I have in mind is: > > > > coproc { > > ipi-parent = <&gic>; > > > > ipis = ; > > ipi-names = "in"; > > }; > > > > This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as > > parameters to the controller. Which means we need a new ipi-cells to > > define how many cells are in ipis property. Note the new ipi-parent too. > > These are still interrupts, so I'd prefer to use or extend the > interrupt binding if possible. I agree. It should be possible to just describe these as interrupts, with the interrupt-parent being a special interrupt controller node to represent these IPIs. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson