From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolin Chen Subject: Re: [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping Date: Wed, 12 Jun 2019 01:25:49 -0700 Message-ID: <20190612082549.GA9072@Asurada> References: <20190612012219.21652-1-nicoleotsuka@gmail.com> <261b46c7-0c5e-4268-619d-f8381fbc3aeb@amd.com> <20190612080214.GA8876@Asurada> <170c3828-115b-38e5-35fc-1b88c08c492a@amd.com> <20190612081554.GB8876@Asurada> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Koenig, Christian" Cc: "sumit.semwal@linaro.org" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-kernel@vger.kernel.org" , "daniel.vetter@ffwll.ch" List-Id: dri-devel@lists.freedesktop.org On Wed, Jun 12, 2019 at 08:20:41AM +0000, Koenig, Christian wrote: > Am 12.06.19 um 10:15 schrieb Nicolin Chen: > > Hi Christian, > > > > On Wed, Jun 12, 2019 at 08:05:53AM +0000, Koenig, Christian wrote: > >> Am 12.06.19 um 10:02 schrieb Nicolin Chen: > >> [SNIP] > >>> We haven't used DRM/GRM_PRIME yet but I am also curious would it > >>> benefit DRM also if we reduce this overhead in the dma_buf? > >> No, not at all. > > From you replies, in a summary, does it means that there won't be a case > > of DRM having a dma_buf attaching to the same device, i.e. multiple calls > > of drm_gem_prime_import() function with same parameters of dev + dma_buf? > > Well, there are some cases where this happens. But in those cases we > intentionally want to get a new attachment :) Got it. > So thinking more about it you would actually break those and that is not > something we can do. That's true... > > If so, we can just ignore/drop this patch. Sorry for the misunderstanding. > > It might be interesting for things like P2P, but even then it might be > better to just cache the P2P settings instead of the full attachment. I see. Thank you for the answers!