From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1133CC433DF for ; Tue, 30 Jun 2020 02:24:49 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D573E20774 for ; Tue, 30 Jun 2020 02:24:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="P2qa2xv9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="eqGvK2P0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D573E20774 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=45rO0+MHEMY3VvVOdTbvXCSux0sUJI8gX13qG9smv2I=; b=P2qa2xv9tgcw6QXQBruNu1VYn UQ9pPgniDM/BYERRfddWZBgLpWcKhi29dBePvq1vbG00o0fwsDVU7/iwAgr0QuEWUTfWBGfHertcd gxpp57uRVfH9Fjbc8zJDLHmoVZKjo5jQj+nqYqoC+kqbfWp0Dnz0YfcMDlq5i2RcRIpT9DLSuAScx 8GvcwaTuyugpWtla5Kq3/t/wSbaCd4DKOt5+S/rqEdnhcaZ2eAFvyVMxYrpZkyPD6XiHrQV+aT4zj MIws+OYySuDIjeufKf5OcA7TxRf9QYZBFRLU9TUZfkZwvayHIGasuELa2sEDQpogGOct9KeKfk9Tc 1JnIE0eXg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jq5vP-000181-5y; Tue, 30 Jun 2020 02:23:07 +0000 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jq5vM-00017c-A7 for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 02:23:05 +0000 Received: by mail-pj1-x1044.google.com with SMTP id gc15so1393016pjb.0 for ; Mon, 29 Jun 2020 19:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=D7EQW6LVu/0LCQVaLjrZlygqrUoX4J/4WhIdq95ups4=; b=eqGvK2P0KbEv7YNVWM3sX4gdSuUS22MEImdYUCitDNbLwwQhlXEWVMN+sfnQfxSI7s X3ZIBVg76VMnPRXZLDlylOoDN2aMsPdl82fJrcCwBMALeO9TkTUu4vmMLyek91DGMJKb b5KkT4yWgiJNfABUQSLhbMG+6l8qMZK7pv24h3ZS18gqVw5Kq1LmRqmgHfUnSrdtbjfb bSMaxciVuXntSrLmo3XqJ4Td/FraZqYIPvwoEXdWHAV/LeSKTk+BRhZOU2ypdssfZ/le crp20QShS7XdaU+N1xz+B+0AbQA4L0rm24yak5coOERB5bK9q1uVAn7wadqkY1rG1c13 CMwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=D7EQW6LVu/0LCQVaLjrZlygqrUoX4J/4WhIdq95ups4=; b=D3dr50Coxn1elBNWVv3wQ3Z/1QcDe3L3IfoMRroyIyg0IdACEQRFJ0IIlJJ3lHgNvh hzSJLtOtef7xqtsKVvPnWsYF//BpE8yatuVeHyB55dsl+RYUpgkubjyx5JWWP5c29Jtt N4rYs7BYyCi6UAvhWSkYfIvxSUl+GMBiJjBO8/w4hVY7qTvJCzGiQ1V0u2cDNsEAT2B/ Tl4gwi44v9+8Zg0hf88AbuBESHpNHZFKUTEhCHEy/ewUYW/lx2Dzwg0phEtrXEyqMd2Z lUhHihP8qJ6QReKYTd7hcQPXOLIXeNR/WNw2IKa+NQnTvZmja7kTUPDEK4sOC04lTGmX rBJw== X-Gm-Message-State: AOAM532KdgCaCQKcyJEASTxUfNanRTlA36FrpxLNDJv6lTjZYawy/Ng/ MuhUXNETbOkXkW6xsZmTxAr+7Q== X-Google-Smtp-Source: ABdhPJzrYacdOd5DIB52tslC3wsLFea6Uoc0i4RCCBB1Jf0xYsnX6xU+fppqQC3njjiitgbGDm3/BQ== X-Received: by 2002:a17:90a:20e9:: with SMTP id f96mr20462600pjg.13.1593483781624; Mon, 29 Jun 2020 19:23:01 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id j19sm819933pfn.109.2020.06.29.19.23.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 19:23:00 -0700 (PDT) Date: Mon, 29 Jun 2020 19:20:29 -0700 From: Bjorn Andersson To: Stefano Stabellini Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings Message-ID: <20200630022029.GC407764@builder.lan> References: <1587749770-15082-1-git-send-email-ben.levinsky@xilinx.com> <1587749770-15082-5-git-send-email-ben.levinsky@xilinx.com> <20200511221755.GA13585@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ohad@wizery.com" , Rob Herring , "devicetree@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stefano Stabellini , Jolly Shah , Rajan Vaja , Michal Simek , Ben Levinsky , "mark.rutland@arm.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel