diff mbox

[v4,3/3] dmaengine: dw: some Intel devices has no memcpy support

Message ID 1444756159-125867-4-git-send-email-andriy.shevchenko@linux.intel.com (mailing list archive)
State Accepted
Headers show

Commit Message

Andy Shevchenko Oct. 13, 2015, 5:09 p.m. UTC
Provide a flag to choose if the device does support memory-to-memory transfers.
At least this is not true for iDMA32 controller that might be supported in the
future. Besides that Intel BayTrail and Braswell users should not try this
feature due to HW specific behaviour.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/dma/dw/core.c                | 6 +++++-
 include/linux/platform_data/dma-dw.h | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

Comments

Vinod Koul Oct. 27, 2015, 1:01 a.m. UTC | #1
On Tue, Oct 13, 2015 at 08:09:19PM +0300, Andy Shevchenko wrote:
> Provide a flag to choose if the device does support memory-to-memory transfers.
> At least this is not true for iDMA32 controller that might be supported in the
> future. Besides that Intel BayTrail and Braswell users should not try this
> feature due to HW specific behaviour.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/dma/dw/core.c                | 6 +++++-
>  include/linux/platform_data/dma-dw.h | 2 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index 41b7592..7067b6d 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1541,6 +1541,7 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
>  
>  		/* Fill platform data with the default values */
>  		pdata->is_private = true;
> +		pdata->is_memcpy = true;

But you are setting this always, so what is the point of this patch
Andy Shevchenko Oct. 27, 2015, 8:26 a.m. UTC | #2
On Tue, 2015-10-27 at 10:01 +0900, Vinod Koul wrote:
> On Tue, Oct 13, 2015 at 08:09:19PM +0300, Andy Shevchenko wrote:
> > Provide a flag to choose if the device does support memory-to-
> > memory transfers.
> > At least this is not true for iDMA32 controller that might be
> > supported in the
> > future. Besides that Intel BayTrail and Braswell users should not
> > try this
> > feature due to HW specific behaviour.
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >  drivers/dma/dw/core.c                | 6 +++++-
> >  include/linux/platform_data/dma-dw.h | 2 ++
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> > index 41b7592..7067b6d 100644
> > --- a/drivers/dma/dw/core.c
> > +++ b/drivers/dma/dw/core.c
> > @@ -1541,6 +1541,7 @@ int dw_dma_probe(struct dw_dma_chip *chip,
> > struct dw_dma_platform_data *pdata)
> >  
> >  		/* Fill platform data with the default values */
> >  		pdata->is_private = true;
> > +		pdata->is_memcpy = true;
> 
> But you are setting this always, so what is the point of this patch

Yes, this setting works for all cases where we are using auto
configuration. Otherwise it will come from platform data (see the
patches 1 and 2).
Vinod Koul Oct. 28, 2015, 6:31 a.m. UTC | #3
On Tue, Oct 27, 2015 at 10:26:11AM +0200, Andy Shevchenko wrote:
> On Tue, 2015-10-27 at 10:01 +0900, Vinod Koul wrote:
> > On Tue, Oct 13, 2015 at 08:09:19PM +0300, Andy Shevchenko wrote:
> > > Provide a flag to choose if the device does support memory-to-
> > > memory transfers.
> > > At least this is not true for iDMA32 controller that might be
> > > supported in the
> > > future. Besides that Intel BayTrail and Braswell users should not
> > > try this
> > > feature due to HW specific behaviour.
> > > 
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > >  drivers/dma/dw/core.c                | 6 +++++-
> > >  include/linux/platform_data/dma-dw.h | 2 ++
> > >  2 files changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> > > index 41b7592..7067b6d 100644
> > > --- a/drivers/dma/dw/core.c
> > > +++ b/drivers/dma/dw/core.c
> > > @@ -1541,6 +1541,7 @@ int dw_dma_probe(struct dw_dma_chip *chip,
> > > struct dw_dma_platform_data *pdata)
> > >  
> > >  		/* Fill platform data with the default values */
> > >  		pdata->is_private = true;
> > > +		pdata->is_memcpy = true;
> > 
> > But you are setting this always, so what is the point of this patch
> 
> Yes, this setting works for all cases where we are using auto
> configuration. Otherwise it will come from platform data (see the
> patches 1 and 2).

