[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200423092431.v3.5.I72892d485088e57378a4748c86bc0f6c2494d807@changeid>
Date: Thu, 23 Apr 2020 09:25:47 -0700
From: Douglas Anderson <dianders@...omium.org>
To: linus.walleij@...aro.org, bgolaszewski@...libre.com,
airlied@...ux.ie, daniel@...ll.ch, robh+dt@...nel.org,
narmstrong@...libre.com, a.hajda@...sung.com,
Laurent.pinchart@...asonboard.com, spanda@...eaurora.org
Cc: swboyd@...omium.org, devicetree@...r.kernel.org,
linux-gpio@...r.kernel.org, jeffrey.l.hugo@...il.com,
dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
robdclark@...omium.org, jernej.skrabec@...l.net, jonas@...boo.se,
bjorn.andersson@...aro.org,
Douglas Anderson <dianders@...omium.org>,
linux-kernel@...r.kernel.org
Subject: [PATCH v3 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
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@...omium.org>
Reviewed-by: Stephen Boyd <swboyd@...omium.org>
---
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 | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 6d7d40ad45ac..5746416b0f73 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -28,6 +28,10 @@ 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.
+
vccio-supply:
description: A 1.8V supply that powers the digital IOs.
@@ -207,6 +211,8 @@ examples:
clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
clock-names = "refclk";
+ no-hpd;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.26.1.301.g55bc3eb7cb9-goog
Powered by blists - more mailing lists