From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 3/3] drm/i915: remove the vblank_wait hack from HSW+
Date: Wed, 12 Feb 2014 20:06:20 +0200 [thread overview]
Message-ID: <20140212180620.GG3891@intel.com> (raw)
In-Reply-To: <CA+gsUGRjBM67d9SHh8rgkwz6ajD11p9pfE9u9SbOHkqUezfcnw@mail.gmail.com>
On Wed, Feb 12, 2014 at 03:02:13PM -0200, Paulo Zanoni wrote:
> 2014-02-12 9:26 GMT-02:00 Ville Syrjälä <ville.syrjala@linux.intel.com>:
> > On Wed, Feb 12, 2014 at 01:13:17PM +0200, Ville Syrjälä wrote:
> >> On Thu, Dec 19, 2013 at 07:12:31PM -0200, Paulo Zanoni wrote:
> >> > From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> >
> >> > When I forked haswell_crtc_enable I copied all the code from
> >> > ironlake_crtc_enable. The last piece of the function contains a big
> >> > comment with a call to intel_wait_for_vblank. After this fork, we
> >> > rearranged the Haswell code so that it enables the planes as the very
> >> > last step of the modeset sequence, so we're sure that we call
> >> > intel_enable_primary_plane after the pipe is really running, so the
> >> > vblank waiting functions work as expected. I really believe this is
> >> > what fixes the problem described by the big comment, so let's give it
> >> > a try and get rid of that intel_wait_for_vblank, saving around 16ms
> >> > per modeset (and init/resume). We can always revert if needed :)
> >>
> >> I noticed this got merged, but I'd actually prefer we go the other way.
> >> Ie. remove the vblank wait from enable_primary_plane(). We're going to
> >> want to use the atomic update also for enabling the planes at modeset
> >> soon enough, so I think this change is going in the wrong direction.
>
> The enable_primary_plane() wait happens on all gens, and it's there by
> design. The code removed by this patch is only for HSW and, considered
> the comment block involved, it's just a workaround.
It's not a workaround. It's there to prevent completing a subsequent
pageflip before it even had a chance to happen. That's still needed.
Now it sort of works by accident since enable_primary_plane has the
wait, but there's not even a comment saying why the wait is needed
there. But I admit, even the original comment was quite vague.
Hmm. Now that I think about it more, I think we need to go for the flip
counter approach anyway, since if you currently do a set_base w/o
actually changing the fb, and then follow that with a page flip, we hit
the same problem where the page flip might be completed too early.
> So removing the
> enable_primary_plane() wait would have been a totally different patch,
> affecting all gens, instead of a HSW+ only patch.
>
> So if you want to move the wait form enable_primary_plane() to the end
> of crtc_enable() on _all_ gens, it's fine, but it's a separate patch
> with a different purpose.
I have a patch for that somewhere. Maybe it was part of the plane
enable/disable reordering that only got partially applied (just for
HSW). Or it might be a part of my remaining PCH watermark patches.
Also we don't need the wait at all on gmch platforms (except vlv)
since those don't have a flip done interrupt that gets triggred by
mmio flips. So having the wait in enable_primary is a bit wasteful
on those platforms.
But if you don't want to undo the change, I'll just stick a note to my
TODO file to fix it all up at some point.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-02-12 18:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 21:12 [PATCH 1/3] drm/i915: add wait_for_vblank argument to intel_enable_pipe Paulo Zanoni
2013-12-19 21:12 ` [PATCH 2/3] drm/i915: don't wait for vblank after enabling pipe on HSW Paulo Zanoni
2014-01-15 18:26 ` Jesse Barnes
2013-12-19 21:12 ` [PATCH 3/3] drm/i915: remove the vblank_wait hack from HSW+ Paulo Zanoni
2013-12-19 21:17 ` Daniel Vetter
2013-12-20 14:32 ` Paulo Zanoni
2013-12-20 22:32 ` Lee, Chon Ming
2014-01-02 16:08 ` Paulo Zanoni
2014-01-15 18:28 ` Jesse Barnes
2014-02-12 11:13 ` Ville Syrjälä
2014-02-12 11:26 ` Ville Syrjälä
2014-02-12 17:02 ` Paulo Zanoni
2014-02-12 18:06 ` Ville Syrjälä [this message]
2014-02-12 18:35 ` Paulo Zanoni
2013-12-20 6:41 ` [PATCH 1/3] drm/i915: add wait_for_vblank argument to intel_enable_pipe Jani Nikula
2014-01-15 18:25 ` Jesse Barnes
2014-01-15 23:40 ` Daniel Vetter
2014-01-17 15:46 ` Paulo Zanoni
2014-01-17 15:51 ` [PATCH 4/3] drm/i915: pass intel_crtc as argument for intel_enable_pipe Paulo Zanoni
2014-01-17 15:51 ` [PATCH 5/3] drm/i915: remove pch_port argument form intel_enable_pipe Paulo Zanoni
2014-02-10 14:17 ` Damien Lespiau
2014-01-17 15:51 ` [PATCH 6/3] drm/i915: remove "dsi" " Paulo Zanoni
2014-02-10 14:21 ` Damien Lespiau
2014-02-10 17:19 ` Daniel Vetter
2014-01-17 15:51 ` [PATCH 7/3] drm/i915: remove wait_for_vblank " Paulo Zanoni
2014-02-10 14:33 ` Damien Lespiau
2014-02-10 14:59 ` Ville Syrjälä
2014-01-17 15:51 ` [PATCH 8/3] drm/i915: WARN in case we're enabling the pipe and it's enabled Paulo Zanoni
2014-02-10 14:34 ` Damien Lespiau
2014-02-10 14:17 ` [PATCH 4/3] drm/i915: pass intel_crtc as argument for intel_enable_pipe Damien Lespiau
2014-02-10 17:23 ` Daniel Vetter
2014-02-11 15:23 ` Paulo Zanoni
2014-02-11 15:44 ` Daniel Vetter
2014-02-11 17:09 ` Paulo Zanoni
2014-02-11 17:20 ` Paulo Zanoni
2014-02-11 21:54 ` Daniel Vetter
2014-02-12 15:56 ` Paulo Zanoni
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=20140212180620.GG3891@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=przanoni@gmail.com \
/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.