From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH] drm/dp: Do not busy-loop during link training Date: Mon, 14 Dec 2015 16:23:41 +0100 Message-ID: <20151214152341.GA1998@ulmo> References: <1450099316-31126-1-git-send-email-thierry.reding@gmail.com> <20151214144809.GO4437@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0563208311==" Return-path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by gabe.freedesktop.org (Postfix) with ESMTPS id 724E06E0D4 for ; Mon, 14 Dec 2015 07:24:15 -0800 (PST) Received: by wmnn186 with SMTP id n186so125612930wmn.0 for ; Mon, 14 Dec 2015 07:24:14 -0800 (PST) In-Reply-To: <20151214144809.GO4437@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0563208311== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 14, 2015 at 04:48:09PM +0200, Ville Syrj=C3=A4l=C3=A4 wrote: > On Mon, Dec 14, 2015 at 02:21:56PM +0100, Thierry Reding wrote: > > From: Thierry Reding > >=20 > > Use microsecond sleeps for the clock recovery and channel equalization > > delays during link training. The duration of these delays can be from > > 100 us up to 16 ms. It is rude to busy-loop for that amount of time. >=20 > Do you have some numbers on how this affects a typical link training > cycle? Not really. Sinks aren't required to provide a value here, in which case the specification says that a default of 100 us and 400 us should be used for clock recovery and channel equalization, respectively. If the sink provides an AUX_RD_INTERVAL value, it is used for both CR and CE (and is in units of 4 ms). Best case a typical link training cycle would therefore take something like 0.5 ms and worst case, since the number of retries should be limited to 5, it'd be around 5 * 16 ms =3D 80 ms. That's not counting the actual AUX transactions, though they should be pretty fast. Since this patch uses usleep_range(min, min * 2) the worst case now becomes ~ 160 ms. That's still not very much from a responsiveness point of view, but the upside is of course that there are no busy loops that could potentially hog the CPU. Thierry --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWbt76AAoJEN0jrNd/PrOhTAIQAKCyJYm3gKvObxwaeGX50WSv Oc97k0hs9yqzFZ3dvqS9Ac+t4RneJm3UA8VNYzn0qu3AhMbRo3RSf7qgNeOHaLT/ SbrwYpFn5iABRgLgynANIlcRcl1zVZElkHR7IqAk6+mGDI978EE7MFui47+4uMqV DHeBmnIuWMXxh185Sfmh33y2GNMX5xvK1VRkdV7w3foIzDcR58ij9PuNutkyDY/u GbSpnQCT0/btkV9SDAJ/9JfUFumTKq0bj7yofertRd7jhb/GRgQaG2Q/6qQQjyxv YyMPQSKwiKNE8iq1xqoxgyz7lIwSA1UN6GRrcvvhaHcdP6MxPeKtdDXgnW0JPYUV JR6iNUGkC2MD/4vhUqlL83V+RSDAKggrzFJL1hfVrtNTBnxZv6zLzSnXJzZVRISo j/yqzw7bQIpIVBwGOo8wsA8ZSzjw4tD3/s7eDAEM38GlwVMERm9NeZEQXdj5CJYF FXhkvSwHgw8CAtBjGbBem1LddY+vWitqqvAVrcfxCYnJl+kNSuyOaCtEnDmUjxuI 4vhcMrU2sbxarQtNtyzsoYSQRujqyAMOdWgErqxar+G+hBh5kRgQgnZ0fRlYz8VH x8c4nPLUyigPFFWgJFLYJsb2K5dWBJ760No93onnrhDv0pFxyeB3KcMttXwrqH/Q L00X8uguKAl3N+EwXYfW =Udcg -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- --===============0563208311== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0563208311==--