All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	robdclark@chromium.org, Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	devicetree@vger.kernel.org, swboyd@chromium.org,
	linux-arm-msm@vger.kernel.org,
	Steev Klimaszewski <steev@kali.org>,
	eballetbo@gmail.com, Andy Gross <agross@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	drinkcat@chromium.org, 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 16:27:37 -0700	[thread overview]
Message-ID: <YFKQaXOmOwYyeqvM@google.com> (raw)
In-Reply-To: <20210316140707.RFC.1.I3a21995726282f1e9fcb70da5eb96f19ed96634f@changeid>

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.

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>

WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: robdclark@chromium.org, devicetree@vger.kernel.org,
	drinkcat@chromium.org, David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org, Andy Gross <agross@kernel.org>,
	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>,
	swboyd@chromium.org, Sam Ravnborg <sam@ravnborg.org>,
	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 16:27:37 -0700	[thread overview]
Message-ID: <YFKQaXOmOwYyeqvM@google.com> (raw)
In-Reply-To: <20210316140707.RFC.1.I3a21995726282f1e9fcb70da5eb96f19ed96634f@changeid>

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.

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

  parent reply	other threads:[~2021-03-17 23:28 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 ` Matthias Kaehlcke [this message]
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
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
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=YFKQaXOmOwYyeqvM@google.com \
    --to=mka@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=dianders@chromium.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+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 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.