On Thu, Dec 17, 2015 at 11:31:14AM +0000, Qais Yousef wrote: > > > Maybe it would help to look at the new IPI reservation API? > > > > > > https://lkml.org/lkml/2015/12/8/249 > > > > Hmm.. not as much as I might have hoped. > > > > From the API, it looks like you're reserving IPIs to signal between > > different CPUs all of which are in Linux. From your description here > > it sounds like the coproc is a separate specialized thing not running > > Linux (or at least, not the same Linux instance as the host OS which > > this device tree is for). > > No the CPUs aren't only Linux CPUs. It should be any CPU that the interrupt > controller can talk to. > That CPU can be one of Linux CPUs, or a coproc. Ok.. but it looks like anything you can reserve an IPI for must be cpu_possible_mask, so I'm guessing they're CPUs that could be CPUs, even if they're not at the present time. Is that right? I guess the point is that the targets of these IPIs are participating in the same coherency fabric as the host CPUs, yes? > > > I'm not sure I understood you completely but no, there's no translation > > > happening. When the IPI is allocated it would be routed > > > to the coproc. When the host wants to send a signal, it'll use the > allocated > > > hwirq value (indirectly via the virq) to write to a register, which will > > > cause an interrupt to be generated at the coproc. > > > > Where is this magic register located? In the host cpu? In the > > coproc? In some special IPI controller? > > The IPI controller. In my use case, the IPI controller is the same as the > interrupt controller used by Linux. Generally they don't have to be the > same though. Ok. So, the one existing thing I can think of which might fit - although it seems a bit odd - is the gpio binding. I'm not that familiar with the binding, so it's possible I've overlooked something that would make it unsuitable, still.. I think you might be able to treat the IPIs bound for a coproc as gpios to that coproc device, with the IPI controller designated as the gpio controller. The driver for this gpio controller would know that it uses the IPI reservation mechanism to trigger those "gpio" lines. This scheme would have the advatage that if you ever have a version of the coproc that exists as a separate piece of hardware *not* belonging to the same coherency fabric as the host cpu - and with it's inbound interrupts instead triggered by "real" gpios - then that should, at least in theory, be supported without host kernel changes. > > So as noted above, I'm now sure that 'interrupts' is not the right > > thing. I'm trying to understand the coprocs and the ipi mechanism a > > bit better to work out if there is something existing which would make > > sense, or if we do need something entirely new. > > Let me know if I can help. I don't know what sort of software is running on the coproc. If it also uses a device tree, then the device tree from the coproc point of view *would* represent these inbound IPIs as 'interrupts' properties - probably on some node representing the host cpu / system. -- 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
Attachment:
signature.asc
Description: PGP signature
