From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932390Ab1LOG4h (ORCPT ); Thu, 15 Dec 2011 01:56:37 -0500 Received: from eu1sys200aog106.obsmtp.com ([207.126.144.121]:48669 "EHLO eu1sys200aog106.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932276Ab1LOG4f (ORCPT ); Thu, 15 Dec 2011 01:56:35 -0500 Message-ID: <4EE99A15.8010608@st.com> Date: Thu, 15 Dec 2011 12:26:21 +0530 From: Pratyush Anand User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Koul, Vinod" Cc: "Williams, Dan J" , Viresh KUMAR , "linux-kernel@vger.kernel.org" , Shiraz HASHIM , Armando VISCONTI , Deepak SIKRI , Vipin KUMAR , Vipul Kumar SAMAR , Vincenzo FRASCINO , Mirko GARDI , Rajeev KUMAR , Amit VIRDI , Bhupesh SHARMA , "linus.walleij@linaro.org" Subject: Re: dmaengine/Query: What about scatter/gather for mem to mem transfers. References: <4EE038BD.7010705@st.com> <1323329870.1641.27.camel@vkoul-udesk3> <4EE06C3C.8080003@st.com> <4EE8469B.8050201@st.com> <4EE97E77.8060703@st.com> <8D3F6266AEB6384E807C6FFC6FE195E327F2B0@BGSMSX101.gar.corp.intel.com> <4EE98478.5070209@st.com> In-Reply-To: <4EE98478.5070209@st.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/15/2011 10:54 AM, Pratyush Anand wrote: > On 12/15/2011 10:36 AM, Koul, Vinod wrote: >>> >>> Hello Vinod/Dan, >>> >>> Please write your opinion. >> I am on vacation, but will reply briefly here, more next week > > Thanks for your quick reply. > >>> >>> 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 >> So why can't it be split like: >> 0x1000--0x2000 => 0x6000 --0x7000 >> 0x3000 -- 0x4000 => 0x7000 - 0x8000 >> 0x4000 -- 0x5000 => 0x9000 - 0xA000 >> 0x6000 -- 0x7000 => 0xA000 - 0xB000 >> >> That way existing mechanism would work well for you. >> You need to split the chunks properly, which is what dma would do anyway >> > > Yes, they can be split like this, but then splitting onus will go on dma > user driver, and so there would be replication of similar logic at > several places. Therefore, I was thinking to make device_prep_dma_sg as > generic by adding these flags. I see one more issue in using device_prep_interleaved_dma. Src and Dst address has been allocated in user space. Now a kernel module extracts physical addresses from these pages and prepares a sg list, which it submits to DMA. These addresses would be virtually contiguous and incrementing. But, I am not sure if they are always physically incrementing too. If they are not guaranteed to be incrementing, then I see issue. Otherwise also, a situation can arise when scattered memory is not always incrementing or decrementing in the same sg list. > > Regards > Pratyush > >> -- >> ~Vinod >