lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Jun 2016 15:08:50 -0700 From: Stéphane Marchesin <marcheu@...omium.org> To: Rob Clark <robdclark@...il.com> Cc: Doug Anderson <dianders@...omium.org>, Thierry Reding <thierry.reding@...il.com>, Mark Rutland <mark.rutland@....com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Rob Herring <robh+dt@...nel.org> Subject: Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark <robdclark@...il.com> wrote: > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson <dianders@...omium.org> wrote: >> Rob, >> >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@...il.com> wrote: >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@...omium.org> wrote: >>>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >>>> using eDP interfaces. >>> >>> so drive-by comment... but shouldn't eDP be probe-able? Not sure why >>> we need panel drivers or DT bindings? >> >> I was wondering about that too. As far as I can tell: >> >> 1. We need a panel driver because that appears to be what owns a >> reference to the backlight / panel power regulator and that part is >> not auto-probable. > > oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel > driver hell.. I guess being able to use panel-simple is at least an > improvement. But panel specific sequences is sounds like panel-simple > won't save us all the time :-( Yes, although you can probably make things mostly work with improper sequencing and enough retries, a lot of ARM hw either requires interesting sequencing, or has broken/unreliable DDC, which translates into the use of panel simple on the sw side. > >> 2. As far as I could tell, there is no way to declare a generic >> (unspecified) panel in the device tree. Everyone seems to include >> "simple-panel" in their compatible string but as far as I can tell >> nothing in the kernel looks at it. >> >> 3. In theory, all the info specified here should match the EDID >> exactly and thus (as you said) be probable. However, it sounds like >> (for power sequencing reasons) there might be reasons why you'd want >> to know exactly what panel was present beforehand. You might need to >> power the panel and backlight in very specific sequences, for >> instance. I'm not sure it's always 100% possible in all embedded >> designs to read the EDID before you know how the sequencing should >> work (but, of course, I'm a NOOB). >> >> 4. Reading the EDID can be slow. If you happen to know all the info >> on the panel beforehand you can significantly speed up boot speed, >> notably how fast you can get something on the screen. > > The theory is (although I think not true currently for most of the arm > drivers) that we should be reading back from hw the current config > from bootloader splash screen, to avoid a modeset (and conveniently > also the need to read edid) at boot. On some devices the firmware doesn't set any video mode, so there isn't anything we can read back. That is our case :) Stéphane > > BR, > -R > >> >> Anyway, maybe someone else who actually knows what they're talking >> about will chime in. ;) >> >> -Doug
Powered by blists - more mailing lists