Re: [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon

Chris Wilson
2013-11-15T09:40:33Z

On Fri, Nov 15, 2013 at 01:29:30AM +0100, Daniel Vetter wrote:
> On Thu, Nov 14, 2013 at 04:04:24PM -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)
> >
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> Just for the record I'm still freaked out who we're supposed to keep this
> working. But since all the ideas I could come up are somewhere between
> groos and "that's not going to work" I'm leaning towards ignoring it.

This used to disable the outputs attached to the current bios fb if we
failed to takeover the fb. This is required to prevent the machine
reading out garbage whilst we modify the GTT and potentially hanging the
GPU. This is also a regression from about 3.2.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre