[lkml]   [2019]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping
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!

 \ /
  Last update: 2019-06-12 10:26    [W:0.033 / U:18.616 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site