On Wed, Dec 05, 2018 at 10:08:50PM +0530, Vinod Koul wrote:
> 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
Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
