linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation
Date: Thu, 15 Oct 2015 09:29:23 +0530	[thread overview]
Message-ID: <20151015035923.GA27370@localhost> (raw)
In-Reply-To: <561E6E7A.6080408@ti.com>

On Wed, Oct 14, 2015 at 06:02:18PM +0300, Peter Ujfalusi wrote:
> On 10/14/2015 05:41 PM, Vinod Koul wrote:
> > On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> >> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy(
> >>  	struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> >>  	size_t len, unsigned long tx_flags)
> >>  {
> >> -	int ret;
> >> +	int ret, nslots;
> >>  	struct edma_desc *edesc;
> >>  	struct device *dev = chan->device->dev;
> >>  	struct edma_chan *echan = to_edma_chan(chan);
> >> -	unsigned int width;
> >> +	unsigned int width, pset_len;
> >>  
> >>  	if (unlikely(!echan || !len))
> >>  		return NULL;
> >>  
> >> -	edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> >> +	if (len < SZ_64K) {
> >> +		/*
> >> +		 * Transfer size less than 64K can be handled with one paRAM
> >> +		 * slot. ACNT = length
> >> +		 */
> >> +		width = len;
> >> +		pset_len = len;
> >> +		nslots = 1;
> >> +	} else {
> >> +		/*
> >> +		 * Transfer size bigger than 64K will be handled with maximum of
> >> +		 * two paRAM slots.
> >> +		 * slot1: ACNT = 32767, length1: (length / 32767)
> >> +		 * slot2: the remaining amount of data.
> >> +		 */
> >> +		width = SZ_32K - 1;
> >> +		pset_len = rounddown(len, width);
> >> +		/* One slot is enough for lengths multiple of (SZ_32K -1) */
> > 
> > Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> > slot and 12K in second slot ?
> 
> Not exactly. If the size is less than 64K it can be done with one 'burst' but
> if it is bigger we need to have two sets of transfer:
> 1. 32K blocks
> 2. the remaining data
> 
> so in case of 140K:
> 4 x 32K followed by 12K

Okay this part wasn't very clear to me, can you please add some comment
explaining this bit

> 
> > 
> > Is there a limit on 'blocks' of 64K we can do here?
> 
> 32767 32K blocks is the limit.
> 
> The 64K burst is only possible if the whole transfer is less less than 64K.
> With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
> we need to use the BCNT counter and for that to work the the distance between
> the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
> this is the reason why we have 32K 'blocks' to transfer first followed by the
> remaining.

Okay IIUC, we have option to single burst if its less that 64K using one
slot, otherwise split to 32K chunk with 2 slots, or would it be N in that
case

Really need more documentation here :)
-- 
~Vinod

  reply	other threads:[~2015-10-15  3:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 13:12 [PATCH 00/13] dmaenigne: edma/ti-crossbar: fixes, new bindings Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 01/13] dmaengine: edma: Remove alignment constraint for memcpy Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 02/13] dmaengine: edma: Optimize memcpy operation Peter Ujfalusi
2015-10-14 14:41   ` Vinod Koul
2015-10-14 15:02     ` Peter Ujfalusi
2015-10-15  3:59       ` Vinod Koul [this message]
2015-10-14 13:12 ` [PATCH 03/13] dmaengine: edma: Simplify function parameter list for channel operations Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 04/13] dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 05/13] dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 06/13] dmaengine: edma: Get qDMA channel information from HW also Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 07/13] dmaengine: edma: Refactor the dma device and channel struct initialization Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 08/13] dmaengine: edma: Do not allocate memory for edma_rsv_info in case of DT boot Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 09/13] dmaengine: edma: Merge the of parsing functions Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx Peter Ujfalusi
2015-10-14 14:48   ` Vinod Koul
2015-10-14 14:53     ` Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 11/13] dmaengine: edma: New device tree binding Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 12/13] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 13/13] ARM: DTS: am437x: " Peter Ujfalusi

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=20151015035923.GA27370@localhost \
    --to=vinod.koul@intel.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).