From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jyri Sarha Subject: Re: [PATCH RFC 00/11] drm/tilcdc: Atomic modeset support Date: Tue, 10 May 2016 00:16:45 +0300 Message-ID: <5730FE3D.3030407@ti.com> References: <57309A38.6000702@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0686376215==" Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by gabe.freedesktop.org (Postfix) with ESMTPS id 738076E3EF for ; Mon, 9 May 2016 21:17:08 +0000 (UTC) In-Reply-To: <57309A38.6000702@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen , dri-devel@lists.freedesktop.org Cc: laurent.pinchart@ideasonboard.com List-Id: dri-devel@lists.freedesktop.org --===============0686376215== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qU8liKJEr1eLkknP8Tb1HhoSOoRrjq3Ju" --qU8liKJEr1eLkknP8Tb1HhoSOoRrjq3Ju Content-Type: multipart/mixed; boundary="TdSQx0DHXvX5AAbqxuRCFDf1iEe7dmLK8" From: Jyri Sarha To: Tomi Valkeinen , dri-devel@lists.freedesktop.org Cc: airlied@linux.ie, daniel@ffwll.ch, laurent.pinchart@ideasonboard.com, robdclark@gmail.com Message-ID: <5730FE3D.3030407@ti.com> Subject: Re: [PATCH RFC 00/11] drm/tilcdc: Atomic modeset support References: <57309A38.6000702@ti.com> In-Reply-To: <57309A38.6000702@ti.com> --TdSQx0DHXvX5AAbqxuRCFDf1iEe7dmLK8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/09/16 17:10, Tomi Valkeinen wrote: > Hi Jyri, >=20 > On 11/04/16 19:46, Jyri Sarha wrote: >> The LCDC in its simplicity does not fit too well into DRM atomic >> modeset abstractions. I wonder if I am doing the right thing in >> implementing the dummy primary plane and in implementing >> mode_set_nofb() crtc helper when the crtc actually needs the >> framebuffer to be there when configuring it. See individual patch >> descriptions for details. There is still lot of room for cleaning up >> but I would first like to know if I am moving at all to the right >> direction. >=20 > I'm no expert on atomic modesetting, but here are my comments/questions= : >=20 > You add drm_crtc_vblank_off() to crtc_destroy() callback. Why is that? = I > think you should call drm_crtc_vblank_on() in crtc_enable(), and > vblank_off in disable. >=20 I did not really think of that. I'll make the change. > You remove the setting of tilcdc_crtc_helper_funcs.dpms, but leave the > tilcdc_crtc_dpms, which you use elsewhere. I think all dpms stuff shoul= d > be removed from crtc, as it's all either "enable" or "disable". Git gre= p > shows that in omapdrm, there's just one reference to dpms, in > omap_connector.c: .dpms =3D drm_atomic_helper_connector_dpms >=20 I left that for subsequent clean up after general approach is accepted. > It's not clear to me if a (primary) plane is required with atomic > universal planes and modesetting or not... I guess it is, when thinking= > of how e.g. a framebuffer is configured to be shown on a screen when > using the atomic modesetting uapi. >=20 As modeset_nofb is the preferred call back for setting the mode, and it does not require any fb or plane, I needed something to express the mandatory framebuffer. The primatry plane just wast the first solution that came to my mind and it appeared to work. > But if it is required, it makes me wonder, are there other HWs out ther= e > without any planes? The dummy plane implementation you added is not > complex, but is it something that should be implemented with DRM helper= > funcs? >=20 > Tomi >=20 --TdSQx0DHXvX5AAbqxuRCFDf1iEe7dmLK8-- --qU8liKJEr1eLkknP8Tb1HhoSOoRrjq3Ju 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.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXMP5LAAoJEJA2s1DX1hlB0FoP/Rh/w1L13JWF3Pylsa2xOSN8 7WZMpEbh4gIUtSpIBPn29v31Ox6MX9auCjxwRzAywNOAB8FfP9xOuw1YplRS6eAo As1iXUUENUtOz62r4/zF14c0wyYCz85O/Sq2dOpJHY0MH7FoNmIOO76LC66nxuuj tkPyKHVXMZnrBEnIdKdUXp1UDEX/s1gTZrwmVkMarQ2vNCRnA9kJRPvtEtOIx1Xc B7Djrr+P9SWKjgu3Yrk7KlEOrC+U4Hfxizt9rrWFBaYAYZZfIX6aVWt6xNKSoT+r 5Z1ci+a2nGaHKzdoExbOOo1Y5ebXQr0/MyDOvqr53Ea7I4seow+ZKUPyG2rpM+OT NQP3YPPLS2QZHYc6dRwW87M5ururTl03tBPO2Abc5bkx9AclA45KTb8nWot6c3T5 PdD9QowPSNC/MvBAyTScXnmurzNrbvzR/GuwNsCNCxj5IQrbtg2G/DKYuK9jLJMt 00CGvNbeLD3O9zACkoiwdo5VsqcGwYnuDbE8SEW7YAe2DWejJu/+YyOgmrH+Zcdq CGt+/CoORMLLjVSJN3lrv4I+JmDNMdkMUjKnWZasV5a+NFxqnLnowaW0sfQLaS6g aMy8GY+2aPWVv5uKBcl7JBKrESXTfPYRPrKR5EeURAp7d7RwCXNBKX8xbcvxsDdW 0t1EZM+6zBxOdTKm9Qef =zXCv -----END PGP SIGNATURE----- --qU8liKJEr1eLkknP8Tb1HhoSOoRrjq3Ju-- --===============0686376215== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0686376215==--