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
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 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 \
    --subject='Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom' \
    /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

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.