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 -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
