Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3538239imu; Mon, 17 Dec 2018 23:24:51 -0800 (PST) X-Google-Smtp-Source: AFSGD/Wud+raheMowWXmVf2axvaq5uv9qz9dAwaJ9u5YEyrOCWqsL9qt9F23cvEcDOTCc5TajBfv X-Received: by 2002:a17:902:8c91:: with SMTP id t17mr14985089plo.119.1545117891718; Mon, 17 Dec 2018 23:24:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545117891; cv=none; d=google.com; s=arc-20160816; b=elrF7Qor/Co0jdtN7vLTKZbMq8nX0kBJhvACfS3gfQw5+plI8VM0I+xOSH09Wjzwgn BykLOGmNvHSSDupCNPBgnU8MgN9u5don3bcForai2HPFS1XzUUXVdFsq6jBLSuk/SHp5 gzeuJo62BUhqiSbyzkwn1GCp1xYnn8e4cMtobZlmFK3GrLljvWVBszOMUEWO/A+oDjjZ JCvYD3ubFUpPPdLwR/v56CR7dW4p3yMiCNiAFztv0B1uKJeBxZC5DpVvYPt38zcfg83n DM2hkZzj6Zqax9SxLYPsryiAIkCdgikoBZBwLRwReOD5Pma22t5obuwh5s5hzRH6c71N Xl0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=rXAbq+7gPg7ftySi18RLKiOZP5ChhlNAMQPad33V3tg=; b=dZKqdeewtWO3kT2io2ugV+zs2FAzN+zZI87iYA72zmmAP0VEkpB+m8jO2YaxX5UmnF 3J82Fy8WbBgJ60aEt8se0KlHYYg4KtpDdWP2yWAJ58dwES1rlUyrkRGsYRNYEk/EivEx ssLmEz5cTPOYnECaQvSipY2LbJVY1q/VJ4EyPE/LI4c4ydq6pHE5sfzkAODJ4oe4j6cG GbEKJ8OHe3wD+w4F56SfEtfDAUjJ4pk7ZgOR69O71iOxjTFK/yh3yTTLP/+3RfVL6sqt OkYCDsSw1wE24xDrLu14jd8tg5rR6fMNplBG2997R25+0F1BhZFZ4ujZiZrq7uL7Ck9p CYpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=mX1EOumc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b15si10393521plm.431.2018.12.17.23.24.23; Mon, 17 Dec 2018 23:24:51 -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=pass header.i=@chromium.org header.s=google header.b=mX1EOumc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726368AbeLRHXA (ORCPT + 99 others); Tue, 18 Dec 2018 02:23:00 -0500 Received: from mail-yw1-f66.google.com ([209.85.161.66]:45807 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726324AbeLRHW7 (ORCPT ); Tue, 18 Dec 2018 02:22:59 -0500 Received: by mail-yw1-f66.google.com with SMTP id d190so6265918ywd.12 for ; Mon, 17 Dec 2018 23:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rXAbq+7gPg7ftySi18RLKiOZP5ChhlNAMQPad33V3tg=; b=mX1EOumciwAlufHq4kC0L/SFQ6FPBBSLMp4Zz4dyUI/cUO+3Vb+vZLK5S6GXWC2vag QH+1SLYmb/7MMPajrfD6ThOUALiKhTnAs5pT71BVgXYtCyUdriG+7MSX0DvYo6sQfYZj I86CbY6af+3m8NISO7eQZJZOSCLXFFUbPkiis= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rXAbq+7gPg7ftySi18RLKiOZP5ChhlNAMQPad33V3tg=; b=PsHL9WA76M8cjzYKCQu7Efeokiv1ubuZFJmmaXbzLRdJvRAa/X428ToTst/vTqq9jn 4VZ2ca7KvzyiMD211udDc4ifeAItYXQ6o+ShQamBIYpxfwgyr8UV/tmkzSqctfwiJbGV 2s/GYCs1LOMED9Pcxl3pSb9o/RtQ6EO8Nx9BqHWL4xLwS0s3Vwm2Lw5T0R2tzhyhyFna 4pH+ZkxffquSYO+4ecsArc4Fl4Reqt7s9hSYE3ixb7uUPqbS4fezO2gKkN5yhNnah27Q sZshBJpcwnH585zlRl7xFGAm/TGF48ueGdm+d9HBmDqOrBeh18EJx9VHb0aa4cu5MpQq l4SA== X-Gm-Message-State: AA+aEWbII6L7CwhbvdNE+e2hQggRH0QukYidMnznBsWHjWUX8YGrQUZI LGud7pcDrxSlhtoeHE8AF7srxGeuHWWz0Q== X-Received: by 2002:a81:110b:: with SMTP id 11mr16597393ywr.386.1545117777099; Mon, 17 Dec 2018 23:22:57 -0800 (PST) Received: from mail-yw1-f51.google.com (mail-yw1-f51.google.com. [209.85.161.51]) by smtp.gmail.com with ESMTPSA id y83sm4602298ywd.65.2018.12.17.23.22.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 23:22:55 -0800 (PST) Received: by mail-yw1-f51.google.com with SMTP id i73so5114692ywg.3 for ; Mon, 17 Dec 2018 23:22:55 -0800 (PST) X-Received: by 2002:a81:3194:: with SMTP id x142mr15655803ywx.92.1545117775088; Mon, 17 Dec 2018 23:22:55 -0800 (PST) MIME-Version: 1.0 References: <20180821170629.18408-3-matwey@sai.msu.ru> <2213616.rQm4DhIJ7U@avalon> <20181207152502.GA30455@infradead.org> <20181212090917.GA30598@infradead.org> <20181212135440.GA6137@infradead.org> <20181213140329.GA25339@infradead.org> <20181214123624.GA5824@infradead.org> In-Reply-To: <20181214123624.GA5824@infradead.org> From: Tomasz Figa Date: Tue, 18 Dec 2018 16:22:43 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Christoph Hellwig Cc: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 14, 2018 at 9:36 PM Christoph Hellwig wrote: > > On Fri, Dec 14, 2018 at 12:12:38PM +0900, Tomasz Figa wrote: > > > If the buffer always is physically contiguous, as it is in the currently > > > posted series, we can always map it with a single dma_map_single call > > > (if the hardware can handle that in a single segment is a different > > > question, but out of scope here). > > > > Are you sure the buffer is always physically contiguous? At least the > > ARM IOMMU dma_ops [1] and the DMA-IOMMU dma_ops [2] will simply > > allocate pages without any continuity guarantees and remap the pages > > into a contiguous kernel VA (unless DMA_ATTR_NO_KERNEL_MAPPING is > > given, which makes them return an opaque cookie instead of the kernel > > VA). > > > > [1] http://git.infradead.org/users/hch/misc.git/blob/2dbb028e4a3017e1b71a6ae3828a3548545eba24:/arch/arm/mm/dma-mapping.c#l1291 > > [2] http://git.infradead.org/users/hch/misc.git/blob/2dbb028e4a3017e1b71a6ae3828a3548545eba24:/drivers/iommu/dma-iommu.c#l450 > > We never end up in this allocator for the new DMA_ATTR_NON_CONSISTENT > case, and that is intentional. 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. 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 Best regards, Tomasz