From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver Date: Mon, 10 Apr 2017 09:17:59 +0200 Message-ID: <20170410071758.GA7819@ulmo.ba.sec> References: <10367276.mxSL6V0lE5@avalon> <20170405065127.4080-1-laurent.pinchart+renesas@ideasonboard.com> <20170407173308.GA3984@ulmo.ba.sec> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0852163124==" Return-path: Received: from hqemgate16.nvidia.com (hqemgate16.nvidia.com [216.228.121.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 80C886E24C for ; Mon, 10 Apr 2017 07:21:06 +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: Emil Velikov Cc: Laurent Pinchart , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0852163124== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote: > Hi Thierry, >=20 > I don't mean to stir up anything, just voicing "my 2c" as they say. >=20 > On 7 April 2017 at 18:33, Thierry Reding wrote: >=20 > > Ever since the simple-panel binding was introduced, which is now about > > 3 1/2 years ago, >=20 > Do you have a link to these discussions? Your blog article does not > have any links and I only found the "Runtime Interpreted Power > Sequences" thread. > That in itself does not cover the pros/cons of storing HW information* > within DT. There's some discussion here: https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html which continues here: https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html There are a couple of earlier threads, though, that discuss similar issues. This one seems to be the earliest I can find that is publicly archived: http://www.spinics.net/lists/devicetree/msg08497.html Going over all these threads again wasn't a very pleasant experience. I realize how much time I already spent discussing these, and I don't have any desire to repeat that discussion. We've had these differences ever since the very beginning. So we're now again going in circles. The main concern back at the time was that having to specify timings in the driver would result in a complete mess because we have zillions of panels that we need to support. That's turned out to be a complete non- issue. We've got something on the order of 50 or 60 drivers supported in the simple-panel driver, and for everything that's more complicated we have a handful of separate drivers, all fairly simple as well. So while I understand why people want to put all this information into DT, we've repeatedly discussed the disadvantages that this would have. And while we were never able to get everyone to agree, the current solution has had enough agreement that we merged it. And it turned out to be good enough. There's nothing in panel-lvds that I can see that fundamentally changes this. > Personally, the idea of having hardware information* in DT does not > sound all that bad. The simple panel driver(s) can use those > properties and any panels that require anything more complex will > still need their own driver. Again, the point is that you're going to have to modify the driver in any case, because you need to support the new compatible string. Without that compatible string you have zero information about the panel, and matching on a generic one isn't going to give you a working panel. So if you're already going to have to support a panel in a driver, why not go all the way and fully describe its capabilities and properties? We do it for all other devices. Panels are not at all special. > For better or for worse, there's already a handful of drivers and > bindings that rely on/provide these. Using that information > consistently across the board, would be of a benefit, IMHO. Would you mind pointing out which ones these are? I'm aware of only a couple that seemed to have sneeked in because people were trying to side-step adding drm/panel support for their boards, so I don't think that qualifies as a reason to rethink how drm/panel works. Thierry --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAljrMaQACgkQ3SOs138+ s6HwaA//VihCa7i9l4ujzc0CSKGrpAc2E8crNcNPlOQaJplIjVnHWXGHrPOdBKo+ EBJ0S2QPqYRZa3q2VUH9qvmvlvtLh+EyRw5ZWt6awatkSNwmo6PZ/FfCPy4NzmUB 8DqlQWp6bQ2A1Ij0KWlQ7t9tIm3XPU6wwGfvgkOKFds2p6hxKkGaBj3/wv9sMaN2 K81X0TVHR3TDqVjwnKaLGvrljmXm3NEXTyyvdtXODEAfaeGO99pjpfdiX7hvmM17 BOGRbWwMYLfIQ2cfKOETYe3LrIREoyI5s879NNULsFcuNjdBLRJgYzq8YXxQkImF TPPCbDumHN1m+5nCkOeM9t3ZxdbOiupnQ7eHw9TdqgZEeOZztipyVP0XzoRjaMET V2HXvqQptvACeOwet/LXgI5nmfZDah7/MYilNqDsNsIyvsD8AwMRiePC9X2/PVFt aMdiwA48wvw0NzrrQSle+JgjlozOUel4BsFwXRyX5RfrWACtIQBWA8o93c9Osa+j ewcXGw78IVOwwha3vA2CnX95Mjp59U0wUvpFCiyIOAf6B9B3Wbx7ILO0v00Pc1BP jGwTp0rCAfZtKVn6na/QBQ8PSa03NxiWfiRtF3iShubruhHJUynu0L7TH9f5R+1o l7zMiW51eHRfhMOvbCGpomk6A+3fSumcSgNj1G8CgonRwPjjcdw= =wDH9 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- --===============0852163124== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0852163124==--