From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Date: Thu, 10 Dec 2015 17:15:09 +0000 Subject: Re: [PATCH RFC 0/9] omapdrm/omapfb/omapdss split Message-Id: <5669B31D.6000102@ti.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ" List-Id: References: <1449757535-5674-1-git-send-email-tomi.valkeinen@ti.com> In-Reply-To: To: Emil Velikov Cc: Linux Fbdev development list , "dri-devel@lists.freedesktop.org" , Laurent Pinchart --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/12/15 19:00, Emil Velikov wrote: > On 10 December 2015 at 14:53, Rob Clark wrote: >=20 >> It would be nice to see omapdrm eventually using the panel framework, >> etc. But I think copy/paste to decouple omapdrm from omapfb/vout as >> the first step makes sense. >> > Moar panels/bridges :-P I have a bunch more in my TI branch, which I have never upstreamed because I haven't wanted to push too much into the omap specific panel/encoder directory... > But seriously, I think that this is the better idea, despite the > duplication that'll exist in the first place. Otherwise you'll end up > pulling your hairs out trying to balance everything drm and fbdev/vout > working. >=20 > A suggestion... do throw a big scary warning in the fbdev copy - "Here > be dragons... old, mostly maintained code, bugfixes only please". > Otherwise some poor soul might decide to port the drm patches back > into the fbdev copy, or try to de-duplicate things :-) The fbdev maintainer (me) will block any attempts to do so, but good point, it doesn't harm to add a small README to the omapfb side. Tomi --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ 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 iQIcBAEBCAAGBQJWabMdAAoJEPo9qoy8lh71Q/gQAKX+gv9e6SImUxqMq8tYg0dN qNAE/hx3z6vAt7YGORBEEVZYpmwJERkpXefcOhSd04WBrqOqejLf9XfypH4iw7OT iZj6mXnaJ8aUTrVDnRoYuu5LJFSCFZejgF3Gh3YKz69fK1t2t2N1OJwvpbZUVohN 406+Qzhto0fxHGCNxMd1u8S//VfsX7Rlecr5QW7BsuMrsS+g/7PJ6S9rwPktnBwW D6LH3iqtAPbpFaHPvJF5PSzHMuZAGE4NQQ+zWwI++hlg/Ozk9dDdmClj9+ZN8WHD CF8JMCd9W0yF47VvBxUqPIXCwgxvoMtZmP/sv8TXuYTnQYq1kq8GjSkwuWBCgfS9 1PQKNwFSUwxC40JMLDnNa21o2TZ98KnpD1gJkhlzact3xPeAjdd50syI10z3HeIn eeIYt/7SF9XvGIXEw1T3oQzLA/hQ/llNuG5PdKuD9Vf/36DDKdynNBArbcByl1Ct 0ZrL80M3H5VRFREdGPmvsGAbss5Ln9rZASAqqS6dBbYwEzIlUwKwcBVuPSp6/oVv oez9H4RV0WCFDgXijsbPIYMebeENiFjUq78ciGZqu7oUljFmOaX6b1Cnwf51Z1uN hSAMSLOQDgDeryzc2DWpQmeyOXCOMkR7SzV39nMwvxXxDevokbl7FXIiIfQALvn1 TOTpFfrtfgpbppky/9Sa =vpGW -----END PGP SIGNATURE----- --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH RFC 0/9] omapdrm/omapfb/omapdss split Date: Thu, 10 Dec 2015 19:15:09 +0200 Message-ID: <5669B31D.6000102@ti.com> References: <1449757535-5674-1-git-send-email-tomi.valkeinen@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1254578415==" Return-path: Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by gabe.freedesktop.org (Postfix) with ESMTPS id B38A86EB55 for ; Thu, 10 Dec 2015 09:15:17 -0800 (PST) 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: Emil Velikov Cc: Linux Fbdev development list , "dri-devel@lists.freedesktop.org" , Laurent Pinchart List-Id: dri-devel@lists.freedesktop.org --===============1254578415== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ" --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/12/15 19:00, Emil Velikov wrote: > On 10 December 2015 at 14:53, Rob Clark wrote: >=20 >> It would be nice to see omapdrm eventually using the panel framework, >> etc. But I think copy/paste to decouple omapdrm from omapfb/vout as >> the first step makes sense. >> > Moar panels/bridges :-P I have a bunch more in my TI branch, which I have never upstreamed because I haven't wanted to push too much into the omap specific panel/encoder directory... > But seriously, I think that this is the better idea, despite the > duplication that'll exist in the first place. Otherwise you'll end up > pulling your hairs out trying to balance everything drm and fbdev/vout > working. >=20 > A suggestion... do throw a big scary warning in the fbdev copy - "Here > be dragons... old, mostly maintained code, bugfixes only please". > Otherwise some poor soul might decide to port the drm patches back > into the fbdev copy, or try to de-duplicate things :-) The fbdev maintainer (me) will block any attempts to do so, but good point, it doesn't harm to add a small README to the omapfb side. Tomi --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ 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 iQIcBAEBCAAGBQJWabMdAAoJEPo9qoy8lh71Q/gQAKX+gv9e6SImUxqMq8tYg0dN qNAE/hx3z6vAt7YGORBEEVZYpmwJERkpXefcOhSd04WBrqOqejLf9XfypH4iw7OT iZj6mXnaJ8aUTrVDnRoYuu5LJFSCFZejgF3Gh3YKz69fK1t2t2N1OJwvpbZUVohN 406+Qzhto0fxHGCNxMd1u8S//VfsX7Rlecr5QW7BsuMrsS+g/7PJ6S9rwPktnBwW D6LH3iqtAPbpFaHPvJF5PSzHMuZAGE4NQQ+zWwI++hlg/Ozk9dDdmClj9+ZN8WHD CF8JMCd9W0yF47VvBxUqPIXCwgxvoMtZmP/sv8TXuYTnQYq1kq8GjSkwuWBCgfS9 1PQKNwFSUwxC40JMLDnNa21o2TZ98KnpD1gJkhlzact3xPeAjdd50syI10z3HeIn eeIYt/7SF9XvGIXEw1T3oQzLA/hQ/llNuG5PdKuD9Vf/36DDKdynNBArbcByl1Ct 0ZrL80M3H5VRFREdGPmvsGAbss5Ln9rZASAqqS6dBbYwEzIlUwKwcBVuPSp6/oVv oez9H4RV0WCFDgXijsbPIYMebeENiFjUq78ciGZqu7oUljFmOaX6b1Cnwf51Z1uN hSAMSLOQDgDeryzc2DWpQmeyOXCOMkR7SzV39nMwvxXxDevokbl7FXIiIfQALvn1 TOTpFfrtfgpbppky/9Sa =vpGW -----END PGP SIGNATURE----- --JsmlUQFdlesPscD4uG3QXBIAUvBFdA7xQ-- --===============1254578415== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1254578415==--