From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: Broken LVDS output at mode changes Date: Fri, 30 Mar 2012 09:56:48 -0700 Message-ID: <20120330095648.2488dcd8@jbarnes-desktop> References: <20120329121638.GA20275@phenom.ffwll.local> <1333025081_141778@CP5-2952> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0480780527==" Return-path: Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by gabe.freedesktop.org (Postfix) with SMTP id 77E8C9E9F2 for ; Fri, 30 Mar 2012 09:56:53 -0700 (PDT) In-Reply-To: <1333025081_141778@CP5-2952> 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: Chris Wilson Cc: Takashi Iwai , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0480780527== Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/vk0qzdgpnNo=9UzGy1W+QfC"; protocol="application/pgp-signature" --Sig_/vk0qzdgpnNo=9UzGy1W+QfC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 29 Mar 2012 13:44:28 +0100 Chris Wilson wrote: > On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter wrote: > > On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote: > > > Hi, > > >=20 > > > we've encountered a broken LVDS output on some IVY/SNB machines when > > > the mode is changed (from/to native resolution). When this happens, > > > the whole laptop panel gets half white and half black. This doesn't > > > recover until the LVDS is turned off once. > > >=20 > > > And, there is no signficant difference between working and non-working > > > cases in the register dumps. From the software POV, all looks sane. > > > So, we suspect this is rather specific to some panel hardware. > > >=20 > > > However, through debugging, I found that disabling LVDS at mode change > > > works around the problem. A test patch is attached below. > > >=20 > > > My question now is: can this workaround have any serious drawback? > > > I thought of a longer blank time, but I didn't notice any difference > > > before and after the patch. > > >=20 > > > Or, any other suggestion as a saner fix? > >=20 > > No idea, I'm wondering though whether we should just accept some > > flickering while modesetting unconditionally. Does anyone know what > > Windows does in this case and at least on my work machine here it looks > > like Windows just blanks the screen. I haven't checked with reg dumps > > though how exactly they upscale stuff on lvds. > >=20 > > git blame says that Chris Wilson created the original PCH_SPLIT check. > > Chris, any comments on this? >=20 > It dates back from an earlier commit that presupposes that we can modify > the panel on the fly and avoid the power-cycling delays. >=20 > PP_STATUS: Panel Power On Status [bit 31] >=20 > In conjunction with bits Power Sequence Progress field and Power Cycle > Delay Active, this bit set to a one indicates that the panel is > currently powered up or is currently in the power down sequence and it > is unsafe to change the timing, port, and DPLL registers for the pipe or > transcoder that is assigned to the panel output. >=20 > Guess that rules that out. Yeah but the docs are too conservative there. In many cases it's fine to modify things while the panel is on, it just requires lots of testing for the different cases. On newer chips changing the panel fitting should be ok while the panel is active, but on older ones we need to shut down the panel first (I think the split is around Cantiga/Ironlake). --=20 Jesse Barnes, Intel Open Source Technology Center --Sig_/vk0qzdgpnNo=9UzGy1W+QfC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPdeXQAAoJEIEoDkX4Qk9hzukQAJwzGaqeEQ9eWUf/leVMukHj VHTyJhqUgs3b9GEUbBTnezN7nHulnnLEay8licbaOLYjGHMdG6vTcxM/L1QkWkSf mwXSuTt/9A4w6+eCB5ITVkuHaydTUaMbNEfKsosZJhN/eFPy9fq66XMc5voRcVML xGNmaK1OeYkP5h4Ml/3IWhDLeYA1QQLiHJUiaFByTbHkgLotgfnhqpYK/T5scQaS JCGCCrP0fkPzaFmuhAGAf+6ONa8k5HpDv4sx/0vKCI5R4qEHuIknMX5B2WLp2Nts VyfDCfEItGitlO2/L1bbneQqAU1ZfiF/a1vQmTN+IMGcCT3RjnLR9yTsyA6Js/Tu mzRJTxOTUepNd7IyibOnHa4XDARyJMvk17ALAZ/ztZt0OEfnlM0Goud5rJl9dUHn Qp4L3gucCPTXV9Jr0lCwzORRFSn/m21a164B4WHIQi2AFq0OJqxypqp3FMn+tUb7 s9GXe+3g9TKiodNYdnH7b4JC/+qhm+PLZk28v90pktlcgNqLI6ic7H9oSi6SDUCO YARQRVge58Kem/Mxg+78Z790wzUoJ9ZBJcYwqOjXUKDmjkt9o3mnkWNrfl1RercW QVOW0QXTI3A4oCG1dm1ZuxYKpfzZyke012yyPo8l5rlyqWFNcTwGOf5M1oaRjfMj 8nu834NLMUNXkoW4AKj+ =zrxh -----END PGP SIGNATURE----- --Sig_/vk0qzdgpnNo=9UzGy1W+QfC-- --===============0480780527== 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 --===============0480780527==--