On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote:

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:

quoted

And since I failed to make this clear: There's not really a
fundamental
reason ast and cirrus use the dirty tracking for fbdev. It's just that
doing it that way was the fastest way to get those servers booting, and
ever since no one cared. It's a bit tricky to do right because fbdev
assumes it always own the framebuffer and that it never moves, 

That can be worked around from my memories of hacking fbdev many years
ago. Basically fbdev only owns it if it's the current VT and you can
make it release it if the user switches to KD_GRAPHICS which userspace
should always do before taking over.

As for multi userspace client, well, swapping an mmap between HW and
memory backing store is a somewhat solved problem already.

Hm, I didn't know that, but then all existing drm drivers have fairly
simplistic fbdev mmap implementations.

quoted

whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
something once, and if there's indeed more interest into vram dumb buffer
drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
fb helpers we have) to make it all pretty and nice and fast and
essentially plug-in-and-forget from a driver authors pov.

That would be nice. I don't have the bandwidth to swap-in enough
understanding of TTM guts right now but I might look into it some time next 
year if nobody beats me to it.

Probably best would be to first extract some helpers for ttm based vram
dumb buffer management, and then start to implement some of the
improvements so that all drivers can benefit. Like you've said it's not
rocket science, it just needs to be done ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch