All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Anderson <dianders@chromium.org>
To: linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org,
	narmstrong@baylibre.com, a.hajda@samsung.com,
	Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org
Cc: jonas@kwiboo.se, jeffrey.l.hugo@gmail.com,
	linux-gpio@vger.kernel.org, bjorn.andersson@linaro.org,
	swboyd@chromium.org, jernej.skrabec@siol.net,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, robdclark@chromium.org,
	Douglas Anderson <dianders@chromium.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v5 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
Date: Thu,  7 May 2020 14:34:59 -0700	[thread overview]
Message-ID: <20200507143354.v5.5.I72892d485088e57378a4748c86bc0f6c2494d807@changeid> (raw)
In-Reply-To: <20200507213500.241695-1-dianders@chromium.org>

The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware.  Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for knowing when the panel is ready, not for
detecting physical plug events.

Currently the driver in Linux just assumes that nobody has HPD hooked
up.  It relies on folks setting the "no-hpd" property in the panel
node to specify that HPD isn't hooked up and then the panel driver
using this to add some worst case delays when turning on the panel.

Apparently it's also useful to specify "no-hpd" in the bridge node so
that the bridge driver can make sure it's doing the right thing
without peeking into the panel [1].  This would be used if anyone ever
found it useful to implement support for the HW HPD pin on the bridge.
Let's add this property to the bindings.

NOTES:
- This is somewhat of a backward-incompatible change.  All current
  known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
  bridge node yet none of them had HPD hooked up.  This worked because
  the current Linux driver just assumed that HPD was never hooked up.
  We could make it less incompatible by saying that for this bridge
  it's assumed HPD isn't hooked up _unless_ a property is defined, but
  "no-hpd" is much more standard and it's unlikely to matter unless
  someone quickly goes and implements HPD in the driver.
- It is sensible to specify "no-hpd" at the bridge chip level and
  specify "hpd-gpios" at the panel level.  That would mean HPD is
  hooked up to some other GPIO in the system, just not the hardware
  HPD pin on the bridge chip.

