From patchwork Fri Oct 19 20:19:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 10650145 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 384941750 for ; Fri, 19 Oct 2018 20:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 29C2B27FA3 for ; Fri, 19 Oct 2018 20:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1DF052810E; Fri, 19 Oct 2018 20:20:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AC92327FA3 for ; Fri, 19 Oct 2018 20:20:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726403AbeJTE1n (ORCPT ); Sat, 20 Oct 2018 00:27:43 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:33051 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726246AbeJTE1n (ORCPT ); Sat, 20 Oct 2018 00:27:43 -0400 Received: by mail-pl1-f193.google.com with SMTP id s4-v6so16333030plp.0 for ; Fri, 19 Oct 2018 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ypr1b3a+zTVdUsID9jpNzwdeEbE3kjN+Jye3j5dNozs=; b=E5ulmdwKluwmNGIOt/jql1ysD/0xZKGGOcItwTmi+EPPB6A/MwVdHyxS93zpYYKAzA AfoEHspCw9abUiseXBZPFdaN4X0UBbFKWR+zA0bzfa+rmKuSwOiW4jBgJg8QKg+dAlbI DfR5NoRi0QLCtTzIh5WPBN5mhcf/bqvq4VdY8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ypr1b3a+zTVdUsID9jpNzwdeEbE3kjN+Jye3j5dNozs=; b=PRtD2UCKPP5aFEogakf8KjVBKdcQ2XCv0HDl4w8jAZXPCYRpn68Nr/C0miQWvafBJQ C8cdaUWTG0nL5QYKo+Noshkd5Pjv+fDUe30oimj+HA/IQRuJsapV6x5UNOR0xeo3bAXJ AshoD8/AuDqcCpNoQvBrG6ooiLd2CTAerJyShMCQL7jd7bFz+afqgTWYR96VG/w6SClu TtqlHFdCoIlsd/LQEC50jEQJj77PbVuxDclq8aI3Qlz9AVM/IYsZeiJYCrVUb1Vz2n20 nTYzuKbHbeA7SFkVSJDLDcLfeaianLDSNc5EXjUOmTCjb4xT67KeyI9qtZ72tHQ2gDYl 6cFg== X-Gm-Message-State: ABuFfohmPEzk1VTY1Y8PkUiyxuj7De8KEUvMo9hBpDmfeS1IyPFJyo9m F9smeEbFpmfE6F1y4ti1gLMmfQ== X-Google-Smtp-Source: ACcGV63l9PCzkCFguh++1dbH5hO4c7VDo4aZTvkBcrQOxkODTpeNviy5w0TXpgWq04LfYELdrl9eAA== X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11-v6mr34975271plb.219.1539980407151; Fri, 19 Oct 2018 13:20:07 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:c8e0:70d7:4be7:a36]) by smtp.gmail.com with ESMTPSA id i184-v6sm38281573pfg.88.2018.10.19.13.20.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 13:20:06 -0700 (PDT) From: Douglas Anderson To: Sandeep Panda , Sean Paul Cc: linux-arm-msm@vger.kernel.org, jsanka@codeaurora.org, ryandcase@chromium.org, Douglas Anderson , Andrzej Hajda , Stephen Boyd , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, David Airlie , Rob Herring , Mark Rutland 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> X-Mailer: git-send-email 2.19.1.568.g152ad8e336-goog MIME-Version: 1.0 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- .../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>; From patchwork Fri Oct 19 20:19:40 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 10650141 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A5E0D3B73 for ; Fri, 19 Oct 2018 20:20:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9762F2810E for ; Fri, 19 Oct 2018 20:20:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8AAB62832D; Fri, 19 Oct 2018 20:20:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CEC642810E for ; Fri, 19 Oct 2018 20:20:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726709AbeJTE1p (ORCPT ); Sat, 20 Oct 2018 00:27:45 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:40920 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726282AbeJTE1p (ORCPT ); Sat, 20 Oct 2018 00:27:45 -0400 Received: by mail-pl1-f194.google.com with SMTP id 1-v6so16318760plv.7 for ; Fri, 19 Oct 2018 13:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CMdWozsdXVjUEKyRAJeDLJEom6q5Exv1pHWt7qF5ZiM=; b=nPqzb0BOL6Ymae/PfZ251oOFWNDISM+Z4Vo5sitiK0dwLYv9uOR/suU2GqkmINYsb1 naksXkExXhhZcmmhQQzv3BvtiqI7L7zOc7EsboWiul3KrAqcCxs/isQ+aYGN3V3mAwxF LiF2uXCvfi6Zi2AhtZQ6fEPbYmXBE+xokzuco= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CMdWozsdXVjUEKyRAJeDLJEom6q5Exv1pHWt7qF5ZiM=; b=JucI+18pZ0KORU5nGyxiAT4zcknuDCgcSwqVDPnpSIrrUiU+X/6j0LyHyQOuvWvC27 QrGf3jBG8KpMsxaUKo5Qx9jukNKk8V6QQYBthhK2GPK3zhRU2D+aAu0XkP0qVlYdVFTW OQdL7MVjuSJciYqKk3i/yJmWFe12ztZgFM72Yf0OV8tazkm3cJCwHMqshCME57gkGn2U PWv4VWr5gBaZgYonVhLd2WsKemRAU0A5/sWk2+xOuNzNPSsAmbX23KSk+7l3/sDW+8nE DFWPciRwKflk4VpM1hOdK09damDYgrAoe3iDjylTHoJmBsEhB1S/BRGO/GYF8bGySFF5 x2yg== X-Gm-Message-State: ABuFfog/lJcPobXnflFflpqML/5R8wUQ28K6I3u9WwWzVcAodAuQ1l89 aawYIbHzwnQRqPVOWej9Adpn5Q== X-Google-Smtp-Source: ACcGV604hIcC7dA3C1ysPHg9aCVDOqjxmVIWoJ9ZrdGSyRCZ8QVzB3yXfruNrobjvdLNBzpy8RARsw== X-Received: by 2002:a17:902:3fe4:: with SMTP id a91-v6mr35363027pld.187.1539980408689; Fri, 19 Oct 2018 13:20:08 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:c8e0:70d7:4be7:a36]) by smtp.gmail.com with ESMTPSA id i184-v6sm38281573pfg.88.2018.10.19.13.20.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 13:20:07 -0700 (PDT) From: Douglas Anderson To: Sandeep Panda , Sean Paul Cc: linux-arm-msm@vger.kernel.org, jsanka@codeaurora.org, ryandcase@chromium.org, Douglas Anderson , Andrzej Hajda , Archit Taneja , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, David Airlie , Laurent Pinchart Subject: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay" Date: Fri, 19 Oct 2018 13:19:40 -0700 Message-Id: <20181019201940.138179-2-dianders@chromium.org> X-Mailer: git-send-email 2.19.1.568.g152ad8e336-goog In-Reply-To: <20181019201940.138179-1-dianders@chromium.org> References: <20181019201940.138179-1-dianders@chromium.org> MIME-Version: 1.0 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Let's solve the mystery of commit bf1178c98930 ("drm/bridge: ti-sn65dsi86: Add mystery delay to enable()"). Specifically the reason we needed that mystery delay is that we weren't paying attention to HPD. Looking at the datasheet for the same panel that was tested for the original commit, I see there's a timing "t3" that times from power on to the aux channel being operational. This time is specced as 0 - 200 ms. The datasheet says that the aux channel is operational at exactly the same time that HPD is asserted. Scoping the signals on this board showed that HPD was asserted 84 ms after power was asserted. That very closely matches the magic 70 ms delay that we had. ...and actually, in my esting the 70 ms wasn't quite enough of a delay and some percentage of the time the display didn't come up until I bumped it to 100 ms. To solve this, we tried to hook up the HPD signal in the bridge. ...but in doing so we found that that the bridge didn't report that HPD was asserted until ~280 ms after we powered it (!). This is explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD (Hot Plug/Unplug Detection)". Reading there we see that the bridge isn't even intended to report HPD until 100 ms after it's asserted. ...but that would have left us at 184 ms. The extra 100 ms (presumably) comes from this part in the datasheet: > The HPD state machine operates off an internal ring oscillator. The > ring oscillator frequency will vary [ ... ]. The min/max range in > the HPD State Diagram refers to the possible times based off > variation in the ring oscillator frequency. Given that the 280 ms we'll end up delaying if we hook up HPD is _slower_ than the 200 ms we could just hardcode, for now we'll solve the problem by just allowing boards to hardcode a value. If someone using this part finds that they can get things to work more quickly by actually hooking up HPD that can always be a future patch. One last note is that I tried to solve this through another way: In ti_sn_bridge_enable() I tried to use various combinations of dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel was up. In theory that would let me detect _exactly_ when I could continue and do link training. Unfortunately even if I did an aux transfer w/out waiting I couldn't see any errors. Possibly I could keep looping over link training until it came back with success, but that seemed a little overly hacky to me. Signed-off-by: Douglas Anderson --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 45 ++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index f8a931cf3665..5deed667480c 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -93,6 +93,7 @@ struct ti_sn_bridge { struct clk *refclk; struct drm_panel *panel; struct gpio_desc *enable_gpio; + int panel_hpd_delay_ms; struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM]; }; @@ -459,16 +460,37 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) int ret; /* - * FIXME: - * This 70ms was found necessary by experimentation. If it's not - * present, link training fails. It seems like it can go anywhere from - * pre_enable() up to semi-auto link training initiation below. + * 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. * - * Neither the datasheet for the bridge nor the panel tested mention a - * delay of this magnitude in the timing requirements. So for now, add - * the mystery delay until someone figures out a better fix. + * While we could configure the bridge to report the HPD signal to us + * and add a delay here until the HPD is asserted, it turns out that's + * slower than just hardcoding the max delay from the panel in some + * cases. 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. + * + * For now we don't know of any cases where paying attention to HPD + * is better than hardcoding the value. Thus for now only support the + * hardcoded delay and print a warning if it wasn't specified. Later + * one could imagine improving the driver to enable HPD support if + * panel-hpd-delay-ms wasn't specified in the device tree. */ - msleep(70); + if (pdata->panel_hpd_delay_ms >= 0) + msleep(pdata->panel_hpd_delay_ms); + else + DRM_WARN("HPD not supported; consider a hardcoded delay\n"); /* DSI_A lane config */ val = CHA_DSI_LANES(4 - pdata->dsi->lanes); @@ -656,6 +678,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client, { struct ti_sn_bridge *pdata; int ret; + u32 val; if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { DRM_ERROR("device doesn't support I2C\n"); @@ -712,6 +735,12 @@ static int ti_sn_bridge_probe(struct i2c_client *client, if (ret) return ret; + if (!of_property_read_u32(pdata->dev->of_node, + "ti,panel-hpd-delay-ms", &val)) + pdata->panel_hpd_delay_ms = val; + else + pdata->panel_hpd_delay_ms = -1; + pm_runtime_enable(pdata->dev); i2c_set_clientdata(client, pdata);