* RE: 2.6.22-rc1-mm1 - s390 vs. md @ 2007-05-17 6:36 Williams, Dan J 2007-05-18 5:39 ` Cornelia Huck 0 siblings, 1 reply; 11+ messages in thread From: Williams, Dan J @ 2007-05-17 6:36 UTC (permalink / raw) To: Williams, Dan J, Cornelia Huck, Andrew Morton Cc: linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 > From: Williams, Dan J > On a closer look, it seems async_tx should be its own directory like crypto... > I'll post the incremental changes to the md-accel git tree for review. > Here is a copy of the patch added to the md-accel series (git://lost.foo-projects.org/~dwillia2/git/iop md-accel-linus). This along with some other code re-factoring makes async_tx mimic the organization of crypto, and should resolve the S390 clash. --- async_tx: add the Kconfig infrastructure for async_tx From: Dan Williams <dan.j.williams@intel.com> async_tx is similar to crypto in that there is an api component and a drivers component. * Add 'source "async_tx/Kconfig"' to the per architecture Kconfig files, for each architecture that sources drivers/md/Kconfig (which appears to be all of them). * Add 'select' statements for the subsystems that use async_tx (md-raid4,5) Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- arch/alpha/Kconfig | 1 + arch/arm/Kconfig | 2 ++ arch/arm26/Kconfig | 2 ++ arch/avr32/Kconfig | 2 ++ arch/blackfin/Kconfig | 2 ++ arch/cris/Kconfig | 2 ++ arch/frv/Kconfig | 2 ++ arch/h8300/Kconfig | 2 ++ arch/i386/Kconfig | 2 ++ arch/ia64/Kconfig | 2 ++ arch/m32r/Kconfig | 2 ++ arch/m68k/Kconfig | 2 ++ arch/m68knommu/Kconfig | 2 ++ arch/mips/Kconfig | 2 ++ arch/parisc/Kconfig | 2 ++ arch/powerpc/Kconfig | 2 ++ arch/ppc/Kconfig | 2 ++ arch/s390/Kconfig | 2 ++ arch/sh/Kconfig | 2 ++ arch/sh64/Kconfig | 2 ++ arch/sparc/Kconfig | 2 ++ arch/sparc64/Kconfig | 2 ++ arch/um/Kconfig | 2 ++ arch/v850/Kconfig | 2 ++ arch/x86_64/Kconfig | 2 ++ arch/xtensa/Kconfig | 2 ++ async_tx/Kconfig | 27 +++++++++++++++++++++++++++ drivers/md/Kconfig | 3 +++ 28 files changed, 81 insertions(+), 0 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 770f717..1fb0075 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -650,3 +650,4 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1f2809c..dd49b2a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1048,3 +1048,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/arm26/Kconfig b/arch/arm26/Kconfig index 20688bc..bc8b99d 100644 --- a/arch/arm26/Kconfig +++ b/arch/arm26/Kconfig @@ -248,3 +248,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig index 3ec7658..5f16cc6 100644 --- a/arch/avr32/Kconfig +++ b/arch/avr32/Kconfig @@ -213,3 +213,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index 1a49305..648043a 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -987,3 +987,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index 4b41248..f902242 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -205,3 +205,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index 114738a..6aa888b 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -390,3 +390,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 618dbad..95e33df 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -227,3 +227,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index c2d54b8..2776164 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -1236,6 +1236,8 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + # # Use the generic interrupt handling code in kernel/irq/: # diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index de1bff6..929e59b 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -552,6 +552,8 @@ source "fs/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + # # Use the generic interrupt handling code in kernel/irq/: # diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig index c3bb8a7..35c6c08 100644 --- a/arch/m32r/Kconfig +++ b/arch/m32r/Kconfig @@ -412,3 +412,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index b8536c7..1421427 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -677,3 +677,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig index 823f737..9cf83cf 100644 --- a/arch/m68knommu/Kconfig +++ b/arch/m68knommu/Kconfig @@ -683,3 +683,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0f09412..581040c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1963,3 +1963,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 3d73545..afc4bad 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -276,3 +276,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 56d3c0d..65f6c55 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -887,6 +887,8 @@ source "arch/powerpc/sysdev/qe_lib/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + menu "Instrumentation Support" depends on EXPERIMENTAL diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig index ccce2a4..e249d9a 100644 --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -1458,3 +1458,5 @@ source "arch/ppc/Kconfig.debug" source "security/Kconfig" source "crypto/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 098c62c..25d86af 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -556,3 +556,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 038179e..6f99b0e 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -728,3 +728,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/sh64/Kconfig b/arch/sh64/Kconfig index ff65420..32f032a 100644 --- a/arch/sh64/Kconfig +++ b/arch/sh64/Kconfig @@ -292,6 +292,8 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + # # Use the generic interrupt handling code in kernel/irq/: # diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index bd992c0..a782692 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -315,3 +315,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig index 831781c..16a9175 100644 --- a/arch/sparc64/Kconfig +++ b/arch/sparc64/Kconfig @@ -447,3 +447,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/um/Kconfig b/arch/um/Kconfig index c504312..220d7de 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -325,6 +325,8 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" +source "async_tx/Kconfig" + if BROKEN source "drivers/mtd/Kconfig" endif diff --git a/arch/v850/Kconfig b/arch/v850/Kconfig index 5f54c12..bdee041 100644 --- a/arch/v850/Kconfig +++ b/arch/v850/Kconfig @@ -347,4 +347,6 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + ######################################################################## ##### diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 145bb82..2b8b637 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -784,3 +784,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "async_tx/Kconfig" diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index 7fbb44b..b18d15f 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -259,4 +259,6 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "async_tx/Kconfig" + diff --git a/async_tx/Kconfig b/async_tx/Kconfig new file mode 100644 index 0000000..4a6801e --- /dev/null +++ b/async_tx/Kconfig @@ -0,0 +1,27 @@ +menuconfig ASYNC_CORE + tristate "Asynchronous Bulk Memory Transfers/Transforms" + default n + ---help--- + This enables the async_tx interface layer for dma (offload) engines. + Subsystems coded to this api will use offload engines for bulk memory + operations (e.g. memcpy, memset, xor...). When an offload engine is not + available the interface will implicitly fall back to a software + implementation of the operation. + + If unsure, say N + +if ASYNC_CORE + +config ASYNC_MEMCPY + default m + tristate "async_memcpy support" + +config ASYNC_XOR + default m + tristate "async_xor support" + +config ASYNC_MEMSET + default m + tristate "async_memset support" + +endif diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 7df934d..9fa1555 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -109,6 +109,9 @@ config MD_RAID10 config MD_RAID456 tristate "RAID-4/RAID-5/RAID-6 mode" depends on BLK_DEV_MD + select ASYNC_CORE + select ASYNC_MEMCPY + select ASYNC_XOR ---help--- A RAID-5 set of N drives with a capacity of C MB per drive provides the capacity of C * (N - 1) MB, and protects against a failure ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-17 6:36 2.6.22-rc1-mm1 - s390 vs. md Williams, Dan J @ 2007-05-18 5:39 ` Cornelia Huck 2007-05-18 16:30 ` Williams, Dan J 0 siblings, 1 reply; 11+ messages in thread From: Cornelia Huck @ 2007-05-18 5:39 UTC (permalink / raw) To: Williams, Dan J Cc: Andrew Morton, linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 On Wed, 16 May 2007 23:36:56 -0700, "Williams, Dan J" <dan.j.williams@intel.com> wrote: > async_tx: add the Kconfig infrastructure for async_tx > > From: Dan Williams <dan.j.williams@intel.com> > > async_tx is similar to crypto in that there is an api component and a > drivers component. > > * Add 'source "async_tx/Kconfig"' to the per architecture Kconfig files, > for each architecture that sources drivers/md/Kconfig (which appears > to be > all of them). > * Add 'select' statements for the subsystems that use async_tx > (md-raid4,5) Finer granularity is certainly better here, but I'm not quite sure if this solves our s390 problem (we don't have dma support). All those backends should also have a non-dma version... ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-18 5:39 ` Cornelia Huck @ 2007-05-18 16:30 ` Williams, Dan J 2007-05-21 7:24 ` Cornelia Huck 0 siblings, 1 reply; 11+ messages in thread From: Williams, Dan J @ 2007-05-18 16:30 UTC (permalink / raw) To: Cornelia Huck Cc: Andrew Morton, linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 > From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com] > Finer granularity is certainly better here, but I'm not quite sure if > this solves our s390 problem (we don't have dma support). All those > backends should also have a non-dma version... In fact that is already there. Here is the form of async_memcpy for example: ... async_memcpy( ... ) { struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMCPY); struct dma_device *device = chan ? chan->device : NULL; int int_en = callback ? 1 : 0; struct dma_async_tx_descriptor *tx = device ? device->device_prep_dma_memcpy(chan, len, int_en) : NULL; if (tx) { /* run the memcpy asynchronously */ ... } else { /* run the memcpy synchronously */ ... } } When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form: ... async_tx_find_channel( ... ) { return NULL; } So in the S390 case the entire asynchronous path will be compiled away. -- Dan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-18 16:30 ` Williams, Dan J @ 2007-05-21 7:24 ` Cornelia Huck 2007-05-21 8:52 ` Williams, Dan J 2007-05-23 0:25 ` Williams, Dan J 0 siblings, 2 replies; 11+ messages in thread From: Cornelia Huck @ 2007-05-21 7:24 UTC (permalink / raw) To: Williams, Dan J Cc: Andrew Morton, linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 On Fri, 18 May 2007 09:30:09 -0700, "Williams, Dan J" <dan.j.williams@intel.com> wrote: > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form: > ... async_tx_find_channel( ... ) > { > return NULL; > } > > So in the S390 case the entire asynchronous path will be compiled away. Unfortunately, do_async_xor() (and others) is not ifdef'ed and contains dma_map_page(), which led to the compile failure... ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-21 7:24 ` Cornelia Huck @ 2007-05-21 8:52 ` Williams, Dan J 2007-05-23 0:25 ` Williams, Dan J 1 sibling, 0 replies; 11+ messages in thread From: Williams, Dan J @ 2007-05-21 8:52 UTC (permalink / raw) To: Cornelia Huck Cc: Andrew Morton, linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 > From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com] > On Fri, 18 May 2007 09:30:09 -0700, > "Williams, Dan J" <dan.j.williams@intel.com> wrote: > > > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form: > > ... async_tx_find_channel( ... ) > > { > > return NULL; > > } > > > > So in the S390 case the entire asynchronous path will be compiled away. > > Unfortunately, do_async_xor() (and others) is not ifdef'ed and contains > dma_map_page(), which led to the compile failure... Sorry, I did not realize dma_map_page did not exist on s390. I am building an s390 cross compiler so I can clean up these errors. ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-21 7:24 ` Cornelia Huck 2007-05-21 8:52 ` Williams, Dan J @ 2007-05-23 0:25 ` Williams, Dan J 2007-05-23 8:05 ` Martin Schwidefsky 1 sibling, 1 reply; 11+ messages in thread From: Williams, Dan J @ 2007-05-23 0:25 UTC (permalink / raw) To: Cornelia Huck Cc: Andrew Morton, linux-kernel, NeilBrown, Martin Schwidefsky, linux-s390 > From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com] > On Fri, 18 May 2007 09:30:09 -0700, > "Williams, Dan J" <dan.j.williams@intel.com> wrote: > > > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form: > > ... async_tx_find_channel( ... ) > > { > > return NULL; > > } > > > > So in the S390 case the entire asynchronous path will be compiled away. > > Unfortunately, do_async_xor() (and others) is not ifdef'ed and contains > dma_map_page(), which led to the compile failure... The approach I have taken is to add the missing definitions to include/asm-s390/dma-mapping.h [ a non-outlook-mangled version of the patch is pushed out in my rebased git tree ]. I was not able to fully compile-test this change as the three s390-cross-toolchains I tried each died early in the kernel build process. The most common error was: "s390-unknown-linux-gnu-ld: unrecognised emulation mode: elf64_s390" --- s390: add dma mapping api stub definitions for async_tx From: Dan Williams <dan.j.williams@intel.com> The asynchronous path in async_tx is meant to be compiled away on platforms like s390 with CONFIG_DMA_ENGINE=n. However, it is difficult to compile something away if it does not compile in the first place. This patch adds the missing dma api definitions as BUG() stubs. Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- include/asm-s390/dma-mapping.h | 78 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 78 insertions(+), 0 deletions(-) diff --git a/include/asm-s390/dma-mapping.h b/include/asm-s390/dma-mapping.h index 3f8c12f..33a3c82 100644 --- a/include/asm-s390/dma-mapping.h +++ b/include/asm-s390/dma-mapping.h @@ -4,9 +4,87 @@ * S390 version * * This file exists so that #include <dma-mapping.h> doesn't break anything. + * It also includes stub definitions of the API so common code like async_tx + * can compile. */ #ifndef _ASM_DMA_MAPPING_H #define _ASM_DMA_MAPPING_H +#include <linux/mm.h> +#include <asm/scatterlist.h> + +static inline dma_addr_t +dma_map_single(struct device *dev, void *cpu_addr, size_t size, + enum dma_data_direction dir) +{ + BUG(); + return 0; +} + +static inline dma_addr_t +dma_map_page(struct device *dev, struct page *page, + unsigned long offset, size_t size, + enum dma_data_direction dir) +{ + BUG(); + return 0; +} + +static inline void +dma_unmap_single(struct device *dev, dma_addr_t handle, size_t size, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline void +dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline int +dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, + enum dma_data_direction dir) +{ + BUG(); + return 0; +} + +static inline void +dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline void +dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle, size_t size, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline void +dma_sync_single_for_device(struct device *dev, dma_addr_t handle, size_t size, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline void +dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents, + enum dma_data_direction dir) +{ + BUG(); +} + +static inline void +dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents, + enum dma_data_direction dir) +{ + BUG(); +} #endif /* _ASM_DMA_MAPPING_H */ ^ permalink raw reply related [flat|nested] 11+ messages in thread
* RE: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-23 0:25 ` Williams, Dan J @ 2007-05-23 8:05 ` Martin Schwidefsky 2007-05-23 8:46 ` Cornelia Huck 0 siblings, 1 reply; 11+ messages in thread From: Martin Schwidefsky @ 2007-05-23 8:05 UTC (permalink / raw) To: Williams, Dan J Cc: Cornelia Huck, Andrew Morton, linux-kernel, NeilBrown, linux-s390 On Tue, 2007-05-22 at 17:25 -0700, Williams, Dan J wrote: > The approach I have taken is to add the missing definitions to > include/asm-s390/dma-mapping.h [ a non-outlook-mangled version of the > patch is pushed out in my rebased git tree ]. I was not able to fully > compile-test this change as the three s390-cross-toolchains I tried > each We are trying to get rid of dma-mapping.h, see the last change to the file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't think we should reintroduce dma related definition but split the async_tx in a way that allows to compile it on an architecture with CONFIG_NO_DMA=y (yes I know that is harder that to just add the dma stubs). You've said that there is a software implementation if there is no dma engine present. This software implementation should be independent of dma-mapping.h. Without having looked at the code, isn't it possible to isolate that software implementation into its own C file? That would be the only one that gets compiled for s390. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-23 8:05 ` Martin Schwidefsky @ 2007-05-23 8:46 ` Cornelia Huck 2007-05-23 8:55 ` Martin Schwidefsky 2007-05-24 22:11 ` Williams, Dan J 0 siblings, 2 replies; 11+ messages in thread From: Cornelia Huck @ 2007-05-23 8:46 UTC (permalink / raw) To: schwidefsky Cc: Williams, Dan J, Andrew Morton, linux-kernel, NeilBrown, linux-s390 On Wed, 23 May 2007 10:05:39 +0200, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: > We are trying to get rid of dma-mapping.h, see the last change to the > file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't think > we should reintroduce dma related definition but split the async_tx in a > way that allows to compile it on an architecture with CONFIG_NO_DMA=y > (yes I know that is harder that to just add the dma stubs). > You've said that there is a software implementation if there is no dma > engine present. This software implementation should be independent of > dma-mapping.h. Without having looked at the code, isn't it possible to > isolate that software implementation into its own C file? That would be > the only one that gets compiled for s390. Taking a quick look at the async_*.c stuff, the functions in question basically seem to be of the form check_if_we_can_do_it_async(); if (async_ok) { /* do async stuff */ /* that's where the dma mapping creeps in */ } else { /* do it sync */ /* seems fine for us */ } So you should be able to factor out (say) async_memset_{sync,async}() and put it into async_memset_{sync,async}.c. async_memset() would then be async_memset() { #if CONFIG_HAS_DMA if (check_if_we_can_do_at_async()) async_memset_async(); #endif return async_memset_sync(); } Kconfig could then do config ASYNC_MEMSET default m tristate "async_memset support" select ASYNC_MEMSET_ASYNC if HAS_DMA config ASYNC_MEMSET_ASYNC depends on HAS_DMA tristate "async_memset async via dma support" Thoughts? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-23 8:46 ` Cornelia Huck @ 2007-05-23 8:55 ` Martin Schwidefsky 2007-05-24 22:11 ` Williams, Dan J 1 sibling, 0 replies; 11+ messages in thread From: Martin Schwidefsky @ 2007-05-23 8:55 UTC (permalink / raw) To: Cornelia Huck Cc: Williams, Dan J, Andrew Morton, linux-kernel, NeilBrown, linux-s390 On Wed, 2007-05-23 at 10:46 +0200, Cornelia Huck wrote: > Taking a quick look at the async_*.c stuff, the functions in question > basically seem to be of the form > > check_if_we_can_do_it_async(); > if (async_ok) { > /* do async stuff */ > /* that's where the dma mapping creeps in */ > } else { > /* do it sync */ > /* seems fine for us */ > } Hmm, on what does the async_ok depend? Is that a runtime check that is done once or is it something more complicated like the availability of a dma slot? If it is a simple runtime check then there should be a operations structure that has indirect function pointers for the different async_memset_{sync,async}() functions. Instead of doing the async_ok check just call the function. That would save an if as well. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-23 8:46 ` Cornelia Huck 2007-05-23 8:55 ` Martin Schwidefsky @ 2007-05-24 22:11 ` Williams, Dan J 2007-05-25 6:02 ` Cornelia Huck 1 sibling, 1 reply; 11+ messages in thread From: Williams, Dan J @ 2007-05-24 22:11 UTC (permalink / raw) To: Cornelia Huck, schwidefsky Cc: Andrew Morton, linux-kernel, NeilBrown, linux-s390 > From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com] > On Wed, 23 May 2007 10:05:39 +0200, > Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: > > > We are trying to get rid of dma-mapping.h, see the last change to the > > file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't think > > we should reintroduce dma related definition but split the async_tx in a > > way that allows to compile it on an architecture with CONFIG_NO_DMA=y > > (yes I know that is harder that to just add the dma stubs). Not harder, it just a question of which is "uglier", but given the direction taken with CONFIG_HAS_DMA it now appears more appropriate to change async_tx. > > You've said that there is a software implementation if there is no dma > > engine present. This software implementation should be independent of > > dma-mapping.h. Without having looked at the code, isn't it possible to > > isolate that software implementation into its own C file? That would be > > the only one that gets compiled for s390. > > Taking a quick look at the async_*.c stuff, the functions in question > basically seem to be of the form > > check_if_we_can_do_it_async(); > if (async_ok) { > /* do async stuff */ > /* that's where the dma mapping creeps in */ > } else { > /* do it sync */ > /* seems fine for us */ > } > > So you should be able to factor out (say) async_memset_{sync,async}() > and put it into async_memset_{sync,async}.c. async_memset() would then > be > > async_memset() > { > #if CONFIG_HAS_DMA > if (check_if_we_can_do_at_async()) > async_memset_async(); > #endif > return async_memset_sync(); > } > > Kconfig could then do > > config ASYNC_MEMSET > default m > tristate "async_memset support" > select ASYNC_MEMSET_ASYNC if HAS_DMA > > config ASYNC_MEMSET_ASYNC > depends on HAS_DMA > tristate "async_memset async via dma support" > > Thoughts? I took your approach of encasing the HAS_DMA dependent portion of the code in #ifdef CONFIG_HAS_DMA, and I dropped the dma-mapping-stub patch. I let the compiler do the factoring out for me by making async_tx_find_channel become the following when CONFIG_DMA_ENGINE=n: static inline struct dma_chan * async_tx_find_channel(struct dma_async_tx_descriptor *depend_tx, enum dma_transaction_type tx_type) { return NULL; } --- diff --git a/async_tx/async_memcpy.c b/async_tx/async_memcpy.c index 7896ba8..547976e 100644 --- a/async_tx/async_memcpy.c +++ b/async_tx/async_memcpy.c @@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset, int_en) : NULL; if (tx) { /* run the memcpy asynchronously */ + #ifdef CONFIG_HAS_DMA dma_addr_t dma_addr; enum dma_data_direction dir; @@ -75,6 +76,9 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset, async_tx_submit(chan, tx, flags, depend_tx, callback, callback_param); + #else + BUG(); + #endif /* CONFIG_HAS_DMA */ } else { /* run the memcpy synchronously */ void *dest_buf, *src_buf; pr_debug("%s: (sync) len: %zu\n", __FUNCTION__, len); diff --git a/async_tx/async_memset.c b/async_tx/async_memset.c index 736c7c2..9166a27 100644 --- a/async_tx/async_memset.c +++ b/async_tx/async_memset.c @@ -55,6 +55,7 @@ async_memset(struct page *dest, int val, unsigned int offset, int_en) : NULL; if (tx) { /* run the memset asynchronously */ + #ifdef CONFIG_HAS_DMA dma_addr_t dma_addr; enum dma_data_direction dir; @@ -67,6 +68,9 @@ async_memset(struct page *dest, int val, unsigned int offset, async_tx_submit(chan, tx, flags, depend_tx, callback, callback_param); + #else + BUG(); + #endif /* CONFIG_HAS_DMA */ } else { /* run the memset synchronously */ void *dest_buf; pr_debug("%s: (sync) len: %zu\n", __FUNCTION__, len); diff --git a/async_tx/async_xor.c b/async_tx/async_xor.c index 37ae5fc..5e4bc29 100644 --- a/async_tx/async_xor.c +++ b/async_tx/async_xor.c @@ -31,6 +31,7 @@ #include <linux/raid/xor.h> #include <linux/async_tx.h> +#ifdef CONFIG_HAS_DMA static void do_async_xor(struct dma_async_tx_descriptor *tx, struct dma_device *device, struct dma_chan *chan, struct page *dest, struct page **src_list, @@ -62,6 +63,17 @@ do_async_xor(struct dma_async_tx_descriptor *tx, struct dma_device *device, async_tx_submit(chan, tx, flags, depend_tx, callback, callback_param); } +#else +static void +do_async_xor(struct dma_async_tx_descriptor *tx, struct dma_device *device, + struct dma_chan *chan, struct page *dest, struct page **src_list, + unsigned int offset, unsigned int src_cnt, size_t len, + enum async_tx_flags flags, struct dma_async_tx_descriptor *depend_tx, + dma_async_tx_callback callback, void *callback_param) +{ + BUG(); +} +#endif /* CONFIG_HAS_DMA */ static void do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset, @@ -265,6 +277,7 @@ async_xor_zero_sum(struct page *dest, struct page **src_list, BUG_ON(src_cnt <= 1); if (tx) { + #ifdef CONFIG_HAS_DMA dma_addr_t dma_addr; enum dma_data_direction dir; @@ -281,6 +294,9 @@ async_xor_zero_sum(struct page *dest, struct page **src_list, async_tx_submit(chan, tx, flags, depend_tx, callback, callback_param); + #else + BUG(); + #endif /* CONFIG_HAS_DMA */ } else { unsigned long xor_flags = flags; ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: 2.6.22-rc1-mm1 - s390 vs. md 2007-05-24 22:11 ` Williams, Dan J @ 2007-05-25 6:02 ` Cornelia Huck 0 siblings, 0 replies; 11+ messages in thread From: Cornelia Huck @ 2007-05-25 6:02 UTC (permalink / raw) To: Williams, Dan J Cc: schwidefsky, Andrew Morton, linux-kernel, NeilBrown, linux-s390 On Thu, 24 May 2007 15:11:08 -0700, "Williams, Dan J" <dan.j.williams@intel.com> wrote: > --- a/async_tx/async_memcpy.c > +++ b/async_tx/async_memcpy.c > @@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src, > unsigned int dest_offset, > int_en) : NULL; > > if (tx) { /* run the memcpy asynchronously */ > + #ifdef CONFIG_HAS_DMA > dma_addr_t dma_addr; > enum dma_data_direction dir; Can you factor out the async stuff into a function so you can use the #ifdefs to define different functions rather than put them in the middle of a complex function? (Maybe you should rather use #ifdef CONFIG_DMA_ENGINE, since the async part is not needed for !DMA_ENGINE either.) ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-05-25 6:02 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-05-17 6:36 2.6.22-rc1-mm1 - s390 vs. md Williams, Dan J 2007-05-18 5:39 ` Cornelia Huck 2007-05-18 16:30 ` Williams, Dan J 2007-05-21 7:24 ` Cornelia Huck 2007-05-21 8:52 ` Williams, Dan J 2007-05-23 0:25 ` Williams, Dan J 2007-05-23 8:05 ` Martin Schwidefsky 2007-05-23 8:46 ` Cornelia Huck 2007-05-23 8:55 ` Martin Schwidefsky 2007-05-24 22:11 ` Williams, Dan J 2007-05-25 6:02 ` Cornelia Huck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox