From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 8/8] drm/i915: remove early fb allocation dependency on CONFIG_FB v2 Date: Sun, 9 Mar 2014 10:33:05 -0700 Message-ID: <20140309103305.63202e8d@jbarnes-desktop> References: <1394211475-2646-1-git-send-email-jbarnes@virtuousgeek.org> <1394211475-2646-8-git-send-email-jbarnes@virtuousgeek.org> <20140308103315.GL25837@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy18-pub.mail.unifiedlayer.com (oproxy18-pub.mail.unifiedlayer.com [69.89.17.20]) by gabe.freedesktop.org (Postfix) with SMTP id 89013FA6B5 for ; Sun, 9 Mar 2014 10:32:28 -0700 (PDT) In-Reply-To: <20140308103315.GL25837@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Sat, 8 Mar 2014 11:33:15 +0100 Daniel Vetter wrote: > On Fri, Mar 07, 2014 at 08:57:55AM -0800, Jesse Barnes wrote: > > By stuffing the fb allocation into the crtc, we get mode set lifetime > > refcounting for free, but have to handle the initial pin & fence > > slightly differently. It also means we can move the shared fb handling > > into the core rather than leaving it out in the fbdev code. > > > > v2: null out crtc->fb on error (Daniel) > > take fbdev fb ref and remove unused error path (Daniel) > > > > Requested-by: Daniel Vetter > > Signed-off-by: Jesse Barnes > > Ok, I've merged patches 1-4 and this one here from the series. Not > terribly happy that you didn't squash in this fixup, since now people > might stumble over the strange lifetime rules of the previous patches. But > meh ;-) Yeah even though there's a handoff from the core to the fbdev side, I still think they're correct as far as fbs go. The underlying obj ref may not be correct though; I think that was papering over an earlier bug. Either way those should manifest as a leaked object (the stolen fb will stick around forever) rather than a crash or something. Whereas this last patch is more likely to cause serious trouble I think since it's a bit more invasive and relies on some other bits more... Anyway thanks, looking forward to seeing the perf data on the swizzle stuff. -- Jesse Barnes, Intel Open Source Technology Center