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

[Laurent Pinchart]

Hi Thierry,

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/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.

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.

-- 
Regards,

Laurent Pinchart