On Tue, 25 Oct 2011 14:26:07 +0100 Alan Cox alan@lxorguk.ukuu.org.uk wrote:
As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
- fbs are not reference counted, hence when destroying we need to
disable all crtcs (and now also planes) that use them. drm_framebuffer_cleanup does that atm
- drivers that hold onto fbs after the kms core drops the
corresponding pointer needs to hold a ref onto the underlying backing storage (like e.g. for pageflip on the to-be-flipped-out fb as long as it might still be scanned out).
We need proper refcounting for these ... But for now this patch is missing the plane cleanup in drm_framebuffer_cleanup.
I'd rather we fixed the framebuffer kref stuff as part of doing this rather than have a poorer API because of something we have to fix anyway.
It shouldn't be *that* hard to fix, at least for this kind of use case. Resize locking, fb moving etc are ugly issues, refcount shouldn't be, and the tty layer also refcounts so we can only have the fb objects themselves to worry about as we can defer fb destruction to tty close or drm last unref even for those with consoles on them.
Oh it doesn't affect the userspace API so I don't think it's urgent. But I agree, it would be nice to clean up fb management a bit... Any volunteers? :)
Thanks, Jesse