Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs

From: Suman Anna
Date: Thu May 28 2020 - 20:23:38 EST

Next message: Logan Gunthorpe: "Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api"
Previous message: Dave Airlie: "[git pull] drm fixes for 5.7-rc8/final"
In reply to: Suman Anna: "Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Rob,

On 5/28/20 5:47 PM, Suman Anna wrote:

Hi Rob,

On 5/28/20 5:32 PM, Rob Herring wrote:

On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:

Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.

Signed-off-by: Suman Anna <s-anna@xxxxxx>
---
v2:
Â - Updated the example to include the root-node to fix the bot errors from v1

Pretty sure that was not why you had errors.

It is because of the default values used for #address-cells and #size-cells in the example_template and example_start variables used in the dt-extract-example script. They are 1 by default, so the generated template ended up with the root-node using 1, and the actual example using 2 resulting in the mismatch.

When I updated the script to use 2 for both #address-cells and #size-cells, then the warnings go away. This is the reason, dtbs_check on my actual dts files goes through fine.

Just to clarify, the warnings were only because of the mismatched 'ranges'. If I limit the example to just the dsp node, eliminating all ranges usage, then it passes fine.

So, you would see this with any example that uses ranges with #address-cells and #size-cells as 2 without explicitly using the appropriate top-level #address-cells and #size-cells.

Â - Added maxItems to resets, mboxes, memory-region, sram properties
Â - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
Â - Addressed the minor review comments from Mathieu
v1: https://patchwork.kernel.org/patch/11458571/

Â .../bindings/remoteproc/ti,k3-dsp-rproc.yamlÂ | 190 ++++++++++++++++++
Â 1 file changed, 190 insertions(+)
Â create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
new file mode 100644
index 000000000000..cdf649655838
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 DSP devices
+
+maintainers:
+Â - Suman Anna <s-anna@xxxxxx>
+
+description: |
+Â The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
+Â that are used to offload some of the processor-intensive tasks or algorithms,
+Â for achieving various system level goals.
+
+Â These processor sub-systems usually contain additional sub-modules like
+Â L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
+Â controller, a dedicated local power/sleep controller etc. The DSP processor
+Â cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
+Â TMS320C71x CorePac processor.
+
+Â Each DSP Core sub-system is represented as a single DT node. Each node has a
+Â number of required or optional properties that enable the OS running on the
+Â host processor (Arm CorePac) to perform the device management of the remote
+Â processor and to communicate with the remote processor.
+
+properties:
+Â compatible:
+ÂÂÂ const: ti,j721e-c66-dsp
+ÂÂÂ description:
+ÂÂÂÂÂ Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs

What else are you going to use? There's only one compatible string. Drop
description.

Is updated in a subsequent binding update where I added the C71 support.

See https://patchwork.kernel.org/patch/11563231/.

Let me know if you prefer that I combine both of them. Any changes to this patch will also affect the other.

+
+Â reg:
+ÂÂÂ description: |
+ÂÂÂÂÂ Should contain an entry for each value in 'reg-names'.
+ÂÂÂÂÂ Each entry should have the memory region's start address
+ÂÂÂÂÂ and the size of the region, the representation matching
+ÂÂÂÂÂ the parent node's '#address-cells' and '#size-cells' values.

Don't need generic descriptions. That's every 'reg'.

What you can do is an 'items' list describing what each region is.

OK, I am bit confused here. I have listed the items under the reg-names, while using just the minItems or maxItems here. What is the convention, aren't reg and reg-names associative.

+ÂÂÂ minItems: 3
+ÂÂÂ maxItems: 3
+
+Â reg-names:
+ÂÂÂ description: |
+ÂÂÂÂÂ Should contain strings with the names of the specific internal
+ÂÂÂÂÂ memory regions, and should be defined in this order

Again, drop.

OK

