<html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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 <div class="moz-cite-prefix">On 12/17/20 4:13 PM, Andrey Grodzovsky wrote: </div> <blockquote type="cite" cite="mid:5feff301-0aca-3e07-c1c4-31e4a91fc942@amd.com"> <blockquote type="cite" style="color: #000000;"> <blockquote type="cite" style="color: #000000;">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. </blockquote> 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. </blockquote> 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 </blockquote> </body> </html>