From patchwork Wed Jan 14 09:00:24 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Courbot X-Patchwork-Id: 5629361 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9D6CFC058D for ; Wed, 14 Jan 2015 09:03:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C508E20120 for ; Wed, 14 Jan 2015 09:03:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B4A3820256 for ; Wed, 14 Jan 2015 09:03:15 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YBJpQ-00021W-Cb; Wed, 14 Jan 2015 09:01:28 +0000 Received: from hqemgate16.nvidia.com ([216.228.121.65]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1YBJpI-0001w8-A6 for linux-arm-kernel@lists.infradead.org; Wed, 14 Jan 2015 09:01:21 +0000 Received: from hqnvupgp07.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com id ; Wed, 14 Jan 2015 01:01:34 -0800 Received: from HQMAIL106.nvidia.com ([172.20.12.94]) by hqnvupgp07.nvidia.com (PGP Universal service); Wed, 14 Jan 2015 00:52:43 -0800 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 14 Jan 2015 00:52:43 -0800 Received: from DRHKMAIL102.nvidia.com (10.25.59.16) by HQMAIL106.nvidia.com (172.18.146.12) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 14 Jan 2015 09:00:58 +0000 Received: from [10.19.57.128] (10.19.57.128) by drhkmail102.nvidia.com (10.25.59.16) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 14 Jan 2015 09:00:46 +0000 Message-ID: <54B63028.3090701@nvidia.com> Date: Wed, 14 Jan 2015 18:00:24 +0900 From: Alexandre Courbot Organization: NVIDIA User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Will Deacon , , , Subject: Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops References: <1417453034-21379-1-git-send-email-will.deacon@arm.com> <1417453034-21379-9-git-send-email-will.deacon@arm.com> In-Reply-To: <1417453034-21379-9-git-send-email-will.deacon@arm.com> X-NVConfidentiality: public X-Originating-IP: [10.19.57.128] X-ClientProxiedBy: HKMAIL104.nvidia.com (10.18.16.13) To drhkmail102.nvidia.com (10.25.59.16) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150114_010120_439155_D2CB729F X-CRM114-Status: GOOD ( 18.65 ) X-Spam-Score: -5.0 (-----) Cc: jroedel@suse.de, Heiko Stuebner , thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com, Varun.Sethi@freescale.com, hdoyu@nvidia.com, dwmw2@infradead.org, m.szyprowski@samsung.com X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 12/02/2014 01:57 AM, Will Deacon wrote: > This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't > actually called outside of a few drivers) into arch_setup_dma_ops, so > that we can use IOMMUs for DMA transfers in a more generic fashion. > > Since this significantly complicates the arch_setup_dma_ops function, > it is moved out of line into dma-mapping.c. If CONFIG_ARM_DMA_USE_IOMMU > is not set, the iommu parameter is ignored and the normal ops are used > instead. A series for IOMMU support with Tegra/Nouveau ceased to work after this patch. The Tegra IOMMU is not registered by the time the DT is parsed, and thus all devices end up without the proper DMA ops set up because the phandle to the IOMMU cannot be resolved. Subsequently calling arm_iommu_create_mapping() and arm_iommu_attach_device() from the driver (as I used to do until 3.18) does not help since the call to set_dma_ops() has been moved out of arm_iommu_attach_device(). Therefore there seems to be no way for a device to gets its correct DMA ops unless the IOMMU is ready by the time the DT is parsed. Also potentially affected by this are the Rockchip DRM and OMAP3 ISP drivers, which follow the same pattern. This raises the following questions: 1) Why are arm_iommu_create_mapping() and arm_iommu_attach_device() still public since they cannot set the DMA ops and thus seem to be useless outside of arch_setup_dma_ops()? 2) Say you want to use the IOMMU API in your driver, and have an iommu property in your device's DT node. If by chance your IOMMU is registered early, you will already have a mapping automatically created even before your probe function is called. Can this be avoided? Is it even safe? The issue is workarounded (at least for me) with the following patch: return 0; This allows arm_iommu_create_mapping() and arm_iommu_attach_device() to set the correct DMA ops when called from the driver. But it doesn't look like mergeable material and I'd like to know whether there is a better way to handle this, or whether I should just use the IOMMU API directly. Knowing that even this might not be safe if ARM_DMA_USE_IOMMU is enabled because of point 2) above. So basically I'm afraid I might not even be able to use the IOMMU safely after this. Or am I missing anything? Thanks, Alex. --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1961,6 +1961,7 @@ int arm_iommu_attach_device(struct device *dev, kref_get(&mapping->kref); dev->archdata.mapping = mapping; + set_dma_ops(dev, &iommu_ops); pr_debug("Attached IOMMU controller to %s device.\n", dev_name(dev));