+ÂÂÂ maxItems: 3
+ÂÂÂ items:
+ÂÂÂÂÂ - const: l2sram
+ÂÂÂÂÂ - const: l1pram
+ÂÂÂÂÂ - const: l1dram
+
+Â ti,sci:
+ÂÂÂ $ref: /schemas/types.yaml#/definitions/phandle
+ÂÂÂ description:
+ÂÂÂÂÂ Should be a phandle to the TI-SCI System Controller node
+
+Â ti,sci-dev-id:
+ÂÂÂ $ref: /schemas/types.yaml#/definitions/uint32
+ÂÂÂ description: |
+ÂÂÂÂÂ Should contain the TI-SCI device id corresponding to the DSP core.
+ÂÂÂÂÂ Please refer to the corresponding System Controller documentation
+ÂÂÂÂÂ for valid values for the DSP cores.
+
+Â ti,sci-proc-ids:
+ÂÂÂ description: Should contain a single tuple of <proc_id host_id>.
+ÂÂÂ allOf:
+ÂÂÂÂÂ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ÂÂÂÂÂ - maxItems: 1
+ÂÂÂÂÂÂÂ items:
+ÂÂÂÂÂÂÂÂÂ items:
+ÂÂÂÂÂÂÂÂÂÂÂ - description: TI-SCI processor id for the DSP core device
+ÂÂÂÂÂÂÂÂÂÂÂ - description: TI-SCI host id to which processor control
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ownership should be transferred to

I assume these properties appear in multiple TI nodes? We don't need
them defined multiple times. Create a schema for them that you can
include here.

Only the remoteprocs, so they are limited to this binding and one more R5F remoteproc binding.

Can you confirm if these are the properties you want moved - ti,sci, ti,sci-dev-id and ti,sci-proc-ids? Any recommended path I should be using, is remoteproc folder still fine for this?

regards
Suman

+
+Â resets:
+ÂÂÂ description: |
+ÂÂÂÂÂ Should contain the phandle to the reset controller node
+ÂÂÂÂÂ managing the local resets for this device, and a reset
+ÂÂÂÂÂ specifier. Please refer to the following reset bindings
+ÂÂÂÂÂ for the reset argument specifier,
+ÂÂÂÂÂ Documentation/devicetree/bindings/reset/ti,sci-reset.txt

Drop.

Entire description or just the reference to the reset bindings file?

+ÂÂÂ maxItems: 1
+
+Â firmware-name:
+ÂÂÂ description: |
+ÂÂÂÂÂ Should contain the name of the default firmware image
+ÂÂÂÂÂ file located on the firmware search path
+
+Â mboxes:
+ÂÂÂ description: |
+ÂÂÂÂÂ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ÂÂÂÂÂ communication with the remote processor. This property should match
+ÂÂÂÂÂ with the sub-mailbox node used in the firmware image. The specifier
+ÂÂÂÂÂ format is as per the bindings,
+ÂÂÂÂÂ Documentation/devicetree/bindings/mailbox/omap-mailbox.txt

Drop. What mailbox provider is used is outside the scope of this
binding.

OK.

+ÂÂÂ maxItems: 1
+
+Â memory-region:
+ÂÂÂ minItems: 2
+ÂÂÂ maxItems: 8
+ÂÂÂ description: |
+ÂÂÂÂÂ phandle to the reserved memory nodes to be associated with the remoteproc
+ÂÂÂÂÂ device. There should be at least two reserved memory nodes defined - the
+ÂÂÂÂÂ first one would be used for dynamic DMA allocations like vrings and vring
+ÂÂÂÂÂ buffers, and the remaining ones used for the firmware image sections. The
+ÂÂÂÂÂ reserved memory nodes should be carveout nodes, and should be defined as
+ÂÂÂÂÂ per the bindings in
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

items:
ÂÂ - description: dynamic DMA allocations like vrings and vring buffers
ÂÂ - description: firmware image section ???
ÂÂ - description: firmware image section ???

Yeah, this is scalable if we will have multiple separate DDR regions. I had to choose a decent maxItems value, so I chose 8. Wouldn't listing the individual items override the number of minItems/maxItems?

