From mboxrd@z Thu Jan 1 00:00:00 1970 From: kumarrav@codeaurora.org (Ravi Kumar V) Date: Mon, 30 Jan 2012 13:23:50 +0530 Subject: [PATCH v2 0/2] Add Qualcomm MSM ADM DMAEngine driver In-Reply-To: <4F1FFF7E.3000802@codeaurora.org> References: <1325854052-21402-1-git-send-email-kumarrav@codeaurora.org> <1326807902.1540.116.camel@vkoul-udesk3> <4F195E4C.6080805@codeaurora.org> <1327066287.517.4.camel@vkoul-udesk3> <4F1D4052.3070701@codeaurora.org> <1327326713.517.32.camel@vkoul-udesk3> <4F1FFF7E.3000802@codeaurora.org> Message-ID: <4F264C8E.5030007@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 1/25/2012 6:41 PM, Ravi Kumar V wrote: > On 1/23/2012 7:21 PM, Vinod Koul wrote: >> On Mon, 2012-01-23 at 16:41 +0530, Ravi Kumar V wrote: >>> >>> If some changes are made in interleave API then it can support our BOX >>> mode. Here in interleaved template he is assuming destination pattern as >>> can be contiguous or same as source pattern, but in our case destination >>> pattern is different from source pattern. >>> So if a new parameter destination data chunk is added in "struct >>> dma_interleaved_template" structure then it can support different >>> destination pattern. >> do you mean you have cases where you are doing a "memcpy" from one >> interleaved memory to another? >> Can you provide me with a scenario where this maybe helpful? > > Presently we are transferring data from interleaved memory tho > contagious memory and vice-verse. > We can use the interleaved API for present scenario, but it will > restrict the HW capability of transferring data from one interleaved > pattern to other interleaved pattern. > >> >> The reason why the API was designed like this was to give ability to >> take these kind of interleaved memory and copy them to peripheral >> (constant addr) or memory (typically contagious). >> >> In case it is just a pattern I wonder why it cannot be described in >> standard scatter gather definitions as you can split the block further >> down to copy from one respective block to somewhere else in memory. > > We can use scatter gather but it will be extra burden on software to > create those many SG list unlike in box mode just a single command > serves the purpose. > >>> Also it will good if you can provide another parameter for passing >>> private data to dma driver. >> 1. what does this parameter do? > > Private parameter in our case will be command configuration parameter > where we are passing information to HW like endianness, synchronization > & acknowledge mechanism between DMA HW and peripherals running with > different clock than DMA. > >> 2. is this parameter static for a channel or it changes per transfer? >> > This parameter changes per each transfer. > > We can see these possibilities to implement our DMA driver but still > have to add new parameter in "scatterlist" & "interleaved template" for > supporting per transfer private data like our command configuration > parameter. > > 1.We have to add new parameter "struct data_chunk" in > "interleaved_template" for supporting different destination pattern. > It helps a lot for implementing our total HW capability. > > 2.We have to use present API's for box mode. > --scatter gather API for different interleaved source & destination > patterns. > --interleaved API for interleaved source pattern to destination > contiguous pattern/vice-verse. > It causes some extra burden on our software to create sglist. > > 3.Implement New API for BOX mode. > > I feel if we can go with first option then it helps a lot. > > Please can you suggest a better way to solve our problem. > > Thanks, > Ravi Kumar > Please can you suggest best way. -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.