Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2186057imu; Thu, 17 Jan 2019 09:45:29 -0800 (PST) X-Google-Smtp-Source: ALg8bN46HhCBuTtlGpXfuo2+eSYoOV/pTPdrxStZrfIV3UBZNKuxExSXl+9e7rqTYetjz18nm8VC X-Received: by 2002:a63:c303:: with SMTP id c3mr13148874pgd.268.1547747129104; Thu, 17 Jan 2019 09:45:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547747129; cv=none; d=google.com; s=arc-20160816; b=xYRX/hiYIz8O4uEpxutVRT0HYe/8M5Q4hxZ1d3HuzOXWEyaZxjvVzg7o0B1n4AamkX tIVQApeala/Ffo7z9ptYfAb2D7dN6RjIDBVmR8A/Qs/cac0pDP90KGi0OM33PBca5/tY M1Y+/tOGsOgu8cpcDUTwHrq+Qh4pFTY+ci5rh/W/i3UPoy+cxxB4FR7Dn4Whtv4ekuHW 6F2DWYMFBGMUzb8RtTMRTOvIlPNX2Q83F0yCcSZKLqTf5+h5hh51WFg36mwvggJXypRv 3sA0MmqaXCgyBzuTjUNVYDyhPFRsml5AuXRYt4b6wcEYdMIgsHrS7pZ7wrGH/nVxRilN 91dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=75W+Ge6WzG/nZq+nVqveWuypKSZvraI6LILJzwqh4L0=; b=a/htmM9q3qNubERPEOiKNOw3/mtEPUjkWaoBlK1+9VOmj2+/DIBt9q/rrCC4sItIgO UjPPH/4gsRPm6x48M+LeFx2r9QyjJPeels6ygBuYULmL8qfA41uJPOi68pZBPxvm8YIU Aw2qWVpB5oDW/hf9GSIOQROJPVFRiDDRXyA4nGBRWeZP8yY7IRSvM75kbHaxmW+723y1 3OMDDKfMH4aNWb3HISU21WCuzeJ1UuJ3yOrRl1SZsV/WhHQ4AwGgMqWoZlsUmbENryVJ BEwyUsZt7oX7kRVsJWwWBzpRiT+taLrpTX0BFzqeBx1mnMZ3hsyo3RESzF3GaZ5hVGtx u/wA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p9si2261313pll.63.2019.01.17.09.45.13; Thu, 17 Jan 2019 09:45:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728184AbfAQRVy (ORCPT + 99 others); Thu, 17 Jan 2019 12:21:54 -0500 Received: from verein.lst.de ([213.95.11.211]:38650 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727226AbfAQRVy (ORCPT ); Thu, 17 Jan 2019 12:21:54 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 0146668CEB; Thu, 17 Jan 2019 18:21:52 +0100 (CET) Date: Thu, 17 Jan 2019 18:21:52 +0100 From: Christoph Hellwig To: Marek Szyprowski Cc: Christoph Hellwig , Pawel Osciak , Kyungmin Park , Niklas =?iso-8859-1?Q?S=F6derlund?= , Russell King , Mauro Carvalho Chehab , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource Message-ID: <20190117172152.GA32292@lst.de> References: <20190111181731.11782-1-hch@lst.de> <20190111181731.11782-4-hch@lst.de> <6f8892ac-c2aa-10df-c74f-ba032bf75160@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f8892ac-c2aa-10df-c74f-ba032bf75160@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote: > Hi Christoph, > > On 2019-01-11 19:17, Christoph Hellwig wrote: > > vb2_dc_get_userptr pokes into arm direct mapping details to get the > > resemblance of a dma address for a a physical address that does is > > not backed by a page struct. Not only is this not portable to other > > architectures with dma direct mapping offsets, but also not to uses > > of IOMMUs of any kind. Switch to the proper dma_map_resource / > > dma_unmap_resource interface instead. > > > > Signed-off-by: Christoph Hellwig > > There are checks for IOMMU presence in other places in vb2-dma-contig, > so it was used only when no IOMMU is available, but I agree that the > hacky code should be replaced by a generic code if possible. > > Tested-by: Marek Szyprowski > > V4L2 pipeline works fine on older Exynos-based boards with CMA and IOMMU > disabled. Do you know if these rely on the offsets? E.g. would they still work with the patch below applied on top. That would keep the map_resource semantics as-is as solve the issue pointed out by Robin for now. If not I can only think of a flag to bypass the offseting for now, but that would be pretty ugly. Or go for the long-term solution of discovering the relationship between the two devices, as done by the PCIe P2P code.. diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 8e0359b04957..25bd19974223 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -359,7 +359,7 @@ EXPORT_SYMBOL(dma_direct_map_sg); dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - dma_addr_t dma_addr = phys_to_dma(dev, paddr); + dma_addr_t dma_addr = paddr; if (unlikely(!dma_direct_possible(dev, dma_addr, size))) { report_addr(dev, dma_addr, size);