From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CEA5C433DF for ; Thu, 20 Aug 2020 05:15:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1EF492078D for ; Thu, 20 Aug 2020 05:15:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EF492078D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 358756B00A0; Thu, 20 Aug 2020 01:15:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E02E8D0003; Thu, 20 Aug 2020 01:15:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B6AE6B00A3; Thu, 20 Aug 2020 01:15:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 025486B00A0 for ; Thu, 20 Aug 2020 01:15:17 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AB524181AEF07 for ; Thu, 20 Aug 2020 05:15:17 +0000 (UTC) X-FDA: 77169783474.01.mark26_2d0afc92702e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 626571004C7A6 for ; Thu, 20 Aug 2020 05:15:17 +0000 (UTC) X-HE-Tag: mark26_2d0afc92702e X-Filterd-Recvd-Size: 3932 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 05:15:16 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Cc: Christoph Hellwig , Mauro Carvalho Chehab , Thomas Bogendoerfer , "James E.J. Bottomley" , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Ben Skeggs , Pawel Osciak , Marek Szyprowski , Matt Porter , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Tom Lendacky , alsa-devel@alsa-project.org, linux-samsung-soc , linux-ia64@vger.kernel.org, linux-scsi@vger.kernel.org, linux-parisc@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, Linux Kernel Mailing List , linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Media Mailing List Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 626571004C7A6 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem.