From: Rob Clark <robdclark@gmail.com>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>,
Rob Clark <robdclark@chromium.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Nicolas Boichat <drinkcat@chromium.org>,
David Airlie <airlied@linux.ie>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Steev Klimaszewski <steev@kali.org>,
Stephen Boyd <swboyd@chromium.org>,
Sam Ravnborg <sam@ravnborg.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Date: Wed, 17 Mar 2021 18:53:04 -0700 [thread overview]
Message-ID: <CAF6AEGtu+GBwYfkH3x=UuPs5Ouj0TxqbVjpjFEtMKKWvd1-Gbg@mail.gmail.com> (raw)
In-Reply-To: <YFKQaXOmOwYyeqvM@google.com>
On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > 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@chromium.org>
> > ---
>
> Sounds reasonable to me if DT maintainers can live with this abstract
> hardware definition. It's clearer than the 'white lie' approach.
Yeah, it is a weird grey area between "discoverable" and "not
discoverable".. but I favor DT reflecting reality as much as
possible/feasible, so I think this is definity cleaner than "white
lies"
Reviewed-by: Rob Clark <robdclark@gmail.com>
> It's then up to the vendor/manufacturer to ensure to only ship devices
> with panels that have compatible timings.
>
> > .../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
>
> s/confirm/conform/ ?
>
> > + # 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
>
> FWIW:
>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-18 1:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 21:08 [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom Douglas Anderson
2021-03-16 21:08 ` [RFC PATCH 2/3] drm/panel: panel-simple: " Douglas Anderson
2021-03-16 21:08 ` [RFC PATCH 3/3] arm64: dts: qcom: Don't specify exactly what panel is on pompom Douglas Anderson
2021-03-17 23:27 ` [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom Matthias Kaehlcke
2021-03-18 1:53 ` Rob Clark [this message]
2021-03-26 12:39 ` Thierry Reding
2021-03-26 15:18 ` Rob Clark
2021-03-26 15:24 ` Rob Clark
2021-03-26 17:00 ` Bjorn Andersson
2021-03-26 19:48 ` Rob Herring
2021-03-26 22:16 ` Rob Clark
2021-03-26 23:48 ` Rob Herring
2021-03-27 0:33 ` Rob Clark
2021-03-27 0:49 ` Rob Clark
2021-03-29 15:51 ` Doug Anderson
2021-03-29 16:07 ` Doug Anderson
2021-03-26 0:09 ` Rob Herring
2021-03-29 16:25 ` Doug Anderson
2021-04-22 22:08 ` Doug Anderson
2021-04-23 11:14 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAF6AEGtu+GBwYfkH3x=UuPs5Ouj0TxqbVjpjFEtMKKWvd1-Gbg@mail.gmail.com' \
--to=robdclark@gmail.com \
--cc=agross@kernel.org \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=drinkcat@chromium.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mka@chromium.org \
--cc=robdclark@chromium.org \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=steev@kali.org \
--cc=swboyd@chromium.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).