On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > eDP panels usually have EDID EEPROM, so there's no need to define panel > > width/height or any modes/timings in dts. But this panel still may have > > regulator and/or backlight. > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@xxxxxxxxx> > > --- > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++ > > 1 file changed, 7 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt > > Please don't try to make panels look more generic than they really are. > You're going to have to provide a compatible string for your device that > is more specific than "panel-edp". You claim that you don't need any > extra information that is panel specific, but you don't know that now. > We have in the past thought that we didn't need things like prepare > delay, but then we ran into situations where we did need them. > > Just do what everybody else does. Provide a specific compatible string > and match on that in the panel-simple driver. Even if you can read all > the video timings from an EDID EEPROM, you can still provide a mode in > the panel descriptor to serve as a fallback if for example the EEPROM > is faulty on some device. Pinebook used several 768p panels that have slightly different timings and recent batch uses 1080p panel. What panel descriptor should I use as fallback? > Thierry
