[v2,2/7] dmaengine: dw: Remove misleading is_private property

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@linuxfoundation.org> (maintainer:SERIAL DRIVERS)
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >  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@linuxfoundation.org>