From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 3/6] drm/i915: Wrap the preallocated BIOS
 framebuffer and preserve for KMS fbcon v7
Date: Fri, 13 Dec 2013 11:09:05 -0800
Message-ID: <20131213110905.06046c4e@jbarnes-desktop>
References: <1386880917-2951-1-git-send-email-jbarnes@virtuousgeek.org>
	<1386880917-2951-3-git-send-email-jbarnes@virtuousgeek.org>
	<20131212225437.GT9804@phenom.ffwll.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from alt-proxy11.mail.unifiedlayer.com
	(alt-proxy11.mail.unifiedlayer.com [74.220.211.241])
	by gabe.freedesktop.org (Postfix) with SMTP id 6281EFAF94
	for <intel-gfx@lists.freedesktop.org>;
	Fri, 13 Dec 2013 11:07:20 -0800 (PST)
In-Reply-To: <20131212225437.GT9804@phenom.ffwll.local>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces@lists.freedesktop.org
Errors-To: intel-gfx-bounces@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Thu, 12 Dec 2013 23:54:37 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> > @@ -258,8 +357,102 @@ static void intel_fbdev_destroy(struct drm_device *dev,
> >  
> >  	drm_fb_helper_fini(&ifbdev->helper);
> >  
> > -	drm_framebuffer_unregister_private(&ifbdev->ifb.base);
> > -	intel_framebuffer_fini(&ifbdev->ifb);
> > +	drm_framebuffer_unregister_private(&ifbdev->fb->base);
> > +	intel_framebuffer_fini(ifbdev->fb);
> > +	kfree(ifbdev->fb);  
> 
> No need to go the private fb route here anymore since now the fb is
> free-standing. Normal refcounting should work. But a separate prep/cleanup
> patch (prep since switching ifbdev->fb from struct to point would look
> neat as a separate patch).

Oh and can you explain this?  I wouldn't be surprised if I got the
refcounting wrong, but given how tricky it can be, can you explain
where we'll take the ref here, and show that the right thing will
happen if/when we mode set away from this buffer?

I haven't actually seen a bug here with or without this patch (no
crashes or warns), but I thought I needed this to make sure the obj
didn't get a negative count after a mode set...

-- 
Jesse Barnes, Intel Open Source Technology Center