From: David Weinehall <david.weinehall@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: add module param for live_status
Date: Wed, 17 Aug 2016 12:25:40 +0300 [thread overview]
Message-ID: <20160817092540.wtukfkctppovwnb4@boom> (raw)
In-Reply-To: <20160817080858.GE22696@nuc-i3427.alporthouse.com>
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-17 9:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 8:02 [PATCH 0/2] Live status detection fixes David Weinehall
2016-08-17 8:02 ` [PATCH 1/2] drm/i915: Skip live status if not supported David Weinehall
2016-08-17 8:02 ` [PATCH 2/2] drm/i915: add module param for live_status David Weinehall
2016-08-17 8:08 ` Chris Wilson
2016-08-17 9:25 ` David Weinehall [this message]
2016-08-17 9:35 ` Chris Wilson
2016-08-18 9:56 ` Daniel Vetter
2016-08-17 8:35 ` ✗ Ro.CI.BAT: failure for Live status detection fixes Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160817092540.wtukfkctppovwnb4@boom \
--to=david.weinehall@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox