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

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

[Andy Shevchenko]

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 -
 include/linux/platform_data/dma-dw.h               | 3 ---
 6 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index db757df7057d..0bedceed1963 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -23,8 +23,6 @@ Deprecated properties:
 
 
 Optional properties:
-- is_private: The device channels should be marked as private and not for by the
-  general purpose DMA channel allocator. False if not passed.
 - multi-block: Multi block transfers supported by hardware. Array property with
   one cell per channel. 0: not supported, 1 (default): supported.
 - snps,dma-protection-control: AHB HPROT[3:1] protection setting.
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index dc053e62f894..e25503986680 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1227,7 +1227,6 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 		pdata->block_size = dma_readl(dw, MAX_BLK_SIZE);
 
 		/* Fill platform data with the default values */
-		pdata->is_private = true;
 		pdata->is_memcpy = true;
 		pdata->chan_allocation_order = CHAN_ALLOCATION_ASCENDING;
 		pdata->chan_priority = CHAN_PRIORITY_ASCENDING;
@@ -1340,8 +1339,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 
 	/* Set capabilities */
 	dma_cap_set(DMA_SLAVE, dw->dma.cap_mask);
-	if (pdata->is_private)
-		dma_cap_set(DMA_PRIVATE, dw->dma.cap_mask);
+	dma_cap_set(DMA_PRIVATE, dw->dma.cap_mask);
 	if (pdata->is_memcpy)
 		dma_cap_set(DMA_MEMCPY, dw->dma.cap_mask);
 
diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c
index 313ba10c6224..570498faadc3 100644
--- a/drivers/dma/dw/pci.c
+++ b/drivers/dma/dw/pci.c
@@ -17,7 +17,6 @@
 
 static struct dw_dma_platform_data mrfld_pdata = {
 	.nr_channels = 8,
-	.is_private = true,
 	.is_memcpy = true,
 	.is_idma32 = true,
 	.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 31ff8113c3de..6dd8cd1820c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -128,9 +128,6 @@ dw_dma_parse_dt(struct platform_device *pdev)
 	pdata->nr_masters = nr_masters;
 	pdata->nr_channels = nr_channels;
 
-	if (of_property_read_bool(np, "is_private"))
-		pdata->is_private = true;
-
 	/*
 	 * All known devices, which use DT for configuration, support
 	 * memory-to-memory transfers. So enable it by default.
diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
index 2a71616890a4..1a6ee21cfcec 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -153,7 +153,6 @@ static int byt_serial_setup(struct lpss8250 *lpss, struct uart_port *port)
 #ifdef CONFIG_SERIAL_8250_DMA
 static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
 	.nr_channels = 2,
-	.is_private = true,
 	.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
 	.chan_priority = CHAN_PRIORITY_ASCENDING,
 	.block_size = 4095,
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 1a1d58ebffbf..d443025c5c72 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -38,8 +38,6 @@ struct dw_dma_slave {
 /**
  * struct dw_dma_platform_data - Controller configuration parameters
  * @nr_channels: Number of channels supported by hardware (max 8)
- * @is_private: The device channels should be marked as private and not for
- *	by the general purpose DMA channel allocator.
  * @is_memcpy: The device channels do support memory-to-memory transfers.
  * @is_idma32: The type of the DMA controller is iDMA32
  * @chan_allocation_order: Allocate channels starting from 0 or 7
@@ -53,7 +51,6 @@ struct dw_dma_slave {
  */
 struct dw_dma_platform_data {
 	unsigned int	nr_channels;
-	bool		is_private;
 	bool		is_memcpy;
 	bool		is_idma32;
 #define CHAN_ALLOCATION_ASCENDING	0	/* zero to seven */

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

[Vinod Koul]

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

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

[Greg Kroah-Hartman]

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>