linux-stable.git/drivers/dma/dw, branch v5.3

dmaengine: dw: Enable iDMA 32-bit on Intel Elkhart Lake

2019-06-25T04:33:33+00:00

Intel Elkhart Lake OSE (Offload Service Engine) provides few DMA controllers
to the host. Enable them in the driver.

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

dmaengine: dw: Distinguish ->remove() between DW and iDMA 32-bit

2019-06-25T04:27:41+00:00

In the same way as done for ->probe(), call ->remove() based on
the type of the hardware.

While it works now due to equivalency of the two removal functions,
it might be changed in the future.

Signed-off-by: Andy Shevchenko 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul

Merge branch 'topic/dw' into for-linus

2019-03-12T06:33:47+00:00

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: Don't pollute CTL_LO on iDMA 32-bit

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

Intel iDMA 32-bit doesn't have a concept of bus masters and thus
there is no need to setup any kind of masters in the CTL_LO register.

Moreover, the burst size for memory-to-memory transfer is not what is says,
we need to have a corrected list of possible sizes. Note, that
the size of 8 items, each of that up to 4 bytes, is chosen because of
maximum of 1/2 FIFO, which is 64 bytes on Intel Merrifield.

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

dmaengine: dw: Reset DRAIN bit when resume the channel

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

For Intel iDMA 32-bit the channel can be drained on a suspend.
We need to reset the bit on the resume to return a status quo.

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: Add missed multi-block support for iDMA 32-bit

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

Intel integrated DMA 32-bit support multi-block transfers.
Add missed setting to the platform data.

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