On 08/14/2017 03:07 AM, Linus Walleij wrote: > 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: Even if it is used by somebody, the code is out of tree and thus unsupported. Unless they upstream their code and utilize DMA_SG, the burden is on them to maintain whatever support they need. Linux kernel does not maintain dead code. I have quite a bit of "extra" code in ioatdma that would make my life easier if it's upstream and used by third parties. However I can't because upstream does not take code with no in kernel consumer. So I continue to support them out of tree. The DMA_SG code really shouldn't have been accepted into the kernel in the first place. > > 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 > -- 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
