| Message ID | 1444756159-125867-4-git-send-email-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
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
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).
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...
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 --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;
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(-)