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
next prev parent 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).