From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH v4 15/22] drm/tilcdc: Get rid of complex ping-pong mechanism Date: Thu, 25 Feb 2016 08:55:24 +0200 Message-ID: <56CEA55C.2000306@ti.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1994463952==" Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7BDAD6E927 for ; Thu, 25 Feb 2016 06:55:32 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark , Jyri Sarha Cc: "dri-devel@lists.freedesktop.org" , Laurent Pinchart List-Id: dri-devel@lists.freedesktop.org --===============1994463952== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Un51sa4do7Dd3cDIAQjfp12v4lKoQqeLt" --Un51sa4do7Dd3cDIAQjfp12v4lKoQqeLt Content-Type: multipart/mixed; boundary="V7XMTMI1HawWBOLHGr9wH5vFwPfj2rG8W" From: Tomi Valkeinen To: Rob Clark , Jyri Sarha Cc: "dri-devel@lists.freedesktop.org" , David Airlie , Daniel Vetter , Laurent Pinchart Message-ID: <56CEA55C.2000306@ti.com> Subject: Re: [PATCH v4 15/22] drm/tilcdc: Get rid of complex ping-pong mechanism References: In-Reply-To: --V7XMTMI1HawWBOLHGr9wH5vFwPfj2rG8W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/02/16 22:31, Rob Clark wrote: > On Wed, Feb 24, 2016 at 11:48 AM, Jyri Sarha wrote: >> From: Tomi Valkeinen >> >> Get rid of complex ping-pong mechanism and replace it with simpler >> single buffer flipping code. >> >> The LCDC HW appears to be designed mainly static framebuffers in >> mind. There are two modes of operation, either static single buffer, >> or ping pong double buffering with two static buffers switching back >> and forth. Luckily the framebuffer start address is fetched only in >> the beginning of the frame and changing the address after that only >> takes effect after the next vertical blank. The page flipping code can= >> simply write the address of the new framebuffer and the page is >> flipped automatically after the next vertical blank. Using the ping >> pong double buffering makes the flipping code way more complex and it >> does not provide any benefit, so it is better to switch to single >> buffer operation. >> >> There is still one problem in updating the framebuffer dma address on >> the fly. There are two registers defining the framebuffer dma area and= >> things may break if the dma address is fetched in while the registers >> are are being updated. >=20 > Just curious, but does this mean you need to avoid writing the reg's > too near to vblank? (I think there are other drivers which do not Yes. > have double buffered registers and must do this.. but it's a pain..) >=20 > The ping-pong mode is super-wonky, and would be nice to get rid of.. > but with this scheme I'm not quite sure what happens if a pageflip > comes in too close to vblank.. It's the same problem with both single and double buffer (ping-pong) modes. The HW is designed to have a static configuration of one or two buffers, never changed at runtime. If you change the buffers at runtime, and change them exactly at the bad time during vblank when the HW starts using the start and end addresses, you end up with broken display. In other words, using the double buffering mode only adds extra complexity to the driver, without any benefit. In fact, with the double-buffering mode I think it's impossible to make the system reliable. The driver cannot reliably track which of those two buffers are currently shown on the screen, so when you do a page flip, you could flip the wrong buffer. The next patch adds some safety margin for the "page-flip near vblank" issue. Tomi --V7XMTMI1HawWBOLHGr9wH5vFwPfj2rG8W-- --Un51sa4do7Dd3cDIAQjfp12v4lKoQqeLt 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 iQIcBAEBCAAGBQJWzqVdAAoJEPo9qoy8lh71N8oP/3zRznlfAVc3fypcwCHFNttZ OZgxDXtaGvPOwOFgVRLglGi+K3u9tUIDB0LnaQznnYC4i5eBMoPOPzfUHdyXALBB dUXuQRU4hzhiIJe4AVtFZswylZSETUkg6VihxtI+PLcLtGKwNmckuO7hMkH51Mqi UnlPW6mQXZFEcX77NzCPmuN546NKi5qBr45J3pNqq79rG3OxEQEOuBfX/e6WpObs KxNa6i05W6747WcQPiwS/asB9Jv7OvkxUUtbEy+g/Ku+5CXrtJZ3MIlTyP41zEN3 ZJ6iEY5aEqdxARM9Wp1v0YMP4kkjqKb54LNt1wCr/3vMRllzKoj32tHydkgRpYZq GzRw/xQo3Tkr67MsC5phazaGTQaGt0PIrmhCxFjOBy3uTL7PFlq3/8iwGypQZlXS kfg2L1hPoqu4R3v3CwnrB9OiEx0nSeUPWvLxtsMM5PtDLmOuqMg5rpKpui5g3Zi0 rajiLoSrdk4ermcikISEzGG4alv+tP9G5TWxfotdptFISuYiRp9T3gaXNqWJxsOt V+USRgtu9gMZGMOZd0dycUUQQjTCcxTmbsq6yMngA+SdJZCnPIelo8lDcCWdDS6K C/NTlQKR+fIEtoz0NLMCZvIcyUmZLfbdTHY1gjxqeSdRkdwQBhvcIhJag3U7A8uD FBptBQfdRB1h9nqiazzP =EF2a -----END PGP SIGNATURE----- --Un51sa4do7Dd3cDIAQjfp12v4lKoQqeLt-- --===============1994463952== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1994463952==--