+
+# Optional properties:
+# --------------------
+
+Â sram:
+ÂÂÂ $ref: /schemas/types.yaml#/definitions/phandle-array
+ÂÂÂ minItems: 1
+ÂÂÂ maxItems: 4
+ÂÂÂ description: |
+ÂÂÂÂÂ phandles to one or more reserved on-chip SRAM regions. The regions
+ÂÂÂÂÂ should be defined as child nodes of the respective SRAM node, and
+ÂÂÂÂÂ should be defined as per the generic bindings in,
+ÂÂÂÂÂ Documentation/devicetree/bindings/sram/sram.yaml
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+ - mboxes
+ - memory-region
+
+additionalProperties: false
+
+examples:
+Â - |
+ÂÂÂ / {
+ÂÂÂÂÂÂÂ model = "Texas Instruments K3 J721E SoC";
+ÂÂÂÂÂÂÂ compatible = "ti,j721e";
+ÂÂÂÂÂÂÂ #address-cells = <2>;
+ÂÂÂÂÂÂÂ #size-cells = <2>;
+
+ÂÂÂÂÂÂÂ /* DSP Carveout reserved memory nodes */
+ÂÂÂÂÂÂÂ reserved-memory {
+ÂÂÂÂÂÂÂÂÂÂÂ #address-cells = <2>;
+ÂÂÂÂÂÂÂÂÂÂÂ #size-cells = <2>;
+ÂÂÂÂÂÂÂÂÂÂÂ ranges;
+
+ÂÂÂÂÂÂÂÂÂÂÂ c66_0_dma_memory_region: c66-dma-memory@a6000000 {
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ compatible = "shared-dma-pool";
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <0x00 0xa6000000 0x00 0x100000>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ no-map;
+ÂÂÂÂÂÂÂÂÂÂÂ };
+
+ÂÂÂÂÂÂÂÂÂÂÂ c66_0_memory_region: c66-memory@a6100000 {
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ compatible = "shared-dma-pool";
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <0x00 0xa6100000 0x00 0xf00000>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ no-map;
+ÂÂÂÂÂÂÂÂÂÂÂ };
+ÂÂÂÂÂÂÂ };

Drop all of this. Outside the scope of this binding. And will likely
start failing validation as schemas become more complete.

This is a complete example because of the memory-region references below.

+
+ÂÂÂÂÂÂÂ cbass_main: bus@100000 {

Drop unused labels.

OK.

regards
Suman

+ÂÂÂÂÂÂÂÂÂÂÂ compatible = "simple-bus";
+ÂÂÂÂÂÂÂÂÂÂÂ #address-cells = <2>;
+ÂÂÂÂÂÂÂÂÂÂÂ #size-cells = <2>;
+ÂÂÂÂÂÂÂÂÂÂÂ ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
+
+ÂÂÂÂÂÂÂÂÂÂÂ /* J721E C66_0 DSP node */
+ÂÂÂÂÂÂÂÂÂÂÂ c66_0: dsp@4d80800000 {
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ compatible = "ti,j721e-c66-dsp";
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <0x4d 0x80800000 0x00 0x00048000>,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <0x4d 0x80e00000 0x00 0x00008000>,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <0x4d 0x80f00000 0x00 0x00008000>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg-names = "l2sram", "l1pram", "l1dram";
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ti,sci = <&dmsc>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ti,sci-dev-id = <142>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ti,sci-proc-ids = <0x03 0xFF>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ resets = <&k3_reset 142 1>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ firmware-name = "j7-c66_0-fw";
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ memory-region = <&c66_0_dma_memory_region>,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <&c66_0_memory_region>;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
+ÂÂÂÂÂÂÂÂÂÂÂ };
+ÂÂÂÂÂÂÂ };
+ÂÂÂ };
--
2.26.0

Next message: Logan Gunthorpe: "Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api"
Previous message: Dave Airlie: "[git pull] drm fixes for 5.7-rc8/final"
In reply to: Suman Anna: "Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]