Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751957AbdGFI0Z (ORCPT ); Thu, 6 Jul 2017 04:26:25 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33373 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbdGFI0V (ORCPT ); Thu, 6 Jul 2017 04:26:21 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705071215.17603-1-tfiga@chromium.org> <20170705071215.17603-2-tfiga@chromium.org> <20170705151728.GA2479@lst.de> <20170705172019.GB5246@lst.de> From: Arnd Bergmann Date: Thu, 6 Jul 2017 10:26:19 +0200 X-Google-Sender-Auth: D362BexIknaEBtsCx_dlKU4RX0k Message-ID: Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols To: Tomasz Figa Cc: Christoph Hellwig , "open list:IOMMU DRIVERS" , "linux-kernel@vger.kernel.org" , Marek Szyprowski , Robin Murphy , Greg Kroah-Hartman , Joerg Roedel , Will Deacon , Vineet Gupta , Hans-Christian Noren Egtvedt , Mitchel Humpherys , Krzysztof Kozlowski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2676 Lines: 57 On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote: > On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote: >> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote: >> In general I think moving dma >> ops and iommu implementations into modules is a bad idea > > Could you elaborate on this? I'd be interested in seeing the reasoning > behind this. > >> but I >> don't want to reject the idea before seeing the code. Or maybe >> by looking at the user we can come up with an even better idea >> to solve the original issue you're trying to solve, so please also >> explain your rationale. I had pretty much the same thoughts here. > Basically we have an x86 platform with a camera subsystem that is a > PCI device, has its own MMU and needs cache maintenance. Moreover, the > V4L2 subsystem, which is the right place for camera drivers, heavily > relies on DMA mapping as a way to abstract memory allocation, mapping > and cache maintenance. So it feels natural to me to hide the hardware > details (additional cache maintenance, mapping into the built-in > IOMMU) in the DMA mapping ops for this camera subsystem and simply > make V4L2 just work without knowing those details. I can understand your reasoning here, but I'm also not convinced that this is the best approach. There may be a middle ground somewhere though. Generally speaking I don't want to have to deal with the horrors of deciding whether an IOMMU is going to be there eventually or not at probe() time. At some point, we had decided that IOMMUs need to be initialized (almost) as early as irqchips and clocksources so we can rely on them to be there at device discovery time. That got pushed back already, and now we may have to deal with -EPROBE_DEFER when an IOMMU has not been fully initialized at device probe time, but at least we can reliably see if one is there or not. Making IOMMUs modular will add further uncertainty here. Obviously we cannot attach an IOMMU to a device once we have started using DMA mapping calls on it. For your particular use case, I would instead leave the knowledge about the IOMMU in the driver itself, like we do for the IOMMUs that are integrated in desktop GPUs, and have the code use the DMA mapping API with the system-provided dma_map_ops to get dma_addr_t tokens which you then program into the device IOMMU. An open question however would be whether to use the IOMMU API without the DMA mapping API here, or whether to completely leave the knowledge of the IOMMU inside of the driver itself. I don't have a strong opinion on that part, and I guess this mostly depends on what the hardware looks like. Arnd