Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752751AbdGFNt2 (ORCPT ); Thu, 6 Jul 2017 09:49:28 -0400 Received: from mail-yw0-f182.google.com ([209.85.161.182]:35065 "EHLO mail-yw0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752566AbdGFNt0 (ORCPT ); Thu, 6 Jul 2017 09:49:26 -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: Tomasz Figa Date: Thu, 6 Jul 2017 22:49:03 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols To: Arnd Bergmann 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 , Hans Verkuil , Sakari Ailus , Pawel Osciak , Laurent Pinchart , Linux Media Mailing List 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: 2493 Lines: 50 On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote: > On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote: >> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote: >>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote: >>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote: >>>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote: >> >>>> >>>> I'd say that this is something that has been consistently tried to be >>>> avoided by V4L2 and that's why it's so tightly integrated with DMA >>>> mapping. IMHO re-implementing the code that's already there in >>>> videobuf2 again in the driver, only because, for no good reason >>>> mentioned as for now, having a loadable module providing DMA ops was >>>> disliked. >>> >>> Sorry, I intended to mean: >>> >>> IMHO re-implementing the code that's already there in videobuf2 again >>> in the driver, only because, for no good reason mentioned as for now, >>> having a loadable module providing DMA ops was disliked, would make no >>> sense. >> >> Why would we need to duplicate that code? I would expect that the videobuf2 >> core can simply call the regular dma_mapping interfaces, and you handle the >> IOPTE generation at the point when the buffer is handed off from the core >> code to the device driver. Am I missing something? > > Well, for example, the iommu-dma helpers already implement all the > IOVA management, SG iterations, IOMMU API calls, sanity checks and so > on. There is a significant amount of common code. > > On the other hand, if it's strictly about base/dma-mapping, we might > not need it indeed. The driver could call iommu-dma helpers directly, > without the need to provide its own DMA ops. One caveat, though, we > are not able to obtain coherent (i.e. uncached) memory with this > approach, which might have some performance effects and complicates > the code, that would now need to flush caches even for some small > internal buffers. I think I should add a bit of explanation here: 1) the device is non-coherent with CPU caches, even on x86, 2) it looks like x86 does not have non-coherent DMA ops, (but it might be something that could be fixed) 3) one technically could still use __get_vm_area() and map_vm_area(), which _are_ exported, to create an uncached mapping. I'll leave it to you to judge if it would be better than using the already available generic helpers. Best regards, Tomasz