[PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

Laurent Pinchart laurent.pinchart at ideasonboard.com
Tue Apr 11 04:41:04 UTC 2017


Hi Dave,

(CC'ing Rob)

On Tuesday 11 Apr 2017 05:27:04 Dave Airlie wrote:
> On 10 April 2017 at 19:03, Laurent Pinchart wrote:
> > On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote:
> >> 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 at 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/0495
> >>       09.html
> >> 
> >> which continues here:
> >>       https://lists.freedesktop.org/archives/dri-devel/2013-December/0500
> >>       82.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.
> > 
> > It will *if* the panel doesn't need any device-specific handling. In all
> > other cases I agree with you, panel-specific code will be needed in the
> > kernel (to handle power sequences for instance).
> > 
> >> 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.
> > 
> > That we agree on, panels are not special. They're not the only devices
> > that store in DT information that could be hardcoded in the driver based
> > on the compatible string. We have many devices whose compatible string
> > contains the SoC version. Driver could then hardcode interrupts or clocks
> > without any need to specific them in DT. We don't do that as it would be
> > more complex to handle.
> > 
> > Regarding timings, I've long hesitated (albeit I confess I was more on the
> > side of specifying them in DT) until Rob Herring convinced me with the
> > generic rule that adding information in DT that are generally exposed by
> > devices themselves makes sense. Displays traditionally expose video mode
> > information through EDID, which is effectively device firmware. When a
> > panel is integrated in a system, and the system designer decides to save
> > money by removing the EDID I2C EEPROM, moving that piece of device
> > firmware data to system firmware makes sense to me.
> > 
> > I certainly won't try to revive the power sequence discussions, I don't
> > believe it belongs to DT.
> > 
> >>> 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.
> 
> Okay I'm afraid I agree with Thierry here.
> 
> I don't want mode timings or EDID in DT files, I'm pretty sure I was one of
> the people who helped decide that just having a compatible string and modes
> in a driver makes sense. So if we have imported code to be the opposite of
> this please work on removing it.
> 
> If you move EDID from over the wire into DT it's not really tied to the
> panel anymore, and is now just a complicated way of specifying the modes
> from the panel documentation.
> 
> EDID and DDC are a way for a panel to communicate to the host system,
> timing constraints and mode info, if you remove the i2c link, why bother
> encoding stuff in an EDID?

Re-reading my previous e-mail I now see that I expressed myself poorly. I'm 
not advocating for specifying EDID information in DT, my point (and Rob's 
point) was that adding property to the device tree to store information 
typically provided through EDID is just moving firmware data from one place of 
the system to another, and thus makes sense. That information should certainly 
not be stored as a binary EDID blob, but as native DT properties instead.

The LVDS panel DT bindings don't contain EDID binary data, but contain the 
panel's physical size and video timings.

-- 
Regards,

Laurent Pinchart



More information about the dri-devel mailing list