[Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[Ville Syrjälä]

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