Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Douglas Anderson <dianders@chromium.org>
To:     Sandeep Panda <spanda@codeaurora.org>,
        Sean Paul <seanpaul@chromium.org>
Cc:     linux-arm-msm@vger.kernel.org, jsanka@codeaurora.org,
        ryandcase@chromium.org, Douglas Anderson <dianders@chromium.org>,
        Andrzej Hajda <a.hajda@samsung.com>,
        Stephen Boyd <swboyd@chromium.org>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>
Subject: [PATCH 1/2] dt-bindings: drm/bridge: sn65dsi86: Add panel-hpd-delay
Date:   Fri, 19 Oct 2018 13:19:39 -0700
Message-Id: <20181019201940.138179-1-dianders@chromium.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

The timing diagram of some eDP panels says that you're supposed to
wait for HPD to be asserted before the aux channel is operational.

In some cases, however, it's better to just hardcode the max delay
instead of trying to use HPD.  Why?

The sn65dsi86 datasheet says that it only reports the debounced
HPD signal to software.  It will tell software about HPD assertion
as quickly as 100 ms after it's asserted, but sometimes it might
take 400 ms because it's timed with a very inaccurate ring
oscillator.  In practice it was measured at 200 ms on at least
one system.

On a particular panel, HPD was asserted 84 ms after power was given.
This same panel specified that HPD would always be asserted within
200 ms of applying power.  Thus on this panel with the measured
84 ms to assert HPD + the 200 ms measured debounce we'd wait 284 ms
which is 84 ms longer than just hardcoding the sleep.

Let's allow boards to explicitly choose the hardcoded delay by adding
a device tree attribute for it.  A few notes:
a) This delay can't easily be in the panel bindings because the delay
   wouldn't actually be needed if the same panel were hooked somewhere
   else (someplace with more sane HPD behavior).
b) The nice thing about being able to set this delay is that it's also
   useful on boards where HPD wasn't hooked up at all (for whatever
   reason).

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 .../bindings/display/bridge/ti,sn65dsi86.txt          | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
index 0a3fbb53a16e..1a1ca0f7a1d8 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -33,6 +33,15 @@ Optional properties:
 
 - suspend-gpios: specification for GPIO1 pin on bridge (active low)
 
+- ti,panel-hpd-delay-ms: Assume that HPD from the panel will be asserted within
+			 this many milliseconds after giving power to the panel.
+			 With this number we can ignore the HPD signal from
+			 the panel and just hardcode a delay.  This is useful
+			 to do because the bridge chip only provides the
+			 debounced HPD signal to software and the timing of the
+			 debounce is very inaccurate so it's often faster to
+			 hardcode the max from the panel spec.
+
 Required nodes:
 This device has two video ports. Their connections are modelled using the
 OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
@@ -62,6 +71,8 @@ edp-bridge@2d {
 	clock-names = "refclk";
 	clocks = <&input_refclk>;
 
+	ti,panel-hpd-delay-ms = <200>;
+
 	ports {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.19.1.568.g152ad8e336-goog