Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3549767imu; Mon, 17 Dec 2018 23:41:04 -0800 (PST) X-Google-Smtp-Source: AFSGD/V+On+pl6vZZ79dUL0waiWcYGDb01ODgSLshVxE86Lnk+olSEDnPI6Jq3EcMgws+zW25ML2 X-Received: by 2002:a17:902:4225:: with SMTP id g34mr15928418pld.152.1545118864553; Mon, 17 Dec 2018 23:41:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545118864; cv=none; d=google.com; s=arc-20160816; b=tFLdn+CY4YzsrFyXkgzfcTMvzbnAIxzvkDSKeEpiNcnDNIRJu3kn9TsKf0lJzqio4j c03QDCh5qBrD2HBcI3IIFB2rxSWHUuKMroH3uvy3hYZoDg/g5I7ZQULDazsgHumX0QJG Z77HCIUYLhwWNfJ864YJHjiAVjLZyfIg01w4BHAra+tTnqmCGSuCZb0/gU6Ru8NMuQwv o35xZ86IEQ2/Y8H3xUzaZdh7i9YM7hpOFm10K2BwNvNlg3naJYyfAOCVEcMXBQhqFmUX odB3l9f+gGsf99wVhGrlU+M76WSrEQ1Z6VFBQp/Y+3HT4QS3AlUaI5Ag56dHsKDIXpoH aX9g== 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:dkim-signature; bh=WzeH3TUgsIdeLiBDUJctOAhNPrFwEjE+QueOyLQxYCA=; b=vffMKgMmaEpKsZTirjeNkd4KQC4QGSoma0gmkql8anYFJCHk9AYx3RgBojz7fxxnbA dU0oFgl+KtuweXYmPfnFoCjilCxgnK0IsvdSj6a1IFMpLRNSp/ORqeaQOSykxls40/ow DZ4yqTSTYGub/AxJL2u/M0W3jb8ye5GvsvmmkuI9xdpx7h/TliecjMnOugO7MiRR/ckc a3lenY6Ja52CH0kq+mpf+7KFA18bUyKN6LHg6RfFiW6FJpCWgNSPHmta7vB+NlqI0YUR tZBh7+WMUU68k7VMgYXQXBC49/Ju2NBINlmOS/0FPkQL0yGQANzn7XWr5RwjbNo6w60n c2eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=eTElaZPL; 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 d23si12899330pgj.558.2018.12.17.23.40.48; Mon, 17 Dec 2018 23:41:04 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=eTElaZPL; 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 S1726410AbeLRHi5 (ORCPT + 99 others); Tue, 18 Dec 2018 02:38:57 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34004 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726346AbeLRHi5 (ORCPT ); Tue, 18 Dec 2018 02:38:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WzeH3TUgsIdeLiBDUJctOAhNPrFwEjE+QueOyLQxYCA=; b=eTElaZPLrVJKh7nAcsbB19+hi okOtAo88127AYLlij5sJfivLV5Qm1pFzx21H7kEPs6nNwPIPjhrIi+ij3MQ6KiF5m8jhoT9W7dO/P O24o6fsY317KwhPDxmioC9e2q7fNWSIIizZFU0aYjLeieLSQBGPSzMhK8aDKOSph5mwZlWaAMyBaL 1wsavnj3gLgV9AgZca3bmIXsPYw+awCJv9MQpHgY+uxsAYu0EPuUvCA8U/1EeL8a8uuCNU3BFv+gM 4EVxTtFyJynyR9dh6+/MMlS/ApHxQCzbQqDp2CxvMDbP7r6R5a94RPjQCdBAuYsQGmuWWrDKs6wgi 7bft4M1HQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1gZ9xn-0002fj-Bx; Tue, 18 Dec 2018 07:38:47 +0000 Date: Mon, 17 Dec 2018 23:38:47 -0800 From: Christoph Hellwig To: Tomasz Figa Cc: Christoph Hellwig , Laurent Pinchart , "Matwey V. Kornilov" , Linux Media Mailing List , Linux Kernel Mailing List , "Matwey V. Kornilov" , Alan Stern , Ezequiel Garcia , hdegoede@redhat.com, Hans Verkuil , Mauro Carvalho Chehab , rostedt@goodmis.org, mingo@redhat.com, Mike Isely , Bhumika Goyal , Colin King , Kieran Bingham , keiichiw@chromium.org Subject: Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Message-ID: <20181218073847.GA4552@infradead.org> References: <20181207152502.GA30455@infradead.org> <20181212090917.GA30598@infradead.org> <20181212135440.GA6137@infradead.org> <20181213140329.GA25339@infradead.org> <20181214123624.GA5824@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 18, 2018 at 04:22:43PM +0900, Tomasz Figa wrote: > It kind of limits the usability of this API, since it enforces > contiguous allocations even for big sizes even for devices behind > IOMMU (contrary to the case when DMA_ATTR_NON_CONSISTENT is not set), > but given that it's just a temporary solution for devices like these > USB cameras, I guess that's fine. The problem is that you can't have flexibility and simplicity at the same time. Once you use kernel virtual address remapping you need to be prepared to have multiple segments. So as I said you can call dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT in a loop with a suitably small chunk size, then stuff the results into a scatterlist and map that again for the device share with if you don't want a single contigous region. You just have to either deal with non-contigous access from the kernel or use vmap and the right vmap cache flushing helpers. > Note that in V4L2 we use the DMA API extensively, so that we don't > need to embed any device-specific or integration-specific knowledge in > the framework. Right now we're using dma_alloc_attrs() with > driver-provided attrs [1], but current driver never request > non-consistent memory. We're however thinking about making it possible > to allocate non-consistent memory. What would you suggest for this? > > [1] https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/media/common/videobuf2/videobuf2-dma-contig.c#L139 I would advice against new non-consistent users until this series goes through, mostly because dma_cache_sync is such an amazing bad API. Otherwise things will just work at the allocation side, you'll just need to be careful to transfer ownership between the cpu and the device(s) carefully using the dma_sync_* APIs.