Re: [PATCH 00/20] DMA: DMA unmap fixes
On Wednesday 07 November 2012 21:40:57 Dan Williams wrote: > On Mon, Nov 5, 2012 at 2:00 AM, Bartlomiej Zolnierkiewicz > wrote: > > Hi, > > > > Currently DMA subsystem does DMA mapping in the core code and DMA > > unmapping is done by device drivers. This is counterintuitive, > > causes code duplication and subtle errors (some drivers like PL330 > > one don't implement DMA unmapping code). The following patchset > > modifies DMA subsystem to do DMA unmapping in the core code. > > It results in simpler code, less code duplication (more than 400 > > LOC is gone) and fixes the issue with missing DMA unmapping code > > in some drivers. Additionally many cases when DMA wasn't unmapped > > on a failure are also fixed. > > > > > > patches #1-3 add missing DMA unmap on failure to async_tx core > > code (async_memcpy()), ioat and fsmc_nand drivers > > > > patch #4 fixes DMA flags used by carma-fpga driver > > Ack patches 1-4 [...] > > patch #8 adds missing DMA unmap on failure to ioat3 driver > > > > patch #9 fixes build for async_memset.c > > > > patch #10 adds missing DMA unmap on failure to async tx core > > code (async_memset()) > > Ack patches 8-10 Thank you. Could these patches be merged for 3.8 by either your's or Vinod's tree? Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland R Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/20] DMA: DMA unmap fixes
On Wednesday 07 November 2012 21:40:57 Dan Williams wrote: On Mon, Nov 5, 2012 at 2:00 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, Currently DMA subsystem does DMA mapping in the core code and DMA unmapping is done by device drivers. This is counterintuitive, causes code duplication and subtle errors (some drivers like PL330 one don't implement DMA unmapping code). The following patchset modifies DMA subsystem to do DMA unmapping in the core code. It results in simpler code, less code duplication (more than 400 LOC is gone) and fixes the issue with missing DMA unmapping code in some drivers. Additionally many cases when DMA wasn't unmapped on a failure are also fixed. patches #1-3 add missing DMA unmap on failure to async_tx core code (async_memcpy()), ioat and fsmc_nand drivers patch #4 fixes DMA flags used by carma-fpga driver Ack patches 1-4 [...] patch #8 adds missing DMA unmap on failure to ioat3 driver patch #9 fixes build for async_memset.c patch #10 adds missing DMA unmap on failure to async tx core code (async_memset()) Ack patches 8-10 Thank you. Could these patches be merged for 3.8 by either your's or Vinod's tree? Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/20] DMA: DMA unmap fixes
On Mon, Nov 5, 2012 at 2:00 AM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Currently DMA subsystem does DMA mapping in the core code and DMA > unmapping is done by device drivers. This is counterintuitive, > causes code duplication and subtle errors (some drivers like PL330 > one don't implement DMA unmapping code). The following patchset > modifies DMA subsystem to do DMA unmapping in the core code. > It results in simpler code, less code duplication (more than 400 > LOC is gone) and fixes the issue with missing DMA unmapping code > in some drivers. Additionally many cases when DMA wasn't unmapped > on a failure are also fixed. > > > patches #1-3 add missing DMA unmap on failure to async_tx core > code (async_memcpy()), ioat and fsmc_nand drivers > > patch #4 fixes DMA flags used by carma-fpga driver Ack patches 1-4 > patches #5-7 fix core code and dmatest driver to DMA unmap for > MEMCPY operations Yes, this needs to move out of the drivers, but it needs to move past the core and into the dmaengine clients directly (md/raid and net_dma). The slave_dma usage model already does this as each client takes responsibility for dma mapping. Doing this in the core has some downsides, maybe they're negligible: 1/ all drivers suffer the size increase to dma_async_tx_descriptor 2/ pure polling usage models like net_dma will now trigger dma channel interrupts to run the callback. That being said this cleanup does get us a step closer to where dmaengine needs to go, and I have not found time to do the "move it to the client" patches mentioned above. So I'm inclined to proceed with them. Does anyone still see positive benefits from net_dma? > patch #8 adds missing DMA unmap on failure to ioat3 driver > > patch #9 fixes build for async_memset.c > > patch #10 adds missing DMA unmap on failure to async tx core > code (async_memset()) Ack patches 8-10 > > patches #11-18 fix async_tx core code and dmatest driver to do > DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations > Some comments in the patch. > patches #19-20 remove no longer needed DMA unmap code from > device drivers and DMA unmap flags from code code > > > This patchset was tested on PL330 DMA controller using MEMCPY > operations. It would be great if somebody could test it on > more advanced controller capable of MEMSET, XOR, XOR_VAL, > PQ and PQ_VAL operations (especially since the conversion of > XOR and PQ operations was not obvious). async_tx has a bug in that it permits overlapping dma mappings or operations that cross dma boundaries, but these patches don't make this worse. The interim "fix" I am proposing for this to drop support for channel configurations that require an operation chain to switch channels. This will allow the removal the async_tx_ack() machinery and hopefully prompt channel switching users to contribute to the md changes needed to support this properly. In the meantime the async_tx_ack bits are just adding needless complexity to the drivers that don't care about that functionality. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/20] DMA: DMA unmap fixes
On Mon, Nov 5, 2012 at 2:00 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, Currently DMA subsystem does DMA mapping in the core code and DMA unmapping is done by device drivers. This is counterintuitive, causes code duplication and subtle errors (some drivers like PL330 one don't implement DMA unmapping code). The following patchset modifies DMA subsystem to do DMA unmapping in the core code. It results in simpler code, less code duplication (more than 400 LOC is gone) and fixes the issue with missing DMA unmapping code in some drivers. Additionally many cases when DMA wasn't unmapped on a failure are also fixed. patches #1-3 add missing DMA unmap on failure to async_tx core code (async_memcpy()), ioat and fsmc_nand drivers patch #4 fixes DMA flags used by carma-fpga driver Ack patches 1-4 patches #5-7 fix core code and dmatest driver to DMA unmap for MEMCPY operations Yes, this needs to move out of the drivers, but it needs to move past the core and into the dmaengine clients directly (md/raid and net_dma). The slave_dma usage model already does this as each client takes responsibility for dma mapping. Doing this in the core has some downsides, maybe they're negligible: 1/ all drivers suffer the size increase to dma_async_tx_descriptor 2/ pure polling usage models like net_dma will now trigger dma channel interrupts to run the callback. That being said this cleanup does get us a step closer to where dmaengine needs to go, and I have not found time to do the move it to the client patches mentioned above. So I'm inclined to proceed with them. Does anyone still see positive benefits from net_dma? patch #8 adds missing DMA unmap on failure to ioat3 driver patch #9 fixes build for async_memset.c patch #10 adds missing DMA unmap on failure to async tx core code (async_memset()) Ack patches 8-10 patches #11-18 fix async_tx core code and dmatest driver to do DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations Some comments in the patch. patches #19-20 remove no longer needed DMA unmap code from device drivers and DMA unmap flags from code code This patchset was tested on PL330 DMA controller using MEMCPY operations. It would be great if somebody could test it on more advanced controller capable of MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations (especially since the conversion of XOR and PQ operations was not obvious). async_tx has a bug in that it permits overlapping dma mappings or operations that cross dma boundaries, but these patches don't make this worse. The interim fix I am proposing for this to drop support for channel configurations that require an operation chain to switch channels. This will allow the removal the async_tx_ack() machinery and hopefully prompt channel switching users to contribute to the md changes needed to support this properly. In the meantime the async_tx_ack bits are just adding needless complexity to the drivers that don't care about that functionality. -- Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/20] DMA: DMA unmap fixes
Hi Bart, On Monday 05 of November 2012 11:00:11 Bartlomiej Zolnierkiewicz wrote: > Hi, > > Currently DMA subsystem does DMA mapping in the core code and DMA > unmapping is done by device drivers. This is counterintuitive, > causes code duplication and subtle errors (some drivers like PL330 > one don't implement DMA unmapping code). The following patchset > modifies DMA subsystem to do DMA unmapping in the core code. > It results in simpler code, less code duplication (more than 400 > LOC is gone) and fixes the issue with missing DMA unmapping code > in some drivers. Additionally many cases when DMA wasn't unmapped > on a failure are also fixed. > > > patches #1-3 add missing DMA unmap on failure to async_tx core > code (async_memcpy()), ioat and fsmc_nand drivers > > patch #4 fixes DMA flags used by carma-fpga driver > > patches #5-7 fix core code and dmatest driver to DMA unmap for > MEMCPY operations > > patch #8 adds missing DMA unmap on failure to ioat3 driver > > patch #9 fixes build for async_memset.c > > patch #10 adds missing DMA unmap on failure to async tx core > code (async_memset()) > > patches #11-18 fix async_tx core code and dmatest driver to do > DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations > > patches #19-20 remove no longer needed DMA unmap code from > device drivers and DMA unmap flags from code code > > > This patchset was tested on PL330 DMA controller using MEMCPY > operations. It would be great if somebody could test it on > more advanced controller capable of MEMSET, XOR, XOR_VAL, > PQ and PQ_VAL operations (especially since the conversion of > XOR and PQ operations was not obvious). > > > Bartlomiej Zolnierkiewicz (20): > async_tx: add missing DMA unmap to async_memcpy() > ioat: add missing DMA unmap to ioat_dma_self_test() > mtd: fsmc_nand: add missing DMA unmap to dma_xfer() > carma-fpga: pass correct flags to ->device_prep_dma_memcpy() > dmatest: do DMA unmap for MEMCPY operations > DMA: do DMA unmap in core for MEMCPY operations > async_tx: do DMA unmap in core for MEMCPY operations > ioat3: add missing DMA unmap to ioat_xor_val_self_test() > async_tx: fix build for async_memset > async_tx: add missing DMA unmap to async_memset() > async_tx: do DMA unmap in core for MEMSET operations > dmatest: do DMA unmap for XOR operations > async_tx: do DMA unmap in core for XOR operations > async_tx: do DMA unmap in core for XOR_VAL operations > dmatest: do DMA unmap for PQ operations > async_tx: do DMA unmap in async_raid6_recov.c for PQ operations > async_tx: do DMA unmap in core for PQ operations > async_tx: do DMA unmap in core for PQ_VAL operations > DMA: remove DMA unmap from drivers > DMA: remove DMA unmap flags > > arch/arm/include/asm/hardware/iop3xx-adma.h | 30 > arch/arm/mach-iop13xx/include/mach/adma.h | 26 --- > crypto/async_tx/async_memcpy.c | 27 ++- > crypto/async_tx/async_memset.c | 23 ++- > crypto/async_tx/async_pq.c | 129 + > crypto/async_tx/async_raid6_recov.c | 42 - > crypto/async_tx/async_tx.c | 25 ++- > crypto/async_tx/async_xor.c | 98 +++--- > drivers/ata/pata_arasan_cf.c| 3 +- > drivers/dma/amba-pl08x.c| 31 > drivers/dma/at_hdmac.c | 25 --- > drivers/dma/dmaengine.c | 59 +- > drivers/dma/dmatest.c | 14 +- > drivers/dma/dw_dmac.c | 20 --- > drivers/dma/ep93xx_dma.c| 32 +--- > drivers/dma/fsldma.c| 16 -- > drivers/dma/ioat/dma.c | 28 +-- > drivers/dma/ioat/dma.h | 12 -- > drivers/dma/ioat/dma_v2.c | 1 - > drivers/dma/ioat/dma_v3.c | 179 +- > drivers/dma/iop-adma.c | 70 +--- > drivers/dma/mv_xor.c| 45 + > drivers/dma/ppc4xx/adma.c | 270 > drivers/dma/timb_dma.c > | 36 > drivers/dma/txx9dmac.c | 24 --- > drivers/media/platform/m2m-deinterlace.c| 3 +- > drivers/media/platform/timblogiw.c | 2 +- > drivers/misc/carma/carma-fpga.c | 3 +- > drivers/mtd/nand/atmel_nand.c | 3 +- > drivers/mtd/nand/fsmc_nand.c| 20 ++- > drivers/net/ethernet/micrel/ks8842.c| 6 +- > drivers/spi/spi-dw-mid.c| 4 +- > include/linux/async_tx.h| 4 + > include/linux/dmaengine.h | 34 ++-- > 34 files changed, 446 insertions(+), 898 deletions(-) For all patches: Reviewed-by: Tomasz Figa Best regards, -- Tomasz Figa Samsung Poland R Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send
Re: [PATCH 00/20] DMA: DMA unmap fixes
Hi Bart, On Monday 05 of November 2012 11:00:11 Bartlomiej Zolnierkiewicz wrote: Hi, Currently DMA subsystem does DMA mapping in the core code and DMA unmapping is done by device drivers. This is counterintuitive, causes code duplication and subtle errors (some drivers like PL330 one don't implement DMA unmapping code). The following patchset modifies DMA subsystem to do DMA unmapping in the core code. It results in simpler code, less code duplication (more than 400 LOC is gone) and fixes the issue with missing DMA unmapping code in some drivers. Additionally many cases when DMA wasn't unmapped on a failure are also fixed. patches #1-3 add missing DMA unmap on failure to async_tx core code (async_memcpy()), ioat and fsmc_nand drivers patch #4 fixes DMA flags used by carma-fpga driver patches #5-7 fix core code and dmatest driver to DMA unmap for MEMCPY operations patch #8 adds missing DMA unmap on failure to ioat3 driver patch #9 fixes build for async_memset.c patch #10 adds missing DMA unmap on failure to async tx core code (async_memset()) patches #11-18 fix async_tx core code and dmatest driver to do DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations patches #19-20 remove no longer needed DMA unmap code from device drivers and DMA unmap flags from code code This patchset was tested on PL330 DMA controller using MEMCPY operations. It would be great if somebody could test it on more advanced controller capable of MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations (especially since the conversion of XOR and PQ operations was not obvious). Bartlomiej Zolnierkiewicz (20): async_tx: add missing DMA unmap to async_memcpy() ioat: add missing DMA unmap to ioat_dma_self_test() mtd: fsmc_nand: add missing DMA unmap to dma_xfer() carma-fpga: pass correct flags to -device_prep_dma_memcpy() dmatest: do DMA unmap for MEMCPY operations DMA: do DMA unmap in core for MEMCPY operations async_tx: do DMA unmap in core for MEMCPY operations ioat3: add missing DMA unmap to ioat_xor_val_self_test() async_tx: fix build for async_memset async_tx: add missing DMA unmap to async_memset() async_tx: do DMA unmap in core for MEMSET operations dmatest: do DMA unmap for XOR operations async_tx: do DMA unmap in core for XOR operations async_tx: do DMA unmap in core for XOR_VAL operations dmatest: do DMA unmap for PQ operations async_tx: do DMA unmap in async_raid6_recov.c for PQ operations async_tx: do DMA unmap in core for PQ operations async_tx: do DMA unmap in core for PQ_VAL operations DMA: remove DMA unmap from drivers DMA: remove DMA unmap flags arch/arm/include/asm/hardware/iop3xx-adma.h | 30 arch/arm/mach-iop13xx/include/mach/adma.h | 26 --- crypto/async_tx/async_memcpy.c | 27 ++- crypto/async_tx/async_memset.c | 23 ++- crypto/async_tx/async_pq.c | 129 + crypto/async_tx/async_raid6_recov.c | 42 - crypto/async_tx/async_tx.c | 25 ++- crypto/async_tx/async_xor.c | 98 +++--- drivers/ata/pata_arasan_cf.c| 3 +- drivers/dma/amba-pl08x.c| 31 drivers/dma/at_hdmac.c | 25 --- drivers/dma/dmaengine.c | 59 +- drivers/dma/dmatest.c | 14 +- drivers/dma/dw_dmac.c | 20 --- drivers/dma/ep93xx_dma.c| 32 +--- drivers/dma/fsldma.c| 16 -- drivers/dma/ioat/dma.c | 28 +-- drivers/dma/ioat/dma.h | 12 -- drivers/dma/ioat/dma_v2.c | 1 - drivers/dma/ioat/dma_v3.c | 179 +- drivers/dma/iop-adma.c | 70 +--- drivers/dma/mv_xor.c| 45 + drivers/dma/ppc4xx/adma.c | 270 drivers/dma/timb_dma.c | 36 drivers/dma/txx9dmac.c | 24 --- drivers/media/platform/m2m-deinterlace.c| 3 +- drivers/media/platform/timblogiw.c | 2 +- drivers/misc/carma/carma-fpga.c | 3 +- drivers/mtd/nand/atmel_nand.c | 3 +- drivers/mtd/nand/fsmc_nand.c| 20 ++- drivers/net/ethernet/micrel/ks8842.c| 6 +- drivers/spi/spi-dw-mid.c| 4 +- include/linux/async_tx.h| 4 + include/linux/dmaengine.h | 34 ++-- 34 files changed, 446 insertions(+), 898 deletions(-) For all patches: Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCH 00/20] DMA: DMA unmap fixes
On Mon, Nov 05, 2012 at 11:00:11AM +0100, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Currently DMA subsystem does DMA mapping in the core code and DMA > unmapping is done by device drivers. This is counterintuitive, > causes code duplication and subtle errors (some drivers like PL330 > one don't implement DMA unmapping code). The following patchset > modifies DMA subsystem to do DMA unmapping in the core code. > It results in simpler code, less code duplication (more than 400 > LOC is gone) and fixes the issue with missing DMA unmapping code > in some drivers. Additionally many cases when DMA wasn't unmapped > on a failure are also fixed. > > > patches #1-3 add missing DMA unmap on failure to async_tx core > code (async_memcpy()), ioat and fsmc_nand drivers > > patch #4 fixes DMA flags used by carma-fpga driver > > patches #5-7 fix core code and dmatest driver to DMA unmap for > MEMCPY operations > > patch #8 adds missing DMA unmap on failure to ioat3 driver > > patch #9 fixes build for async_memset.c > > patch #10 adds missing DMA unmap on failure to async tx core > code (async_memset()) > > patches #11-18 fix async_tx core code and dmatest driver to do > DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations > > patches #19-20 remove no longer needed DMA unmap code from > device drivers and DMA unmap flags from code code > > > This patchset was tested on PL330 DMA controller using MEMCPY > operations. It would be great if somebody could test it on > more advanced controller capable of MEMSET, XOR, XOR_VAL, > PQ and PQ_VAL operations (especially since the conversion of > XOR and PQ operations was not obvious). > > > Bartlomiej Zolnierkiewicz (20): > async_tx: add missing DMA unmap to async_memcpy() > ioat: add missing DMA unmap to ioat_dma_self_test() > mtd: fsmc_nand: add missing DMA unmap to dma_xfer() > carma-fpga: pass correct flags to ->device_prep_dma_memcpy() > dmatest: do DMA unmap for MEMCPY operations > DMA: do DMA unmap in core for MEMCPY operations > async_tx: do DMA unmap in core for MEMCPY operations > ioat3: add missing DMA unmap to ioat_xor_val_self_test() > async_tx: fix build for async_memset > async_tx: add missing DMA unmap to async_memset() > async_tx: do DMA unmap in core for MEMSET operations > dmatest: do DMA unmap for XOR operations > async_tx: do DMA unmap in core for XOR operations > async_tx: do DMA unmap in core for XOR_VAL operations > dmatest: do DMA unmap for PQ operations > async_tx: do DMA unmap in async_raid6_recov.c for PQ operations > async_tx: do DMA unmap in core for PQ operations > async_tx: do DMA unmap in core for PQ_VAL operations > DMA: remove DMA unmap from drivers > DMA: remove DMA unmap flags > > arch/arm/include/asm/hardware/iop3xx-adma.h | 30 > arch/arm/mach-iop13xx/include/mach/adma.h | 26 --- > crypto/async_tx/async_memcpy.c | 27 ++- > crypto/async_tx/async_memset.c | 23 ++- > crypto/async_tx/async_pq.c | 129 + > crypto/async_tx/async_raid6_recov.c | 42 - > crypto/async_tx/async_tx.c | 25 ++- > crypto/async_tx/async_xor.c | 98 +++--- > drivers/ata/pata_arasan_cf.c| 3 +- > drivers/dma/amba-pl08x.c| 31 > drivers/dma/at_hdmac.c | 25 --- > drivers/dma/dmaengine.c | 59 +- > drivers/dma/dmatest.c | 14 +- > drivers/dma/dw_dmac.c | 20 --- > drivers/dma/ep93xx_dma.c| 32 +--- > drivers/dma/fsldma.c| 16 -- > drivers/dma/ioat/dma.c | 28 +-- > drivers/dma/ioat/dma.h | 12 -- > drivers/dma/ioat/dma_v2.c | 1 - > drivers/dma/ioat/dma_v3.c | 179 +- > drivers/dma/iop-adma.c | 70 +--- > drivers/dma/mv_xor.c| 45 + > drivers/dma/ppc4xx/adma.c | 270 > > drivers/dma/timb_dma.c | 36 > drivers/dma/txx9dmac.c | 24 --- > drivers/media/platform/m2m-deinterlace.c| 3 +- > drivers/media/platform/timblogiw.c | 2 +- > drivers/misc/carma/carma-fpga.c | 3 +- > drivers/mtd/nand/atmel_nand.c | 3 +- > drivers/mtd/nand/fsmc_nand.c| 20 ++- > drivers/net/ethernet/micrel/ks8842.c| 6 +- > drivers/spi/spi-dw-mid.c| 4 +- > include/linux/async_tx.h| 4 + > include/linux/dmaengine.h | 34 ++-- > 34 files changed, 446 insertions(+), 898 deletions(-) > > -- > 1.8.0 > Hello Bartlomiej Zolnierkiewicz, The carma-fpga and fsldma parts look good to me. For those parts, Acked-by: Ira W. Snyder Thanks, Ira -- To unsubscribe from
Re: [PATCH 00/20] DMA: DMA unmap fixes
On Mon, Nov 05, 2012 at 11:00:11AM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, Currently DMA subsystem does DMA mapping in the core code and DMA unmapping is done by device drivers. This is counterintuitive, causes code duplication and subtle errors (some drivers like PL330 one don't implement DMA unmapping code). The following patchset modifies DMA subsystem to do DMA unmapping in the core code. It results in simpler code, less code duplication (more than 400 LOC is gone) and fixes the issue with missing DMA unmapping code in some drivers. Additionally many cases when DMA wasn't unmapped on a failure are also fixed. patches #1-3 add missing DMA unmap on failure to async_tx core code (async_memcpy()), ioat and fsmc_nand drivers patch #4 fixes DMA flags used by carma-fpga driver patches #5-7 fix core code and dmatest driver to DMA unmap for MEMCPY operations patch #8 adds missing DMA unmap on failure to ioat3 driver patch #9 fixes build for async_memset.c patch #10 adds missing DMA unmap on failure to async tx core code (async_memset()) patches #11-18 fix async_tx core code and dmatest driver to do DMA unmap for MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations patches #19-20 remove no longer needed DMA unmap code from device drivers and DMA unmap flags from code code This patchset was tested on PL330 DMA controller using MEMCPY operations. It would be great if somebody could test it on more advanced controller capable of MEMSET, XOR, XOR_VAL, PQ and PQ_VAL operations (especially since the conversion of XOR and PQ operations was not obvious). Bartlomiej Zolnierkiewicz (20): async_tx: add missing DMA unmap to async_memcpy() ioat: add missing DMA unmap to ioat_dma_self_test() mtd: fsmc_nand: add missing DMA unmap to dma_xfer() carma-fpga: pass correct flags to -device_prep_dma_memcpy() dmatest: do DMA unmap for MEMCPY operations DMA: do DMA unmap in core for MEMCPY operations async_tx: do DMA unmap in core for MEMCPY operations ioat3: add missing DMA unmap to ioat_xor_val_self_test() async_tx: fix build for async_memset async_tx: add missing DMA unmap to async_memset() async_tx: do DMA unmap in core for MEMSET operations dmatest: do DMA unmap for XOR operations async_tx: do DMA unmap in core for XOR operations async_tx: do DMA unmap in core for XOR_VAL operations dmatest: do DMA unmap for PQ operations async_tx: do DMA unmap in async_raid6_recov.c for PQ operations async_tx: do DMA unmap in core for PQ operations async_tx: do DMA unmap in core for PQ_VAL operations DMA: remove DMA unmap from drivers DMA: remove DMA unmap flags arch/arm/include/asm/hardware/iop3xx-adma.h | 30 arch/arm/mach-iop13xx/include/mach/adma.h | 26 --- crypto/async_tx/async_memcpy.c | 27 ++- crypto/async_tx/async_memset.c | 23 ++- crypto/async_tx/async_pq.c | 129 + crypto/async_tx/async_raid6_recov.c | 42 - crypto/async_tx/async_tx.c | 25 ++- crypto/async_tx/async_xor.c | 98 +++--- drivers/ata/pata_arasan_cf.c| 3 +- drivers/dma/amba-pl08x.c| 31 drivers/dma/at_hdmac.c | 25 --- drivers/dma/dmaengine.c | 59 +- drivers/dma/dmatest.c | 14 +- drivers/dma/dw_dmac.c | 20 --- drivers/dma/ep93xx_dma.c| 32 +--- drivers/dma/fsldma.c| 16 -- drivers/dma/ioat/dma.c | 28 +-- drivers/dma/ioat/dma.h | 12 -- drivers/dma/ioat/dma_v2.c | 1 - drivers/dma/ioat/dma_v3.c | 179 +- drivers/dma/iop-adma.c | 70 +--- drivers/dma/mv_xor.c| 45 + drivers/dma/ppc4xx/adma.c | 270 drivers/dma/timb_dma.c | 36 drivers/dma/txx9dmac.c | 24 --- drivers/media/platform/m2m-deinterlace.c| 3 +- drivers/media/platform/timblogiw.c | 2 +- drivers/misc/carma/carma-fpga.c | 3 +- drivers/mtd/nand/atmel_nand.c | 3 +- drivers/mtd/nand/fsmc_nand.c| 20 ++- drivers/net/ethernet/micrel/ks8842.c| 6 +- drivers/spi/spi-dw-mid.c| 4 +- include/linux/async_tx.h| 4 + include/linux/dmaengine.h | 34 ++-- 34 files changed, 446 insertions(+), 898 deletions(-) -- 1.8.0 Hello Bartlomiej Zolnierkiewicz, The carma-fpga and fsldma parts look good to me. For those parts, Acked-by: Ira W. Snyder i...@ovro.caltech.edu Thanks, Ira -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
