linux-kernel - Re: [PATCH v2 0/5] dmaengine: dw: Introduce non-mem peripherals optimizations

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 Aug 2020 11:58:47 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Viresh Kumar <vireshk@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Serge Semin <fancer.lancer@...il.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Rob Herring <robh+dt@...nel.org>, dmaengine@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] dmaengine: dw: Introduce non-mem peripherals
 optimizations

On 31-07-20, 23:08, Serge Semin wrote:
> After a lot of tests and thorough DW DMAC databook studying we've
> discovered that the driver can be optimized especially when it comes to
> working with non-memory peripherals.
> 
> First of all we've found out that since each DW DMAC channel can
> be synthesized with different parameters, then even when two of them
> are configured to perform the same DMA transactions they may execute them
> with different performance. Since some DMA client devices might be
> sensitive to such important parameter as performance, then it is a good
> idea to let them request only suitable DMA channels. In this patchset we
> introduce a functionality, which makes it possible by passing the DMA
> channels mask either over the "dmas" DT property or in the dw_dma_slave
> platform data descriptor.
> 
> Secondly FIFO-mode of the "FIFO readiness" criterion is more suitable for
> the pure memory DMA transfers, since it minimizes the system bus
> utilization, but causes some performance drop. When it comes to working with
> non-memory peripherals the DMA engine performance comes to the first
> place. Since normally DMA client devices keep data in internal FIFOs, any
> latency at some critical moment may cause a FIFO being overflown and
> consequently losing data. So in order to minimize a chance of the DW DMAC
> internal FIFO being a bottle neck during the DMA transfers to and from
> non-memory peripherals we propose not to use FIFO-mode for them.
> 
> Thirdly it has been discovered that using a DMA transaction length is
> redundant when calculating the destination transfer width for the
> dev-to-mem DMA communications. That shall increase performance of the DMA
> transfers with unaligned data length.
> 
> Finally there is a small optimization in the burst length setting. In
> particular we've found out, that according to the DW DMAC databoot it's
> pointless to set one for the memory peripherals since they don't have
> handshaking interface connected to the DMA controller. So we suggest to
> just ignore the burst length config when it comes to setting the memory
> peripherals up.

Applied all, thanks

-- 
~Vinod