From: Vinod Koul <vinod.koul@intel.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: nsekhar@ti.com, linux@arm.linux.org.uk, olof@lixom.net,
arnd@arndb.de, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
tony@atomide.com, r.schwebel@pengutronix.de
Subject: Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation
Date: Wed, 14 Oct 2015 20:11:05 +0530 [thread overview]
Message-ID: <20151014144105.GV27370@localhost> (raw)
In-Reply-To: <1444828344-21378-3-git-send-email-peter.ujfalusi@ti.com>
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 ?
Is there a limit on 'blocks' of 64K we can do here?
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation
Date: Wed, 14 Oct 2015 20:11:05 +0530 [thread overview]
Message-ID: <20151014144105.GV27370@localhost> (raw)
In-Reply-To: <1444828344-21378-3-git-send-email-peter.ujfalusi@ti.com>
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 ?
Is there a limit on 'blocks' of 64K we can do here?
--
~Vinod
next prev parent reply other threads:[~2015-10-14 14:41 UTC|newest]
Thread overview: 56+ 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 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 01/13] dmaengine: edma: Remove alignment constraint for memcpy Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 02/13] dmaengine: edma: Optimize memcpy operation Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 14:41 ` Vinod Koul [this message]
2015-10-14 14:41 ` Vinod Koul
2015-10-14 15:02 ` Peter Ujfalusi
2015-10-14 15:02 ` Peter Ujfalusi
2015-10-14 15:02 ` Peter Ujfalusi
[not found] ` <561E6E7A.6080408-l0cyMroinI0@public.gmane.org>
2015-10-15 3:59 ` Vinod Koul
2015-10-15 3:59 ` Vinod Koul
2015-10-15 3:59 ` Vinod Koul
2015-10-14 13:12 ` [PATCH 03/13] dmaengine: edma: Simplify function parameter list for channel operations Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 09/13] dmaengine: edma: Merge the of parsing functions Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
[not found] ` <1444828344-21378-11-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
2015-10-14 14:48 ` Vinod Koul
2015-10-14 14:48 ` Vinod Koul
2015-10-14 14:48 ` Vinod Koul
2015-10-14 14:53 ` Peter Ujfalusi
2015-10-14 14:53 ` Peter Ujfalusi
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 ` Peter Ujfalusi
2015-10-14 13:12 ` 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 ` Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` [PATCH 13/13] ARM: DTS: am437x: " Peter Ujfalusi
2015-10-14 13:12 ` Peter Ujfalusi
2015-10-14 13:12 ` 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=20151014144105.GV27370@localhost \
--to=vinod.koul@intel.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nsekhar@ti.com \
--cc=olof@lixom.net \
--cc=peter.ujfalusi@ti.com \
--cc=r.schwebel@pengutronix.de \
--cc=tony@atomide.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.