On 05-12-18, 18:28, Andy Shevchenko wrote:
> 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 <gregkh@xxxxxxxxxxxxxxxxxxx> (maintainer:SERIAL DRIVERS)
> Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> ---
> Documentation/devicetree/bindings/dma/snps-dma.txt | 2 --
> drivers/dma/dw/core.c | 4 +---
> drivers/dma/dw/pci.c | 1 -
> drivers/dma/dw/platform.c | 3 ---
> drivers/tty/serial/8250/8250_lpss.c | 1 -
Need ack from greg before applying this
--
~Vinod
