From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934713AbcCOMDj (ORCPT ); Tue, 15 Mar 2016 08:03:39 -0400 Received: from [210.118.77.11] ([210.118.77.11]:30662 "EHLO mailout1.w1.samsung.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S934440AbcCOMDa (ORCPT ); Tue, 15 Mar 2016 08:03:30 -0400 X-AuditID: cbfec7f4-f79026d00000418a-35-56e7f9fa6da6 Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture To: Magnus Damm References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com> Cc: iommu@lists.linux-foundation.org, "linux-arm-kernel@lists.infradead.org" , linux-kernel , Inki Dae , Krzysztof Kozlowski , Russell King - ARM Linux , Heiko Stuebner , Arnd Bergmann , Bartlomiej Zolnierkiewicz , Catalin Marinas , Joerg Roedel , Will Deacon , dri-devel@lists.freedesktop.org, Tomasz Figa , linaro-mm-sig@lists.linaro.org, Sakari Ailus , Laurent Pinchart , Mark Yao , Robin Murphy From: Marek Szyprowski Message-id: <56E7F9F8.6030203@samsung.com> Date: Tue, 15 Mar 2016 13:03:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02RbUhTYRiGe885OzuORqf50ZuBwUokQ3MR8fZBDhM6f4JAsZCsjvOg0qay qWR/FLTIKeZHls4yo2W6Rua0UsHmpmhimKJIYk5LZZrOzdSciqvmCvx3Pfdz3Tw/HgoXDRL+ VHJKOqdMYeViUkD0uXqGQzbWrTFhphWItkq7+aixooGH7LWFAA2v2kn0+/s8D5VOFBOoxngG 5Ve94aP5WQnKL9Hy0crwNwwZpkZ4aKjtMYnGhoRo8pWNRC0POjBkckzz0CdjPYmW77hINLf0 kZD6MNOmaozRV+sBk5dbSDKbG6WAqcoZJJhWzTifqbpXyWM6V58RzERBD8Y0abOZMdcUzpR9 eQmYLY2RYIqadYB5P1KNM8uGgEt0rOBsAidPzuSUx87dECQZh35gae3et7T360AOsO5RAy8K 0idgV8ca8LAfHLA0kGogoET0CwCd5lbgGawAPmr+iqkBRXnTcXCmOMtd8KGDoM5Q/s/pB1C3 ML7dxulaEs44cjG3RdISqLapSTcL6WBo+dXIdzNBB8Ll6dnt0770Vdiz2A88zl7oLLMQbvai o6DDNbqd4/RJuDLXyfPwQdikt+HFgNbsqGh2aJodWg3AdcCXy5ClqeITFZJQFatQZaQkhspS FQbgefRKC3jefdoMaAqIdwsr/K0xIh6bqcpSmAGkcLGP0O78GwkT2KzbnDL1ujJDzqnM4ABF iPcJn7TZo0V0IpvO3eS4NE75f4tRXv45IPL1RE9AOJd3cWLUFu8wtwUW1cf5bZqyQs5nTMrH Lh+V2g6nX9vqIrLRqfLjmrWlEHZ1f7zv1Bys4x96WmLYpf1gHKh7Gz4sPRLWdMGiD0pKFvzs Swguk32Wt0ffHRyLqn14pVehljpjhLGV2R26AC5fFLGORb7rlS3kRxQsiglVEisJxpUq9g+z HdTV5AIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On 2016-03-15 12:18, Magnus Damm wrote: > Hi Marek, > > On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski > wrote: >> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation >> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The >> side-effect of this change is a switch from bitmap-based IO address space >> management to tree-based code. There should be no functional changes >> for drivers, which rely on initialization from generic arch_setup_dna_ops() >> interface. Code, which used old arm_iommu_* functions must be updated to >> new interface. >> >> Signed-off-by: Marek Szyprowski >> --- > Thanks for your efforts and my apologies for late comments. Just FYI > I'll try your patch (and this series) with the ipmmu-vmsa.c driver on > 32-bit ARM and see how it goes. Nice not to have to support multiple > interfaces depending on architecture! Thanks for testing! > One question that comes to mind is how to handle features. > > For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS > while the shared code in drivers/iommu/dma-iommu.c does not. I assume > existing users may rely on such features so from my point of view it > probably makes sense to carry over features from the 32-bit ARM code > into the shared code before pulling the plug. Right, this has to be added to common code before merging. > I also wonder if it is possible to do a step-by-step migration and > support both old and new interfaces in the same binary? That may make > things easier for multiplatform enablement. So far I've managed to > make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some > ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with > the shared code in drivers/iommu/dma-iommu.c may also be possible. And > probably involving even more ugly magic. =) Having one IOMMU driver for both 32-bit and 64-bit ARM archs is quite easy IF you rely on the iommu core to setup everything. See exynos-iommu driver - after my last patches it now works fine on both archs (using arch specific interfaces). Most of the magic is done automatically by arch_setup_dma_ops(). The real problem is the fact that there are drivers (like DRM) which rely on specific dma-mapping functions from ARM architecture, which need to be rewritten. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture Date: Tue, 15 Mar 2016 13:03:04 +0100 Message-ID: <56E7F9F8.6030203@samsung.com> References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-reply-to: 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: Magnus Damm Cc: linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, Krzysztof Kozlowski , Russell King - ARM Linux , Heiko Stuebner , Arnd Bergmann , Bartlomiej Zolnierkiewicz , Catalin Marinas , Will Deacon , linux-kernel , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Inki Dae , 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 Hello, On 2016-03-15 12:18, Magnus Damm wrote: > Hi Marek, > > On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski > wrote: >> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation >> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The >> side-effect of this change is a switch from bitmap-based IO address space >> management to tree-based code. There should be no functional changes >> for drivers, which rely on initialization from generic arch_setup_dna_ops() >> interface. Code, which used old arm_iommu_* functions must be updated to >> new interface. >> >> Signed-off-by: Marek Szyprowski >> --- > Thanks for your efforts and my apologies for late comments. Just FYI > I'll try your patch (and this series) with the ipmmu-vmsa.c driver on > 32-bit ARM and see how it goes. Nice not to have to support multiple > interfaces depending on architecture! Thanks for testing! > One question that comes to mind is how to handle features. > > For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS > while the shared code in drivers/iommu/dma-iommu.c does not. I assume > existing users may rely on such features so from my point of view it > probably makes sense to carry over features from the 32-bit ARM code > into the shared code before pulling the plug. Right, this has to be added to common code before merging. > I also wonder if it is possible to do a step-by-step migration and > support both old and new interfaces in the same binary? That may make > things easier for multiplatform enablement. So far I've managed to > make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some > ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with > the shared code in drivers/iommu/dma-iommu.c may also be possible. And > probably involving even more ugly magic. =) Having one IOMMU driver for both 32-bit and 64-bit ARM archs is quite easy IF you rely on the iommu core to setup everything. See exynos-iommu driver - after my last patches it now works fine on both archs (using arch specific interfaces). Most of the magic is done automatically by arch_setup_dma_ops(). The real problem is the fact that there are drivers (like DRM) which rely on specific dma-mapping functions from ARM architecture, which need to be rewritten. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Tue, 15 Mar 2016 13:03:04 +0100 Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture In-Reply-To: References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com> Message-ID: <56E7F9F8.6030203@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On 2016-03-15 12:18, Magnus Damm wrote: > Hi Marek, > > On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski > wrote: >> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation >> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The >> side-effect of this change is a switch from bitmap-based IO address space >> management to tree-based code. There should be no functional changes >> for drivers, which rely on initialization from generic arch_setup_dna_ops() >> interface. Code, which used old arm_iommu_* functions must be updated to >> new interface. >> >> Signed-off-by: Marek Szyprowski >> --- > Thanks for your efforts and my apologies for late comments. Just FYI > I'll try your patch (and this series) with the ipmmu-vmsa.c driver on > 32-bit ARM and see how it goes. Nice not to have to support multiple > interfaces depending on architecture! Thanks for testing! > One question that comes to mind is how to handle features. > > For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS > while the shared code in drivers/iommu/dma-iommu.c does not. I assume > existing users may rely on such features so from my point of view it > probably makes sense to carry over features from the 32-bit ARM code > into the shared code before pulling the plug. Right, this has to be added to common code before merging. > I also wonder if it is possible to do a step-by-step migration and > support both old and new interfaces in the same binary? That may make > things easier for multiplatform enablement. So far I've managed to > make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some > ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with > the shared code in drivers/iommu/dma-iommu.c may also be possible. And > probably involving even more ugly magic. =) Having one IOMMU driver for both 32-bit and 64-bit ARM archs is quite easy IF you rely on the iommu core to setup everything. See exynos-iommu driver - after my last patches it now works fine on both archs (using arch specific interfaces). Most of the magic is done automatically by arch_setup_dma_ops(). The real problem is the fact that there are drivers (like DRM) which rely on specific dma-mapping functions from ARM architecture, which need to be rewritten. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland