From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 4/8] dma-buf: add peer2peer flag Date: Fri, 20 Apr 2018 05:46:25 -0700 Message-ID: <20180420124625.GA31078@infradead.org> References: <20180403090909.GN3881@phenom.ffwll.local> <20180403170645.GB5935@redhat.com> <20180403180832.GZ3881@phenom.ffwll.local> <20180416123937.GA9073@infradead.org> <20180419081657.GA16735@infradead.org> <20180420071312.GF31310@phenom.ffwll.local> <3e17afc5-7d6c-5795-07bd-f23e34cf8d4b@gmail.com> <20180420101755.GA11400@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Christoph Hellwig , Jerome Glisse , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:DMA BUFFER SHARING FRAMEWORK" , dri-devel , amd-gfx list , Linux Kernel Mailing List , Logan Gunthorpe , Dan Williams List-Id: amd-gfx.lists.freedesktop.org On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > num_resources) which does the handling common to all drivers. > > A structure that contains > > > > {page,offset,len} + {dma_addr+dma_len} > > > > is not a good container for storing > > > > {virt addr, dma_addr, len} > > > > no matter what interface you build arond it. > > Why not? I mean at least for my use case we actually don't need the virtual > address. If you don't need the virtual address you need scatterlist even list. > What we need is {dma_addr+dma_len} in a consistent interface which can come > from both {page,offset,len} as well as {resource, len}. Ok. > What I actually don't need is separate handling for system memory and > resources, but that would we get exactly when we don't use sg_table. At the very lowest level they will need to be handled differently for many architectures, the questions is at what point we'll do the branching out.