Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5019107imu; Tue, 15 Jan 2019 09:44:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN55ZIE3QMyT062CGls8liiEH3YB0z1gOf+5RvqARjCut3ToltZn9iw9jmG/BsYAogJBfER6 X-Received: by 2002:a63:5723:: with SMTP id l35mr4659884pgb.228.1547574288854; Tue, 15 Jan 2019 09:44:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547574288; cv=none; d=google.com; s=arc-20160816; b=xPWN/kzXKH6U08NqiQMit5BTrKwSashXSYW2gwgsiqV+peo02NuClrHL6Dc/ifrx47 SffGHwIJgc1WCTljismyzYFblBhS6Jt47R7bfc37RDp4w+E7oHpZFp+yXN1O2q2XlvHG 03kKeHzm+3Wuk5yvSrSw++ZGEjfJ/kaj5tY+OFBuT+bLgvToM103cZsRQkE0DtVDthZE qP/wtg9M2OAa0PASR1mMH3I03DOkXnu4In+FdAQdANRU+JOWZ5rHiVp0B3fnvUQHZ2pe 6aNRCd7SxMdYoSU3ASMUpmYR/8Ap+tS84smnOWkb7+mawxvjDVJP0T9XRSvJ/Pv7h33+ lp6w== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=k7NYadiyrKPCLw1zkyfiQqvVyiRQCRXUI04SRz/q+9A=; b=diptvaJHz5fOqIpXxvx4TtjPrDUTw8DxaiUYfJPimdn/U+ODdEkk1D+DXlGBn2F5n6 OQb7RAAboErAy9udHNcqMR3FT62a0Y0gbOAQzutGKHov3cDAPDRuLotmTYeRq6FOEWV0 9csDZ4Lo551UHg5EUM1PwgOi86NHxM8zXf99Q4VvBDHCFZgECoVf6R1R/DjZUARZrvPx Crutgow3dYtzsKRQLcXiOKNhsvKM+HMmMohd52uqby8imXArUhZi7ElToReqy7x5FZXf yTWRBz0hSxRJXhdYZLIDlmNaB9g+Lppj2bOYleE8RdYvgToR1Jbri3q1Cko1mHSU4p0d cqvw== 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 e9si3785812plt.181.2019.01.15.09.44.31; Tue, 15 Jan 2019 09:44:48 -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 S1730793AbfAOPUb (ORCPT + 99 others); Tue, 15 Jan 2019 10:20:31 -0500 Received: from verein.lst.de ([213.95.11.211]:53668 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728418AbfAOPUa (ORCPT ); Tue, 15 Jan 2019 10:20:30 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 5831167358; Tue, 15 Jan 2019 16:20:29 +0100 (CET) Date: Tue, 15 Jan 2019 16:20:29 +0100 From: "hch@lst.de" To: christian.koenig@amd.com Cc: Thomas Hellstrom , "hch@lst.de" , "jgg@ziepe.ca" , "syeh@vmware.com" , "linux-rdma@vger.kernel.org" , "daniel.vetter@ffwll.ch" , "jian.xu.zheng@intel.com" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "sakari.ailus@linux.intel.com" , "bingbu.cao@intel.com" , "yong.zhi@intel.com" , "shiraz.saleem@intel.com" , "tian.shu.qiu@intel.com" , "linux-media@vger.kernel.org" Subject: Re: [PATCH] lib/scatterlist: Provide a DMA page iterator Message-ID: <20190115152029.GB2325@lst.de> References: <20190104223531.GA1705@ziepe.ca> <20190110234218.GM6890@ziepe.ca> <20190114094856.GB29604@lst.de> <1fb20ab4b171b281e9994b6c55734c120958530b.camel@vmware.com> <2b440a3b-ed2f-8fd6-a21e-97ca0b2f5db9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2b440a3b-ed2f-8fd6-a21e-97ca0b2f5db9@gmail.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 Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian K?nig wrote: > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs. > > If the DMA API finds that a piece of memory is not directly accessible by > the GPU we need to return an error and not try to use bounce buffers behind > the surface. > > That is something which always annoyed me with the DMA API, which is > otherwise rather cleanly defined. That is exactly what I want to fix with my series to make DMA_ATTR_NON_CONSISTENT more useful and always available: https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031985.html With that you allocate the memory using dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT, and use dma_sync_single_* to transfer ownership to the cpu and back to the device, with a gurantee that there won't be any bouncing. So far the interest by the parties that requested the feature has been rather lacklustre, though.