From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Subject: Re: [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay
Date: Wed, 7 Dec 2016 20:49:22 +0200 [thread overview]
Message-ID: <20161207184922.GW31595@intel.com> (raw)
In-Reply-To: <20161207182550.GE4815@nuc-i3427.alporthouse.com>
On Wed, Dec 07, 2016 at 06:25:50PM +0000, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:51:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 07, 2016 at 05:41:39PM +0000, Chris Wilson wrote:
> > > Or we can push this wait to where it can interrupt, such as prepare_planes_fb.
> > > (For intel_atomic_commit_tail, intel_crtc_disable_noatomic() should always
> > > be a no-op.) And then we are down to just the shrinker running
> > > uninterruptibly, just one last place to fix.
> >
> > Hmm. Yeah I guess we could try to do this in a different place.
>
> If we do the intel_overlay_off() via mmio (rather than CS) that makes it
> simpler, as we just have to wait for the prior operation.
>
> I'm not imagining that we can just use mmio, right?
Yeah, I have a branch that always uses mmio for the overlay
enable/disable/flips. I finished rebasing it the other night,
though it seems I have a bit of a buglet in there on 830 on
account of the DOVSTA "overlay update finished" bit not being
truthful once the overlay has turned off. So still needs a bit
more work I think.
And we still need to use the ring for the texture cache vs.
overlay line buffers reconfiguration thing though. So far what
I have doesn't really split the steps apart that much. Ie. I
always emit the MI_OVERLAY_OFF as soon as the plane has turned
off. We could postpone it a bit just in case the plane is about
to be re-enabled almost immediately (eg. could be it's just
getting moved to the other pipe).
Though I'm not really sure if the cache reconfiguration alone
depends on the pipe somehow, or if we could just shut down the
pipe before the cache recofiguration has finished. I'd have to
play around with it a bit more to find out I guess.
So there are still a few unknowns with the mmio apporach.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-12-07 18:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 17:28 [PATCH 00/11] drm/i915: Overlay fixes ville.syrjala
2016-12-07 17:28 ` [PATCH 01/11] drm/i915: Fix oops in overlay due to frontbuffer trakcing ville.syrjala
2016-12-07 17:48 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 02/11] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff ville.syrjala
2016-12-07 17:44 ` Chris Wilson
2016-12-07 17:49 ` Ville Syrjälä
2016-12-07 17:56 ` [PATCH] " Chris Wilson
2016-12-07 18:11 ` Ville Syrjälä
2016-12-07 18:22 ` Chris Wilson
2016-12-21 14:45 ` [PATCH] drm/i915: Initialize overlay->last_flip properly ville.syrjala
2016-12-07 17:28 ` [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay ville.syrjala
2016-12-07 17:41 ` Chris Wilson
2016-12-07 17:51 ` Ville Syrjälä
2016-12-07 18:25 ` Chris Wilson
2016-12-07 18:45 ` [PATCH] drm/i915: Asynchronously wait for the overlay to finish Chris Wilson
2016-12-07 18:49 ` Ville Syrjälä [this message]
2016-12-07 17:28 ` [PATCH 04/11] drm/i915: Fix the overlay frontbuffer tracking ville.syrjala
2016-12-08 9:46 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 05/11] drm/i915: Use pipe_src_w in overlay code ville.syrjala
2016-12-08 8:35 ` Chris Wilson
2016-12-08 16:11 ` Ville Syrjälä
2016-12-07 17:28 ` [PATCH 06/11] drm/i915: Kill intel_panel_fitter_pipe() ville.syrjala
2016-12-08 8:31 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 07/11] drm/i915: Simplify SWIDTHSW calculation ville.syrjala
2016-12-08 8:40 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 08/11] drm/i915: Reorganize overlay filter coeffs into a nicer form ville.syrjala
2016-12-08 8:45 ` Chris Wilson
2016-12-08 16:17 ` Ville Syrjälä
2016-12-08 16:26 ` Chris Wilson
2016-12-22 19:55 ` Ville Syrjälä
2016-12-07 17:28 ` [PATCH 09/11] drm/i915: Use primary plane->state for overlay ckey setup ville.syrjala
2016-12-08 8:50 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 10/11] drm/i915: Disable L2 cache clock gating on 830 when using the overlay ville.syrjala
2016-12-08 9:39 ` Chris Wilson
2016-12-07 17:28 ` [PATCH 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround ville.syrjala
2016-12-08 0:02 ` kbuild test robot
2016-12-08 14:27 ` kbuild test robot
2016-12-22 19:52 ` [PATCH v2 " ville.syrjala
2016-12-22 21:40 ` Chris Wilson
2016-12-23 14:46 ` Ville Syrjälä
2016-12-07 20:22 ` ✓ Fi.CI.BAT: success for drm/i915: Overlay fixes (rev3) Patchwork
2016-12-21 15:45 ` ✓ Fi.CI.BAT: success for drm/i915: Overlay fixes (rev4) Patchwork
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=20161207184922.GW31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.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