On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote: > Hi Thierry, > > I don't mean to stir up anything, just voicing "my 2c" as they say. > > On 7 April 2017 at 18:33, Thierry Reding <treding@xxxxxxxxxx> wrote: > > > Ever since the simple-panel binding was introduced, which is now about > > 3 1/2 years ago, > > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
