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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqKGqRs7DGiBcy-Ta_WkajGv-xg8GYMiDe13nQiyLj2VfA@mail.gmail.com>
Date:   Wed, 19 Aug 2020 08:02:37 -0600
From:   Rob Herring <robh@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Serge Semin <fancer.lancer@...il.com>,
        Viresh Kumar <vireshk@...nel.org>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 
        <dmaengine@...r.kernel.org>, devicetree@...r.kernel.org,
        Vinod Koul <vkoul@...nel.org>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>
Subject: Re: [PATCH v2 1/5] dt-bindings: dma: dw: Add optional DMA-channels
 mask cell support

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