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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.