Re: [PATCH v1 1/1] spi: dw-mid: set DMA burst on memory side

[Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On Tue, Apr 12, 2016 at 07:06:01PM +0300, Andy Shevchenko wrote:
> 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.

Well a dmaengine maybe operating in a 32bit or 64 bit bus. Doing 64bit will
not help in former case. How do we guess?

I do agree that clients shouldn't be bothered with this

> 
> 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!

That is not correct :)

> 
> >> Looks like all Intel related DMA drivers should be fixed (HSU,
> > > iDMA64,
> > > dw_dmac).
> 
> 
> -- 
> Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Intel Finland Oy
> 

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html