From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op
Date: Fri, 31 May 2013 18:50:09 +0100 [thread overview]
Message-ID: <20130531175008.GA11399@cantiga.alporthouse.com> (raw)
In-Reply-To: <CAKMK7uHwQHbUR8ckPBczRKB3nh6H_TMWQmz0bQRc3-GrXOy40g@mail.gmail.com>
On Fri, May 31, 2013 at 05:15:10PM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 4:05 PM, Paulo Zanoni <przanoni@gmail.com> wrote:
> > 2013/5/23 Daniel Vetter <daniel@ffwll.ch>:
> >> On Thu, May 23, 2013 at 01:57:17PM +0100, Chris Wilson wrote:
> >>> If none of the CRTC parameters change along with the framebuffer, we can
> >>> forgo rewriting the register and waiting for a vblank. There are a few
> >>> calls made by the display managers as they start up which tend to end up
> >>> performing no-ops on the current CRTC settings.
> >>>
> >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>
> >> Makes sense. Queued for -next, thanks for the patch. Now the only things
> >> left (besides beating fastboot into good shape) is to cache the edids a
> >> bit and we've (hopefully) killed all kms stalls at startup ...
> >
> > This commit introduced a regression.
> >
> > - Boot with both eDP and DP plugged
> > - When I boot like this, eDP1 has 1920x1080 and DP1 has 1920x1080i.
> > - Run "xrandr --output DP1 --mode 0x55" (that's 1024x768@60Hz here)
> > - See the black screen on DP output, dmesg has the "skipping reset of
> > current fb" message.
> > - After we get the black screen, if we run "xrandr --output DP1 --off;
> > xrandr --output DP1 --mode 0x55" the mode will work.
> >
> > If I diff the "bad state" with the "good state" we'll see the cause is
> > the DSPCNTR register. When we do the early return in
> > intel_pipe_set_base we don't call the update_plane function. For me
> > what changes is the pixel format and the trickle feed bits.
>
> Oh, in the modeset case we can't optimize the update_fb away, even
> when both fbs are the same ...
Hopefully we can push the check higher to the fb fast path then? The
skip is much safer in the kernel as it has correct knowledge of the
current state (as opposed to trying to track it the ddx sharing control
of the machine).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-05-31 17:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 12:57 [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op Chris Wilson
2013-05-23 21:27 ` Daniel Vetter
2013-05-31 14:05 ` Paulo Zanoni
2013-05-31 15:15 ` Daniel Vetter
2013-05-31 15:19 ` Paulo Zanoni
2013-05-31 16:32 ` Ville Syrjälä
2013-05-31 17:50 ` Chris Wilson [this message]
2013-05-31 18:55 ` Daniel Vetter
2013-06-04 14:08 ` [PATCH] drm/i915: Always disable trickle feed on Broadwater/Crestline Chris Wilson
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=20130531175008.GA11399@cantiga.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox