From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 3/8] ARM: dma-mapping: use asm-generic/dma-mapping-common.h Date: Mon, 27 Jun 2011 15:19:43 +0200 Message-ID: <201106271519.43581.arnd@arndb.de> References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <201106241736.43576.arnd@arndb.de> <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> Sender: owner-linux-mm@kvack.org To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, 'Kyungmin Park' , 'Joerg Roedel' , 'Russell King - ARM Linux' , Lennert Buytenhek List-Id: linux-arch.vger.kernel.org On Monday 27 June 2011, Marek Szyprowski wrote: > On Friday, June 24, 2011 5:37 PM Arnd Bergmann wrote: > > > On Monday 20 June 2011, Marek Szyprowski wrote: > > > This patch modifies dma-mapping implementation on ARM architecture to > > > use common dma_map_ops structure and asm-generic/dma-mapping-common.h > > > helpers. > > > > > > Signed-off-by: Marek Szyprowski > > > Signed-off-by: Kyungmin Park > > > > This is a good idea in general, but I have a few concerns about details: > > > > First of all, should we only allow using dma_map_ops on ARM, or do we > > also want to support a case where these are all inlined as before? > > I really wonder if it is possible to have a clean implementation of > dma_map_ops based and linear inlined dma-mapping framework together. > Theoretically it should be possible, but it will end with a lot of > #ifdef hackery which is really hard to follow and understand for > anyone but the authors. Right. It's probably not worth unless there is a significant overhead in terms of code size or performance in the coherent linear case. > > I suppose for the majority of the cases, the overhead of the indirect > > function call is near-zero, compared to the overhead of the cache > > management operation, so it would only make a difference for coherent > > systems without an IOMMU. Do we care about micro-optimizing those? > > Even in coherent case, the overhead caused by additional function call > should have really negligible impact on drivers performance. What about object code size? I guess since ixp23xx is the only platform that announces itself as coherent, we probably don't need to worry about it too much either. Lennert? On everything else, we only replace a direct functin call with an indirect one. > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > b/arch/arm/include/asm/dma-mapping.h > > > index 799669d..f4e4968 100644 > > > --- a/arch/arm/include/asm/dma-mapping.h > > > +++ b/arch/arm/include/asm/dma-mapping.h > > > @@ -10,6 +10,27 @@ > > > #include > > > #include > > > > > > +extern struct dma_map_ops dma_ops; > > > + > > > +static inline struct dma_map_ops *get_dma_ops(struct device *dev) > > > +{ > > > + if (dev->archdata.dma_ops) > > > + return dev->archdata.dma_ops; > > > + return &dma_ops; > > > +} > > > > I would not name the global structure just 'dma_ops', the identifier could > > too easily conflict with a local variable in some driver. How about > > arm_dma_ops or linear_dma_ops instead? > > I'm fine with both of them. Even arm_linear_dma_ops make some sense. Ok, just pick one then if nobody has a strong opinion either way. > > You should not need to make these symbols visible in the header file any > > more unless they are used outside of the main file later. > > They are used by the dma bounce code once converted to dma_map_ops framework. Ok, I see. Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.126.171]:56214 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759847Ab1F0NUI (ORCPT ); Mon, 27 Jun 2011 09:20:08 -0400 From: Arnd Bergmann Subject: Re: [PATCH 3/8] ARM: dma-mapping: use asm-generic/dma-mapping-common.h Date: Mon, 27 Jun 2011 15:19:43 +0200 References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <201106241736.43576.arnd@arndb.de> <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> In-Reply-To: <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <201106271519.43581.arnd@arndb.de> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, 'Kyungmin Park' , 'Joerg Roedel' , 'Russell King - ARM Linux' , Lennert Buytenhek Message-ID: <20110627131943.IBrbQgLX_BMDQdm9RgHIZba_HSCZGNvdIGri0CTCM68@z> On Monday 27 June 2011, Marek Szyprowski wrote: > On Friday, June 24, 2011 5:37 PM Arnd Bergmann wrote: > > > On Monday 20 June 2011, Marek Szyprowski wrote: > > > This patch modifies dma-mapping implementation on ARM architecture to > > > use common dma_map_ops structure and asm-generic/dma-mapping-common.h > > > helpers. > > > > > > Signed-off-by: Marek Szyprowski > > > Signed-off-by: Kyungmin Park > > > > This is a good idea in general, but I have a few concerns about details: > > > > First of all, should we only allow using dma_map_ops on ARM, or do we > > also want to support a case where these are all inlined as before? > > I really wonder if it is possible to have a clean implementation of > dma_map_ops based and linear inlined dma-mapping framework together. > Theoretically it should be possible, but it will end with a lot of > #ifdef hackery which is really hard to follow and understand for > anyone but the authors. Right. It's probably not worth unless there is a significant overhead in terms of code size or performance in the coherent linear case. > > I suppose for the majority of the cases, the overhead of the indirect > > function call is near-zero, compared to the overhead of the cache > > management operation, so it would only make a difference for coherent > > systems without an IOMMU. Do we care about micro-optimizing those? > > Even in coherent case, the overhead caused by additional function call > should have really negligible impact on drivers performance. What about object code size? I guess since ixp23xx is the only platform that announces itself as coherent, we probably don't need to worry about it too much either. Lennert? On everything else, we only replace a direct functin call with an indirect one. > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > b/arch/arm/include/asm/dma-mapping.h > > > index 799669d..f4e4968 100644 > > > --- a/arch/arm/include/asm/dma-mapping.h > > > +++ b/arch/arm/include/asm/dma-mapping.h > > > @@ -10,6 +10,27 @@ > > > #include > > > #include > > > > > > +extern struct dma_map_ops dma_ops; > > > + > > > +static inline struct dma_map_ops *get_dma_ops(struct device *dev) > > > +{ > > > + if (dev->archdata.dma_ops) > > > + return dev->archdata.dma_ops; > > > + return &dma_ops; > > > +} > > > > I would not name the global structure just 'dma_ops', the identifier could > > too easily conflict with a local variable in some driver. How about > > arm_dma_ops or linear_dma_ops instead? > > I'm fine with both of them. Even arm_linear_dma_ops make some sense. Ok, just pick one then if nobody has a strong opinion either way. > > You should not need to make these symbols visible in the header file any > > more unless they are used outside of the main file later. > > They are used by the dma bounce code once converted to dma_map_ops framework. Ok, I see. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 27 Jun 2011 15:19:43 +0200 Subject: [PATCH 3/8] ARM: dma-mapping: use asm-generic/dma-mapping-common.h In-Reply-To: <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <201106241736.43576.arnd@arndb.de> <000601cc34c4$430f91f0$c92eb5d0$%szyprowski@samsung.com> Message-ID: <201106271519.43581.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 27 June 2011, Marek Szyprowski wrote: > On Friday, June 24, 2011 5:37 PM Arnd Bergmann wrote: > > > On Monday 20 June 2011, Marek Szyprowski wrote: > > > This patch modifies dma-mapping implementation on ARM architecture to > > > use common dma_map_ops structure and asm-generic/dma-mapping-common.h > > > helpers. > > > > > > Signed-off-by: Marek Szyprowski > > > Signed-off-by: Kyungmin Park > > > > This is a good idea in general, but I have a few concerns about details: > > > > First of all, should we only allow using dma_map_ops on ARM, or do we > > also want to support a case where these are all inlined as before? > > I really wonder if it is possible to have a clean implementation of > dma_map_ops based and linear inlined dma-mapping framework together. > Theoretically it should be possible, but it will end with a lot of > #ifdef hackery which is really hard to follow and understand for > anyone but the authors. Right. It's probably not worth unless there is a significant overhead in terms of code size or performance in the coherent linear case. > > I suppose for the majority of the cases, the overhead of the indirect > > function call is near-zero, compared to the overhead of the cache > > management operation, so it would only make a difference for coherent > > systems without an IOMMU. Do we care about micro-optimizing those? > > Even in coherent case, the overhead caused by additional function call > should have really negligible impact on drivers performance. What about object code size? I guess since ixp23xx is the only platform that announces itself as coherent, we probably don't need to worry about it too much either. Lennert? On everything else, we only replace a direct functin call with an indirect one. > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > b/arch/arm/include/asm/dma-mapping.h > > > index 799669d..f4e4968 100644 > > > --- a/arch/arm/include/asm/dma-mapping.h > > > +++ b/arch/arm/include/asm/dma-mapping.h > > > @@ -10,6 +10,27 @@ > > > #include > > > #include > > > > > > +extern struct dma_map_ops dma_ops; > > > + > > > +static inline struct dma_map_ops *get_dma_ops(struct device *dev) > > > +{ > > > + if (dev->archdata.dma_ops) > > > + return dev->archdata.dma_ops; > > > + return &dma_ops; > > > +} > > > > I would not name the global structure just 'dma_ops', the identifier could > > too easily conflict with a local variable in some driver. How about > > arm_dma_ops or linear_dma_ops instead? > > I'm fine with both of them. Even arm_linear_dma_ops make some sense. Ok, just pick one then if nobody has a strong opinion either way. > > You should not need to make these symbols visible in the header file any > > more unless they are used outside of the main file later. > > They are used by the dma bounce code once converted to dma_map_ops framework. Ok, I see. Arnd