[Intel-gfx] [PATCH 2/2] drm/i915: add module param for live_status

David Weinehall david.weinehall at linux.intel.com
Wed Aug 17 09:25:40 UTC 2016


On Wed, Aug 17, 2016 at 09:08:58AM +0100, Chris Wilson wrote:
> On Wed, Aug 17, 2016 at 11:02:32AM +0300, David Weinehall wrote:
> > Since the workaround for buggy displays that do not reply to
> > live status detect immediately affects a rather limited set of
> > displays, and since the price paid (almost 100ms per HDMI-port),
> > we should have that hack disabled by default.
> > 
> > Rather than leaving people with these kinds of broken displays
> > out in the cold completely, add a module parameter, defaulting
> > to -1 (live status detection on supported platforms, but without
> > the extra delays), that allows for re-enabling this hack.
> 
> No. It is a regression. We revert back to the previous status quo,
> and then try to introduce live-status checking in a way that works if at
> all possible.

The way I understand it, the only approaches that would allow for
combining live status checking with buggy displays are:

* The current behaviour (unconditionally waiting until we're sure
  that even the buggiest displays replies; wastes ~90ms per port
  on working setups when there's no display connected)

or

* live status check as in my patch, with the additional delay
  configurable

The other option is not to bother with with live status check at all.
It seems to work just fine for anything < gen 7; I'm not sure
if it's necessary for any newer setups either.

Seeing as I'm trying to optimise suspend/resume times, I'm kinda
biased towards any solutions that removes the delays by default.
Whether we remove them by doing the live status check without retries
by default (forcing users with buggy displays to enable the workaround)
or by ripping out the live status check completely isn't really
all that important to me. As long as we can get rid of the current
overhead.


Kind regards, David Weienhall


More information about the Intel-gfx mailing list