Messages in this thread |  | | | Subject | Re: dmaengine/Query: What about scatter/gather for mem to mem transfers. | | From | Vinod Koul <> | | Date | Tue, 20 Dec 2011 14:51:35 +0530 |
| |
On Thu, 2011-12-15 at 12:26 +0530, Pratyush Anand wrote: > >> 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. Well I am not sure how adding flags handles this? There are few things you should consider 1) do you have h/w support for these, if yes then we can talk about dmaengine APIs doing such a thing 2) if objective is to support such transfers from dma driver POV, then I wouldn't agree, as these can be split easily to standard dma sg list. >From the code POV, it wouldn't hurt to create a wrapper which take in these non standard sg list list and converts then to uniform list
Most important question: in which practical scenario would src and dstn lengths be different?
> > 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. What _exactly_ are you trying to do?
DMA would need buffers which are physically contagious. Also the user pages can be swapped out, you would need to pin these pages.
-- ~Vinod
|  |