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