From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 01/11] drm: add plane support Date: Tue, 25 Oct 2011 15:42:42 +0200 Message-ID: <20111025134242.GF2894@phenom.ffwll.local> References: <1319536026-2877-1-git-send-email-jbarnes@virtuousgeek.org> <1319536026-2877-2-git-send-email-jbarnes@virtuousgeek.org> <20111025115855.GC2894@phenom.ffwll.local> <20111025142607.4e81ff40@pyx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20111025142607.4e81ff40@pyx> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Alan Cox Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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