On 08/09/2017 07:20 PM, Dan Williams wrote: > On Wed, Aug 9, 2017 at 7:15 PM, Dan Williams <dan.j.willi...@intel.com> wrote: >> On Mon, Aug 7, 2017 at 9:39 AM, Dave Jiang <dave.ji...@intel.com> 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.ji...@intel.com> >>> --- >>> 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. _______________________________________________ Linux-nvdimm mailing list Linuxfirstname.lastname@example.org https://lists.01.org/mailman/listinfo/linux-nvdimm