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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox