On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On 10 April 2017 at 19:03, Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> 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@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. >> >> 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? EDID is a way to make the h/w discoverable as is DT. Both are just data. Both are OS independent data. Only the mechanism of providing the data differs. I can envision putting DT overlays into EEPROMs on add-on boards which then would even have the same mechanism. This is not an either or decision. DT can provide data and the OS can decide whether it uses it or not as long as we continue with specific compatible strings. Rob _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
