| 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: Sun, 15 Jan 2023 15:45:32 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Tanmay Shah <tanmays@....com>, Tanmay Shah <tanmay.shah@....com>,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: sram: Tightly Coupled Memory (TCM) bindings
On 13/01/2023 19:04, Tanmay Shah wrote:
> Hi Krzysztof Thanks for your reviews.
>
> Please find my comments below.
>
> On 1/12/23 11:52 PM, Krzysztof Kozlowski wrote:
>> On 13/01/2023 08:30, Tanmay Shah wrote:
>>> This patch introduces bindings for TCM memory address space on AMD-xilinx
>>> platforms. As of now TCM addresses are hardcoded in xilinx remoteproc
>>> driver. This bindings will help in defining TCM in device-tree and
>>> make it's access platform agnostic and data-driven from the driver.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@....com>
>>> ---
>>> .../devicetree/bindings/sram/xlnx,tcm.yaml | 137 ++++++++++++++++++
>>> 1 file changed, 137 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/sram/xlnx,tcm.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/sram/xlnx,tcm.yaml b/Documentation/devicetree/bindings/sram/xlnx,tcm.yaml
>>> new file mode 100644
>>> index 000000000000..02d17026fb1f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sram/xlnx,tcm.yaml
>>> @@ -0,0 +1,137 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/sram/xlnx,tcm.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Tightly Coupled Memory (TCM)
>>> +
>>> +maintainers:
>>> + - Tanmay Shah <tanmay.shah@....com>
>>> +
>>> +description: |
>>> + Tightly Coupled Memory(TCM) is available on AMD-Xilinx paltforms for ARM
>>> + cortex remote processors to use. It is low-latency memory that provide
>>> + predictable instruction execution and predictable data load/store timing.
>>> + TCM can be configured in lockstep mode or split mode. In split mode
>>> + configuration each RPU core has its own set of ATCM and BTCM memories and in
>>> + lockstep mode redundant processor's TCM become available to lockstep
>>> + processor. So In lockstep mode ATCM and BTCM size is increased.
>>> +
>>> +properties:
>>> + $nodename:
>>> + pattern: "sram-[0-9a-f]+$"
>> Drop node name requirement.
>> Why do you need sram node at all?
>
>
> I will remove sram- node. However, it device-tree I was planning to put
>
> all TCM nodes under single node for example:
>
> tcm {
>
> tcm-lockstep {
>
> };
>
> tcm-core@0 {
Mix of nodes with and without unit address is pointing to some design
issues.
>
> };
>
> };
>
> The top-most tcm node I assumed sram node. So I kept sram@...x
>
>>> +
>>> +patternProperties:
>>> + "^tcm-[a-z]+@[0-9a-f]+$":
>>> + type: object
>>> + description: |
>>> + During the split mode, each RPU core has its own set of ATCM and BTCM memory
>>> +
>>> + During the lock-step operation, the TCMs that are associated with the
>>> + redundant processor become available to the lock-step processor.
>>> + For example if each individual processor has 64KB ATCM, then in lockstep mode
>>> + The size of ATCM become 128KB. Same for BTCM. tcm-lockstep node represents
>>> + TCM address space in lockstep mode. tcm-core@x node specfies each core's
>>> + TCM address space in split mode.
>>> +
>>> + properties:
>>> + compatible:
>>> + oneOf:
>> This is not oneOf.
>>
>>> + - items:
>> and you do not have more than one item.
>>
>>> + - enum:
>>> + - xlnx,tcm-lockstep
>>> + - xlnx,tcm-split
>> compatible describes hardware, not configuration. What you encode here
>> does not fit compatible.
>
>
> I see. So, only xlnx,tcm is enough.
No, it must be specific to SoC.
>
>
>>
>>> +
>>> + "#address-cells":
>> Use consistent quotes, either " or '
>
>
> Ack.
>
>
>>
>>> + const: 1
>>> +
>>> + "#size-cells":
>>> + const: 1
>>> +
>>> + reg:
>>> + items:
>>> + - description: |
>>> + ATCM Memory address space. An ATCM typically holds interrupt or
>>> + exception code that must be accessed at high speed, without any
>>> + potential delay resulting from a cache miss.
>>> + RPU on AMD-Xilinx platform can also fetch data from ATCM
>>> + - description: |
>>> + BTCM Memory address space. A BTCM typically holds a block of data
>>> + for intensive processing, such as audio or video processing. RPU on
>>> + AMD-Xilinx Platforms can also fetch Code (Instructions) from BTCM
>>> +
>>> + reg-names:
>>> + items:
>>> + - const: atcm
>>> + - const: btcm
>>> +
>>> + ranges: true
>>> +
>>> + power-domains:
>>> + maxItems: 8
>>> + items:
>>> + - description: list of ATCM Power domains
>>> + - description: list of BTCM Power domains
>>> + additionalItems: true
>> And what are the rest?
> As both items are list, we should be able to include more than one
> power-domain I believe.
>
>
> So first item I am trying to create list of ATCM power domains.
>
> In split mode, first item is ATCM power-domain and second item is BTCM
> power domain.
>
> However, In lockstep mode, second core's TCM physically relocates and
> two ATCM combines and
Why power domains of a device depend on the mode? This does not look
like binding describing hardware.
>
> makes single region of ATCM. However, their power-domains remains same.
>
> So, In lockstep mode, first two banks are ATCM and so, first two items
> are ATCM power-domains.
>
> I am not sure best way to represent this. But, first itmes is list.
>
> So, I am assuming list of all ATCM power-domains possible.
List all items. Order is fixed, you cannot say BTCM is second item and
then put here something else.
Best regards,
Krzysztof
Powered by blists - more mailing lists