On Tue, Oct 25, 2011 at 02:26:07PM +0100, Alan Cox 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.
Imo we should do things piece by piece. Fixing up drm fb refcounting is imo a rather low-prio thing for core drm. And I've already asked Rob Clarke whether he can clean up some of the confiusion in the kms framebuffer->destroy() functions.
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
I'm talking solely about kms framebuffers. I.e. completely orthogonal to any issues you're seeing wrt kms<->linux fb subsystem integration. Or I'm completely misunderstanding you here ... -Daniel