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 <[email protected]> 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. Regards, Bjorn > Ben will reply with a simplified bindings proposal.
