| 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
| ||
|
Message-ID: <2c45d7fb-06e4-468d-9415-0eaa48c5250b@amd.com> Date: Mon, 11 Mar 2024 11:27:42 -0500 From: Tanmay Shah <tanmay.shah@....com> To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, andersson@...nel.org, mathieu.poirier@...aro.org, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, michal.simek@....com, ben.levinsky@....com Cc: linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Radhey Shyam Pandey <radhey.shyam.pandey@....com> Subject: Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings Hello Krzysztof, Thanks for reviews. Please find my comments below. On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote: > On 01/03/2024 19:16, Tanmay Shah wrote: > > From: Radhey Shyam Pandey <radhey.shyam.pandey@....com> > > > > Introduce bindings for TCM memory address space on AMD-xilinx Zynq > > UltraScale+ platform. It will help in defining TCM in device-tree > > and make it's access platform agnostic and data-driven. > > > > Tightly-coupled memories(TCMs) are low-latency memory that provides > > predictable instruction execution and predictable data load/store > > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory > > banks on the ATCM and BTCM ports, for a total of 128 KB of memory. > > > > The TCM resources(reg, reg-names and power-domain) are documented for > > each TCM in the R5 node. The reg and reg-names are made as required > > properties as we don't want to hardcode TCM addresses for future > > platforms and for zu+ legacy implementation will ensure that the > > old dts w/o reg/reg-names works and stable ABI is maintained. > > > > It also extends the examples for TCM split and lockstep modes. > > > > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@....com> > > Signed-off-by: Tanmay Shah <tanmay.shah@....com> > > --- > > > > Changes in v12: > > - add "reg", "reg-names" and "power-domains" in pattern properties > > - add "reg" and "reg-names" in required list > > - keep "power-domains" in required list as it was before the change > > > > Changes in v11: > > - Fix yamllint warning and reduce indentation as needed > > > > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 ++++++++++++++++-- > > 1 file changed, 168 insertions(+), 20 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > index 78aac69f1060..dc6ce308688f 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > > @@ -20,9 +20,21 @@ properties: > > compatible: > > const: xlnx,zynqmp-r5fss > > > > + "#address-cells": > > + const: 2 > > + > > + "#size-cells": > > + const: 2 > > + > > + ranges: > > + description: | > > + Standard ranges definition providing address translations for > > + local R5F TCM address spaces to bus addresses. > > + > > xlnx,cluster-mode: > > $ref: /schemas/types.yaml#/definitions/uint32 > > enum: [0, 1, 2] > > + default: 1 > > description: | > > The RPU MPCore can operate in split mode (Dual-processor performance), Safety > > lock-step mode(Both RPU cores execute the same code in lock-step, > > @@ -37,7 +49,7 @@ properties: > > 2: single cpu mode > > > > patternProperties: > > - "^r5f-[a-f0-9]+$": > > + "^r5f@[0-9a-f]+$": > > type: object > > description: | > > The RPU is located in the Low Power Domain of the Processor Subsystem. > > @@ -54,8 +66,17 @@ patternProperties: > > compatible: > > const: xlnx,zynqmp-r5f > > > > + reg: > > + minItems: 1 > > + maxItems: 4 > > + > > + reg-names: > > + minItems: 1 > > + maxItems: 4 > > + > > power-domains: > > - maxItems: 1 > > + minItems: 2 > > + maxItems: 5 > > > > mboxes: > > minItems: 1 > > @@ -101,35 +122,162 @@ patternProperties: > > > > required: > > - compatible > > + - reg > > + - reg-names > > - power-domains > > > > - unevaluatedProperties: false > > - > > required: > > - compatible > > + - "#address-cells" > > + - "#size-cells" > > + - ranges > > + > > +allOf: > > + - if: > > + properties: > > + xlnx,cluster-mode: > > + enum: > > + - 1 > > + then: > > + patternProperties: > > + "^r5f@[0-9a-f]+$": > > + type: object > > + > > + properties: > > + reg: > > + minItems: 1 > > + items: > > + - description: ATCM internal memory > > + - description: BTCM internal memory > > + - description: extra ATCM memory in lockstep mode > > + - description: extra BTCM memory in lockstep mode > > + > > + reg-names: > > + minItems: 1 > > + items: > > + - const: atcm0 > > + - const: btcm0 > > + - const: atcm1 > > + - const: btcm1 > > Why power domains are flexible? User may not want to use all the TCMs. For example, if users want to turn-on only TCM-A and rest of them want to keep off, then they can avoid having power-domains of other TCMs in the device-tree. This helps with less power-consumption when needed. Hence flexible list of power-domains list. I can certainly mention "items:" under power-domains property. > > > + > > + else: > > + patternProperties: > > + "^r5f@[0-9a-f]+$": > > + type: object > > + > > + properties: > > + reg: > > + minItems: 1 > > + items: > > + - description: ATCM internal memory > > + - description: BTCM internal memory > > + > > + reg-names: > > + minItems: 1 > > + items: > > + - const: atcm0 > > + - const: btcm0 > > + > > + power-domains: > > + maxItems: 3 > > Please list power domains. Okay. But minItems will be still what's mentioned above i.e. 2. I hope it's fine. > > > > > additionalProperties: false > > > Best regards, > Krzysztof >
Powered by blists - more mailing lists