From: Keith Packard <keithp@keithp.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/8] drm/i915/dp: clear DP encoder CRTC if the receiver disappears
Date: Fri, 01 Jul 2011 17:31:32 -0700 [thread overview]
Message-ID: <yunpqlted5n.fsf@aiko.keithp.com> (raw)
In-Reply-To: <20110701165948.0e82225b@jbarnes-desktop>
[-- Attachment #1.1: Type: text/plain, Size: 1628 bytes --]
On Fri, 1 Jul 2011 16:59:48 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> That depends on what behavior we want. With the previous fixes, if you
> unplug, we'll get a hotplug event, fail to detect a link, and tear down
> the receiver. With the old code you'd get bad behavior unless you had
> hit a DPMS path earlier.
Yeah, the old code was clearly wrong; this looks like something that
needs fixing, I just don't know what the right fix is.
> A subsequent hotplug will be ignored as far as link training goes, since
> we don't have a receiver configured.
Do we need separate variables for 'should be configured' and 'actually is
configured' then? We need to know if there is a configuration we should
be selecting, and then we need to know whether the display is actually
using that configuration.
> In both cases, we'll emit hotplug events to userspace, which is free to
> react (or not) however it wants.
Let's assume (for now) that user space doesn't do anything. That seems
like a good first step to get right; we should assume that if user space
sets some mode then it should work correctly.
> So I think we'd need to leave the receiver_configured bit set even if
> the hot plug re-train failed, and just try it again on the next hot
> plug (assuming we want to preserve user configs across hot plug
> events and not just let userspace handle the hotplug events).
I don't think we want to lose the user config -- in the absence of any
user-driven changes, we want to reset the mode exactly as it was when
the monitor is plugged back in.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2011-07-02 0:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 22:22 [RFC] misc DP fixes/changes Jesse Barnes
2011-07-01 22:22 ` [PATCH 1/8] drm/i915/dp: retry link status read 3 times on failure Jesse Barnes
2011-07-01 23:41 ` Keith Packard
2011-07-01 23:47 ` Jesse Barnes
2011-07-06 4:27 ` Eric Anholt
2011-07-06 16:09 ` Jesse Barnes
2011-07-01 22:22 ` [PATCH 2/8] drm/i915/dp: use DP DPCD defines when looking at DPCD values Jesse Barnes
2011-07-01 23:43 ` Keith Packard
2011-07-01 22:22 ` [PATCH 3/8] drm/i915/dp: read more receiver capability bits on hotplug Jesse Barnes
2011-07-01 23:45 ` Keith Packard
2011-07-01 22:22 ` [PATCH 4/8] drm/i915/dp: try to read receiver capabilities 3 times when detecting Jesse Barnes
2011-07-01 23:45 ` Keith Packard
2011-07-01 22:22 ` [PATCH 5/8] drm/i915/dp: set DP DPMS mode to "on" in ->commit Jesse Barnes
2011-07-01 23:46 ` Keith Packard
2011-07-01 22:22 ` [PATCH 6/8] drm/i915/dp: clear DP encoder CRTC if the receiver disappears Jesse Barnes
2011-07-01 23:48 ` Keith Packard
2011-07-01 23:59 ` Jesse Barnes
2011-07-02 0:31 ` Keith Packard [this message]
2011-07-01 22:22 ` [PATCH 7/8] drm/i915/dp: rename dpms_mode to receiver_configured Jesse Barnes
2011-07-01 23:50 ` Keith Packard
2011-07-01 22:22 ` [PATCH 8/8] drm/i915/dp: clear receiver_configured when link training fails Jesse Barnes
2011-07-01 23:51 ` Keith Packard
2011-07-01 23:39 ` [RFC] misc DP fixes/changes Keith Packard
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=yunpqlted5n.fsf@aiko.keithp.com \
--to=keithp@keithp.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.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