Re: [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux