New async patch for resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Thanks,
Jesse


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux