From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 2/6] drm/i915: retrieve current fb config
 into new plane_config structure at init
Date: Tue, 17 Dec 2013 22:19:13 +0100
Message-ID: <CAKMK7uHn=HVQnYcVoiZUrP8VRjNUfVjL5ReWwsaty+P3UBDmVQ@mail.gmail.com>
References: <1386880917-2951-1-git-send-email-jbarnes@virtuousgeek.org>
	<1386880917-2951-2-git-send-email-jbarnes@virtuousgeek.org>
	<20131214110147.GJ9804@phenom.ffwll.local>
	<20131216160141.64ef8685@jbarnes-desktop>
	<20131217083836.GK9804@phenom.ffwll.local>
	<20131217130404.435cbc66@jbarnes-desktop>
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 mail-ie0-f179.google.com (mail-ie0-f179.google.com
	[209.85.223.179])
	by gabe.freedesktop.org (Postfix) with ESMTP id B38B9106AA1
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 17 Dec 2013 13:19:13 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id x13so8868640ief.24
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 17 Dec 2013 13:19:13 -0800 (PST)
In-Reply-To: <20131217130404.435cbc66@jbarnes-desktop>
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: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Tue, Dec 17, 2013 at 10:04 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > Hm yeah the ownership is less clear in the CONFIG_FB=n case.  I think
>> > the driver will own the buffer, and it'll get dropped on the first mode
>> > set with a new buffer.  But even then there will be no process to deref
>> > the object finally, so it'll stick around.  Hm... maybe just disable it
>> > if CONFIG_FB=n is the right answer for now.
>>
>> If you switch the fbdev code to look at crtc->fb instead of
>> crtc->plane_config.fb and just drop the plane_config.fb pointer (and it's
>> reference) it should pan out. Then the only reference+pointers we have are
>> the ones in crtc->fb, and the drm core will take care of those.
>
> How can I switch to looking at crtc->fb?  Or do you mean
> get_plane_config should stuff a full fb into crtc->fb instead of the
> plane_config struct?

Yeah, that would be my idea. Since crtc->fb is managed by the drm core
we could also enable the recovery for CONFIG_FB=n and so enable smooth
transitions without fbdev being present. Well, super-smooth only with
fastboot ofc ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch