On Sat, Aug 12, 2017 at 1:20 AM, Dave Jiang <dave.jiang@xxxxxxxxx> wrote:
> There are no in kernel consumers for DMA_SG op. Removing operation,
> dead code, and test code in dmatest.
>
> Signed-off-by: Dave Jiang <dave.jiang@xxxxxxxxx>
> Cc: Gary Hook <gary.hook@xxxxxxx>
> Cc: Ludovic Desroches <ludovic.desroches@xxxxxxxxxxxxx>
> Cc: Kedareswara rao Appana <appana.durga.rao@xxxxxxxxxx>
> Cc: Li Yang <leoyang.li@xxxxxxx>
> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
> Cc: Michal Simek <michal.simek@xxxxxxxxxx>
So we need to figure out why it was added in the first place.
I.e. this:
commit a86ee03ce6f279ebe581a7a8c0c4393eaeb789ee
Author: Ira Snyder <iws@xxxxxxxxxxxxxxxx>
Date: Thu Sep 30 11:46:44 2010 +0000
dma: add support for scatterlist to scatterlist copy
This adds support for scatterlist to scatterlist DMA transfers. A
similar interface is exposed by the fsldma driver (through the DMA_SLAVE
API) and by the ste_dma40 driver (through an exported function).
This patch paves the way for making this type of copy operation a part
of the generic DMAEngine API. Futher patches will add support in
individual drivers.
Signed-off-by: Ira W. Snyder <iws@xxxxxxxxxxxxxxxx>
Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
It seems this existed in the fsldma driver for a certain CARMA board
and then it was generalized for others to use. They must have had a
certain usecase for it. CARMA was used for high rate data acquisition
for a radio telescope for example. I am aware of boards like this
being used in CERN and elsewhere for other data acquisition. I do not
want to screw things up for these people.
The info page for the board is still there:
https://www.mmarray.org/~dwh/carma_board/index.html
Even if CARMA is discontinued we need to know if this feature is
generally useful on such data acquisition systems.
Can we get a statement from Ira about this?
What was this feature really used for?
I do not think it was developed as a thereapeutic activity.
I guess it would be needed for any DMA memcpy operation where the
source and/or destination are over a certain size, so e.g. a decoding
buffer for HD video or whatever, if it is presented as SGs. (CC:ing Mauro
and Benjamin to check if such things actually turn up in reality.)
But it *SEEMS* like a pretty useful thing. For example for defragmenting
memory (if memory management people would have interest in it)
using just DMA. Or for large media buffers that don't want to walk
in and out of the cache, but will be happy of just being moved from one
part of the physical memory to another without bouncing in the cache?
As noted already when introduced, we already handle sg-to-sg inside
the STE DMA40 driver, just this small chunk was needed for the external
interface:
- static struct dma_async_tx_descriptor *
-d40_prep_memcpy_sg(struct dma_chan *chan,
- struct scatterlist *dst_sg, unsigned int dst_nents,
- struct scatterlist *src_sg, unsigned int src_nents,
- unsigned long dma_flags)
-{
- if (dst_nents != src_nents)
- return NULL;
-
- return d40_prep_sg(chan, src_sg, dst_sg, src_nents,
- DMA_MEM_TO_MEM, dma_flags);
-}
I'm being a bit conservative because I actually feel that the DMAengine
memory-to-memory copying capability is a bit underutilized in the kernel,
and there might be a bunch of subsystems that could benefit from it and
speed things up if they knew about it and put it to proper use.
I guess it could be argued that these days the datapath of the CPU is
heavily optimized to that CPU memcpy is always faster but I do not
think that is a rule for all systems out there.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
