On Mon, Aug 17, 2020 at 4:17 AM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> 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@xxxxxxxxxx> > > 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