From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users
Date: Tue, 8 Mar 2016 09:46:25 +0100 [thread overview]
Message-ID: <20160308094625.539646f8@bbrezillon> (raw)
In-Reply-To: <20160308075131.GE8418@lukather>
On Tue, 8 Mar 2016 08:51:31 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Tue, Mar 08, 2016 at 08:25:47AM +0530, Vinod Koul wrote:
> > On Mon, Mar 07, 2016 at 09:30:24PM +0100, Maxime Ripard wrote:
> > > On Mon, Mar 07, 2016 at 04:08:57PM +0100, Boris Brezillon wrote:
> > > > Hi Vinod,
> > > >
> > > > On Mon, 7 Mar 2016 20:24:29 +0530
> > > > Vinod Koul <vinod.koul@intel.com> wrote:
> > > >
> > > > > On Mon, Mar 07, 2016 at 10:59:31AM +0100, Boris Brezillon wrote:
> > > > > > +/* Dedicated DMA parameter register layout */
> > > > > > +#define SUN4I_DDMA_PARA_DST_DATA_BLK_SIZE(n) (((n) - 1) << 24)
> > > > > > +#define SUN4I_DDMA_PARA_DST_WAIT_CYCLES(n) (((n) - 1) << 16)
> > > > > > +#define SUN4I_DDMA_PARA_SRC_DATA_BLK_SIZE(n) (((n) - 1) << 8)
> > > > > > +#define SUN4I_DDMA_PARA_SRC_WAIT_CYCLES(n) (((n) - 1) << 0)
> > > > > > +
> > > > > > +/**
> > > > > > + * struct sun4i_dma_chan_config - DMA channel config
> > > > > > + *
> > > > > > + * @para: contains information about block size and time before checking
> > > > > > + * DRQ line. This is device specific and only applicable to dedicated
> > > > > > + * DMA channels
> > > > >
> > > > > What information, can you elobrate.. And why can't you use existing
> > > > > dma_slave_config for this?
> > > >
> > > > Block size is related to the device FIFO size. I guess it allows the
> > > > DMA channel to launch a transfer of X bytes without having to check the
> > > > DRQ line (the line telling the DMA engine it can transfer more data
> > > > to/from the device). The wait cycles information is apparently related
> > > > to the number of clks the engine should wait before polling/checking
> > > > the DRQ line status between each block transfer. I'm not sure what it
> > > > saves to put WAIT_CYCLES() to something != 1, but in their BSP,
> > > > Allwinner tweak that depending on the device.
> >
> > we already have block size aka src/dst_maxburst, why not use that one.
>
> I'm not sure it's really the same thing. The DMA controller also has a
> burst parameter, that is either 1 byte or 8 bytes, and ends up being
> different from this one.
Well, that's what I understood to, but when reading more carefully the
src/dst_maxburst description, it seems to match the block_size concept
exposed by the sun4i dmaengine. But how should we choose the real burst
size then.
IIRC, in most documentation/datasheets, burst size is referred as the
maximum number of words (word size depends on the selected width) a
master is allowed to transfer to a slave through the bus without
being interrupted by other master requests.
Am I correct?
>
> > Why does dmaengine need to wait? Can you explain that
>
> We have no idea, we thought you might have one :)
Yes, it's really unclear to us why this is needed. There might be some
kind of contention, or maybe the slave device takes some time to put
DRQ line to low state, and without these wait_cycles the dmaengine
would assume some data are still available in the FIFO while there's
actually no more data to retrieve.
>
> It doesn't really makes sense to us, but it does have a significant
> impact on the throughput.
I wouldn't say significant impact, but tweaking those parameters has
some impact on the performances, and since it's not that complicated to
implement, I thought it was worth a try, but maybe I'm wrong.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-03-08 8:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 9:59 [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users Boris Brezillon
2016-03-07 14:54 ` Vinod Koul
2016-03-07 15:08 ` Boris Brezillon
2016-03-07 20:30 ` Maxime Ripard
2016-03-08 2:55 ` Vinod Koul
2016-03-08 2:59 ` Vinod Koul
2016-03-08 7:51 ` Maxime Ripard
2016-03-08 8:42 ` [linux-sunxi] " Hans de Goede
2016-03-08 10:05 ` Vinod Koul
2016-03-09 10:58 ` Maxime Ripard
2016-03-08 8:46 ` Boris Brezillon [this message]
2016-03-08 9:10 ` Priit Laes
2016-03-08 10:04 ` Vinod Koul
2016-03-09 10:08 ` [linux-sunxi] " LABBE Corentin
2016-03-08 9:59 ` Vinod Koul
2016-03-09 10:14 ` Boris Brezillon
2016-03-11 6:24 ` Vinod Koul
2016-03-11 9:40 ` Boris Brezillon
2016-03-11 10:06 ` Vinod Koul
2016-03-11 10:26 ` Boris Brezillon
2016-03-11 11:21 ` Vinod Koul
2016-03-09 11:06 ` Boris Brezillon
2016-03-11 6:26 ` Vinod Koul
2016-03-11 9:45 ` Boris Brezillon
2016-03-11 10:09 ` Vinod Koul
2016-03-11 10:55 ` Maxime Ripard
2016-03-11 11:18 ` Vinod Koul
2016-03-14 11:46 ` Maxime Ripard
2016-03-16 3:22 ` Vinod Koul
2016-03-07 15:30 ` [linux-sunxi] " Priit Laes
2016-03-07 15:47 ` Boris Brezillon
2016-03-07 17:15 ` Emilio López
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160308094625.539646f8@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).