[Intel-gfx] New async patch for resume

[Daniel Vetter]

On Thu, Jun 05, 2014 at 08:48:37AM -0700, Jesse Barnes wrote:
> In digging into the async crtc stuff, I found it was going to be really
> difficult to prevent other functions from getting clobbered by a delayed
> crtc enable or disable.  Daniel's work to remove a bunch of the
> ->mode_set callbacks is a good start, but we still end up doing some reg
> reads and writes in the mode set path today.  Until those are cleared up
> and we somehow enforce a rule that all hw changes go through the crtc
> enable/disable paths with everything else staged in multithread safe structs,
> I don't think the async crtc approach will be solid.

Just a quick note: Once the runtim pm for dpms code is in, there's 0 hw
touching going on in mode_set callbacks. The only thing we still do in
there is computing the dpll config.

So if this is somehow annoying your feature work I think we should wait a
bit until that's landed.

> So, since resume is the biggest issue here anyway, I've tried making
> just the resume mode set asynchronous.  Even this is a bit tricky, since
> we need to apply any pending mode set at certain points, then check
> whether the crtc we're operating on in any given path is still active.
> I think I've caught those cases here, but if we have more we can use the
> intel_sync_mode_set() call with appropriate post-call checks (after we
> re-acquire the corresponding crtc mutex).
> 
> Feedback welcome.  This has seen light testing on my BYT and really
> reduces the time spend in the i915 _thaw function, letting userspace
> start running much sooner than before.

I think we've very quickly discussed this on irc, so here's the recap. Rob
Clark's atomic modeset also has an async mode. And we have an awful lot of
code to port over to atomic modeset, and I'm vary of adding more i915
custom solutions which some poor schlock (Ville or me, most likely) needs
to convert.

So from that pov I'd really prefer we'd pour this effort into pushing
Rob's and Ville's patches forward. Of course the delaying probing can go
in, and also the other stuff you're working on I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch