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@nvidia.com> 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