On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef <qais.yousef@xxxxxxxxxx> 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 = <CPU_VALUE IPI_SPEC>;
> 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 think this is better than interrupt-sink and interrupt-source [2] as we
> give the driver the flexibility to give a meaning to what this IPI is.
> One thing I found confusing about interrupt-source and interrupt-sink is
> from what perspective are we viewing that, host system or firmware..
DT is usually from host perspective. But I agree, the naming was still
confusing to me.
> ipis property also is similar to interrupts, so using it would be easier
> (I think).
>
> If we have 2 coprocessors that want to communicate using IPIs that are
> managed by the host we use ipi-refs property to refer to IPIs defined in
> another node.
>
> coproc1 {
> ipis = <CPU1>, <CPU2>, <CPU2>;
Don't you need to specify a certain IPI number in addition to which
cpu is the target?
I'm thinking the cpu target could be part of the interrupts property
flags field or something.
> ipi-names = "in", "coproc2data", "coproc2ctrl";
-names should be optional in general. So define something that works
without them.
> };
>
> coproc2 {
> ipi-refs = <&coproc1 "in">, <&coproc1 "coproc2data">, <&coproc1
> "corpoc2ctrl">;
This isn't actually parseable. You need a known length of cells after a phandle.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
