Re: [PATCH 01/11] drm: add plane support

[Daniel Vetter <daniel@ffwll.ch>]

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@ffwll.ch
Mobile: +41 (0)79 365 57 48