Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Ben Levinsky <BLEVINSK@xilinx.com>
To:     Bjorn Andersson <bjorn.andersson@linaro.org>,
        Stefano Stabellini <stefanos@xilinx.com>
CC:     Rob Herring <robh@kernel.org>, "ohad@wizery.com" <ohad@wizery.com>,
        Michal Simek <michals@xilinx.com>,
        Jolly Shah <JOLLYS@xilinx.com>, Rajan Vaja <RAJANV@xilinx.com>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "linux-remoteproc@vger.kernel.org" <linux-remoteproc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Stefano Stabellini <stefanos@xilinx.com>
Subject: RE: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for
 ZynqMP R5 rproc bindings
Thread-Topic: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for
 ZynqMP R5 rproc bindings
Thread-Index: AQHWGl7uxdGBAyULe0azD2FJNJZOnqijj0uAgBdEEWCAF8YrgIAeHusAgAAc24CAAN6D4A==
Date:   Tue, 30 Jun 2020 15:38:57 +0000
Message-ID: <BYAPR02MB44079AC22428C6D59548E7ECB56F0@BYAPR02MB4407.namprd02.prod.outlook.com>
References: <1587749770-15082-1-git-send-email-ben.levinsky@xilinx.com>
 <1587749770-15082-5-git-send-email-ben.levinsky@xilinx.com>
 <20200511221755.GA13585@bogus>
 <BYAPR02MB44077C8B7B7FD23FDE8E31B8B5B00@BYAPR02MB4407.namprd02.prod.outlook.com>
 <CAL_JsqLGo380SRYska+xGgJhgF8NCRvY56ewafvSCU6c-LmhZw@mail.gmail.com>
 <alpine.DEB.2.21.2006291734370.8121@sstabellini-ThinkPad-T480s>
 <20200630022029.GC407764@builder.lan>
In-Reply-To: <20200630022029.GC407764@builder.lan>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 01cad00d-67c5-4eeb-cd0d-08d81d0bb466
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 15:38:57.9328
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oipKRxZPPA2HEXFexZrDxBYFEPbbGzKEc7CRIOagxcn4WCAClb7q1K/hGn7785pDXN/1hwXUoo+s6LW2fysvbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5430
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Bjorn,


-----Original Message-----
From: Bjorn Andersson <bjorn.andersson@linaro.org>=20
Sent: Monday, June 29, 2020 7:20 PM
To: Stefano Stabellini <stefanos@xilinx.com>
Cc: Rob Herring <robh@kernel.org>; Ben Levinsky <BLEVINSK@xilinx.com>; ohad=
@wizery.com; Michal Simek <michals@xilinx.com>; Jolly Shah <JOLLYS@xilinx.c=
om>; Rajan Vaja <RAJANV@xilinx.com>; mark.rutland@arm.com; linux-remoteproc=
@vger.kernel.org; linux-arm-kernel@lists.infradead.org; devicetree@vger.ker=
nel.org; linux-kernel@vger.kernel.org; Stefano Stabellini <stefanos@xilinx.=
com>
Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for =
ZynqMP R5 rproc bindings

On Mon 29 Jun 17:37 PDT 2020, Stefano Stabellini wrote:

> On Wed, 10 Jun 2020, Rob Herring wrote:
> > On Tue, May 26, 2020 at 11:40 AM Ben Levinsky <BLEVINSK@xilinx.com> wro=
te:
> > >
> > > Hi Rob,
> > >
> > > The Xilinx R5 Remoteproc driver has been around for a long time -- ad=
mittedly we should have upstreamed it long ago. The driver in the current f=
orm is using an "classic" remoteproc device tree node as described here.
> >=20
> > I would rather not have 2 possible bindings to maintain. If there's=20
> > been no rush to upstream this til now, then it can wait longer.
> >=20
> > >
> > > I am working with Stefano to come up with an appropriate System Devic=
e Tree representation but it is not going to be ready right away. Our prefe=
rence would be to upstream the remoteproc node and driver in their current =
forms while system device tree is maturing.
> >=20
> > There's obviously going to still need to be some sort of description=20
> > of the interface between cores, but this has parts that obviously=20
> > conflict with what's getting defined for system DT. The TCMs are the=20
> > most obvious. If you can remove (or hardcode in the driver) what=20
> > conflicts, then perhaps this can be upstreamed now.
>=20
>=20
> Hi Rob,
>=20
> Sorry it took a while to answer back but we wanted to do some research=20
> to make sure the reply is correct.
>=20
>=20
> The System Device Tree version of the OpenAMP remoteproc bindings aims=20
> at being simpler and vendor-neutral. As anything else System Device=20
> Tree, Lopper will read it and generate a "traditional" device tree=20
> with the existing remoteproc bindings. In that sense, it might not=20
> affect Linux directly.
>=20

Can you give some examples of how you will be able to describe the hardware=
 involved in powering/clocking resources surrounding your remoteproc and th=
e necessary resources in a "simpler and vendor neutral"
way that then can be further lopped(?) into something that Linux can use to=
 control any remoteproc?

> However, given the fragmentation of the remoteproc bindings across=20
> multiple vendors (they are all different), I think it is a good idea=20
> for Linux, for System Device Tree, and in general to come up with=20
> simpler remoteproc bindings, more aligned between the vendors. If=20
> nothing else, it is going to make Lopper's development easier.
>=20

In my view the big reason for the fragmentation between bindings is because=
 they all describe different hardware. There has been common properties of =
remoteprocs discussed, but apart from the firmware-name property I don't th=
ink we have agreed on any.

>=20
> So I think it is a good idea to take this opportunity to simplify the=20
> Xilinx remoteproc bindings as you suggested. The idea of to removing=20
> the TCM nodes is a good one. In addition I asked Ben to have a look at=20
> whether the mboxes and mbox-names properties can be removed too.
>=20

If your remoteproc uses a mailbox for signaling, then this should be descri=
bed in devicetree. This will allow you to reuse components in other designs=
 where either part is replaced or reused.

[Ben Levinsky] The Xilinx R5 remoteproc binding can optionally use the mail=
box. That is if loading a simple binary that is not making use of IPC then =
the mailbox is optional and not needed. Not sure if you still would prefer =
to have the example showcasing use of mailbox then.


Regards,
Bjorn

> Ben will reply with a simplified bindings proposal.