[1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.com

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---

Changes in v5: None
Changes in v4:
- Tacked on "or is otherwise unusable." to description.

Changes in v3:
- useful implement => useful to implement

Changes in v2:
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.

 .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml  | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 07d26121afca..be10e8cf31e1 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -28,6 +28,12 @@ properties:
     maxItems: 1
     description: GPIO specifier for GPIO1 pin on bridge (active low).
 
+  no-hpd:
+    type: boolean
+    description:
+      Set if the HPD line on the bridge isn't hooked up to anything or is
+      otherwise unusable.
+
   vccio-supply:
     description: A 1.8V supply that powers the digital IOs.
 
@@ -213,6 +219,8 @@ examples:
         clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
         clock-names = "refclk";
 
+        no-hpd;
+
         ports {
           #address-cells = <1>;
           #size-cells = <0>;
-- 
2.26.2.645.ge9eca65c58-goog


WARNING: multiple messages have this Message-ID (diff)
From: Douglas Anderson <dianders@chromium.org>
To: linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org,
	narmstrong@baylibre.com, a.hajda@samsung.com,
	Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org
Cc: robdclark@chromium.org, devicetree@vger.kernel.org,
	jernej.skrabec@siol.net, jeffrey.l.hugo@gmail.com,
	linux-arm-msm@vger.kernel.org, jonas@kwiboo.se,
	Douglas Anderson <dianders@chromium.org>,
	dri-devel@lists.freedesktop.org, swboyd@chromium.org,
	linux-gpio@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org
Subject: [PATCH v5 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
Date: Thu,  7 May 2020 14:34:59 -0700	[thread overview]
Message-ID: <20200507143354.v5.5.I72892d485088e57378a4748c86bc0f6c2494d807@changeid> (raw)
In-Reply-To: <20200507213500.241695-1-dianders@chromium.org>

The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware.  Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for knowing when the panel is ready, not for
detecting physical plug events.

Currently the driver in Linux just assumes that nobody has HPD hooked
up.  It relies on folks setting the "no-hpd" property in the panel
node to specify that HPD isn't hooked up and then the panel driver
using this to add some worst case delays when turning on the panel.

Apparently it's also useful to specify "no-hpd" in the bridge node so
that the bridge driver can make sure it's doing the right thing
without peeking into the panel [1].  This would be used if anyone ever
found it useful to implement support for the HW HPD pin on the bridge.
Let's add this property to the bindings.

NOTES:
- This is somewhat of a backward-incompatible change.  All current
  known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
  bridge node yet none of them had HPD hooked up.  This worked because
  the current Linux driver just assumed that HPD was never hooked up.
  We could make it less incompatible by saying that for this bridge
  it's assumed HPD isn't hooked up _unless_ a property is defined, but
  "no-hpd" is much more standard and it's unlikely to matter unless
  someone quickly goes and implements HPD in the driver.
- It is sensible to specify "no-hpd" at the bridge chip level and
  specify "hpd-gpios" at the panel level.  That would mean HPD is
  hooked up to some other GPIO in the system, just not the hardware
  HPD pin on the bridge chip.

[1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.com

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---

Changes in v5: None
Changes in v4:
- Tacked on "or is otherwise unusable." to description.

Changes in v3:
- useful implement => useful to implement

Changes in v2:
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.

 .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml  | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 07d26121afca..be10e8cf31e1 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -28,6 +28,12 @@ properties:
     maxItems: 1
     description: GPIO specifier for GPIO1 pin on bridge (active low).
 
+  no-hpd:
+    type: boolean
+    description:
+      Set if the HPD line on the bridge isn't hooked up to anything or is
+      otherwise unusable.
+
   vccio-supply:
     description: A 1.8V supply that powers the digital IOs.
 
@@ -213,6 +219,8 @@ examples:
         clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
         clock-names = "refclk";
 
+        no-hpd;
+
         ports {
           #address-cells = <1>;
           #size-cells = <0>;
-- 
2.26.2.645.ge9eca65c58-goog

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

  parent reply	other threads:[~2020-05-07 21:35 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 21:34 [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Douglas Anderson
2020-05-07 21:34 ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:24   ` Stephen Boyd
2020-05-11 16:24     ` Stephen Boyd
2020-05-12  1:36   ` Bjorn Andersson
2020-05-12  1:36     ` Bjorn Andersson
2020-05-12 12:28   ` Linus Walleij
2020-05-12 12:28     ` Linus Walleij
2020-05-07 21:34 ` [PATCH v5 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare() Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 4/6] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:25   ` Stephen Boyd
2020-05-11 16:25     ` Stephen Boyd
2020-05-07 21:34 ` Douglas Anderson [this message]
2020-05-07 21:34   ` [PATCH v5 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd Douglas Anderson
2020-05-07 21:35 ` [PATCH v5 6/6] arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza Douglas Anderson
2020-05-07 21:35   ` Douglas Anderson
2020-05-12  1:21   ` Bjorn Andersson
2020-05-12  1:21     ` Bjorn Andersson
2020-05-09 20:15 ` [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Sam Ravnborg
2020-05-09 20:15   ` Sam Ravnborg
2020-05-09 22:48   ` Doug Anderson
2020-05-09 22:48     ` Doug Anderson
2020-05-18 14:50     ` Doug Anderson
2020-05-18 14:50       ` Doug Anderson
2020-05-18 17:59       ` Sam Ravnborg
2020-05-18 17:59         ` Sam Ravnborg
2020-05-18 18:05         ` Doug Anderson
2020-05-18 18:05           ` Doug Anderson
2020-05-18 18:28           ` Sam Ravnborg
2020-05-18 18:28             ` Sam Ravnborg

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=20200507143354.v5.5.I72892d485088e57378a4748c86bc0f6c2494d807@changeid \
    --to=dianders@chromium.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=bgolaszewski@baylibre.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robdclark@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=spanda@codeaurora.org \
    --cc=swboyd@chromium.org \
    /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.