Linux-ARM-Kernel Archive on
 help / color / Atom feed
From: Stefano Stabellini <>
To: Bjorn Andersson <>
Cc: "" <>,
	Rob Herring <>,
	"" <>,
	"" <>,
	Stefano Stabellini <>,
	Jolly Shah <>, Rajan Vaja <>,
	Ben Levinsky <>,
	Michal Simek <>,
	"" <>,
	Stefano Stabellini <>,
Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
Date: Fri, 10 Jul 2020 10:42:44 -0700 (PDT)
Message-ID: <alpine.DEB.2.21.2007101023470.4124@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200630022029.GC407764@builder.lan>

Sorry for the late reply, a couple of conferences kept me busy.

On Mon, 29 Jun 2020, Bjorn Andersson wrote:
> > 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.

Yeah, it is as you wrote.

I meant to say that there might be room for improvement if the vendors
come together and agree on a few more common properties. However, I
don't have any concrete suggestions on this yet.  Also, as mentioned, we
can work with today's bindings just fine from a system device tree

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

The description at the system device tree level looks a bit different,
which might make the problem a bit easier, or at least different.

Let me give you some context. Lopper
( is a tool that takes a system
device tree as input and generates one or more traditional device trees
as output (i.e. today's device tree for Linux.)

System device tree comes with the description of multiple "execution
domains" ( and
the ability to assign resources to each of them. That part is
vendor-neutral.  We also have the ability to define a vendor-specific
flag when assigning resources.

All together it enables us to describe an openamp/remoteproc system with
only very few vendor-specific info. I am working on a full example of an
input system device tree with openamp information and the resulting
traditional Linux devicetree. I'll make sure to reach out when I have it

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


linux-arm-kernel mailing list

  parent 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
2020-06-30 17:11               ` Ben Levinsky
2020-07-10 17:42             ` Stefano Stabellini [this message]
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:

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

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2007101023470.4124@sstabellini-ThinkPad-T480s \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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

Linux-ARM-Kernel Archive on

Archives are clonable:
	git clone --mirror linux-arm-kernel/git/0.git
	git clone --mirror 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/ \
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone