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]
Date:	Thu, 15 Dec 2011 10:28:31 +0530
From:	Pratyush Anand <pratyush.anand@...com>
To:	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>
Cc:	Viresh KUMAR <viresh.kumar@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	Armando VISCONTI <armando.visconti@...com>,
	Deepak SIKRI <deepak.sikri@...com>,
	Vipin KUMAR <vipin.kumar@...com>,
	Vipul Kumar SAMAR <vipulkumar.samar@...com>,
	Vincenzo FRASCINO <Vincenzo.FRASCINO@...com>,
	Mirko GARDI <mirko.gardi@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Amit VIRDI <Amit.VIRDI@...com>,
	Bhupesh SHARMA <bhupesh.sharma@...com>,
	<linus.walleij@...aro.org>
Subject: Re: dmaengine/Query: What about scatter/gather for mem to mem transfers.

Hello Vinod/Dan,

Please write your opinion.

Regards
Pratyush

On 12/14/2011 12:17 PM, Pratyush Anand wrote:
> Hello Vinod/Dan,
>
> In continuation to the scatter/gather requirement:
> We might need some generic transfer where source and destination address
> may be overlapped and also gap between two chunk of source and
> destination might not be same.
>
> For examaple,
> Transfer size is - -0x4000
> Our Src is something like this:
> 0x1000 -- 0x2000
> 0x3000 -- 0x5000
> 0x6000 -- 0x7000
>
> and dst is something like this:
> 0x6000 -- 0x8000
> 0x9000 -- 0xB000
>
> It seems that device_prep_interleaved_dma would not be able to handle
> such transfer.
>
> So, what I was thinking that to add following flags in enum dma_ctrl_flags.
>
> DMA_SRC_INC = (1 << 10),
> DMA_SRC_DEC = (2 << 10),
> DMA_SRC_FIX = (3 << 10),
> DMA_DST_INC = (1 << 12),
> DMA_DST_DEC = (2 << 12),
> DMA_DST_FIX = (3 << 12),
>
> Now we can use these flag in device_prep_dma_sg and this function can be
> implemented for generic cases.
>
> I think, the above modifications will not affect other's platform and
> should be acceptable.
>
> Whats your opinion?
>
> Regards
> Pratyush
>
> On 12/8/2011 1:20 PM, Viresh KUMAR wrote:
>> On 12/8/2011 1:07 PM, Vinod Koul wrote:
>>> You mean something like:
>>> struct dma_async_tx_descriptor *(*device_prep_dma_sg)(
>>> struct dma_chan *chan,
>>> struct scatterlist *dst_sg, unsigned int dst_nents,
>>> struct scatterlist *src_sg, unsigned int src_nents,
>>> unsigned long flags);
>>>
>>> Its already there, you need to implement in your driver :)
>>
>> Ok. I didn't knew it. :(
>>
>

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