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.
- 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.
+
+ 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.
+
+ 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
