Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751887AbdGFOHW (ORCPT ); Thu, 6 Jul 2017 10:07:22 -0400 Received: from mail-yw0-f170.google.com ([209.85.161.170]:35533 "EHLO mail-yw0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbdGFOHU (ORCPT ); Thu, 6 Jul 2017 10:07:20 -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 23:06:56 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols To: Arnd Bergmann , Sakari Ailus 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 , 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: 1795 Lines: 38 On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote: > On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote: >> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote: > >>> 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) > > I don't understand what this means here. The PCI on x86 is always > cache-coherent, so why is the device not? > > Do you mean that the device has its own caches that may need > flushing to make the device cache coherent with the CPU cache, > rather than flushing the CPU caches? Sakari might be able to explain this with more technical details, but generally the device is not a standard PCI device one might find on existing x86 systems. It is some kind of embedded subsystem that behaves mostly like a PCI device, with certain exceptions, one being the lack of coherency with CPU caches, at least for certain parts of the subsystem. The reference vendor code disables the coherency completely, for reasons not known to me, but AFAICT this is the preferred operating mode, possibly due to performance effects (this is a memory-heavy image processing subsystem). Best regards, Tomasz