From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: Fixing the hotplug storm bugs once and for all? Date: Mon, 26 Jul 2010 11:45:22 -0700 Message-ID: <87vd82ulod.fsf@pollan.anholt.net> References: <87fwz63zu2.fsf@pollan.anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1178458260==" Return-path: In-Reply-To: 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: Andrew Lutomirski Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1178458260== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 26 Jul 2010 14:06:52 -0400, Andrew Lutomirski wrote: > On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt wrote: > > On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski wr= ote: > >> For well over a year now, I (and apparently lots of other people) have > >> had to run patched kernels to avoid crippling hotplug storms. > >> > >> As far as I can tell, on my laptop, enabling DPC_HOTPLUG_INT_EN is > >> safe, but setting either DPB_... or DPD_... (or both) will cause > >> intermittent hotplug interrupt storms. =C2=A0(Turning off all three DP > >> hotplug bits also makes the laptop stable but prevents the DP port > >> from working.) > >> > >> My laptop is a Lenovo X200s with VGA and LVDS on the laptop itself and > >> DP on the docking port. =C2=A0If I boot w/o the docking port, I have: > >> > >> > >> General definitions block: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 CRT DDC GMBUS addr: 0x02 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Use ACPI DPMS CRT power states: no > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Skip CRT detect at boot: no > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Use DPMS on AIM devices: yes > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Boot display type: 0x0000 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 TV data block present: yes > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Child device info: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Device type: 1= 009 (TV) > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AIM offset: 0 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DVO port: 0x05 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Child device info: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Device type: 1= 022 (LFP) > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AIM offset: 52= 048 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DVO port: 0x04 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Child device info: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Device type: 6= 8c6 (DisplayPort) > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature: > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AIM offset: 61= 152 > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DVO port: 0x08 > >> > >> Maybe it's time we started reading that part of VBIOS to detect which > >> outputs really exist. =C2=A0(If that's unsafe, we could add a DMI list= .) > >> > >> Any thoughts? =C2=A0It would be nice if 2.6.36 could work without patc= hes. > > > > We had patches to not probe outputs unless they were in child dev tables > > for a while. =C2=A0The issue with reading child dev tables is that some > > BIOSes would give you different child dev results depending on whether > > you were docked or not, so you wouldn't get your DP probed unless you > > booted docked. > > >=20 > Do you have a link? I can try to resurrect them. >=20 > (Can Xorg handle new outputs appearing and disappearing at runtime? > If not, we could just pretend to create all possible outputs up > front.) Yeah, I was figuring set up all outputs, and just always report disconnected unless it's in the child dev tables. We can worry about making a pretty output list later after things *work*. commit 6207937d4feea000913e8ca23fe20c7744be7847 Author: Zhao Yakui Date: Wed Jan 6 09:49:31 2010 +0800 drm/i915: Don't use the child device parsed from VBT to setup HDMI/DP =20=20=20=20 On some boxes the BIOS will report different child device arrays when the system is booted with/without the dock. In such case the HDMI/DP port can't be setup correctly. So revert two commits (fc816655236cd9da162356e96e74c7cfb0834d92/ 6e36595a2131e7ed5ee2674be54b2713ba7f0490) that use the child device parsed from VBT to setup HDMI/DP. =20=20=20=20 http://bugzilla.kernel.org/show_bug.cgi?id=3D14854 http://bugzilla.kernel.org/show_bug.cgi?id=3D14860 =20=20=20=20 Signed-off-by: Zhao Yakui Tested-by: Sean Young Signed-off-by: Eric Anholt --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxN18MACgkQHUdvYGzw6vcFDQCfeGsPEb+/unQ1JZU3pv76m/UN 94AAn0f2pphQ1xCrLxThS1Dl1DJ8FQ5R =X8OP -----END PGP SIGNATURE----- --=-=-=-- --===============1178458260== 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 --===============1178458260==--