| Message ID | 20200731200826.9292-1-Sergey.Semin@baikalelectronics.ru |
|---|---|
| Headers | show |
| Series | dmaengine: dw: Introduce non-mem peripherals optimizations | expand |
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
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. Link: https://lore.kernel.org/dmaengine/20200730154545.3965-1-Sergey.Semin@baikalelectronics.ru Changelog v2: - Add Databook version to the commits log. - Use the statement "slave.channels >= BIT(dw->pdata->nr_channels)" to make sure the permitted DMA-channels pool is valid. - Describe new DW DMAC "channels" mask in a single line even though it gets out of 80 columns limit. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: dmaengine@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (5): dt-bindings: dma: dw: Add optional DMA-channels mask cell support dmaengine: dw: Activate FIFO-mode for memory peripherals only dmaengine: dw: Discard dlen from the dev-to-mem xfer width calculation dmaengine: dw: Ignore burst setting for memory peripherals dmaengine: dw: Add DMA-channels mask cell support .../devicetree/bindings/dma/snps,dma-spear1340.yaml | 7 +++++-- drivers/dma/dw/core.c | 6 +++++- drivers/dma/dw/dw.c | 7 +++---- drivers/dma/dw/idma32.c | 5 ++--- drivers/dma/dw/of.c | 7 +++++-- include/linux/platform_data/dma-dw.h | 2 ++ 6 files changed, 22 insertions(+), 12 deletions(-)