| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 May 2020 17:40:22 +0000
From: Ben Levinsky <BLEVINSK@...inx.com>
To: Rob Herring <robh@...nel.org>
CC: "ohad@...ery.com" <ohad@...ery.com>,
"bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
Michal Simek <michals@...inx.com>,
Jolly Shah <JOLLYS@...inx.com>, Rajan Vaja <RAJANV@...inx.com>,
"mark.rutland@....com" <mark.rutland@....com>,
"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stefano Stabellini <stefanos@...inx.com>
Subject: RE: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for
ZynqMP R5 rproc bindings
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 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.
Will also update as per your below comments in a v5 too.
Best Regards,
Ben Levinsky
-----Original Message-----
From: Rob Herring <robh@...nel.org>
Sent: Monday, May 11, 2020 3:18 PM
To: Ben Levinsky <BLEVINSK@...inx.com>
Cc: ohad@...ery.com; bjorn.andersson@...aro.org; Michal Simek <michals@...inx.com>; Jolly Shah <JOLLYS@...inx.com>; Rajan Vaja <RAJANV@...inx.com>; mark.rutland@....com; linux-remoteproc@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; Jason Wu <j.wu@...inx.com>; Jiaying Liang <jliang@...inx.com>
Subject: Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
On Fri, Apr 24, 2020 at 10:36:09AM -0700, Ben Levinsky wrote:
> 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.
This needs to be sorted out as part of the system DT effort that Xilinx is working on. I can't see this binding co-existing with it.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@...inx.com>
> Signed-off-by: Jason Wu <j.wu@...inx.com>
> Signed-off-by: Wendy Liang <jliang@...inx.com>
> Signed-off-by: Michal Simek <michal.simek@...inx.com>
> ---
> Changes since v2:
> - update zynqmp_r5 yaml parsing to not raise warnings for extra
> information in children of R5 node. The warning "node has a unit
> name, but no reg or ranges property" will still be raised though
> as this particular node is needed to describe the
> '#address-cells' and '#size-cells' information.
> Changes since 3:
> - remove warning '/example-0/rpu@...a0000/r5@0:
> node has a unit name, but no reg or ranges property'
> by adding reg to r5 node.
> ---
>
> .../remoteproc/xilinx,zynqmp-r5-remoteproc.yaml | 127 +++++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remotepr
> oc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remote
> proc.yaml
> new file mode 100644
> index 0000000..41520b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-re
> +++ moteproc.yaml
> @@ -0,0 +1,127 @@
> +# 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.
> +
> +maintainers:
> + - Ed Mooring <ed.mooring@...inx.com>
> + - Ben Levinsky <ben.levinsky@...inx.com>
> +
> +properties:
> + compatible:
> + const: "xlnx,zynqmp-r5-remoteproc-1.0"
> +
> + core_conf:
> + description:
> + R5 core configuration (valid string - split or lock-step)
> + maxItems: 1
> +
> + 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:
> + maxItems: 4
> + minItems: 4
> + pnode-id:
> + maxItems: 1
What is this?
[Ben Levinsky] I will description for this. This is used by the Xilinx power management code later on when configuring the RPU.
> + mboxes:
> + maxItems: 2
> + mbox-names:
> + maxItems: 2
> +
> + r5@0:
> + type: object
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + - pnode-id
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + rpu0vdev0vring0: rpu0vdev0vring0@...40000 {
> + no-map;
> + reg = <0x3ed40000 0x4000>;
> + };
> + rpu0vdev0vring1: rpu0vdev0vring1@...44000 {
> + no-map;
> + reg = <0x3ed44000 0x4000>;
> + };
> + rpu0vdev0buffer: rpu0vdev0buffer@...48000 {
> + no-map;
> + reg = <0x3ed48000 0x100000>;
> + };
> + rproc_0_reserved: rproc@...000000 {
> + no-map;
> + reg = <0x3ed00000 0x40000>;
> + };
> + };
> + rpu: rpu@...a0000 {
> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + core_conf = "split";
If split, then where is the 2nd core?
[Ben Levinsky] Will fix, I will add second core in v5.
> + reg = <0xFF9A0000 0x10000>;
> + r5_0: r5@0 {
Unit-addresses are based on 'reg' values.
[Ben Levinsky] Will fix this, thanks
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFF9A0100 0x1000>;
> + memory-region = <&rproc_0_reserved>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
> + pnode-id = <0x7>;
> + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
> + mbox-names = "tx", "rx";
> + tcm_0_a: tcm_0@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFFE00000 0x10000>;
> + pnode-id = <0xf>;
These nodes probably need some sort of compatible. And don't the TCMs have different addresses for R5 vs. the A cores?
[Ben Levinsky] I can add a compatible. The addressesing here is absolute (i.e. 0xffex-xxxx ) as it is used from point of view of A core here.
> + };
> + tcm_0_b: tcm_0@1 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0xFFE20000 0x10000>;
> + pnode-id = <0x10>;
> + };
> + };
> + };
> +
> +
> + zynqmp_ipi1 {
> + compatible = "xlnx,zynqmp-ipi-mailbox";
> + interrupt-parent = <&gic>;
> + interrupts = <0 29 4>;
> + xlnx,ipi-id = <7>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* APU<->RPU0 IPI mailbox controller */
> + ipi_mailbox_rpu0: mailbox@...0000 {
> + reg = <0xff990600 0x20>,
> + <0xff990620 0x20>,
> + <0xff9900c0 0x20>,
> + <0xff9900e0 0x20>;
> + reg-names = "local_request_region",
> + "local_response_region",
> + "remote_request_region",
> + "remote_response_region";
> + #mbox-cells = <1>;
> + xlnx,ipi-id = <1>;
> + };
> + };
> +
> +...
> --
> 2.7.4
>
Powered by blists - more mailing lists