Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4170 bytes --]

On Fri, Jun 10, 2016 at 03:08:50PM -0700, Stéphane Marchesin wrote:
> On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark <robdclark@gmail.com> wrote:
> > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson <dianders@chromium.org> wrote:
> >> Rob,
> >>
> >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@gmail.com> wrote:
> >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.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.

panel-simple has support for very simple sequencing. You can specify
delays after the prepare and enable stages. This is useful because most
panels have specific requirements when it comes to the amount of time it
takes them to receive video data (after being powered up) and the amount
of time it takes them to show the first valid frame after it has been
received.

The former is used to keep drivers from sending video data to make sure
it can be properly received by the panel, and the latter is used to keep
the backlight off until the first valid frame is visible on the display.

This is used to avoid glitches and seems to work well enough for simple
panels. More complex panels have more involved sequences, so separate
drivers are required.

Also note that the simple-panel driver will try to use EDID if available
and only fall back to the hard-coded mode or timings if there is no DDC
to probe or no modes could be parsed from EDID.

> >> 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 :)

Reading out hardware state also doesn't give you all the information
that you need. I've never seen hardware that is programmed with the
physical size of the panel, so there's no way to read that back and
you'd still have to either parse EDID or use the value hard-coded in
the simple-panel driver if you want to compute the pixel density.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel