Re: dmaengine/Query: What about scatter/gather for mem to memtransfers.

[Vinod Koul]

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

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