From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760789AbcBYOpq (ORCPT ); Thu, 25 Feb 2016 09:45:46 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:61269 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760202AbcBYOpp (ORCPT ); Thu, 25 Feb 2016 09:45:45 -0500 From: Arnd Bergmann To: Marek Szyprowski Cc: iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org, Will Deacon , Catalin Marinas , Robin Murphy , Russell King - ARM Linux , Joerg Roedel , Laurent Pinchart , Sakari Ailus , Mark Yao , Heiko Stuebner , Tomasz Figa , Inki Dae , Bartlomiej Zolnierkiewicz , Krzysztof Kozlowski Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture Date: Thu, 25 Feb 2016 15:44:44 +0100 Message-ID: <4895295.FP9RzJmAYS@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56CEF2E9.5040706@samsung.com> References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <2724572.qtPjgumFDJ@wuerfel> <56CEF2E9.5040706@samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Y2Bjl6gLHNo6ku/GJu2hGxIGRvefaG1ooi0dYGtrFM/Y/WWmxt9 5thAsVXSda+YOqAS8z+w9RwVISOjYXM9zIDp1e0vc/h/uf7zWDKtcXu8R6i2LMtJGiwnxZv wjgnKgdbelGH38GjOPZrsSKyBMy9nUY0C5HaU+HMYQ8If7lzDMfZLiCmDT5K0aWML+3ds4T YLnStyOBmtdu82NmYPpHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:6U7RV54vqiY=:q1NgIJcZZ/WI2aL47VxnPw +NXm8Yb1k9IsSmIRxPH1cA8umUThIz61Jknew1XRfie6GdvuLwnfMfyJh3Vl8hRpuOFvKY+Co /cCigO4Ix4wXw0Wl2rZ+qUFaP2JWMh3WGVXd4VZBaWoV7r2qfZlnufhZL1XXZ4LEW06Hup+9M xsFWqG1RK22RO336rqN0M7opwE5K8mEWimMHt1Hqp08MozsCb9+tGh3ZlhGjQd6gvfNT3ZTEp VMVip24nLkIclkm4Wr7Sjg/8Yr+VXJzb/NdU/miH3Zd+Eo1tlfqS8Ar8zue+VDUYZKk7N1z9d AkeX2KhGmxh3eoigKJi7IsNGeP4ziDeMPPNxofgyJkN3KTEGZw0b0zsvqWOIMspU0y9Dczh2z WT4SXvnI50RHM8FilBT08ChACcvTJyHDlvXLzV0nALhhtIAQgl0etXG1eLnjc0pKwCP7g9R2E azM82QcibED64ftSll3/1l4zF99n9N5KuuljMKQ4Yqa27vw2n+V+xt7Pf3w8khXJOTK1tGtHH Hqj4q1syngffaHEBgF/EWEAOfOgVKB2hzEdamKttfFUCrs4LjmU5eIHYqvbqXlwAa2yh6cKUO JDV29/b1+CeXFt55QQ2YoIcqDx+CkvdGfk3zrLRMC4g0qnxf/5ety0zHZ1pOB1Kn4UZ71WHsL Xw6umZX51N8lCCw2whB9xaOvJGaBWD67YWzDiGvT38jEaqgf2HC0trCulvK9XqIG1gdod/TJe tw9q4L6uutsPwSU2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote: > >> +} > >> + > >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page, > >> + gfp_t flags); > >> +extern bool arch_in_atomic_pool(void *start, size_t size); > >> +extern int arch_free_from_atomic_pool(void *start, size_t size); > >> + > >> + > > doesn't feel completely right yet. In particular the arch_flush_page() > > interface is probably still too specific to ARM/ARM64 and won't work > > that way on other architectures. > > > > I think it would be better to do this either more generic, or less generic: > > > > a) leave the iommu_dma_map_ops definition in the architecture specific > > code, but make it call helper functions in the drivers/iommu to do all > > of the really generic parts. > > > > b) clarify that this is only applicable to arch/arm and arch/arm64, and > > unify things further between these two, as they have very similar > > requirements in the CPU architecture. > > Some really generic parts are already in iommu/dma-iommu.c and one can build > it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I > also wanted to use that generic code on both ARM and ARM64, but it > turned out > that both archs, ARM and ARM64 will duplicate 99% of code, which use this > 'generic' functions. This was the reason why I dedided to move all that > common code from arch/{arm,arm64}/mm/dma-mapping.c to > drivers/iommu/dma-iommu-ops.c > > I'm not sure if I can design all the changes that need to be made to > drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will > try to use that code with other, non-ARM architecture based arch glue code, > a better abstraction can be developed. For now I would like to keep all this > code in a common place so both arm and arm64 will benefit from improvements > done there. Fair enough. Let's stay with your approach then. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture Date: Thu, 25 Feb 2016 15:44:44 +0100 Message-ID: <4895295.FP9RzJmAYS@wuerfel> References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <2724572.qtPjgumFDJ@wuerfel> <56CEF2E9.5040706@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56CEF2E9.5040706-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Marek Szyprowski Cc: Inki Dae , Krzysztof Kozlowski , Russell King - ARM Linux , Heiko Stuebner , Bartlomiej Zolnierkiewicz , Catalin Marinas , Will Deacon , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Sakari Ailus , Laurent Pinchart , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Mark Yao List-Id: iommu@lists.linux-foundation.org On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote: > >> +} > >> + > >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page, > >> + gfp_t flags); > >> +extern bool arch_in_atomic_pool(void *start, size_t size); > >> +extern int arch_free_from_atomic_pool(void *start, size_t size); > >> + > >> + > > doesn't feel completely right yet. In particular the arch_flush_page() > > interface is probably still too specific to ARM/ARM64 and won't work > > that way on other architectures. > > > > I think it would be better to do this either more generic, or less generic: > > > > a) leave the iommu_dma_map_ops definition in the architecture specific > > code, but make it call helper functions in the drivers/iommu to do all > > of the really generic parts. > > > > b) clarify that this is only applicable to arch/arm and arch/arm64, and > > unify things further between these two, as they have very similar > > requirements in the CPU architecture. > > Some really generic parts are already in iommu/dma-iommu.c and one can build > it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I > also wanted to use that generic code on both ARM and ARM64, but it > turned out > that both archs, ARM and ARM64 will duplicate 99% of code, which use this > 'generic' functions. This was the reason why I dedided to move all that > common code from arch/{arm,arm64}/mm/dma-mapping.c to > drivers/iommu/dma-iommu-ops.c > > I'm not sure if I can design all the changes that need to be made to > drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will > try to use that code with other, non-ARM architecture based arch glue code, > a better abstraction can be developed. For now I would like to keep all this > code in a common place so both arm and arm64 will benefit from improvements > done there. Fair enough. Let's stay with your approach then. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 25 Feb 2016 15:44:44 +0100 Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture In-Reply-To: <56CEF2E9.5040706@samsung.com> References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <2724572.qtPjgumFDJ@wuerfel> <56CEF2E9.5040706@samsung.com> Message-ID: <4895295.FP9RzJmAYS@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote: > >> +} > >> + > >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page, > >> + gfp_t flags); > >> +extern bool arch_in_atomic_pool(void *start, size_t size); > >> +extern int arch_free_from_atomic_pool(void *start, size_t size); > >> + > >> + > > doesn't feel completely right yet. In particular the arch_flush_page() > > interface is probably still too specific to ARM/ARM64 and won't work > > that way on other architectures. > > > > I think it would be better to do this either more generic, or less generic: > > > > a) leave the iommu_dma_map_ops definition in the architecture specific > > code, but make it call helper functions in the drivers/iommu to do all > > of the really generic parts. > > > > b) clarify that this is only applicable to arch/arm and arch/arm64, and > > unify things further between these two, as they have very similar > > requirements in the CPU architecture. > > Some really generic parts are already in iommu/dma-iommu.c and one can build > it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I > also wanted to use that generic code on both ARM and ARM64, but it > turned out > that both archs, ARM and ARM64 will duplicate 99% of code, which use this > 'generic' functions. This was the reason why I dedided to move all that > common code from arch/{arm,arm64}/mm/dma-mapping.c to > drivers/iommu/dma-iommu-ops.c > > I'm not sure if I can design all the changes that need to be made to > drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will > try to use that code with other, non-ARM architecture based arch glue code, > a better abstraction can be developed. For now I would like to keep all this > code in a common place so both arm and arm64 will benefit from improvements > done there. Fair enough. Let's stay with your approach then. Arnd