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=-9.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 E39CDC43463 for ; Fri, 18 Sep 2020 06:45:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A66762100A for ; Fri, 18 Sep 2020 06:45:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726427AbgIRGpM (ORCPT ); Fri, 18 Sep 2020 02:45:12 -0400 Received: from mo-csw-fb1515.securemx.jp ([210.130.202.171]:52538 "EHLO mo-csw-fb.securemx.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726424AbgIRGpM (ORCPT ); Fri, 18 Sep 2020 02:45:12 -0400 X-Greylist: delayed 961 seconds by postgrey-1.27 at vger.kernel.org; Fri, 18 Sep 2020 02:45:10 EDT Received: by mo-csw-fb.securemx.jp (mx-mo-csw-fb1515) id 08I6TAq1023727; Fri, 18 Sep 2020 15:29:10 +0900 Received: by mo-csw.securemx.jp (mx-mo-csw1516) id 08I6StZl003562; Fri, 18 Sep 2020 15:28:55 +0900 X-Iguazu-Qid: 34trFrx2pqNWq2MYnj X-Iguazu-QSIG: v=2; s=0; t=1600410535; q=34trFrx2pqNWq2MYnj; m=XWOMKSutyKBJnyIaL4q4wThvZCfnOaUx8ba8QIcGqvo= Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.securemx.jp (mx-mr1510) id 08I6Srbq032718; Fri, 18 Sep 2020 15:28:53 +0900 Received: from enc01.toshiba.co.jp ([106.186.93.100]) by imx2.toshiba.co.jp with ESMTP id 08I6Srv6006057; Fri, 18 Sep 2020 15:28:53 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.toshiba.co.jp with ESMTP id 08I6Sq6W005477; Fri, 18 Sep 2020 15:28:53 +0900 From: Punit Agrawal To: Ben Levinsky Cc: stefanos@xilinx.com, michals@xilinx.com, michael.auchter@ni.com, devicetree@vger.kernel.org, emooring@xilinx.com, mathieu.poirier@linaro.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, jliang@xilinx.com, robh+dt@kernel.org, Jason Wu , Michal Simek , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v14 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings References: <20200917194341.16272-1-ben.levinsky@xilinx.com> <20200917194341.16272-5-ben.levinsky@xilinx.com> Date: Fri, 18 Sep 2020 15:28:50 +0900 In-Reply-To: <20200917194341.16272-5-ben.levinsky@xilinx.com> (Ben Levinsky's message of "Thu, 17 Sep 2020 12:43:40 -0700") X-TSB-HOP: ON Message-ID: <87r1qzlhst.fsf@kokedama.swc.toshiba.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org Hi Ben, One query below - Ben Levinsky writes: > Add binding for ZynqMP R5 OpenAMP. > > Represent the RPU domain resources in one device node. Each RPU > processor is a subnode of the top RPU domain node. > > Signed-off-by: Jason Wu > Signed-off-by: Wendy Liang > Signed-off-by: Michal Simek > > Signed-off-by: Ben Levinsky > --- [...] > .../xilinx,zynqmp-r5-remoteproc.yaml | 119 ++++++++++++++++++ > 1 file changed, 119 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > > diff --git a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > new file mode 100644 > index 000000000000..cd2406b4dc24 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > @@ -0,0 +1,119 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Xilinx R5 remote processor controller bindings > + > +description: > + This document defines the binding for the remoteproc component that loads and > + boots firmwares on the Xilinx Zynqmp and Versal family chipset. > + > + Note that the Linux has global addressing view of the R5-related memory (TCM) > + so the absolute address ranges are provided in TCM reg's. > +maintainers: > + - Ed Mooring > + - Ben Levinsky > + > +properties: > + compatible: > + const: "xlnx,zynqmp-r5-remoteproc-1.0" > + > + lockstep-mode: > + description: > + R5 core configuration (split is 0 or lock-step and 1) > + maxItems: 1 Looking at the driver, it seems that it is possible to set the R5s to operate in split or lock-step mode dynamically. If so, the device tree shouldn't really contain this property. Wouldn't it be better to give the users flexibility to choose the mode at run time? Thanks, Punit > + > + interrupts: > + description: > + Interrupt mapping for remoteproc IPI. It is required if the > + user uses the remoteproc driver with the RPMsg kernel driver. > + maxItems: 6 > + > + memory-region: > + description: > + collection of memory carveouts used for elf-loading and inter-processor > + communication. > + maxItems: 4 > + minItems: 4 > + meta-memory-regions: > + description: > + collection of memories that are not present in the top level memory > + nodes' mapping. For example, R5s' TCM banks. These banks are needed > + for R5 firmware meta data such as the R5 firmware's heap and stack > + pnode-id: > + maxItems: 1 > + mboxes: > + maxItems: 2 > + mbox-names: > + maxItems: 2 > + > +examples: > + - | > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + elf_load: rproc@3ed000000 { > + no-map; > + reg = <0x3ed00000 0x40000>; > + }; > + > + rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 { > + no-map; > + reg = <0x3ed40000 0x4000>; > + }; > + rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 { > + no-map; > + reg = <0x3ed44000 0x4000>; > + }; > + rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 { > + no-map; > + reg = <0x3ed48000 0x100000>; > + }; > + > + }; > + > + /* > + * Below nodes are required if using TCM to load R5 firmware > + * if not, then either do not provide nodes are label as disabled in > + * status property > + */ > + tcm0a: tcm_0a@ffe00000 { > + reg = <0xffe00000 0x10000>; > + pnode-id = <0xf>; > + no-map; > + status = "okay"; > + phandle = <0x40>; > + compatible = "xlnx,tcm"; > + }; > + tcm0b: tcm_1a@ffe20000 { > + reg = <0xffe20000 0x10000>; > + pnode-id = <0x10>; > + no-map; > + status = "okay"; > + compatible = "xlnx,tcm"; > + phandle = <0x41>; > + }; > + > + rpu { > + compatible = "xlnx,zynqmp-r5-remoteproc-1.0"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + lockstep-mode = <1>; > + r5_0 { > + ranges; > + #address-cells = <1>; > + #size-cells = <1>; > + memory-region = <&elf_load>, > + <&rpu0vdev0vring0>, > + <&rpu0vdev0vring1>, > + <&rpu0vdev0buffer>; > + meta-memory-regions = <&tcm_0a>, <&tcm_0b>; > + pnode-id = <0x7>; > + }; > + }; > + > +... 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=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 94540C43463 for ; Fri, 18 Sep 2020 06:31:12 +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 370CB20DD4 for ; Fri, 18 Sep 2020 06:31:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="W/lO/tYh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 370CB20DD4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=toshiba.co.jp 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:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aAg12GDj3ikdcb8GFSUZBryjcnNQQ4uExYTqg3eRufY=; b=W/lO/tYhEEmgk9Msnqy1tIFic Q5cTL2I8Ehio5E6HP8UJ7tUwP+9M0mUvxPMUd7+1armNk4frRgaqnrJ/4ZTAGAKvqgaxMmkG26iYU tPfGVYGDJrb29b7vysRuFwsER5QXVRL2GxFUb0USrnBICcLajy7SGiAvgeoZFCxKDGDl8OpoPST/M OePhwOUiYBoC8CXYju2/AAvvyDw7SlW33GlB8DTEuLQhrs7yNlks3WvlIe/mDD968sHc1q80TNfqu 1eG8GGuQJLFg3UBlp9XtBE4uZgeyz+t9J4FtJpDZuamIsc71LYEa48eX6MCZJIsmo202/S60GsZhG V9ZqfvlYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJ9tM-0004N1-0V; Fri, 18 Sep 2020 06:29:08 +0000 Received: from mo-csw1516.securemx.jp ([210.130.202.155] helo=mo-csw.securemx.jp) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJ9tI-0004Mf-AE for linux-arm-kernel@lists.infradead.org; Fri, 18 Sep 2020 06:29:06 +0000 Received: by mo-csw.securemx.jp (mx-mo-csw1516) id 08I6StZl003562; Fri, 18 Sep 2020 15:28:55 +0900 X-Iguazu-Qid: 34trFrx2pqNWq2MYnj X-Iguazu-QSIG: v=2; s=0; t=1600410535; q=34trFrx2pqNWq2MYnj; m=XWOMKSutyKBJnyIaL4q4wThvZCfnOaUx8ba8QIcGqvo= Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.securemx.jp (mx-mr1510) id 08I6Srbq032718; Fri, 18 Sep 2020 15:28:53 +0900 Received: from enc01.toshiba.co.jp ([106.186.93.100]) by imx2.toshiba.co.jp with ESMTP id 08I6Srv6006057; Fri, 18 Sep 2020 15:28:53 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.toshiba.co.jp with ESMTP id 08I6Sq6W005477; Fri, 18 Sep 2020 15:28:53 +0900 From: Punit Agrawal To: Ben Levinsky Subject: Re: [PATCH v14 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings References: <20200917194341.16272-1-ben.levinsky@xilinx.com> <20200917194341.16272-5-ben.levinsky@xilinx.com> Date: Fri, 18 Sep 2020 15:28:50 +0900 In-Reply-To: <20200917194341.16272-5-ben.levinsky@xilinx.com> (Ben Levinsky's message of "Thu, 17 Sep 2020 12:43:40 -0700") X-TSB-HOP: ON Message-ID: <87r1qzlhst.fsf@kokedama.swc.toshiba.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200918_022904_682483_10312D9B X-CRM114-Status: GOOD ( 22.40 ) 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: stefanos@xilinx.com, emooring@xilinx.com, michael.auchter@ni.com, mathieu.poirier@linaro.org, devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, jliang@xilinx.com, robh+dt@kernel.org, michals@xilinx.com, Jason Wu , Michal Simek , 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 Hi Ben, One query below - Ben Levinsky writes: > Add binding for ZynqMP R5 OpenAMP. > > Represent the RPU domain resources in one device node. Each RPU > processor is a subnode of the top RPU domain node. > > Signed-off-by: Jason Wu > Signed-off-by: Wendy Liang > Signed-off-by: Michal Simek > > Signed-off-by: Ben Levinsky > --- [...] > .../xilinx,zynqmp-r5-remoteproc.yaml | 119 ++++++++++++++++++ > 1 file changed, 119 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > > diff --git a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > new file mode 100644 > index 000000000000..cd2406b4dc24 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml > @@ -0,0 +1,119 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Xilinx R5 remote processor controller bindings > + > +description: > + This document defines the binding for the remoteproc component that loads and > + boots firmwares on the Xilinx Zynqmp and Versal family chipset. > + > + Note that the Linux has global addressing view of the R5-related memory (TCM) > + so the absolute address ranges are provided in TCM reg's. > +maintainers: > + - Ed Mooring > + - Ben Levinsky > + > +properties: > + compatible: > + const: "xlnx,zynqmp-r5-remoteproc-1.0" > + > + lockstep-mode: > + description: > + R5 core configuration (split is 0 or lock-step and 1) > + maxItems: 1 Looking at the driver, it seems that it is possible to set the R5s to operate in split or lock-step mode dynamically. If so, the device tree shouldn't really contain this property. Wouldn't it be better to give the users flexibility to choose the mode at run time? Thanks, Punit > + > + interrupts: > + description: > + Interrupt mapping for remoteproc IPI. It is required if the > + user uses the remoteproc driver with the RPMsg kernel driver. > + maxItems: 6 > + > + memory-region: > + description: > + collection of memory carveouts used for elf-loading and inter-processor > + communication. > + maxItems: 4 > + minItems: 4 > + meta-memory-regions: > + description: > + collection of memories that are not present in the top level memory > + nodes' mapping. For example, R5s' TCM banks. These banks are needed > + for R5 firmware meta data such as the R5 firmware's heap and stack > + pnode-id: > + maxItems: 1 > + mboxes: > + maxItems: 2 > + mbox-names: > + maxItems: 2 > + > +examples: > + - | > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + elf_load: rproc@3ed000000 { > + no-map; > + reg = <0x3ed00000 0x40000>; > + }; > + > + rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 { > + no-map; > + reg = <0x3ed40000 0x4000>; > + }; > + rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 { > + no-map; > + reg = <0x3ed44000 0x4000>; > + }; > + rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 { > + no-map; > + reg = <0x3ed48000 0x100000>; > + }; > + > + }; > + > + /* > + * Below nodes are required if using TCM to load R5 firmware > + * if not, then either do not provide nodes are label as disabled in > + * status property > + */ > + tcm0a: tcm_0a@ffe00000 { > + reg = <0xffe00000 0x10000>; > + pnode-id = <0xf>; > + no-map; > + status = "okay"; > + phandle = <0x40>; > + compatible = "xlnx,tcm"; > + }; > + tcm0b: tcm_1a@ffe20000 { > + reg = <0xffe20000 0x10000>; > + pnode-id = <0x10>; > + no-map; > + status = "okay"; > + compatible = "xlnx,tcm"; > + phandle = <0x41>; > + }; > + > + rpu { > + compatible = "xlnx,zynqmp-r5-remoteproc-1.0"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + lockstep-mode = <1>; > + r5_0 { > + ranges; > + #address-cells = <1>; > + #size-cells = <1>; > + memory-region = <&elf_load>, > + <&rpu0vdev0vring0>, > + <&rpu0vdev0vring1>, > + <&rpu0vdev0buffer>; > + meta-memory-regions = <&tcm_0a>, <&tcm_0b>; > + pnode-id = <0x7>; > + }; > + }; > + > +... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel