All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Rob Clark <robdclark@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Stephen Boyd <swboyd@chromium.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Steev Klimaszewski <steev@kali.org>,
	Enric Balletbo Serra <eballetbo@gmail.com>,
	Andy Gross <agross@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Date: Mon, 29 Mar 2021 09:25:24 -0700	[thread overview]
Message-ID: <CAD=FV=XqG8oH5HCttKSNYJV2eHwLxq-tm1C+UFLn+cAHUrBaHg@mail.gmail.com> (raw)
In-Reply-To: <20210326000907.GA1965415@robh.at.kernel.org>

Hi,

On Thu, Mar 25, 2021 at 5:09 PM Rob Herring <robh@kernel.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.
>
> Is this a 'standard' eDP connector? AFAICT, there does seem to be
> such a thing.

To answer this one: there's not any "standard" physical plug as far as
I can tell. There's a connector on the board side for the LCD that has
a whole hodgepodge of signals on it. Maybe USB for a camera. Some
power signals. Maybe a PWM for a backlight. Maybe some DMIC signals.
eDP signals which might be anywhere from 1 to 4 lanes. HPD (which is
really a "panel ready" signal for eDP). The size / style of connector
and the exact set of signals (and their ordering) is board specific.
You then get a board-specific cable that splits things out. Some might
go to a camera/MIC sub board. Some go to the panel and hook onto a
panel-specific connector which has pin count and orderings defined by
that panel. :-P


> I've said in the past I'd be okay with a edp-connector
> node. If that needs just the "HPD absent delay" property, I think that
> would be okay. It's just a never ending stream of new properties with
> each new panel that I don't want to see.

Thinking about this we'd need at least one other property right now
which is an enable delay. Specifically at least one panel I've
supported recently lied about HPD for a short period after bootup.
Specifically see commit 667d73d72f31 ("drm: panel: simple: Delay HPD
checking on boe_nv133fhm_n61 for 15 ms"). ...and, of course, the
existing power supply / enable signals that "simple-panel" already
has.

Also: if we weren't going to add the other delay properties in the
device tree, we'd have to add the code right away that used the EDID
to set other delays. That wouldn't be the end of the world, but it
would be code to write.


One last thought to add: I've looked at ~10 panels specs recently.
Though they are all a little different from each other, I will say
that almost every one of them seems to have the exact same timing
diagram in it just with different numbers filled in. To me that backs
up the idea that you can/should do the power sequence with a fairly
standard (parameterized) driver. I can't link the datasheets I have
but searching for "edp panel datasheet" finds me this random
datasheet:

https://www.data-modul.com/sites/default/files/products/NV156QUM-N72_specification_12039472.pdf

See "8.0 POWER SEQUENCE" in that document. All the panels have a
nearly identical diagram with different numbers filled in. You can
kinda tell it was copied from some other panel since some numbers
(like T4) aren't even defined.

-Doug

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: 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>,
	Thierry Reding <thierry.reding@gmail.com>,
	Steev Klimaszewski <steev@kali.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Date: Mon, 29 Mar 2021 09:25:24 -0700	[thread overview]
Message-ID: <CAD=FV=XqG8oH5HCttKSNYJV2eHwLxq-tm1C+UFLn+cAHUrBaHg@mail.gmail.com> (raw)
In-Reply-To: <20210326000907.GA1965415@robh.at.kernel.org>

Hi,

On Thu, Mar 25, 2021 at 5:09 PM Rob Herring <robh@kernel.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.
>
> Is this a 'standard' eDP connector? AFAICT, there does seem to be
> such a thing.

To answer this one: there's not any "standard" physical plug as far as
I can tell. There's a connector on the board side for the LCD that has
a whole hodgepodge of signals on it. Maybe USB for a camera. Some
power signals. Maybe a PWM for a backlight. Maybe some DMIC signals.
eDP signals which might be anywhere from 1 to 4 lanes. HPD (which is
really a "panel ready" signal for eDP). The size / style of connector
and the exact set of signals (and their ordering) is board specific.
You then get a board-specific cable that splits things out. Some might
go to a camera/MIC sub board. Some go to the panel and hook onto a
panel-specific connector which has pin count and orderings defined by
that panel. :-P


> I've said in the past I'd be okay with a edp-connector
> node. If that needs just the "HPD absent delay" property, I think that
> would be okay. It's just a never ending stream of new properties with
> each new panel that I don't want to see.

Thinking about this we'd need at least one other property right now
which is an enable delay. Specifically at least one panel I've
supported recently lied about HPD for a short period after bootup.
Specifically see commit 667d73d72f31 ("drm: panel: simple: Delay HPD
checking on boe_nv133fhm_n61 for 15 ms"). ...and, of course, the
existing power supply / enable signals that "simple-panel" already
has.

Also: if we weren't going to add the other delay properties in the
device tree, we'd have to add the code right away that used the EDID
to set other delays. That wouldn't be the end of the world, but it
would be code to write.


One last thought to add: I've looked at ~10 panels specs recently.
Though they are all a little different from each other, I will say
that almost every one of them seems to have the exact same timing
diagram in it just with different numbers filled in. To me that backs
up the idea that you can/should do the power sequence with a fairly
standard (parameterized) driver. I can't link the datasheets I have
but searching for "edp panel datasheet" finds me this random
datasheet:

https://www.data-modul.com/sites/default/files/products/NV156QUM-N72_specification_12039472.pdf

See "8.0 POWER SEQUENCE" in that document. All the panels have a
nearly identical diagram with different numbers filled in. You can
kinda tell it was copied from some other panel since some numbers
(like T4) aren't even defined.

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

  reply	other threads:[~2021-03-29 16:26 UTC|newest]

Thread overview: 40+ 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 ` Douglas Anderson
2021-03-16 21:08 ` [RFC PATCH 2/3] drm/panel: panel-simple: " Douglas Anderson
2021-03-16 21:08   ` 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-16 21:08   ` 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-17 23:27   ` Matthias Kaehlcke
2021-03-18  1:53   ` Rob Clark
2021-03-18  1:53     ` Rob Clark
2021-03-26 12:39     ` Thierry Reding
2021-03-26 12:39       ` Thierry Reding
2021-03-26 15:18       ` Rob Clark
2021-03-26 15:18         ` Rob Clark
2021-03-26 15:24         ` Rob Clark
2021-03-26 15:24           ` Rob Clark
2021-03-26 17:00           ` Bjorn Andersson
2021-03-26 17:00             ` Bjorn Andersson
2021-03-26 19:48           ` Rob Herring
2021-03-26 19:48             ` Rob Herring
2021-03-26 22:16             ` Rob Clark
2021-03-26 22:16               ` Rob Clark
2021-03-26 23:48               ` Rob Herring
2021-03-26 23:48                 ` Rob Herring
2021-03-27  0:33                 ` Rob Clark
2021-03-27  0:33                   ` Rob Clark
2021-03-27  0:49                   ` Rob Clark
2021-03-27  0:49                     ` Rob Clark
2021-03-29 15:51             ` Doug Anderson
2021-03-29 15:51               ` Doug Anderson
2021-03-29 16:07       ` Doug Anderson
2021-03-29 16:07         ` Doug Anderson
2021-03-26  0:09 ` Rob Herring
2021-03-26  0:09   ` Rob Herring
2021-03-29 16:25   ` Doug Anderson [this message]
2021-03-29 16:25     ` Doug Anderson
2021-04-22 22:08     ` Doug Anderson
2021-04-22 22:08       ` Doug Anderson
2021-04-23 11:14       ` Thierry Reding
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='CAD=FV=XqG8oH5HCttKSNYJV2eHwLxq-tm1C+UFLn+cAHUrBaHg@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=drinkcat@chromium.org \
    --cc=eballetbo@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.