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

[Rob Herring <robh@kernel.org>]

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