Flicker-free boot in DRM

Flicker-free boot in DRM

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 2376 bytes --]


Steve Langasek came over today and we hacked on the i915 driver
initialization code to try and avoid the initial mode set. I thought I'd
summarize what we found out.

 *  Ubuntu has hacked up grub2 so that it gets the boot monitor running
    in a reasonable configuration using VBE calls if possible. In
    particular, it does try to find a 32bpp mode.

    Unfortunately, this won't actually work on many machines as the BIOS
    is often missing the native mode for the panel. So, we'll often need to
    deal with situations where the BIOS has got the panel running in the
    right mode, but there's a scaler running and the pipe and plane are
    wrong. I wonder if it's possible to change the plane/pipe/scaler
    configuration without turning the panel off and without causing any
    visible artifacts on the screen. My (limited) testing generated
    quite the visual fireworks...

 *  Would UEFI do any better? It does provide a native mode on my MBA,
    it would be nice to know if this is at all common on regular PC
    hardware that has UEFI support.

 *  I've got LVDS pulling the current mode out of the hardware, and
    nearly have eDP doing the same. eDP is a bit harder because
    computing the nominal pixel clock from the hw clock and M/N ratios
    is harder than just pulling the PLL values out.

 *  Constructing a fake drm_framebuffer is a pain; there are a million
    places that assume all kinds of things about the frame buffer on
    a crtc.

 *  DRM destroys all references to the current mode before crtc->mode_set is
    called. This makes it impossible to short-circuit pieces of mode_set
    internally. There's absolutely no reason for this; all of the
    changed data are available as parameters to the underlying functions.

 *  drm should let the driver decide whether mode_set_base will work
    to switch frame buffers. Otherwise, there are all kinds of cases
    which the hardware supports and which it will refuse to let through.
    I think it should return -EAGAIN or some such to signal that the
    system should try to do a full mode set.
  
I'll try changing the interface to mode_set_base and see how much
further I get. All of the preliminary patches I've done are on my
panel-takeover branch on git://people.freedesktop.org/~keithp/linux

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Chris Wilson]

On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" <keithp@keithp.com> wrote:
>  *  Constructing a fake drm_framebuffer is a pain; there are a million
>     places that assume all kinds of things about the frame buffer on
>     a crtc.

This is vital as we need to capture the current GATT and stolen allocations
and preserve them across takeover. Otherwise we end up using the VBIOS
scanout PTEs as our ringbuffer and the actual memory for FBC.

Best case failure is garbage during takeover; worst case is a GPU hang.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Flicker-free boot in DRM

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]

On Sat, 29 Oct 2011 09:12:13 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" <keithp@keithp.com> wrote:
> >  *  Constructing a fake drm_framebuffer is a pain; there are a million
> >     places that assume all kinds of things about the frame buffer on
> >     a crtc.
> 
> This is vital as we need to capture the current GATT and stolen allocations
> and preserve them across takeover. Otherwise we end up using the VBIOS
> scanout PTEs as our ringbuffer and the actual memory for FBC.

Yeah, I'm getting quite the light show at present, could well be due to
this.

> Best case failure is garbage during takeover; worst case is a GPU hang.

Sounds like creating a GEM object that maps stolen pages is not just a
good idea, but actually necessary.

With that and the mode detection, I think we'll be pretty much set
then. The two patches I've got now are sufficient to get from boot
through X only using mode_set_base, albeit with the screen transitioning
through some pretty crazy looking stuff.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]

On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" <keithp@keithp.com> wrote:

>  *  I've got LVDS pulling the current mode out of the hardware

With a machine that has a native VBE mode for the panel, the problem is
that clock computed from the hardware settings is not quite the same as
the clock requested in the mode. I think the clock computation must be
slightly off, but even with that fixed, it will probably not quite
match. I think we'll need a magic flag in this mode telling DRM to allow
a bit of fuzz in clock matching.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Adam Jackson]

On 10/30/11 12:24 AM, Keith Packard wrote:
> On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard"<keithp@keithp.com>  wrote:
>
>>   *  I've got LVDS pulling the current mode out of the hardware
>
> With a machine that has a native VBE mode for the panel, the problem is
> that clock computed from the hardware settings is not quite the same as
> the clock requested in the mode. I think the clock computation must be
> slightly off, but even with that fixed, it will probably not quite
> match. I think we'll need a magic flag in this mode telling DRM to allow
> a bit of fuzz in clock matching.

Yeah, it won't be precise.  That's why there's PLL search code at all, 
and why it has a fuzz factor for finding "good enough".

