[1/3] dt-bindings: dma: Add documentation for DMA domains
diff mbox series

Message ID 20190910115037.23539-2-peter.ujfalusi@ti.com
State Changes Requested
Headers show
Series
  • dmaengine: Support for DMA domain controllers
Related show

Checks

Context Check Description
robh/dt-meta-schema fail build log
robh/checkpatch warning "total: 0 errors, 1 warnings, 88 lines checked"

Commit Message

Peter Ujfalusi Sept. 10, 2019, 11:50 a.m. UTC
On systems where multiple DMA controllers available, non Slave (for example
memcpy operation) users can not be described in DT as there is no device
involved from the DMA controller's point of view, DMA binding is not usable.
However in these systems still a peripheral might need to be serviced by or
it is better to serviced by specific DMA controller.
When a memcpy is used to/from a memory mapped region for example a DMA in the
same domain can perform better.
For generic software modules doing mem 2 mem operations it also matter that
they will get a channel from a controller which is faster in DDR to DDR mode
rather then from the first controller happen to be loaded.

This property is inherited, so it may be specified in a device node or in any
of its parent nodes.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 .../devicetree/bindings/dma/dma-domain.yaml   | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/dma-domain.yaml

Comments

Rob Herring Sept. 13, 2019, 2:36 p.m. UTC | #1
On Tue, Sep 10, 2019 at 02:50:35PM +0300, Peter Ujfalusi wrote:
> On systems where multiple DMA controllers available, non Slave (for example
> memcpy operation) users can not be described in DT as there is no device
> involved from the DMA controller's point of view, DMA binding is not usable.
> However in these systems still a peripheral might need to be serviced by or
> it is better to serviced by specific DMA controller.
> When a memcpy is used to/from a memory mapped region for example a DMA in the
> same domain can perform better.
> For generic software modules doing mem 2 mem operations it also matter that
> they will get a channel from a controller which is faster in DDR to DDR mode
> rather then from the first controller happen to be loaded.
> 
> This property is inherited, so it may be specified in a device node or in any
> of its parent nodes.

If a device needs mem2mem dma, I think we should just use the existing 
dma binding. The provider will need a way to define cell values which 
mean mem2mem.

For generic s/w, it should be able to query the dma speed or get a 
preferred one IMO. It's not a DT problem.

We measure memcpy speeds at boot time to select the fastest 
implementation for a chip, why not do that for mem2mem DMA?

> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  .../devicetree/bindings/dma/dma-domain.yaml   | 88 +++++++++++++++++++
>  1 file changed, 88 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/dma-domain.yaml

Note that you have several errors in your schema. Run 'make dt_bindings_check'.

Rob

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/dma/dma-domain.yaml b/Documentation/devicetree/bindings/dma/dma-domain.yaml
new file mode 100644
index 000000000000..da59bb129c58
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma-domain.yaml
@@ -0,0 +1,88 @@ 
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/dma-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DMA Domain Controller Definition
+
+maintainers:
+  - Vinod Koul <vkoul@kernel.org>
+
+allOf:
+  - $ref: "dma-controller.yaml#"
+
+description:
+  On systems where multiple DMA controllers available, none Slave (for example
+  memcpy operation) users can not be described in DT as there is no device
+  involved from the DMA controller's point of view, DMA binding is not usable.
+  However in these systems still a peripheral might need to be serviced by or
+  it is better to serviced by specific DMA controller.
+  When a memcpy is used to/from a memory mapped region for example a DMA in the
+  same domain can perform better.
+  For generic software modules doing mem 2 mem operations it also matter that
+  they will get a channel from a controller which is faster in DDR to DDR mode
+  rather then from the first controller happen to be loaded.
+
+  This property is inherited, so it may be specified in a device node or in any
+  of its parent nodes.
+
+properties:
+  $dma-domain-controller:
+    $ref: /schemas/types.yaml#definitions/phandle
+    description:
+      phande to the DMA controller node which should be used for the device or
+      domain.
+
+examples:
+  - |
+    / {
+        model = "Texas Instruments K3 AM654 SoC";
+        compatible = "ti,am654";
+        interrupt-parent = <&gic500>;
+        /* For modules without device, DDR to DDR is faster on main UDMAP */
+        dma-domain-controller = <&main_udmap>;
+        #address-cells = <2>;
+        #size-cells = <2>;
+        ...
+    };
+
+    &cbass_main {
+        /* For modules within MAIN domain, use main UDMAP */
+        dma-domain-controller = <&main_udmap>;
+
+        cbass_main_navss: interconnect0 {
+            ...
+            main_udmap: dma-controller@31150000 {
+                compatible = "ti,am654-navss-main-udmap";
+                ...
+            };
+        };
+    };
+
+    &cbass_mcu {
+        /* For modules within MCU domain, use mcu UDMAP */
+        dma-domain-controller = <&mcu_udmap>;
+
+        cbass_mcu_navss: interconnect1 {
+            ...
+            mcu_udmap: dma-controller@285c0000 {
+                compatible = "ti,am654-navss-mcu-udmap";
+                ...
+            };
+        };
+
+        fss: fss@47000000 {
+            compatible = "simple-bus";
+            #address-cells = <2>;
+            #size-cells = <2>;
+            ranges;
+
+            ospi0: spi@47040000 {
+                compatible = "ti,am654-ospi", "cdns,qspi-nor";
+                ...
+                /* memcpy channel will be request from mcu_udmap */
+            };
+        };
+    };
+...