On Tue, 2016-04-12 at 19:32 +0530, Vinod Koul wrote: > 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: > > > 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. My point that peripheral driver does not and _should not_ care about memory side of the transfer. This is property of DMAengine controller and platform that has it installed. Documentation tells nothing how clients should setup _memory side_ of the transfer. Thus, I propose to update documentation to tell that there are two sides of the transfer in case of mem2dev, dev2mem, where one of them is _memory side_, and it's DMAengine controller's responsibility to rightfully set the transfer width and burst size. I would make a patch if we would agree on this. > > > > > > > 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. All three mentioned below takes block size as [0 .. 2 ^ number of bits in the register - 1]. If transfer width is 1 byte (which is calculated automatically now, the burst will be 1 byte on memory side! >> Looks like all Intel related DMA drivers should be fixed (HSU, > > iDMA64, > > dw_dmac). -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- 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
