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

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

[Andy Shevchenko]

To optimize amount of bus writes on memory side set burst to be the same amount
of data on both sides.

Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 drivers/spi/spi-dw-mid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index e31971f9..0e0c34e 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -157,6 +157,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
 
 	txconf.direction = DMA_MEM_TO_DEV;
 	txconf.dst_addr = dws->dma_addr;
+	txconf.src_maxburst = 4 * dws->dma_width;
 	txconf.dst_maxburst = 16;
 	txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	txconf.dst_addr_width = convert_dma_width(dws->dma_width);
@@ -203,6 +204,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
 
 	rxconf.direction = DMA_DEV_TO_MEM;
 	rxconf.src_addr = dws->dma_addr;
+	rxconf.dst_maxburst = 4 * dws->dma_width;
 	rxconf.src_maxburst = 16;
 	rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	rxconf.src_addr_width = convert_dma_width(dws->dma_width);
-- 
2.8.0.rc3

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

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)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Andy Shevchenko]

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).

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.

Looks like all Intel related DMA drivers should be fixed (HSU, iDMA64,
dw_dmac).

Vinod, am I right?

-- 
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy

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

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

[Vinod Koul]

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

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

[Andy Shevchenko]

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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy

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

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

[Vinod Koul]

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