linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Dan Williams <djbw@fb.com>
Cc: linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	vinod.koul@intel.com, Tomasz Figa <t.figa@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	dave.jiang@intel.com
Subject: Re: [PATCH 10/12] async_pq_val: convert to dmaengine_unmap_data
Date: Thu, 06 Dec 2012 16:48:10 +0100	[thread overview]
Message-ID: <201212061648.11062.b.zolnierkie@samsung.com> (raw)
In-Reply-To: <20121206092605.17085.40510.stgit@dev279.prn1.facebook.com>

On Thursday 06 December 2012 10:26:05 Dan Williams wrote:
> Use the generic unmap object to unmap dma buffers.
> 
> Cc: Tomasz Figa <t.figa@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Dan Williams <djbw@fb.com>
> ---
>  crypto/async_tx/async_pq.c |   58 +++++++++++++++++++++++++++-----------------
>  1 file changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
> index 1d78984..e5ddb31 100644
> --- a/crypto/async_tx/async_pq.c
> +++ b/crypto/async_tx/async_pq.c
> @@ -288,50 +288,60 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
>  	struct dma_async_tx_descriptor *tx;
>  	unsigned char coefs[disks-2];
>  	enum dma_ctrl_flags dma_flags = submit->cb_fn ? DMA_PREP_INTERRUPT : 0;
> -	dma_addr_t *dma_src = NULL;
> -	int src_cnt = 0;
> +	struct dmaengine_unmap_data *unmap = NULL;
>  
>  	BUG_ON(disks < 4);
>  
> -	if (submit->scribble)
> -		dma_src = submit->scribble;
> -	else if (sizeof(dma_addr_t) <= sizeof(struct page *))
> -		dma_src = (dma_addr_t *) blocks;
> +	if (device)
> +		unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
>  
> -	if (dma_src && device && disks <= dma_maxpq(device, 0) &&
> +	if (unmap && disks <= dma_maxpq(device, 0) &&
>  	    is_dma_pq_aligned(device, offset, 0, len)) {
>  		struct device *dev = device->dev;
> -		dma_addr_t *pq = &dma_src[disks-2];
> -		int i;
> +		dma_addr_t pq[2];
> +		int i, j = 0, src_cnt = 0;
>  
>  		pr_debug("%s: (async) disks: %d len: %zu\n",
>  			 __func__, disks, len);
> -		if (!P(blocks, disks))
> +
> +		unmap->len = len;
> +		for (i = 0; i < disks-2; i++)
> +			if (likely(blocks[i])) {
> +				unmap->addr[j] = dma_map_page(dev, blocks[i],
> +							      offset, len,
> +							      DMA_TO_DEVICE);
> +				coefs[j] = raid6_gfexp[i];
> +				unmap->to_cnt++;
> +				src_cnt++;
> +				j++;
> +			}
> +
> +		if (!P(blocks, disks)) {
> +			pq[0] = 0;
>  			dma_flags |= DMA_PREP_PQ_DISABLE_P;
> -		else
> +		} else {
>  			pq[0] = dma_map_page(dev, P(blocks, disks),
>  					     offset, len,
>  					     DMA_TO_DEVICE);
> -		if (!Q(blocks, disks))
> +			unmap->addr[j++] = pq[0];
> +			unmap->to_cnt++;
> +		}
> +		if (!Q(blocks, disks)) {
> +			pq[1] = 0;
>  			dma_flags |= DMA_PREP_PQ_DISABLE_Q;
> -		else
> +		} else {
>  			pq[1] = dma_map_page(dev, Q(blocks, disks),
>  					     offset, len,
>  					     DMA_TO_DEVICE);
> +			unmap->addr[j++] = pq[1];
> +			unmap->to_cnt++;
> +		}
>  
>  		if (submit->flags & ASYNC_TX_FENCE)
>  			dma_flags |= DMA_PREP_FENCE;
> -		for (i = 0; i < disks-2; i++)
> -			if (likely(blocks[i])) {
> -				dma_src[src_cnt] = dma_map_page(dev, blocks[i],
> -								offset, len,
> -								DMA_TO_DEVICE);
> -				coefs[src_cnt] = raid6_gfexp[i];
> -				src_cnt++;
> -			}
> -
>  		for (;;) {
> -			tx = device->device_prep_dma_pq_val(chan, pq, dma_src,
> +			tx = device->device_prep_dma_pq_val(chan, pq,
> +							    unmap->addr,
>  							    src_cnt,
>  							    coefs,
>  							    len, pqres,
> @@ -341,6 +351,8 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
>  			async_tx_quiesce(&submit->depend_tx);
>  			dma_async_issue_pending(chan);
>  		}
> +
> +		dma_set_unmap(tx, unmap);
>  		async_tx_submit(chan, tx, submit);
>  
>  		return tx;

What did happen to dmaengine_unmap_put() calls?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung Poland R&D Center

  reply	other threads:[~2012-12-06 15:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-06  9:25 [PATCH 00/12] dmaengine_unmap_data Dan Williams
2012-12-06  9:25 ` [PATCH 01/12] dmaengine: consolidate memcpy apis Dan Williams
2012-12-06  9:25 ` [PATCH 02/12] dmaengine: prepare for generic 'unmap' data Dan Williams
2012-12-06 15:47   ` Bartlomiej Zolnierkiewicz
2013-06-26 10:44     ` dmaengine_unmap_data patches (was: Re: Re: [PATCH 02/12] dmaengine: prepare for generic 'unmap' data) Bartlomiej Zolnierkiewicz
2013-06-28 17:35       ` Dan Williams
2012-12-06  9:25 ` [PATCH 03/12] dmaengine: reference counted unmap data Dan Williams
2012-12-06 15:47   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 04/12] async_memcpy: convert to dmaengine_unmap_data Dan Williams
2012-12-06 15:47   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 05/12] async_memset: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 06/12] async_xor: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 07/12] async_xor_val: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 08/12] async_raid6_recov: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:25 ` [PATCH 09/12] async_pq: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz
2012-12-06  9:26 ` [PATCH 10/12] async_pq_val: " Dan Williams
2012-12-06 15:48   ` Bartlomiej Zolnierkiewicz [this message]
2012-12-06  9:26 ` [PATCH 11/12] dmaengine: remove DMA unmap from drivers Dan Williams
2012-12-06  9:26 ` [PATCH 12/12] dmaengine: remove DMA unmap flags Dan Williams

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=201212061648.11062.b.zolnierkie@samsung.com \
    --to=b.zolnierkie@samsung.com \
    --cc=dave.jiang@intel.com \
    --cc=djbw@fb.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=t.figa@samsung.com \
    --cc=vinod.koul@intel.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 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).