diff mbox series

[v2,1/5] dt-bindings: dma: dw: Add optional DMA-channels mask cell support

Message ID 20200731200826.9292-2-Sergey.Semin@baikalelectronics.ru
State Not Applicable
Headers show
Series dmaengine: dw: Introduce non-mem peripherals optimizations | expand

Checks

Context Check Description
robh/checkpatch success

Commit Message

Serge Semin July 31, 2020, 8:08 p.m. UTC
Each DW DMA controller channel can be synthesized with different
parameters like maximum burst-length, multi-block support, maximum data
width, etc. Most of these parameters determine the DW DMAC channels
performance in its own aspect. On the other hand these parameters can
be implicitly responsible for the channels performance degradation
(for instance multi-block support is a very useful feature, but having
it disabled during the DW DMAC synthesize will provide a more optimized
core). Since DMA slave devices may have critical dependency on the DMA
engine performance, let's provide a way for the slave devices to have
the DMA-channels allocated from a pool of the channels, which according
to the system engineer fulfill their performance requirements.

The pool is determined by a mask optionally specified in the fifth
DMA-cell of the DMA DT-property. If the fifth cell is omitted from the
phandle arguments or the mask is zero, then the allocation will be
performed from a set of all channels provided by the DMA controller.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 .../devicetree/bindings/dma/snps,dma-spear1340.yaml        | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Rob Herring Aug. 3, 2020, 9:51 p.m. UTC | #1
On Fri, 31 Jul 2020 23:08:22 +0300, Serge Semin wrote:
> Each DW DMA controller channel can be synthesized with different
> parameters like maximum burst-length, multi-block support, maximum data
> width, etc. Most of these parameters determine the DW DMAC channels
> performance in its own aspect. On the other hand these parameters can
> be implicitly responsible for the channels performance degradation
> (for instance multi-block support is a very useful feature, but having
> it disabled during the DW DMAC synthesize will provide a more optimized
> core). Since DMA slave devices may have critical dependency on the DMA
> engine performance, let's provide a way for the slave devices to have
> the DMA-channels allocated from a pool of the channels, which according
> to the system engineer fulfill their performance requirements.
> 
> The pool is determined by a mask optionally specified in the fifth
> DMA-cell of the DMA DT-property. If the fifth cell is omitted from the
> phandle arguments or the mask is zero, then the allocation will be
> performed from a set of all channels provided by the DMA controller.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>  .../devicetree/bindings/dma/snps,dma-spear1340.yaml        | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>
Andy Shevchenko Aug. 17, 2020, 10 a.m. UTC | #2
On Mon, Aug 03, 2020 at 03:51:47PM -0600, Rob Herring wrote:
> On Fri, 31 Jul 2020 23:08:22 +0300, Serge Semin wrote:
> > Each DW DMA controller channel can be synthesized with different
> > parameters like maximum burst-length, multi-block support, maximum data
> > width, etc. Most of these parameters determine the DW DMAC channels
> > performance in its own aspect. On the other hand these parameters can
> > be implicitly responsible for the channels performance degradation
> > (for instance multi-block support is a very useful feature, but having
> > it disabled during the DW DMAC synthesize will provide a more optimized
> > core). Since DMA slave devices may have critical dependency on the DMA
> > engine performance, let's provide a way for the slave devices to have
> > the DMA-channels allocated from a pool of the channels, which according
> > to the system engineer fulfill their performance requirements.
> > 
> > The pool is determined by a mask optionally specified in the fifth
> > DMA-cell of the DMA DT-property. If the fifth cell is omitted from the
> > phandle arguments or the mask is zero, then the allocation will be
> > performed from a set of all channels provided by the DMA controller.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>

Rob, I have a question to clarify (it's not directly related to the series,
but to this schema and property names).

We have two drivers for DMA controllers from Synopsys (they are different)
where properties with the same semantics (like block_size or data-width) have
different pattern of naming (okay, block_size for older driver even has _
instead of -), i.e. block_size vs. snps,block-size and data-width vs.
snps,data-width.

I would like to unify them (*) in both drivers and would like to know which
naming pattern is preferred in such case?

*) Yes, we have to leave support for deprecated properties in this case in
   the code.
Rob Herring Aug. 19, 2020, 2:02 p.m. UTC | #3
On Mon, Aug 17, 2020 at 4:17 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Aug 03, 2020 at 03:51:47PM -0600, Rob Herring wrote:
> > On Fri, 31 Jul 2020 23:08:22 +0300, Serge Semin wrote:
> > > Each DW DMA controller channel can be synthesized with different
> > > parameters like maximum burst-length, multi-block support, maximum data
> > > width, etc. Most of these parameters determine the DW DMAC channels
> > > performance in its own aspect. On the other hand these parameters can
> > > be implicitly responsible for the channels performance degradation
> > > (for instance multi-block support is a very useful feature, but having
> > > it disabled during the DW DMAC synthesize will provide a more optimized
> > > core). Since DMA slave devices may have critical dependency on the DMA
> > > engine performance, let's provide a way for the slave devices to have
> > > the DMA-channels allocated from a pool of the channels, which according
> > > to the system engineer fulfill their performance requirements.
> > >
> > > The pool is determined by a mask optionally specified in the fifth
> > > DMA-cell of the DMA DT-property. If the fifth cell is omitted from the
> > > phandle arguments or the mask is zero, then the allocation will be
> > > performed from a set of all channels provided by the DMA controller.
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Rob, I have a question to clarify (it's not directly related to the series,
> but to this schema and property names).
>
> We have two drivers for DMA controllers from Synopsys (they are different)
> where properties with the same semantics (like block_size or data-width) have
> different pattern of naming (okay, block_size for older driver even has _
> instead of -), i.e. block_size vs. snps,block-size and data-width vs.
> snps,data-width.
>
> I would like to unify them (*) in both drivers and would like to know which
> naming pattern is preferred in such case?

Unless there's some sign we'd use it with other vendors, I'd generally
keep the vendor prefix. But I don't think it's worth supporting 3
variants of 'data-width' in the name of unification.

Also, if they don't have a vendor prefix, then they should be in some
standard units rather than an encoded register value. (Which seems to
be the case here).

Rob
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index 20870f5c14dd..ef1d6879c158 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -18,12 +18,15 @@  properties:
     const: snps,dma-spear1340
 
   "#dma-cells":
-    const: 3
+    minimum: 3
+    maximum: 4
     description: |
       First cell is a phandle pointing to the DMA controller. Second one is
       the DMA request line number. Third cell is the memory master identifier
       for transfers on dynamically allocated channel. Fourth cell is the
-      peripheral master identifier for transfers on an allocated channel.
+      peripheral master identifier for transfers on an allocated channel. Fifth
+      cell is an optional mask of the DMA channels permitted to be allocated
+      for the corresponding client device.
 
   reg:
     maxItems: 1