Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754061AbbLJKU4 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 10 Dec 2015 05:20:56 -0500
Received: from mailapp01.imgtec.com ([195.59.15.196]:23839 "EHLO
	mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752383AbbLJKUw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 10 Dec 2015 05:20:52 -0500
Subject: Re: Generic DT binding for IPIs
To: Rob Herring <robh+dt@kernel.org>
References: <561E2BE6.2090807@imgtec.com> <5628BE00.4020106@imgtec.com>
 <20151022115551.GI3953@io.lakedaemon.net> <56684877.3020708@imgtec.com>
 <CAL_Jsq+yv1UnBhrR+x+DEA41yETVANY9_-5W0DSQJVEQ4+Mx_w@mail.gmail.com>
CC: "devicetree-spec@vger.kernel.org" <devicetree-spec@vger.kernel.org>,
        "Jason Cooper" <jason@lakedaemon.net>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Pawel Moll <pawel.moll@arm.com>, Mark Rutland <mark.rutland@arm.com>,
        Ian Campbell <ijc+devicetree@hellion.org.uk>,
        "Kumar Gala" <galak@codeaurora.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Marc Zyngier" <marc.zyngier@arm.com>,
        Jiang Liu <jiang.liu@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Lisa Parratt <Lisa.Parratt@imgtec.com>
From: Qais Yousef <qais.yousef@imgtec.com>
Message-ID: <56695201.2070807@imgtec.com>
Date: Thu, 10 Dec 2015 10:20:49 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAL_Jsq+yv1UnBhrR+x+DEA41yETVANY9_-5W0DSQJVEQ4+Mx_w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [192.168.154.94]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2992
Lines: 86

On 12/09/2015 04:50 PM, Rob Herring wrote:
> On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef <qais.yousef@imgtec.com> wrote:
>
>> 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.

The IPIs have two properties that are different from a regular interrupts:

     1. An IPI is not only received, it could also be sent.
     2. The IPI is dynamic. There's an actual allocation from a pool of 
available
         IPIs happening when we ask for one to be reserved.

The difference might be borderline..

Do you have any rough idea on what a possible extension could look like? 
Reusing means writing less code, which is always better of course :)

By the way, on MIPS GIC, we can use interrupts property to describe an 
IPI the host system will receive. But to send one to the coprocessor, we 
need to define an outgoing IPI.

In this case, the firmware will be hardcoded to send an interrupt to a 
specific hwirq, so one can then describe it in DT as a regular interrupt 
to the host system. Hardcoding is not ideal and less portable though.

>> 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?

No. The way IPI reserving works is we just need to specify the target 
CPU(s).

>
> I'm thinking the cpu target could be part of the interrupts property
> flags field or something.

I'll look more at this option.

>
>>               ipi-names = "in", "coproc2data", "coproc2ctrl";
> -names should be optional in general. So define something that works
> without them.

If it's not specified, then the driver can get the definition by index 
and it would have to define the order it expects the IPIs in the binding?

>>       };
>>
>>       coproc2 {
>>               ipi-refs = <&coproc1 "in">, <&coproc1 "coproc2data">, <&coproc1
>> "corpoc2ctrl">;
> This isn't actually parseable. You need a known length of cells after a phandle.
>

To clarify, what you're saying we can't pass strings, right?

Thanks for your comments!

Thanks,
Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/