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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
