user/sven/linux.git/include/linux/platform_data/dma-dw.h, branch v4.19.162

dmaengine: dw-dmac: implement dma protection control setting

2019-12-13T07:51:43Z

[ Upstream commit 7b0c03ecc42fb223baf015877fee9d517c2c8af1 ] This patch adds a new device-tree property that allows to specify the dma protection control bits for the all of the DMA controller's channel uniformly. Setting the "correct" bits can have a huge impact on the PPC460EX and APM82181 that use this DMA engine in combination with a DesignWare' SATA-II core (sata_dwc_460ex driver). In the OpenWrt Forum, the user takimata reported that: |It seems your patch unleashed the full power of the SATA port. |Where I was previously hitting a really hard limit at around |82 MB/s for reading and 27 MB/s for writing, I am now getting this: | |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 13.65s |user 0m 0.01s |sys 0m 11.89s | |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024 |1024+0 records in |1024+0 records out |real 0m 8.41s |user 0m 0.01s |sys 0m 4.70s | |This means: 121 MB/s reading and 75 MB/s writing! | |The drive is a WD Green WD10EARX taken from an older MBL Single. |I repeated the test a few times with even larger files to rule out |any caching, I'm still seeing the same great performance. OpenWrt is |now completely on par with the original MBL firmware's performance. Another user And.short reported: |I can report that your fix worked! Boots up fine with two |drives even with more partitions, and no more reboot on |concurrent disk access! A closer look into the sata_dwc_460ex code revealed that the driver did initally set the correct protection control bits. However, this feature was lost when the sata_dwc_460ex driver was converted to the generic DMA driver framework. BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55 BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50 Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver") Reviewed-by: Andy Shevchenko Signed-off-by: Christian Lamparter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: dw: add support of iDMA 32-bit hardware

2017-01-25T06:21:40Z

iDMA 32-bit is Intel designed DMA controller that behaves like Synopsys Designware DMA. This patch adds a support of the new Intel hardware. Due to iDMA 32-bit has no autoconfiguration the platform code must provide a platform data to dw_dma_probe(). By default full FIFO (1024 bytes) is assigned to channel 0. Here we slice FIFO on equal parts between channels for iDMA 32-bit case. Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul

dmaengine: DW DMAC: add multi-block property to device tree

2016-11-30T03:27:50Z

Several versions of DW DMAC have multi block transfers hardware support. Hardware support of multi block transfers is disabled by default if we use DT to configure DMAC and software emulation of multi block transfers used instead. Add multi-block property, so it is possible to enable hardware multi block transfers (if present) via DT. Switch from per device is_nollp variable to multi_block array to be able enable/disable multi block transfers separately per channel. Acked-by: Andy Shevchenko Signed-off-by: Eugeniy Paltsev Signed-off-by: Vinod Koul

dmaengine: dw: override LLP support if asked in platform data

2016-08-31T14:13:29Z

There are at least two known devices, e.g. DMA controller found on ARC AXS101 SDP board, that have LLP register and no multi block transfer support at the same time. Override autodetection by user provided data. Reported-by: Eugeniy Paltsev Reviewed-by: Eugeniy Paltsev Signed-off-by: Andy Shevchenko Tested-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: set polarity of handshake interface

2016-08-31T14:13:29Z

Intel Quark UART uses DesignWare DMA IP. Though the DMA IP is connected in such way that handshake interface uses inverted polarity. We have to provide a possibility to set this in the DMA driver when configuring a channel. Introduce a new member of custom slave configuration called 'hs_polarity' and set active low polarity in case this value is 'true'. Acked-by: Vinod Koul Signed-off-by: Andy Shevchenko Tested-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: keep entire platform data in struct dw_dma

2016-05-02T10:01:05Z

Keep the entire platform data in the struct dw_dma. It makes the driver a bit cleaner. Acked-by: Viresh Kumar Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul

dmaengine: dw: revisit data_width property

2016-05-02T10:00:47Z

There several changes are done here: - Convert the property to be in bytes Besides that this is a common practice for such property, the use of a value in bytes much more convenient than handling the encoded one. - Rename data_width to data-width in the device tree bindings The change leaves the support for the old format as well just in case someone will use a newer kernel with an old device tree blob. - While here, replace dwc_fast_ffs() by __ffs() Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar Signed-off-by: Vinod Koul

dmaengine: dw: rename masters to reflect actual topology

2016-04-13T16:06:09Z

The source and destination masters are reflecting buses or their layers to where the different devices can be connected. The patch changes the master names to reflect which one is related to which independently on the transfer direction. The outcome of the change is that the memory data width is now always limited by a data width of the master which is dedicated to communicate to memory. The patch will not break anything since all current users have the same data width for all masters. Though it would be nice to revisit avr32 platforms to check what is the actual hardware topology in use there. It seems that it has one bus and two masters on it as stated by Table 8-2, that's why everything works independently on the master in use. The purpose of the sequential patch is to fix the driver for configuration of more than one bus. The change is done in the assumption that src_master and dst_master are reflecting a connection to the memory and peripheral correspondently on avr32 and otherwise on the rest. Acked-by: Hans-Christian Egtvedt Acked-by: Mark Brown Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul

dmaengine: dw: some Intel devices has no memcpy support

2015-10-31T02:02:43Z

Provide a flag to choose if the device does support memory-to-memory transfers. At least this is not true for iDMA32 controller that might be supported in the future. Besides that Intel BayTrail and Braswell users should not try this feature due to HW specific behaviour. Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar Signed-off-by: Vinod Koul

dmaengine: dw: define DW_DMA_MAX_NR_MASTERS

2015-02-05T06:39:44Z

Instead of using magic number in the code the patch provides DW_DMA_MAX_NR_MASTERS constant. While here, restrict the reading of data width array by amount of the actual number of AHB masters. Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul