Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Ben Levinsky <BLEVINSK@xilinx.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Stefano Stabellini <stefanos@xilinx.com>
Cc: "ohad@wizery.com" <ohad@wizery.com>,
	Rob Herring <robh@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefanos@xilinx.com>,
	Jolly Shah <JOLLYS@xilinx.com>, Rajan Vaja <RAJANV@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
Date: Tue, 30 Jun 2020 15:38:57 +0000
Message-ID: <BYAPR02MB44079AC22428C6D59548E7ECB56F0@BYAPR02MB4407.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20200630022029.GC407764@builder.lan>

Hi Bjorn,



-----Original Message-----
From: Bjorn Andersson <bjorn.andersson@linaro.org> 
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.com>; Rajan Vaja <RAJANV@xilinx.com>; mark.rutland@arm.com; linux-remoteproc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; devicetree@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

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

Can you give some examples of how you will be able to describe the hardware involved in powering/clocking resources surrounding your remoteproc and the 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 
> multiple vendors (they are all different), I think it is a good idea 
> for Linux, for System Device Tree, and in general to come up with 
> simpler remoteproc bindings, more aligned between the vendors. If 
> nothing else, it is going to make Lopper's development easier.
> 

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 think we have agreed on any.

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

If your remoteproc uses a mailbox for signaling, then this should be described 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 mailbox. 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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 17:36 [PATCH v4 0/5] remoteproc: Add zynqmp_r5 driver Ben Levinsky
2020-04-24 17:36 ` [PATCH v4 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration Ben Levinsky
2020-04-24 17:36 ` [PATCH v4 2/5] firmware: xilinx: Add shutdown/wakeup APIs Ben Levinsky
2020-04-24 17:36 ` [PATCH v4 3/5] firmware: xilinx: Add RPU configuration APIs Ben Levinsky
2020-04-24 17:36 ` [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings Ben Levinsky
2020-05-11 22:17   ` Rob Herring
2020-05-26 17:40     ` Ben Levinsky
2020-06-10 20:38       ` Rob Herring
2020-06-30  0:37         ` Stefano Stabellini
2020-06-30  2:20           ` Bjorn Andersson
2020-06-30 15:38             ` Ben Levinsky [this message]
2020-06-30 17:11               ` Ben Levinsky
2020-07-10 17:42             ` Stefano Stabellini
2020-04-24 17:36 ` [PATCH v4 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver Ben Levinsky
2020-05-05 20:53   ` Mathieu Poirier
2020-05-06 21:36   ` Mathieu Poirier
2020-05-07 22:08   ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR02MB44079AC22428C6D59548E7ECB56F0@BYAPR02MB4407.namprd02.prod.outlook.com \
    --to=blevinsk@xilinx.com \
    --cc=JOLLYS@xilinx.com \
    --cc=RAJANV@xilinx.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michals@xilinx.com \
    --cc=ohad@wizery.com \
    --cc=robh@kernel.org \
    --cc=stefanos@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git