All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
Date: Tue, 26 Nov 2013 08:43:01 -0800	[thread overview]
Message-ID: <20131126084301.280a9454@jbarnes-desktop> (raw)
In-Reply-To: <20131126140948.GC16131@nuc-i3427.alporthouse.com>

On Tue, 26 Nov 2013 14:09:48 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Mon, Nov 25, 2013 at 03:51:18PM -0800, Jesse Barnes wrote:
> > Retrieve current framebuffer config info from the regs and create an fb
> > object for the buffer the BIOS or boot loader left us.  This should
> > allow for smooth transitions to userspace apps once we finish the
> > initial configuration construction.
> > 
> > v2: check for non-native modes and adjust (Jesse)
> >     fixup aperture and cmap frees (Imre)
> >     use unlocked unref if init_bios fails (Jesse)
> >     fix curly brace around DSPADDR check (Imre)
> >     comment failure path for pin_and_fence (Imre)
> > v3: fixup fixup of aperture frees (Chris)
> > v4: update to current bits (locking & pin_and_fence hack) (Jesse)
> > v5: move fb config fetch to display code (Jesse)
> >     re-order hw state readout on initial load to suit fb inherit (Jesse)
> >     re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
> > v6: rename to plane_config (Daniel)
> >     check for valid object when initializing BIOS fb (Jesse)
> >     split from plane_config readout and other display changes (Jesse)
> >     drop use_bios_fb option (Chris)
> >     update comments (Jesse)
> >     rework fbdev_init_bios for clarity (Jesse)
> >     drop fb obj ref under lock (Chris)
> > v7: use fb object from plane_config instead (Ville)
> > 
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> Hmm, quietly steals plane_config->fb you mean. Other than bikeshedding
> the kzalloc(intel_fbdev) and the clarity of
> intel_fb_init/intel_fb_init_bios, I don't see anything else. The fb
> lifetime of plane_config->fb is extremely ugly though (the theft could
> be made a little more obvious for instance) and still leaked upon failure?

I free it on failure in fb_init_bios, but maybe I missed an error path?

I agree on the lifetime handling, but it was either this or an ugly
copy of the fb object in the bios function.  And even then we'd have to
find a place to free it that made sense (there is no such place today).

I did comment the field in the struct at least...

-- 
Jesse Barnes, Intel Open Source Technology Center

  reply	other threads:[~2013-11-26 16:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 23:51 [PATCH 1/5] drm/i915: make pitch_for_width take a tiled arg v2 Jesse Barnes
2013-11-25 23:51 ` [PATCH 2/5] drm/i915: split fb allocation and initialization v2 Jesse Barnes
2013-11-25 23:51 ` [PATCH 3/5] drm/i915: retrieve current fb config into new plane_config structure at init v4 Jesse Barnes
2013-11-26 13:57   ` Chris Wilson
2013-11-26 16:41     ` Jesse Barnes
2013-11-26 17:43   ` Daniel Vetter
2013-11-26 18:11     ` Jesse Barnes
2013-11-25 23:51 ` [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7 Jesse Barnes
2013-11-26 14:09   ` Chris Wilson
2013-11-26 16:43     ` Jesse Barnes [this message]
2013-11-26 17:54     ` Daniel Vetter
2013-11-26 18:15       ` Jesse Barnes
2013-11-25 23:51 ` [PATCH 5/5] drm/i915: don't memset the fb buffer if preallocated Jesse Barnes
2013-11-26 14:13   ` Chris Wilson
2013-11-26 13:53 ` [PATCH 1/5] drm/i915: make pitch_for_width take a tiled arg v2 Chris Wilson
2013-11-26 17:28 ` Ville Syrjälä
2013-11-26 17:37   ` Jesse Barnes
2013-11-26 17:57 ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131126084301.280a9454@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.