From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD Date: Tue, 31 Jan 2017 12:13:09 -0800 Message-ID: <87tw8fxa22.fsf@eliezer.anholt.net> References: <20170126123728.5680-1-martin.peres@linux.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1225759190==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 5E6C66E2AA for ; Tue, 31 Jan 2017 20:13:11 +0000 (UTC) In-Reply-To: <20170126123728.5680-1-martin.peres@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Martin Peres , xorg-devel@lists.x.org Cc: Manasi Navare , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1225759190== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Martin Peres writes: > Despite all the careful planing of the kernel, a link may become > insufficient to handle the currently-set mode. At this point, the > kernel should mark this particular configuration as being broken > and potentially prune the mode before setting the offending connector's > link-status to BAD and send the userspace a hotplug event. This may > happen right after a modeset or later on. > > When available, we should use the link-status information to reset > the wanted mode. > > Signed-off-by: Martin Peres If I understand this right, there are two failure modes being handled: 1) A mode that won't actually work because the link isn't good enough. 2) A mode that should work, but link parameters were too optimistic and if we just ask the kernel to set the mode again it'll use more conservative parameters that work. This patch seems good for 2). For 1), the drmmode_set_mode_major is going to set our old mode back. Won't the modeset then fail to link train again, and bring us back into this loop? The only escape that I see would be some other userspace responding to the advertised mode list changing, and then asking X to modeset to something new. To avoid that failure busy loop, should we re-fetching modes at this point, and only re-setting if our mode still exists? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAliQ79UACgkQtdYpNtH8 nuiMMBAAiyzrVfTlFcjMQtCje4pRnpzhCXrRM9El5Ek95My5J/07f00LVWf1z6Kp bbdhVVlW7rIdBXb8wQwlH7u4X+Cl/fnKURKA+mjUDhzjy4uxHeZ4RrsTLKSBuKvh BAtMRwva6tgi+qlPThyGnGnvtZPhqWJMO6c/NK6RtA+eHe5JuJS2DXFDCfF0ZZZ5 t5M3Q+zXcR1ixCvqnnFhWGgHxZZTRhboad8HRO4EsODg2BKho0j5tZ8hJw8RBkBW AYC0F4aLZ/dhdQEI+xZadjs/uKAvVqLjFcLSlNwheQPoguMy2Z/ntV2npsbWaOOi kJ2aHXZ+S0kWMHZ2ws0lWnK0C4RTe9g9Z/8NoYeBY4S0+mUqSriPDr95olmpnppB W9hTXaLeTnYEtU+cjW9wGT9zdKlPDF5MtEHtGty9Ihrg5G/XbHAAzPU9+rUvdaU9 qgaXqvmHsVlIOJOcWjQFjrf+E7QMHhdUtDnL2dZzYznrEPe7dpWXca5wd+YHRmJJ 1LK5A9+Km4p3zXx1uyH4+6NjjoO0xTqzOPHhmKbNGJfBocSZBFa8aS6SqK9vg4TC AJh+bfdXJPKTWc//f8WmwHpstFffsbwOEcpwqgKBLM9LmazdQ+7jz7Q3bNBIuIV3 WGZynFsuXrO+dFMoDIMvy6paivi+u1NRetZlTY00+1bjj8LZkTQ= =ejzk -----END PGP SIGNATURE----- --=-=-=-- --===============1225759190== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1225759190==--