[PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use

[Andrey Grodzovsky]

Hey Daniel, back from vacation and going over our last long thread i think you 
didn't reply
to my last question bellow (Or at least I can't find it).

Andrey

On 12/17/20 4:13 PM, Andrey Grodzovsky wrote:
>>> Ok, so I assumed that with vmap_local you were trying to solve the problem of
>>> quick reinsertion
>>> of another device into same MMIO range that my driver still points too but
>>> actually are you trying to solve
>>> the issue of exported dma buffers outliving the device ? For this we have
>>> drm_device refcount in the GEM layer
>>> i think.
>> That's completely different lifetime problems. Don't mix them up :-)
>> One problem is the hardware disappearing, and for that we _have_ to
>> guarantee timeliness, or otherwise the pci subsystem gets pissed
>> (since like you say, a new device might show up and need it's mmio
>> bars assigned to io ranges). The other is lifetim of the software
>> objects we use as interfaces, both from userspace and from other
>> kernel drivers. There we fundamentally can't enforce timely cleanup,
>> and have to resort to refcounting.
>
>
> So regarding the second issue, as I mentioned above, don't we already use 
> drm_dev_get/put
> for exported BOs ? Earlier in this discussion you mentioned that we are ok for 
> dma buffers since
> we already have the refcounting at the GEM layer and the real life cycle 
> problem we have is the dma_fences
> for which there is no drm_dev refcounting. Seems to me then that vmap_local is 
> superfluous because
> of the recounting we already have for exported dma_bufs and for dma_fences it 
> won't help.
>
> Andrey 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210104/162d6d80/attachment.htm>