From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162AbcCOLST (ORCPT ); Tue, 15 Mar 2016 07:18:19 -0400 Received: from mail-vk0-f45.google.com ([209.85.213.45]:35655 "EHLO mail-vk0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755832AbcCOLSH (ORCPT ); Tue, 15 Mar 2016 07:18:07 -0400 MIME-Version: 1.0 In-Reply-To: <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com> References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com> <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com> Date: Tue, 15 Mar 2016 20:18:06 +0900 Message-ID: Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture From: Magnus Damm To: Marek Szyprowski 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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! 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. 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. =) Cheers, / magnus