From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 01/11] drm: add plane support Date: Tue, 25 Oct 2011 15:32:44 +0200 Message-ID: <20111025153244.7b238fc3@jbarnes-x220> 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: Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by gabe.freedesktop.org (Postfix) with SMTP id B229B9E942 for ; Tue, 25 Oct 2011 06:32:49 -0700 (PDT) In-Reply-To: <20111025142607.4e81ff40@pyx> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alan Cox Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, 25 Oct 2011 14:26:07 +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. > > 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