linux-toradex.git/include/linux/platform_data/dma-dw.h, branch v5.1-rc1

dmaengine: dw: convert to SPDX identifiers

2019-01-07T12:27:13+00:00

This patch updates license to use SPDX-License-Identifier
instead of verbose license text.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: Split DW and iDMA 32-bit operations

2019-01-07T12:27:13+00:00

Here is a kinda big refactoring that should have been done
in the first place, when Intel iDMA 32-bit support appeared.

It splits operations which are different to Synopsys DesignWare and
Intel iDMA 32-bit controllers.

No functional change intended.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: Remove unused internal property

2019-01-07T12:27:13+00:00

All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default.

The rest two cases, i.e. Intel Quark and PPC460ex, instantiate DMA driver and
use its channels exclusively for hardware, which means there is no available
channel for any other purposes anyway.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul

dmaengine: dw: Remove misleading is_private property

2019-01-07T12:27:13+00:00

The commit a9ddb575d6d6

   ("dmaengine: dw_dmac: Enhance device tree support")

introduces is_private property in uncertain understanding what does it mean.

First of all, documentation defines DMA_PRIVATE capability as

Documentation/crypto/async-tx-api.txt:
  The DMA_PRIVATE capability flag is used to tag dma devices that should not be
  used by the general-purpose allocator. It can be set at initialization time
  if it is known that a channel will always be private. Alternatively,
  it is set when dma_request_channel() finds an unused "public" channel.

  A couple caveats to note when implementing a driver and consumer:
  1/ Once a channel has been privately allocated it will no longer be
     considered by the general-purpose allocator even after a call to
     dma_release_channel().
  2/ Since capabilities are specified at the device level a dma_device with
     multiple channels will either have all channels public, or all channels
     private.

Documentation/driver-api/dmaengine/provider.rst:
  - DMA_PRIVATE
    The devices only supports slave transfers, and as such isn't available
    for async transfers.

The capability had been introduced by the commit 59b5ec21446b

  ("dmaengine: introduce dma_request_channel and private channels")

and some code didn't changed from that times ever.

Taking into consideration above and the fact that on all known platforms
Synopsys DesignWare DMA engine is attached to serve slave transfers,
the DMA_PRIVATE capability must be enabled for this device unconditionally.
Otherwise, as rightfully noticed in drivers/dma/at_xdmac.c:
  /*
   * Without DMA_PRIVATE the driver is not able to allocate more than
   * one channel, second allocation fails in private_candidate.
   */
because of of a caveats mentioned in above documentation excerpts.

So, remove conditional around DMA_PRIVATE followed by removal leftovers.

If someone wonders, DMA_PRIVATE can be not used if and only if the all channels
of the DMA controller are supposed to serve memory-to-memory like operations.
For example, EP93xx has two controllers, one of which can only perform
memory-to-memory transfers

Note, this change doesn't affect dmatest to be able to test such controllers.

Cc: Greg Kroah-Hartman  (maintainer:SERIAL DRIVERS)
Cc: Dan Williams 
Signed-off-by: Andy Shevchenko 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Vinod Koul

dmaengine: dw-dmac: implement dma protection control setting

2018-11-24T14:37:22+00:00

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

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

2017-01-25T06:21:40+00:00

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:50+00:00

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:29+00:00

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:29+00:00

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:05+00:00

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