From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH 01/33] drm/omap: HDMI: change enable/disable to avoid sync-losts Date: Tue, 23 Feb 2016 13:33:33 +0200 Message-ID: <56CC438D.7090903@ti.com> References: <1455875288-4370-1-git-send-email-tomi.valkeinen@ti.com> <1455875288-4370-2-git-send-email-tomi.valkeinen@ti.com> <2115833.N0OHxhSoJc@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1195773713==" Return-path: Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by gabe.freedesktop.org (Postfix) with ESMTPS id D6BD06E341 for ; Tue, 23 Feb 2016 11:33:39 +0000 (UTC) In-Reply-To: <2115833.N0OHxhSoJc@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1195773713== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iA35pT0lmlPjm5b7spBgcebH3BfIo6OMR" --iA35pT0lmlPjm5b7spBgcebH3BfIo6OMR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/02/16 12:22, Laurent Pinchart wrote: > Hi Tomi, >=20 > Thank you for the patch. >=20 > On Friday 19 February 2016 11:47:36 Tomi Valkeinen wrote: >> We occasionally see DISPC sync-lost errors when enabling and disabling= >> HDMI. Sometimes we get only a few, which get handled (ignored) by the >> driver, but sometimes there's a flood of the errors which doesn't seem= >> to stop. >> >> The HW team has root caused this to the order in which HDMI and DISPC >> are enabled/disabled. Currently we enable HDMI first, and then DISPC, >> and vice versa when disabling. HW team's suggestion is to do it the >> other way around. >> >> This patch changes the order, but this has two side effects as the pix= el >> clock is produced by HDMI, and the clock is not running when we >> enable/disable DISPC: >> >> * When enabling DISPC first, we don't get vertical sync events >> * When disabling DISPC last, we don't get FRAMEDONE event >> >> At the moment we use both of those to verify that DISPC has been >> enabled/disabled properly. Thus this patch also needs to change the >> omapdrm and omapdss which handle the DISPC side. >> + if (omap_crtc->mgr->output->output_type =3D=3D OMAP_DISPLAY_TYPE_HDM= I) { >> + dispc_mgr_enable(channel, enable); >> + return; >> + } >=20 > This effectively bypasses the wait until the DISPC outputs the first vs= ync=20 > interrupt below. How does HDMI differ from other outputs in such a way = to make=20 > the wait unneeded ? There's to parts here. Enabling the output and disabling the output. Enable: We don't strictly need the wait after enable for any output. The output works after setting the enable bit. There are two reasons for the waiting: 1) A sanity check that the configuration is ok. If the config is broken (which shouldn't happen, of course, as the driver should verify the config), we won't see vsync. At the moment we only print an error in that case. 2) OMAP_DSS_CHANNEL_DIGIT is a bit problematic. That channel is used for analog tv-out (VENC) in older DSS versions, and for HDMI for more recent ones. With VENC we always get a few sync lost errors when enabling the output, so with the wait we can ignore those errors (this sync-lost ignoring is only done for OMAP_DSS_CHANNEL_DIGIT). We have seen similar sync losts with HDMI too, but apparently it is possible to support HDMI without any sync losts. That's what this patch is doing. With this patch we lose both 1) and 2) above, but 1) is not strictly needed and 2) shouldn't happen for HDMI after this patch. We could implement 1) in the HDMI driver too, using the HDMI IP's VSYNC interrupt, but I don't think it's really necessary. Disable: When disabling the output, we do want to wait until the DSS has finished the work at the end of the frame. This is done in the omap_crtc_set_enabled() function for all outputs, using FRAMEDONE interrupt when available, or VSYNC if not. For HDMI we can do it also in the HDMI driver. The HDMI IP has its own FRAMEDONE interrupt, which we wait for in hdmi_wp_video_stop(). Tomi --iA35pT0lmlPjm5b7spBgcebH3BfIo6OMR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWzEONAAoJEPo9qoy8lh718A0QAKTv+Hk4RDyiX9EBL6sSa9G7 /qd2jSefptPqTg2bKA2wE501FD1AtvBHqevRylrQw/f0OP+secK7DgtG1gYYakFt v87qk6O1qf3YS/WOZV6okuNA2bp0xflFjFAqLZEI6q2IjFAP8U9MN8IlNESrcDi4 yOAN4svcvQNskiIGHYt35aYjNxMWJn2DzSESzvwqMxYUTiJ00IZ9FwjfKwRwuCNx cEqypazyhb3baITzVqp+tiBPg5bXLz02u+qU7y5J+wmin7gOyztZkV+09fRVFcCd PaNKn7PhSFcaEkfd2hl6vdImKSwfVbNq2NjOfp8yCMwDzODPfjDzSQBqiFtfAjTJ XXk0GCXf7cqCz/kItB7lr6/in+43KlaAmOkArAJmYSgT5XvR3VkuTa/W6nLxwHl/ W+HaoSZaKBMNgt1fjwlfMKjgXtLV3LE4z1w5WRX0Kww7rHqV8QrU+BNb/9M/l7lZ vEvJVTyo5MJSyYyoSB62REDXeweojQRUzb5sk5BPf8YAGx5HIJC6sdee/NC4DslT ug5X4e+9IphkoPhKeydmDvjBI/Hm8ZGLv7hE7PQ9TQxW0G6GxHtAdQYGaP7vVuIK Vhzg05tyxW1f+/7R27J+o7K/ID4t5j1nClTJur3LYkdkqw+2893RiAmwFCUqScSn o8FPCz05Nfjvp2g0Fcbl =jWE7 -----END PGP SIGNATURE----- --iA35pT0lmlPjm5b7spBgcebH3BfIo6OMR-- --===============1195773713== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1195773713==--