I ran the math for the maximum error in the PLL search back when I was 
fixing a case where it fell through and failed to find timings at all. 
See 6ba770dc5c334aff1c055c8728d34656e0f091e2.

- ajax

Re: Flicker-free boot in DRM

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 2469 bytes --]

On Sat, 29 Oct 2011 00:05:22 -0700
"Keith Packard" <keithp@keithp.com> wrote:

> 
> Steve Langasek came over today and we hacked on the i915 driver
> initialization code to try and avoid the initial mode set. I thought I'd
> summarize what we found out.
> 
>  *  Ubuntu has hacked up grub2 so that it gets the boot monitor running
>     in a reasonable configuration using VBE calls if possible. In
>     particular, it does try to find a 32bpp mode.
> 
>     Unfortunately, this won't actually work on many machines as the BIOS
>     is often missing the native mode for the panel. So, we'll often need to
>     deal with situations where the BIOS has got the panel running in the
>     right mode, but there's a scaler running and the pipe and plane are
>     wrong. I wonder if it's possible to change the plane/pipe/scaler
>     configuration without turning the panel off and without causing any
>     visible artifacts on the screen. My (limited) testing generated
>     quite the visual fireworks...

Should be possible I think, but depends on the specific hardware rev.
Last time I tried lots of combinations was on Crestline for panel
fitting.  Scaling down or up with fitting worked w/o shutting down the
pipe, but to scale back up from a centered mode required a pipeconf
toggle.  I think BIOSes mostly use the fitter though, so it ought to be
possible.

>  *  Constructing a fake drm_framebuffer is a pain; there are a million
>     places that assume all kinds of things about the frame buffer on
>     a crtc.

Easier to just copy the contents out of the current framebuffer into a
new one before flipping to the new buffer.

>  *  DRM destroys all references to the current mode before crtc->mode_set is
>     called. This makes it impossible to short-circuit pieces of mode_set
>     internally. There's absolutely no reason for this; all of the
>     changed data are available as parameters to the underlying functions.
> 
>  *  drm should let the driver decide whether mode_set_base will work
>     to switch frame buffers. Otherwise, there are all kinds of cases
>     which the hardware supports and which it will refuse to let through.
>     I think it should return -EAGAIN or some such to signal that the
>     system should try to do a full mode set.

I think that's already possible if we don't use the helper function for
mode setting.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Adam Jackson]

On 10/29/11 3:05 AM, Keith Packard wrote:

>   *  Would UEFI do any better? It does provide a native mode on my MBA,
>      it would be nice to know if this is at all common on regular PC
>      hardware that has UEFI support.

UEFI firmwares are not required to get native mode on the panel right by 
UEFI itself, I don't believe.  But there are logo requirements programs 
for some operating systems that require it, so it'll probably be quite 
common.

- ajax

Re: Flicker-free boot in DRM

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 482 bytes --]

On Mon, 31 Oct 2011 12:56:58 -0400, Adam Jackson <ajax@redhat.com> wrote:

> Yeah, it won't be precise.  That's why there's PLL search code at all, 
> and why it has a fuzz factor for finding "good enough".

Right, so we'll need a similar fuzz factor when deciding whether we
actually need to flip modes or not. Makes me concerned that we'll be
effectively ignoring minor changes in the mode, which will make tweaking
dot clocks impossible.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 699 bytes --]

On Mon, 31 Oct 2011 09:57:26 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Easier to just copy the contents out of the current framebuffer into a
> new one before flipping to the new buffer.

I'm not excited about doing the copy, but I don't see a better plan --
we want to be able to use stolen memory for other things, but we can't
do that while scanout is happening.

> I think that's already possible if we don't use the helper function for
> mode setting.

I'd like to avoid duplicating all of that logic down in every driver, of
course, so finding a simple way to give the driver a bit more control
seems like a reasonable compromise.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Flicker-free boot in DRM

[Adam Jackson]

On 10/31/11 2:43 PM, Keith Packard wrote:
> On Mon, 31 Oct 2011 12:56:58 -0400, Adam Jackson<ajax@redhat.com>  wrote:
>
>> Yeah, it won't be precise.  That's why there's PLL search code at all,
>> and why it has a fuzz factor for finding "good enough".
>
> Right, so we'll need a similar fuzz factor when deciding whether we
> actually need to flip modes or not. Makes me concerned that we'll be
> effectively ignoring minor changes in the mode, which will make tweaking
> dot clocks impossible.

I don't see why we'd need to use the same equality operator everywhere. 
  The case of "is userspace asking for a fine-tune" seems clearly 
distinguishable from "are the current panel timings close enough to what 
EDID asked for".

- ajax