From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard 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 Message-ID: References: <1309558978-4704-1-git-send-email-jbarnes@virtuousgeek.org> <1309558978-4704-7-git-send-email-jbarnes@virtuousgeek.org> <20110701165948.0e82225b@jbarnes-desktop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2030847588==" Return-path: Received: from keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTP id 071249E78D for ; Fri, 1 Jul 2011 17:31:36 -0700 (PDT) In-Reply-To: <20110701165948.0e82225b@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============2030847588== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Fri, 1 Jul 2011 16:59:48 -0700, Jesse Barnes = 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. =2D-=20 keith.packard@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFODmbkQp8BWwlsTdMRAscCAKCq+fRUlh3F9ZlkTxGv88MKOlPM4wCgtFVq P0rx/3di8CynHp549thuH10= =iDwP -----END PGP SIGNATURE----- --=-=-=-- --===============2030847588== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============2030847588==--