Re: Generic DT binding for IPIs

[David Gibson]

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