On Tue, Apr 12, 2016 at 02:56:35PM +0300, Andy Shevchenko wrote: > On Tue, 2016-04-12 at 01:34 +0100, Mark Brown wrote: > > On Mon, Apr 11, 2016 at 07:30:12PM +0300, Andy Shevchenko wrote: > > > > +Vinod and dmaengine@ > > > > > > > To optimize amount of bus writes on memory side set burst to be the > > > same amount > > > of data on both sides. > > > > > > + txconf.src_maxburst = 4 * dws->dma_width; > > > txconf.dst_maxburst = 16; > > This doesn't seem to do what the subject says (at least not always, > > it'll align for a dma_width of 4)? > > Thanks you didn't apply the patch. > > I think the approach itself is wrong. > > The peripheral drivers usually have no idea and shouldn't know about DMA > engine memory side characteristics (bus width, bursts, etc). These are typically you system characterstics, like 32 bit or 64 bit bus to memory and rest (burst etc) should be maximum as the data will go from/to dmaengine FIFO to/from memory, so you would want to push as fast as possible Said that, maximun burst with 32bit wide should be saner value in modern systems. > > This should be fixed in certain DMA engine drivers. > > Also, as you may have noticed when we get maximum length of the segment > we take into consideration what DMA device supports. Many of them report > something like 2^n - 1, which is apparently unaligned and thus in the > poorly written DMA driver leads to performance degradation. Which Intel controller supports 2^n - 1? AFAIK the dw and idma don't. > Looks like all Intel related DMA drivers should be fixed (HSU, iDMA64, > dw_dmac). > > Vinod, am I right? > > -- > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > Intel Finland Oy > -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
