Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Mon, 2012-10-01 at 15:15 +0530, Vinod Koul wrote: > On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote: > > On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: > > > On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: > > > > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > > > > > Not all of the controllers support the 64 bit data width. Make it > > > > > configurable > > > > > via platform data. The driver will try to get a value from the > > > > > component > > > > > parameters, otherwise it will use the platform data. > > > > > > > > > What was this gen against, I can apply this. > > > %s/can/can't > > Today I got what was happened. I sent an update to one patch of the > > series, but you tried to apply it on top of previous version. It seems I > > was not clear. So, now we have a regression, and I will send a fix soon > > today. > I received a series, and a patch on top and that what I tried to > apply :( > I am okay to revert the whole series now. > > Please send me fix by today, merge window has started, I hate to change > stuff now. I've sent a patch. You could apply on top of the series, or squash it with the one called "dw_dmac: autoconfigure data_width or get it via platform data" -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote: > On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: > > On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: > > > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > > > > Not all of the controllers support the 64 bit data width. Make it > > > > configurable > > > > via platform data. The driver will try to get a value from the component > > > > parameters, otherwise it will use the platform data. > > > > > > > What was this gen against, I can apply this. > > %s/can/can't > Today I got what was happened. I sent an update to one patch of the > series, but you tried to apply it on top of previous version. It seems I > was not clear. So, now we have a regression, and I will send a fix soon > today. I received a series, and a patch on top and that what I tried to apply :( I am okay to revert the whole series now. Please send me fix by today, merge window has started, I hate to change stuff now. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: > On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: > > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > > > Not all of the controllers support the 64 bit data width. Make it > > > configurable > > > via platform data. The driver will try to get a value from the component > > > parameters, otherwise it will use the platform data. > > > > > What was this gen against, I can apply this. > %s/can/can't Today I got what was happened. I sent an update to one patch of the series, but you tried to apply it on top of previous version. It seems I was not clear. So, now we have a regression, and I will send a fix soon today. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. %s/can/can't Today I got what was happened. I sent an update to one patch of the series, but you tried to apply it on top of previous version. It seems I was not clear. So, now we have a regression, and I will send a fix soon today. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote: On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. %s/can/can't Today I got what was happened. I sent an update to one patch of the series, but you tried to apply it on top of previous version. It seems I was not clear. So, now we have a regression, and I will send a fix soon today. I received a series, and a patch on top and that what I tried to apply :( I am okay to revert the whole series now. Please send me fix by today, merge window has started, I hate to change stuff now. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Mon, 2012-10-01 at 15:15 +0530, Vinod Koul wrote: On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote: On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. %s/can/can't Today I got what was happened. I sent an update to one patch of the series, but you tried to apply it on top of previous version. It seems I was not clear. So, now we have a regression, and I will send a fix soon today. I received a series, and a patch on top and that what I tried to apply :( I am okay to revert the whole series now. Please send me fix by today, merge window has started, I hate to change stuff now. I've sent a patch. You could apply on top of the series, or squash it with the one called dw_dmac: autoconfigure data_width or get it via platform data -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 17:00 +0300, Andy Shevchenko wrote: > On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul > wrote: > > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > >> Not all of the controllers support the 64 bit data width. Make it > >> configurable > >> via platform data. The driver will try to get a value from the component > >> parameters, otherwise it will use the platform data. > >> > > What was this gen against, I can apply this. > Just rebased to recent linux-next, no conflicts. And I dont apply patches against linux-next!! I apply against slave-dma-next. > ... > Applying: dw_dmac: mark dwc_dump_chan_regs as inline > Applying: dw_dmac: fill optional encoded parameters in register structure > Applying: dw_dmac: get number of channels from hardware if possible > Applying: dw_dmac: autoconfigure block_size or use platform data > Applying: dw_dmac: autoconfigure data_width or get it via platform data > Applying: dw_dmac: introduce software emulation of LLP transfers > ... > > Have you kept the order of the patches? Obviously see my next The reason for conflict is nature of this patch. It should be split up. arch/arm/mach-spear13xx/spear13xx.c |2 ++ arch/avr32/mach-at32ap/at32ap700x.c |2 ++ It fails here, send these separately to Arnd. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul wrote: > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: >> Not all of the controllers support the 64 bit data width. Make it >> configurable >> via platform data. The driver will try to get a value from the component >> parameters, otherwise it will use the platform data. >> > What was this gen against, I can apply this. Just rebased to recent linux-next, no conflicts. ... Applying: dw_dmac: mark dwc_dump_chan_regs as inline Applying: dw_dmac: fill optional encoded parameters in register structure Applying: dw_dmac: get number of channels from hardware if possible Applying: dw_dmac: autoconfigure block_size or use platform data Applying: dw_dmac: autoconfigure data_width or get it via platform data Applying: dw_dmac: introduce software emulation of LLP transfers ... Have you kept the order of the patches? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: > On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: > > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > > > Not all of the controllers support the 64 bit data width. Make it > > > configurable > > > via platform data. The driver will try to get a value from the component > > > parameters, otherwise it will use the platform data. > > > > > What was this gen against, I can apply this. > > > > %s/can/can't Against linux-next, last used was yesterday's version of it. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > > Not all of the controllers support the 64 bit data width. Make it > > configurable > > via platform data. The driver will try to get a value from the component > > parameters, otherwise it will use the platform data. > > > What was this gen against, I can apply this. > %s/can/can't -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: > Not all of the controllers support the 64 bit data width. Make it configurable > via platform data. The driver will try to get a value from the component > parameters, otherwise it will use the platform data. > What was this gen against, I can apply this. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. %s/can/can't -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. %s/can/can't Against linux-next, last used was yesterday's version of it. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul vinod.k...@linux.intel.com wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. Just rebased to recent linux-next, no conflicts. ... Applying: dw_dmac: mark dwc_dump_chan_regs as inline Applying: dw_dmac: fill optional encoded parameters in register structure Applying: dw_dmac: get number of channels from hardware if possible Applying: dw_dmac: autoconfigure block_size or use platform data Applying: dw_dmac: autoconfigure data_width or get it via platform data Applying: dw_dmac: introduce software emulation of LLP transfers ... Have you kept the order of the patches? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Thu, 2012-09-27 at 17:00 +0300, Andy Shevchenko wrote: On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul vinod.k...@linux.intel.com wrote: On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. What was this gen against, I can apply this. Just rebased to recent linux-next, no conflicts. And I dont apply patches against linux-next!! I apply against slave-dma-next. ... Applying: dw_dmac: mark dwc_dump_chan_regs as inline Applying: dw_dmac: fill optional encoded parameters in register structure Applying: dw_dmac: get number of channels from hardware if possible Applying: dw_dmac: autoconfigure block_size or use platform data Applying: dw_dmac: autoconfigure data_width or get it via platform data Applying: dw_dmac: introduce software emulation of LLP transfers ... Have you kept the order of the patches? Obviously see my next The reason for conflict is nature of this patch. It should be split up. arch/arm/mach-spear13xx/spear13xx.c |2 ++ arch/avr32/mach-at32ap/at32ap700x.c |2 ++ It fails here, send these separately to Arnd. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Tue, Sep 25, 2012 at 5:09 PM, Andy Shevchenko wrote: > Not all of the controllers support the 64 bit data width. Make it configurable > via platform data. The driver will try to get a value from the component > parameters, otherwise it will use the platform data. > > Signed-off-by: Andy Shevchenko > --- > Since v2: > - sometimes memory-to-memory test is failed, that's why we need to choose > minimum data portion between source and destination limits Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
Not all of the controllers support the 64 bit data width. Make it configurable
via platform data. The driver will try to get a value from the component
parameters, otherwise it will use the platform data.
Signed-off-by: Andy Shevchenko
---
Since v2:
- sometimes memory-to-memory test is failed, that's why we need to choose
minimum data portion between source and destination limits
arch/arm/mach-spear13xx/spear13xx.c |2 ++
arch/avr32/mach-at32ap/at32ap700x.c |2 ++
drivers/dma/dw_dmac.c | 47 ++-
drivers/dma/dw_dmac_regs.h |7 ++
include/linux/dw_dmac.h |5
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-spear13xx/spear13xx.c
b/arch/arm/mach-spear13xx/spear13xx.c
index 9491137..5633d69 100644
--- a/arch/arm/mach-spear13xx/spear13xx.c
+++ b/arch/arm/mach-spear13xx/spear13xx.c
@@ -79,6 +79,8 @@ struct dw_dma_platform_data dmac_plat_data = {
.chan_allocation_order = CHAN_ALLOCATION_DESCENDING,
.chan_priority = CHAN_PRIORITY_DESCENDING,
.block_size = 4095U,
+ .nr_masters = 2,
+ .data_width = { 3, 3, 0, 0 },
};
void __init spear13xx_l2x0_init(void)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 2c4aefe..b323d8d 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -606,6 +606,8 @@ static void __init genclk_init_parent(struct clk *clk)
static struct dw_dma_platform_data dw_dmac0_data = {
.nr_channels= 3,
.block_size = 4095U,
+ .nr_masters = 2,
+ .data_width = { 2, 2, 0, 0 },
};
static struct resource dw_dmac0_resource[] = {
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 4af9fad..33c46f0 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -38,12 +38,22 @@
* which does not support descriptor writeback.
*/
+static inline unsigned int dwc_get_dms(struct dw_dma_slave *slave)
+{
+ return slave ? slave->dst_master : 0;
+}
+
+static inline unsigned int dwc_get_sms(struct dw_dma_slave *slave)
+{
+ return slave ? slave->src_master : 1;
+}
+
#define DWC_DEFAULT_CTLLO(_chan) ({\
struct dw_dma_slave *__slave = (_chan->private);\
struct dw_dma_chan *_dwc = to_dw_dma_chan(_chan); \
struct dma_slave_config *_sconfig = &_dwc->dma_sconfig; \
- int _dms = __slave ? __slave->dst_master : 0; \
- int _sms = __slave ? __slave->src_master : 1; \
+ int _dms = dwc_get_dms(__slave);\
+ int _sms = dwc_get_sms(__slave);\
u8 _smsize = __slave ? _sconfig->src_maxburst : \
DW_DMA_MSIZE_16;\
u8 _dmsize = __slave ? _sconfig->dst_maxburst : \
@@ -633,6 +643,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
size_t len, unsigned long flags)
{
struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
+ struct dw_dma_slave *dws = chan->private;
struct dw_desc *desc;
struct dw_desc *first;
struct dw_desc *prev;
@@ -640,6 +651,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
size_t offset;
unsigned intsrc_width;
unsigned intdst_width;
+ unsigned intdata_width;
u32 ctllo;
dev_vdbg(chan2dev(chan),
@@ -652,7 +664,11 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
dest, dma_addr_t src,
return NULL;
}
- src_width = dst_width = dwc_fast_fls(src | dest | len);
+ data_width = min_t(unsigned int, dwc->dw->data_width[dwc_get_sms(dws)],
+dwc->dw->data_width[dwc_get_dms(dws)]);
+
+ src_width = dst_width = min_t(unsigned int, data_width,
+ dwc_fast_fls(src | dest | len));
ctllo = DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_DST_WIDTH(dst_width)
@@ -722,6 +738,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
dma_addr_t reg;
unsigned intreg_width;
unsigned intmem_width;
+ unsigned intdata_width;
unsigned inti;
struct scatterlist *sg;
size_t total_len = 0;
@@ -745,6 +762,8 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
ctllo |= sconfig->device_fc ? DWC_CTLL_FC(DW_DMA_FC_P_M2P) :
DWC_CTLL_FC(DW_DMA_FC_D_M2P);
+ data_width = dwc->dw->data_width[dwc_get_sms(dws)];
+
for_each_sg(sgl, sg, sg_len, i) {
[PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
Not all of the controllers support the 64 bit data width. Make it configurable
via platform data. The driver will try to get a value from the component
parameters, otherwise it will use the platform data.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
Since v2:
- sometimes memory-to-memory test is failed, that's why we need to choose
minimum data portion between source and destination limits
arch/arm/mach-spear13xx/spear13xx.c |2 ++
arch/avr32/mach-at32ap/at32ap700x.c |2 ++
drivers/dma/dw_dmac.c | 47 ++-
drivers/dma/dw_dmac_regs.h |7 ++
include/linux/dw_dmac.h |5
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-spear13xx/spear13xx.c
b/arch/arm/mach-spear13xx/spear13xx.c
index 9491137..5633d69 100644
--- a/arch/arm/mach-spear13xx/spear13xx.c
+++ b/arch/arm/mach-spear13xx/spear13xx.c
@@ -79,6 +79,8 @@ struct dw_dma_platform_data dmac_plat_data = {
.chan_allocation_order = CHAN_ALLOCATION_DESCENDING,
.chan_priority = CHAN_PRIORITY_DESCENDING,
.block_size = 4095U,
+ .nr_masters = 2,
+ .data_width = { 3, 3, 0, 0 },
};
void __init spear13xx_l2x0_init(void)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 2c4aefe..b323d8d 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -606,6 +606,8 @@ static void __init genclk_init_parent(struct clk *clk)
static struct dw_dma_platform_data dw_dmac0_data = {
.nr_channels= 3,
.block_size = 4095U,
+ .nr_masters = 2,
+ .data_width = { 2, 2, 0, 0 },
};
static struct resource dw_dmac0_resource[] = {
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 4af9fad..33c46f0 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -38,12 +38,22 @@
* which does not support descriptor writeback.
*/
+static inline unsigned int dwc_get_dms(struct dw_dma_slave *slave)
+{
+ return slave ? slave-dst_master : 0;
+}
+
+static inline unsigned int dwc_get_sms(struct dw_dma_slave *slave)
+{
+ return slave ? slave-src_master : 1;
+}
+
#define DWC_DEFAULT_CTLLO(_chan) ({\
struct dw_dma_slave *__slave = (_chan-private);\
struct dw_dma_chan *_dwc = to_dw_dma_chan(_chan); \
struct dma_slave_config *_sconfig = _dwc-dma_sconfig; \
- int _dms = __slave ? __slave-dst_master : 0; \
- int _sms = __slave ? __slave-src_master : 1; \
+ int _dms = dwc_get_dms(__slave);\
+ int _sms = dwc_get_sms(__slave);\
u8 _smsize = __slave ? _sconfig-src_maxburst : \
DW_DMA_MSIZE_16;\
u8 _dmsize = __slave ? _sconfig-dst_maxburst : \
@@ -633,6 +643,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
size_t len, unsigned long flags)
{
struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
+ struct dw_dma_slave *dws = chan-private;
struct dw_desc *desc;
struct dw_desc *first;
struct dw_desc *prev;
@@ -640,6 +651,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
size_t offset;
unsigned intsrc_width;
unsigned intdst_width;
+ unsigned intdata_width;
u32 ctllo;
dev_vdbg(chan2dev(chan),
@@ -652,7 +664,11 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
dest, dma_addr_t src,
return NULL;
}
- src_width = dst_width = dwc_fast_fls(src | dest | len);
+ data_width = min_t(unsigned int, dwc-dw-data_width[dwc_get_sms(dws)],
+dwc-dw-data_width[dwc_get_dms(dws)]);
+
+ src_width = dst_width = min_t(unsigned int, data_width,
+ dwc_fast_fls(src | dest | len));
ctllo = DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_DST_WIDTH(dst_width)
@@ -722,6 +738,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
dma_addr_t reg;
unsigned intreg_width;
unsigned intmem_width;
+ unsigned intdata_width;
unsigned inti;
struct scatterlist *sg;
size_t total_len = 0;
@@ -745,6 +762,8 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
ctllo |= sconfig-device_fc ? DWC_CTLL_FC(DW_DMA_FC_P_M2P) :
DWC_CTLL_FC(DW_DMA_FC_D_M2P);
+ data_width = dwc-dw-data_width[dwc_get_sms(dws)];
+
for_each_sg(sgl,
Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data
On Tue, Sep 25, 2012 at 5:09 PM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Not all of the controllers support the 64 bit data width. Make it configurable via platform data. The driver will try to get a value from the component parameters, otherwise it will use the platform data. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- Since v2: - sometimes memory-to-memory test is failed, that's why we need to choose minimum data portion between source and destination limits Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
