Message-Id: <20210316140707.RFC.1.I3a21995726282f1e9fcb70da5eb96f19ed96634f@changeid>
Date:   Tue, 16 Mar 2021 14:08:19 -0700
From:   Douglas Anderson <dianders@...omium.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Sam Ravnborg <sam@...nborg.org>
Cc:     robdclark@...omium.org, Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
        devicetree@...r.kernel.org, swboyd@...omium.org,
        linux-arm-msm@...r.kernel.org, Steev Klimaszewski <steev@...i.org>,
        eballetbo@...il.com, Andy Gross <agross@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        drinkcat@...omium.org, Douglas Anderson <dianders@...omium.org>,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom

The sc7180-trogdor-pompom board might be attached to any number of a
pile of eDP panels. At the moment I'm told that the list might include:
- KD KD116N21-30NV-A010
- KD KD116N09-30NH-A016
- Starry 2081116HHD028001-51D
- Sharp LQ116M1JW10

It should be noted that while the EDID programmed in the first 3
panels indicates that they should run with exactly the same timing (to
keep things simple), the 4th panel not only needs different timing but
has a different resolution.

As is true in general with eDP panels, we can figure out which panel
we have and all the info needed to drive its pixel clock by reading
the EDID. However, we can do this only after we've powered the panel
on. Powering on the panels requires following the timing diagram in
each panel's datasheet which specifies delays between certain
actions. This means that, while we can be quite dynamic about handling
things we can't just totally skip out on describing the panel like we
could do if it was connected to an external-facing DP port.

While the different panels have slightly different delays, it's
possible to come up with a set of unified delays that will work on all
the panels. From reading the datasheets:
* KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016
  - HPD absent delay: 200 ms
  - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms)
* Starry 2081116HHD028001-51D
  - HPD absent delay: 100 ms
  - Enable delay: (link training done till enable BL): 200 ms
  - Unprepare delay: 500 ms
* Sharp LQ116M1JW10
  - HPD absent delay: 200 ms
  - Unprepare delay: 500 ms
  - Prepare to enable delay (power on till backlight): 100 ms

Unified:
- HPD absent delay: 200 ms
- Unprepare delay: 500 ms
- Enable delay: 200 ms

NOTE: in theory the only thing that we _really_ need unity on is the
"HPD absent delay" since once the panel asserts HPD we can read the
EDID and could make per-panel decisions if we wanted.

Let's create a definition of "a panel that can be attached to pompom"
as a panel that provides a valid EDID and can work with the standard
pompom power sequencing. If more panels are later attached to pompom
then it's fine as long as they work in a compatible way.

One might ask why we can't just use a generic string here and provide
the timings directly in the device tree file. As I understand it,
trying to describe generic power sequencing in the device tree is
frowned upon and the one instance (SD/MMC) is regarded as a mistake
that shouldn't be repeated. Specifying a power sequence per board (or
per board class) feels like a reasonable compromise. We're not trying
to define fully generic power sequence bindings but we can also take
advantage of the semi-probable properties of the attached device.

NOTE: I believe that past instances of supporting this type of thing
have used the "white lie" approach. One representative panel was
listed in the device tree. The power sequencings of this
representative panel were OK to use across all panels that might be
attached and other differences were handled by EDID. This patch
attempts to set a new precedent and avoid the need for the white lie.

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---

 .../devicetree/bindings/display/panel/panel-simple.yaml       | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 62b0d54d87b7..9807dbc1cceb 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -140,6 +140,10 @@ properties:
       - giantplus,gpg48273qs5
         # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
       - giantplus,gpm940b0
+        # A panel connected to a google,pompom board. Panel is guaranteed to
+        # confirm to google,pompom-panel power sequencing requirements and then
+        # the specific panel will be probed via EDID.
+      - google,pompom-panel
         # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
       - hannstar,hsd070pww1
         # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
-- 
2.31.0.rc2.261.g7f71774620-goog

Powered by blists - more mailing lists