So do you expect BYT and BSW to use pdata and not autcfg? I thought they
should use autcfg and based on your above comment expected it to be set to
false...
Andy Shevchenko Oct. 28, 2015, 10:08 a.m. UTC | #4
On Wed, 2015-10-28 at 15:31 +0900, Vinod Koul wrote:
> On Tue, Oct 27, 2015 at 10:26:11AM +0200, Andy Shevchenko wrote:
> > On Tue, 2015-10-27 at 10:01 +0900, Vinod Koul wrote:
> > > On Tue, Oct 13, 2015 at 08:09:19PM +0300, Andy Shevchenko wrote:
> > > > Provide a flag to choose if the device does support memory-to-
> > > > memory transfers.
> > > > At least this is not true for iDMA32 controller that might be
> > > > supported in the
> > > > future. Besides that Intel BayTrail and Braswell users should
> > > > not
> > > > try this
> > > > feature due to HW specific behaviour.
> > > > 
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.c
> > > > om>
> > > > ---
> > > >  drivers/dma/dw/core.c                | 6 +++++-
> > > >  include/linux/platform_data/dma-dw.h | 2 ++
> > > >  2 files changed, 7 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> > > > index 41b7592..7067b6d 100644
> > > > --- a/drivers/dma/dw/core.c
> > > > +++ b/drivers/dma/dw/core.c
> > > > @@ -1541,6 +1541,7 @@ int dw_dma_probe(struct dw_dma_chip
> > > > *chip,
> > > > struct dw_dma_platform_data *pdata)
> > > >  
> > > >  		/* Fill platform data with the default values
> > > > */
> > > >  		pdata->is_private = true;
> > > > +		pdata->is_memcpy = true;
> > > 
> > > But you are setting this always, so what is the point of this
> > > patch
> > 
> > Yes, this setting works for all cases where we are using auto
> > configuration. Otherwise it will come from platform data (see the
> > patches 1 and 2).
> 
> So do you expect BYT and BSW to use pdata and not autcfg? I thought
> they
> should use autcfg and based on your above comment expected it to be
> set to
> false...

There are two cases: ACPI) feature should be not used; PCI) it's okay
to use it.

Platform data is added only for ACPI BYT/BSW cases (There are also HSW
and BDW, where feature didn't advertised anyway, though it works in
both cases).
diff mbox

Patch

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 41b7592..7067b6d 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1541,6 +1541,7 @@  int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
 
 		/* 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;
 	} else if (pdata->nr_channels > DW_DMA_MAX_NR_CHANNELS) {
@@ -1653,10 +1654,13 @@  int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
 	dma_writel(dw, CLEAR.DST_TRAN, dw->all_chan_mask);
 	dma_writel(dw, CLEAR.ERROR, dw->all_chan_mask);
 
-	dma_cap_set(DMA_MEMCPY, dw->dma.cap_mask);
+	/* Set capabilities */
 	dma_cap_set(DMA_SLAVE, dw->dma.cap_mask);
 	if (pdata->is_private)
 		dma_cap_set(DMA_PRIVATE, dw->dma.cap_mask);
+	if (pdata->is_memcpy)
+		dma_cap_set(DMA_MEMCPY, dw->dma.cap_mask);
+
 	dw->dma.dev = chip->dev;
 	dw->dma.device_alloc_chan_resources = dwc_alloc_chan_resources;
 	dw->dma.device_free_chan_resources = dwc_free_chan_resources;
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 87ac14c..03b6095 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -37,6 +37,7 @@  struct dw_dma_slave {
  * @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.
  * @chan_allocation_order: Allocate channels starting from 0 or 7
  * @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
  * @block_size: Maximum block size supported by the controller
@@ -47,6 +48,7 @@  struct dw_dma_slave {
 struct dw_dma_platform_data {
 	unsigned int	nr_channels;
 	bool		is_private;
+	bool		is_memcpy;
 #define CHAN_ALLOCATION_ASCENDING	0	/* zero to seven */
 #define CHAN_ALLOCATION_DESCENDING	1	/* seven to zero */
 	unsigned char	chan_allocation_order;