On Thu, Aug 10, 2017 at 9:22 AM, Dave Jiang <dave.jiang@xxxxxxxxx> wrote: > > > On 08/09/2017 07:20 PM, Dan Williams wrote: >> On Wed, Aug 9, 2017 at 7:15 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >>> On Mon, Aug 7, 2017 at 9:39 AM, Dave Jiang <dave.jiang@xxxxxxxxx> wrote: >>>> In preparation of adding an API to perform SG to/from buffer for dmaengine, >>>> we will change DMA_SG to DMA_SG_SG in order to explicitly making clear what >>>> this op type is for. >>>> >>>> Signed-off-by: Dave Jiang <dave.jiang@xxxxxxxxx> >>>> --- >>>> Documentation/dmaengine/provider.txt | 2 +- >>>> drivers/crypto/ccp/ccp-dmaengine.c | 2 +- >>>> drivers/dma/at_hdmac.c | 8 ++++---- >>>> drivers/dma/dmaengine.c | 2 +- >>>> drivers/dma/dmatest.c | 12 ++++++------ >>>> drivers/dma/fsldma.c | 2 +- >>>> drivers/dma/mv_xor.c | 6 +++--- >>>> drivers/dma/nbpfaxi.c | 2 +- >>>> drivers/dma/ste_dma40.c | 6 +++--- >>>> drivers/dma/xgene-dma.c | 4 ++-- >>>> drivers/dma/xilinx/zynqmp_dma.c | 2 +- >>>> include/linux/dmaengine.h | 2 +- >>>> 12 files changed, 25 insertions(+), 25 deletions(-) >>> >>> Given the prevalence and age of DMA_SG I think we should call the new >>> op DMA_SG_SINGLE, or something like that, so that we don't surprise >>> someone who was expecting the old command type. >> >> Oh wait, you already call the new op DMA_MEMCPY_SG, so why does the >> old one need to change? ...and thinking about it further why do we >> need a new op at all? Couldn't we just pass in a single entry >> scatterlist that was setup on the stack with memcpy target address? > > That would probably work if we can do dma_map_sg() before submit and > dma_unmap_page() on completion since we'll lose the sg entry. I also > have concerns with the DMA_SG function provided in the ioatdma driver > since it really doesn't do scatter gather and it's all software > abstracted. It's not a big deal to support a single entry SG, but it > wouldn't be supporting real SG to SG setup without more complex code. I > worry about the overhead and messiness of it. Of course if you are ok > with providing a DMA_SG function that really doesn't do exactly what > it's advertised to do and only cater to pmem usage. I'm fishing for a way to not to make the dmaengine operation-type proliferation problem worse. The sg-to-sg operation is odd in that typical usages of a scatterlist have a contiguous buffer as the source or destination. A change that gets us closer to that typical model is what I'm looking for and not adding baggage that we need to unwind later since everyone seems to agree that this "->prep_X() + ->submit()" model is broken. I'd like to revisit whether we actually need sg-to-sg vs that typical sg-to-buf model, and once we have the typical model can we refactor all commands to use a single entry point to the driver that takes a single scattler list parameter (similar to scsi, usb, etc). -- 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
