linux-kernel - Re: [PATCH v3 01/12] dma: edma: Setup parameters to DMA MAX_NR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52088B8B.9040000@ti.com>
Date:	Mon, 12 Aug 2013 12:45:23 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Joel Fernandes <joelf@...com>
CC:	Tony Lindgren <tony@...mide.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Sricharan R <r.sricharan@...com>,
	Rajendra Nayak <rnayak@...com>,
	Lokesh Vutla <lokeshvutla@...com>,
	Matt Porter <matt@...orter.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Vinod Koul <vinod.koul@...el.com>, Dan Williams <djbw@...com>,
	Mark Brown <broonie@...aro.org>,
	Benoit Cousson <benoit.cousson@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Balaji TK <balajitk@...com>,
	Gururaja Hebbar <gururaja.hebbar@...com>,
	Chris Ball <cjb@...top.org>,
	Jason Kridner <jkridner@...gleboard.org>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux MMC List <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH v3 01/12] dma: edma: Setup parameters to DMA MAX_NR_SG
 at a time

On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
> Changes are made here for configuring existing parameters to support
> DMA'ing them out in batches as needed.
> 
> Also allocate as many as slots as needed by the SG list, but not more
> than MAX_NR_SG. Then these slots will be reused accordingly.
> For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only
> 10 slots will be allocated to DMA the entire SG list of size 40.
> 
> Signed-off-by: Joel Fernandes <joelf@...com>
> ---
>  drivers/dma/edma.c |   14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 5f3e532..7b0853c 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -222,9 +222,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
>  	enum dma_slave_buswidth dev_width;
>  	u32 burst;
>  	struct scatterlist *sg;
> -	int i;
>  	int acnt, bcnt, ccnt, src, dst, cidx;
>  	int src_bidx, dst_bidx, src_cidx, dst_cidx;
> +	int i, num_slots_needed;

'nslots' is more to my liking. Better keep variable names short.

>  
>  	if (unlikely(!echan || !sgl || !sg_len))
>  		return NULL;
> @@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
>  
>  	edesc->pset_nr = sg_len;
>  
> -	for_each_sg(sgl, sg, sg_len, i) {
> -		/* Allocate a PaRAM slot, if needed */
> +	/* Allocate a PaRAM slot, if needed */
> +
> +	num_slots_needed = sg_len > MAX_NR_SG ? MAX_NR_SG : sg_len;

nslots = min(MAX_NR_SG, sg_len);

> +
> +	for (i = 0; i < num_slots_needed; i++) {
>  		if (echan->slot[i] < 0) {
>  			echan->slot[i] =
>  				edma_alloc_slot(EDMA_CTLR(echan->ch_num),
> @@ -273,6 +276,10 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
>  				return NULL;
>  			}
>  		}
> +	}
> +
> +	/* Configure PaRAM sets for each SG */
> +	for_each_sg(sgl, sg, sg_len, i) {
>  
>  		acnt = dev_width;
>  
> @@ -330,6 +337,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
>  		/* Configure A or AB synchronized transfers */
>  		if (edesc->absync)
>  			edesc->pset[i].opt |= SYNCDIM;
> +

Random extra newline.

The patch as such is fine, but I dont think it makes lot of sense
standalone. This needs to be merged into the patch where you actually
handle the entire SG list in batches.

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/