From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures Date: Mon, 15 May 2017 09:32:01 +0300 Message-ID: <297c5d76-37b5-2684-9935-bad9b486e935@ti.com> References: <20170508113303.27521-1-laurent.pinchart@ideasonboard.com> <12054023.GhQOfgyNIu@avalon> <1263aa75-63c4-2e34-0b8b-ea14e6c80dc5@ti.com> <2855175.Oy2uCtIrPR@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1558653295==" Return-path: Received: from lelnx193.ext.ti.com (lelnx193.ext.ti.com [198.47.27.77]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3CA486E0AA for ; Mon, 15 May 2017 06:32:08 +0000 (UTC) In-Reply-To: <2855175.Oy2uCtIrPR@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 --===============1558653295== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iPNWg99QsSe1NNcNklXCjVK57VgGDrXk8" --iPNWg99QsSe1NNcNklXCjVK57VgGDrXk8 Content-Type: multipart/mixed; boundary="SpXnpd8H9a4dis8KvAeOPnJrhuALwXRRx"; protected-headers="v1" From: Tomi Valkeinen To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Message-ID: <297c5d76-37b5-2684-9935-bad9b486e935@ti.com> Subject: Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures References: <20170508113303.27521-1-laurent.pinchart@ideasonboard.com> <12054023.GhQOfgyNIu@avalon> <1263aa75-63c4-2e34-0b8b-ea14e6c80dc5@ti.com> <2855175.Oy2uCtIrPR@avalon> In-Reply-To: <2855175.Oy2uCtIrPR@avalon> --SpXnpd8H9a4dis8KvAeOPnJrhuALwXRRx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/05/17 14:12, Laurent Pinchart wrote: >> Is it? You already use the dss compat string and soc_device_match to >> figure out some versions. Isn't that a proper way to find out about th= e >> SoC? But I agree that a more fine grained version management in each >> individual driver would be better. >=20 > For OMAP2, OMAP4 or OMAP5 it shouldn't be too much of a problem, but OM= AP3=20 > would be more painful to handle. The following machine names are used. >=20 > "AM3505" > "AM3517" > "AM437x" > "OMAP3430/3530" > "OMAP3525" > "OMAP3515" > "OMAP3503" > "OMAP3611" > "OMAP3615/AM3715" > "OMAP3621" > "OMAP3630/DM3730" > "AM3703" > "DM3725" Don't we need all those somewhere in any case? I mean, I presume all the current OMAPDSS_VER_* defines are used somewhere. Which means that somewhere, maybe in multiple different files, we need to handle some or all of those. For some features, perhaps we could move them to DT. If the feature is about how DSS is integrated into the SoC, it might make sense to have that in the DT, as a property for DSS, as it's not part of DSS itself. If the data is missing, we could inject it into the DT at boot time, based on the omap revision. Though I'm not sure if that would really help that much. I think the most annoying "feature" is the blank/porch register field size change, that they made between OMAP3430 ES1 and ES2. And didn't bother to change the DSS IP version... But back to the topic... Are you sure this version detection should not be centralized? If we have that many OMAP3 related devices already (btw, AM4 is not really OMAP3 related, even if the DSS there is)... And if we get one more. Does it mean we need to edit that same new device into many places? Then again, maybe it's better to handle that separately in each file that requires the information, as sometimes all you need to know is that it's DSS3 based, but sometimes you need to know that it's AM4's DSS vs OMAP3's DSS. > But I don't think that removing the extra platform devices is so urgent= =2E I'd=20 > rather do it when we're ready. >=20 > The omapdss driver needs major cleanup and refactoring, and that will r= esult=20 > in a large number of patches that will cause conflicts and be sources o= f=20 > potential errors. I don't think that's avoidable. However, lots of thos= e=20 > cleanups will be independent from each other, so we can start merging t= he less=20 > controversial ones as soon as they're ready. I'll take care of rebasing= the=20 > rest of the patches as needed. Yes, no disagreements there. My hope is just that a series is as small as possible. Or, that's not correct... A series does one change at a time, e.g. here my problem was that the platform change was being done at the same time as the feature change, interleaved. I most likely will need to backport all these to v4.9 kernel. And then manage new patches that will be applied on top of mainline and that v4.9 kernel. And I will gladly take any changes to patch serieses that possibly make that work easier =3D). Tomi --SpXnpd8H9a4dis8KvAeOPnJrhuALwXRRx-- --iPNWg99QsSe1NNcNklXCjVK57VgGDrXk8 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 iQIcBAEBCAAGBQJZGUthAAoJEPo9qoy8lh71F1gP/iYKYDF7KJpMFYggSKZFV2Oz 7GqnNmYNcuisqtxu0SXNSfy/GlsJMNBTcR67q2Wz7VGW6IG2Crr06gOx/wyG+Pab H7gmfl9GVpy7WPpMNuz1cCresmmHs6Lqp4vzj73rKgk0GWCeGweUyazwNx/IK9iW N4hLX8HzCothV/g0zVCGOv1aIGxf50uVe7bHmvk90LEu9wmlhuAXo1fFfiQ+5jpc 6Sl7eJaBNvqobnFyGvZEwLpLYcaijVGx2I9QOXIrkYqrtG/sDvUThmersCa11QBN dp9wCfrz/U3qV2vU7m9GmA8eNE2z46yCRh2MjPz5zD+mGGt/LTKN548CDOUpHVSR R8cf8mOGt5V6CWWC/2HafDxBzsaURGSeTpXTk1qyExRNcgJyZAveGwJgAxrsVUzg xbudvJKmiELnvZRxKPKxCKS5vH9EBktDXohW9IDe7GpROYyElDK/rbVp+VIqOTGk RXWqPzaPIljuldUTJNR6DdMZOBZRkb59NiDhvYdfOmCoDEja/PaSC80+iEzydIu8 9gzlhkd0KpW+p+LMf2C4vGkjfbrFfAeA6ZhBBLrJRQelwWCiF50l9p6O47Da0oWd aX5UCrErBs081o9+UyU1ofycDHVyOkEo/zh/2HNThCMq52RBRuBXdiJJQb5smo0z flrq9jF54y+lk7sUWVqm =h8Lv -----END PGP SIGNATURE----- --iPNWg99QsSe1NNcNklXCjVK57VgGDrXk8-- --===============1558653295== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1558653295==--