Hi, On Tue, Aug 3, 2021 at 1:41 PM Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > > Hi Douglas, > > On Fri, Jul 30, 2021 at 02:26:19PM -0700, Douglas Anderson wrote: > > The goal of this patch series is to move away from hardcoding exact > > eDP panels in device tree files. As discussed in the various patches > > in this series (I'm not repeating everything here), most eDP panels > > are 99% probable and we can get that last 1% by allowing two "power > > up" delays to be specified in the device tree file and then using the > > panel ID (found in the EDID) to look up additional power sequencing > > delays for the panel. > > Have you considered a new driver for edp panels? > panel-edp.c? > > There will be some duplicate code from pnale-simple - but the same can > be said by the other panel drivers too. > In the end I think it is better to separate them so we end up with two > less complex panel drivers rather than one do-it-all panel driver. > > I have not looked in detail how this would look like, but my first > impression is that we should split it out. I certainly could, but my argument against it is that really it's the exact same set of eDP panels that would be supported by both drivers. By definition the "simple" eDP panels are the ones that just have a regulator/enable GPIO and some timings to turn them off. Those are the exact same set of panels that can be probed if we just provide the panel ID that's hardcoded in the EDID. As you can see from the implementation patch I'm actually sharing the private data structures (the ones containing the timing) for panels that are supported both as "probable" and as hardcoded. If we split into two drivers we'd either need to duplicate the timings for all panels supported by both drivers or we'd have to somehow export them (maybe hard if things are in modules). Also, since it's the same set of eDP panels we'd need to exactly duplicate all the code handling delays / HPD. It just doesn't feel right to me. -Doug
