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

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