From mboxrd@z Thu Jan 1 00:00:00 1970 From: Douglas Anderson Subject: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay Date: Thu, 25 Oct 2018 15:21:32 -0700 Message-ID: <20181025222134.174583-4-dianders@chromium.org> References: <20181025222134.174583-1-dianders@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20181025222134.174583-1-dianders@chromium.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sean Paul , Thierry Reding , Sandeep Panda Cc: David Airlie , linux-arm-msm@vger.kernel.org, Douglas Anderson , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ryandcase@chromium.org, Laurent Pinchart List-Id: linux-arm-msm@vger.kernel.org TGV0J3Mgc29sdmUgdGhlIG15c3Rlcnkgb2YgY29tbWl0IGJmMTE3OGM5ODkzMCAoImRybS9icmlk Z2U6CnRpLXNuNjVkc2k4NjogQWRkIG15c3RlcnkgZGVsYXkgdG8gZW5hYmxlKCkiKS4gIFNwZWNp ZmljYWxseSB0aGUKcmVhc29uIHdlIG5lZWRlZCB0aGF0IG15c3RlcnkgZGVsYXkgaXMgdGhhdCB3 ZSB3ZXJlbid0IHBheWluZwphdHRlbnRpb24gdG8gSFBELgoKTG9va2luZyBhdCB0aGUgZGF0YXNo ZWV0IGZvciB0aGUgc2FtZSBwYW5lbCB0aGF0IHdhcyB0ZXN0ZWQgZm9yIHRoZQpvcmlnaW5hbCBj b21taXQsIEkgc2VlIHRoZXJlJ3MgYSB0aW1pbmcgInQzIiB0aGF0IHRpbWVzIGZyb20gcG93ZXIg b24KdG8gdGhlIGF1eCBjaGFubmVsIGJlaW5nIG9wZXJhdGlvbmFsLiAgVGhpcyB0aW1lIGlzIHNw ZWNjZWQgYXMgMCAtIDIwMAptcy4gIFRoZSBkYXRhc2hlZXQgc2F5cyB0aGF0IHRoZSBhdXggY2hh bm5lbCBpcyBvcGVyYXRpb25hbCBhdCBleGFjdGx5CnRoZSBzYW1lIHRpbWUgdGhhdCBIUEQgaXMg YXNzZXJ0ZWQuCgpTY29waW5nIHRoZSBzaWduYWxzIG9uIHRoaXMgYm9hcmQgc2hvd2VkIHRoYXQg SFBEIHdhcyBhc3NlcnRlZCA4NCBtcwphZnRlciBwb3dlciB3YXMgYXNzZXJ0ZWQuICBUaGF0IHZl cnkgY2xvc2VseSBtYXRjaGVzIHRoZSBtYWdpYyA3MCBtcwpkZWxheSB0aGF0IHdlIGhhZC4gIC4u LmFuZCBhY3R1YWxseSwgaW4gbXkgdGVzdGluZyB0aGUgNzAgbXMgd2Fzbid0CnF1aXRlIGVub3Vn aCBvZiBhIGRlbGF5IGFuZCBzb21lIHBlcmNlbnRhZ2Ugb2YgdGhlIHRpbWUgdGhlIGRpc3BsYXkK ZGlkbid0IGNvbWUgdXAgdW50aWwgSSBidW1wZWQgaXQgdG8gMTAwIG1zIChwcmVzdW1hYmx5IDg0 IG1zIHdvdWxkCmhhdmUgd29ya2VkIHRvbykuCgpUbyBzb2x2ZSB0aGlzLCB3ZSB0cmllZCB0byBo b29rIHVwIHRoZSBIUEQgc2lnbmFsIGluIHRoZSBicmlkZ2UuCi4uLmJ1dCBpbiBkb2luZyBzbyB3 ZSBmb3VuZCB0aGF0IHRoYXQgdGhlIGJyaWRnZSBkaWRuJ3QgcmVwb3J0IHRoYXQKSFBEIHdhcyBh c3NlcnRlZCB1bnRpbCB+MjgwIG1zIGFmdGVyIHdlIHBvd2VyZWQgaXQgKCEpLiAgVGhpcyBpcwpl eHBsYWluZWQgYnkgbG9va2luZyBhdCB0aGUgc242NWRzaTg2IGRhdGFzaGVldCBzZWN0aW9uICI4 LjQuNS4xIEhQRAooSG90IFBsdWcvVW5wbHVnIERldGVjdGlvbikiLiAgUmVhZGluZyB0aGVyZSB3 ZSBzZWUgdGhhdCB0aGUgYnJpZGdlCmlzbid0IGV2ZW4gaW50ZW5kZWQgdG8gcmVwb3J0IEhQRCB1 bnRpbCAxMDAgbXMgYWZ0ZXIgaXQncyBhc3NlcnRlZC4KLi4uYnV0IHRoYXQgd291bGQgaGF2ZSBs ZWZ0IHVzIGF0IDE4NCBtcy4gIFRoZSBleHRyYSAxMDAgbXMKKHByZXN1bWFibHkpIGNvbWVzIGZy b20gdGhpcyBwYXJ0IGluIHRoZSBkYXRhc2hlZXQ6Cgo+IFRoZSBIUEQgc3RhdGUgbWFjaGluZSBv cGVyYXRlcyBvZmYgYW4gaW50ZXJuYWwgcmluZyBvc2NpbGxhdG9yLiBUaGUKPiByaW5nIG9zY2ls bGF0b3IgZnJlcXVlbmN5IHdpbGwgdmFyeSBbIC4uLiBdLiBUaGUgbWluL21heCByYW5nZSBpbgo+ IHRoZSBIUEQgU3RhdGUgRGlhZ3JhbSByZWZlcnMgdG8gdGhlIHBvc3NpYmxlIHRpbWVzIGJhc2Vk IG9mZgo+IHZhcmlhdGlvbiBpbiB0aGUgcmluZyBvc2NpbGxhdG9yIGZyZXF1ZW5jeS4KCkdpdmVu IHRoYXQgdGhlIDI4MCBtcyB3ZSdsbCBlbmQgdXAgZGVsYXlpbmcgaWYgd2UgaG9vayB1cCBIUEQg aXMKX3Nsb3dlcl8gdGhhbiB0aGUgMjAwIG1zIHdlIGNvdWxkIGp1c3QgaGFyZGNvZGUsIGZvciBu b3cgd2UnbGwgc29sdmUKdGhlIHByb2JsZW0gYnkganVzdCBoYXJkY29kaW5nIGEgMjAwIG1zIGRl bGF5IGluIHRoZSBwYW5lbCBkcml2ZXIKdXNpbmcgdGhlIHBhdGNoIGluIHRoaXMgc2VyaWVzICgi ZHJtL3BhbmVsOiBzaW1wbGU6IFN1cHBvcnQgcGFuZWxzCndpdGggSFBEIHdoZXJlIEhQRCBpc24n dCBjb25uZWN0ZWQiKS4KCklmIHdlIGxhdGVyIGZpbmQgYSBwYW5lbCB0aGF0IG5lZWRzIHRvIHVz ZSB0aGlzIGJyaWRnZSB3aGVyZSB3ZSBuZWVkCkhQRCB0aGVuIHdlJ2xsIGhhdmUgdG8gY29tZSB1 cCB3aXRoIHNvbWUgbmV3IGNvZGUgdG8gaGFuZGxlIGl0LiAgR2l2ZW4KdGhlIHNpbGx5IGRlYm91 bmNpbmcgaW4gdGhlIGJyaWRnZSBjaGlwLCB0aG91Z2gsIGl0IHNlZW1zIHVubGlrZWx5LgoKT25l IGxhc3Qgbm90ZSBpcyB0aGF0IEkgdHJpZWQgdG8gc29sdmUgdGhpcyB0aHJvdWdoIGFub3RoZXIg d2F5OiBJbgp0aV9zbl9icmlkZ2VfZW5hYmxlKCkgSSB0cmllZCB0byB1c2UgdmFyaW91cyBjb21i aW5hdGlvbnMgb2YKZHBfZHBjZF93cml0ZWIoKSBhbmQgZHBfZHBjZF9yZWFkYigpIHRvIGRldGVj dCB3aGVuIHRoZSBhdXggY2hhbm5lbAp3YXMgdXAuICBJbiB0aGVvcnkgdGhhdCB3b3VsZCBsZXQg bWUgZGV0ZWN0IF9leGFjdGx5XyB3aGVuIEkgY291bGQKY29udGludWUgYW5kIGRvIGxpbmsgdHJh aW5pbmcuICBVbmZvcnR1bmF0ZWx5IGV2ZW4gaWYgSSBkaWQgYW4gYXV4CnRyYW5zZmVyIHcvb3V0 IHdhaXRpbmcgSSBjb3VsZG4ndCBzZWUgYW55IGVycm9ycy4gIFBvc3NpYmx5IEkgY291bGQKa2Vl cCBsb29waW5nIG92ZXIgbGluayB0cmFpbmluZyB1bnRpbCBpdCBjYW1lIGJhY2sgd2l0aCBzdWNj ZXNzLCBidXQKdGhhdCBzZWVtZWQgYSBsaXR0bGUgb3Zlcmx5IGhhY2t5IHRvIG1lLgoKU2lnbmVk LW9mZi1ieTogRG91Z2xhcyBBbmRlcnNvbiA8ZGlhbmRlcnNAY2hyb21pdW0ub3JnPgpSZXZpZXdl ZC1ieTogU2VhbiBQYXVsIDxzZWFuQHBvb3JseS5ydW4+Ci0tLQoKQ2hhbmdlcyBpbiB2MjogTm9u ZQoKIGRyaXZlcnMvZ3B1L2RybS9icmlkZ2UvdGktc242NWRzaTg2LmMgfCAyOSArKysrKysrKysr KysrKystLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAxNiBpbnNlcnRpb25zKCspLCAxMyBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vYnJpZGdlL3RpLXNuNjVk c2k4Ni5jIGIvZHJpdmVycy9ncHUvZHJtL2JyaWRnZS90aS1zbjY1ZHNpODYuYwppbmRleCBmOGE5 MzFjZjM2NjUuLjY4MDU2NmQ5N2FkYyAxMDA2NDQKLS0tIGEvZHJpdmVycy9ncHUvZHJtL2JyaWRn ZS90aS1zbjY1ZHNpODYuYworKysgYi9kcml2ZXJzL2dwdS9kcm0vYnJpZGdlL3RpLXNuNjVkc2k4 Ni5jCkBAIC00NTgsMTggKzQ1OCw2IEBAIHN0YXRpYyB2b2lkIHRpX3NuX2JyaWRnZV9lbmFibGUo c3RydWN0IGRybV9icmlkZ2UgKmJyaWRnZSkKIAl1bnNpZ25lZCBpbnQgdmFsOwogCWludCByZXQ7 CiAKLQkvKgotCSAqIEZJWE1FOgotCSAqIFRoaXMgNzBtcyB3YXMgZm91bmQgbmVjZXNzYXJ5IGJ5 IGV4cGVyaW1lbnRhdGlvbi4gSWYgaXQncyBub3QKLQkgKiBwcmVzZW50LCBsaW5rIHRyYWluaW5n IGZhaWxzLiBJdCBzZWVtcyBsaWtlIGl0IGNhbiBnbyBhbnl3aGVyZSBmcm9tCi0JICogcHJlX2Vu YWJsZSgpIHVwIHRvIHNlbWktYXV0byBsaW5rIHRyYWluaW5nIGluaXRpYXRpb24gYmVsb3cuCi0J ICoKLQkgKiBOZWl0aGVyIHRoZSBkYXRhc2hlZXQgZm9yIHRoZSBicmlkZ2Ugbm9yIHRoZSBwYW5l bCB0ZXN0ZWQgbWVudGlvbiBhCi0JICogZGVsYXkgb2YgdGhpcyBtYWduaXR1ZGUgaW4gdGhlIHRp bWluZyByZXF1aXJlbWVudHMuIFNvIGZvciBub3csIGFkZAotCSAqIHRoZSBteXN0ZXJ5IGRlbGF5 IHVudGlsIHNvbWVvbmUgZmlndXJlcyBvdXQgYSBiZXR0ZXIgZml4LgotCSAqLwotCW1zbGVlcCg3 MCk7Ci0KIAkvKiBEU0lfQSBsYW5lIGNvbmZpZyAqLwogCXZhbCA9IENIQV9EU0lfTEFORVMoNCAt IHBkYXRhLT5kc2ktPmxhbmVzKTsKIAlyZWdtYXBfdXBkYXRlX2JpdHMocGRhdGEtPnJlZ21hcCwg U05fRFNJX0xBTkVTX1JFRywKQEAgLTUzNiw3ICs1MjQsMjIgQEAgc3RhdGljIHZvaWQgdGlfc25f YnJpZGdlX3ByZV9lbmFibGUoc3RydWN0IGRybV9icmlkZ2UgKmJyaWRnZSkKIAkvKiBjb25maWd1 cmUgYnJpZGdlIHJlZl9jbGsgKi8KIAl0aV9zbl9icmlkZ2Vfc2V0X3JlZmNsa19mcmVxKHBkYXRh KTsKIAotCS8qIGluIGNhc2UgZHJtX3BhbmVsIGlzIGNvbm5lY3RlZCB0aGVuIEhQRCBpcyBub3Qg c3VwcG9ydGVkICovCisJLyoKKwkgKiBIUEQgb24gdGhpcyBicmlkZ2UgY2hpcCBpcyBhIGJpdCB1 c2VsZXNzLiAgVGhpcyBpcyBhbiBlRFAgYnJpZGdlCisJICogc28gdGhlIEhQRCBpcyBhbiBpbnRl cm5hbCBzaWduYWwgdGhhdCdzIG9ubHkgdGhlcmUgdG8gc2lnbmFsIHRoYXQKKwkgKiB0aGUgcGFu ZWwgaXMgZG9uZSBwb3dlcmluZyB1cC4gIC4uLmJ1dCB0aGUgYnJpZGdlIGNoaXAgZGVib3VuY2Vz CisJICogdGhpcyBzaWduYWwgYnkgYmV0d2VlbiAxMDAgbXMgYW5kIDQwMCBtcyAoZGVwZW5kaW5n IG9uIHByb2Nlc3MsCisJICogdm9sdGFnZSwgYW5kIHRlbXBlcmF0ZS0tSSBtZWFzdXJlZCBpdCBh dCBhYm91dCAyMDAgbXMpLiAgT25lCisJICogcGFydGljdWxhciBwYW5lbCBhc3NlcnRlZCBIUEQg ODQgbXMgYWZ0ZXIgaXQgd2FzIHBvd2VyZWQgb24gbWVhbmluZworCSAqIHRoYXQgd2Ugc2F3IEhQ RCAyODQgbXMgYWZ0ZXIgcG93ZXIgb24uICAuLi5idXQgdGhlIHNhbWUgcGFuZWwgc2FpZAorCSAq IHRoYXQgaW5zdGVhZCBvZiBsb29raW5nIGF0IEhQRCB5b3UgY291bGQganVzdCBoYXJkY29kZSBh IGRlbGF5IG9mCisJICogMjAwIG1zLiAgV2UnbGwgYXNzdW1lIHRoYXQgdGhlIHBhbmVsIGRyaXZl ciB3aWxsIGhhdmUgdGhlIGhhcmRjb2RlZAorCSAqIGRlbGF5IGluIGl0cyBwcmVwYXJlIGFuZCBh bHdheXMgZGlzYWJsZSBIUEQuCisJICoKKwkgKiBJZiBIUEQgc29tZWhvdyBtYWtlcyBzZW5zZSBv biBzb21lIGZ1dHVyZSBwYW5lbCB3ZSdsbCBoYXZlIHRvCisJICogY2hhbmdlIHRoaXMgdG8gYmUg Y29uZGl0aW9uYWwgb24gc29tZW9uZSBzcGVjaWZ5aW5nIHRoYXQgSFBEIHNob3VsZAorCSAqIGJl IHVzZWQuCisJICovCiAJcmVnbWFwX3VwZGF0ZV9iaXRzKHBkYXRhLT5yZWdtYXAsIFNOX0hQRF9E SVNBQkxFX1JFRywgSFBEX0RJU0FCTEUsCiAJCQkgICBIUERfRElTQUJMRSk7CiAKLS0gCjIuMTku MS41NjguZzE1MmFkOGUzMzYtZ29vZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJl ZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGlu Zm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFA1CECDE46 for ; Thu, 25 Oct 2018 22:22:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93FBA2075D for ; Thu, 25 Oct 2018 22:22:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="c3g0YpEp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93FBA2075D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727624AbeJZG4l (ORCPT ); Fri, 26 Oct 2018 02:56:41 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:45828 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727521AbeJZG4k (ORCPT ); Fri, 26 Oct 2018 02:56:40 -0400 Received: by mail-pg1-f193.google.com with SMTP id s3-v6so4661840pga.12 for ; Thu, 25 Oct 2018 15:22:12 -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=tA/+Y9/2aJwU6vkwStjbLLfZY+0s5KsUaFdKqCJw6Rw=; b=c3g0YpEpGod9nmQkJPTQ1YCgUvW6dQrgWqoMS0Hzja+mvjM9rFGsFhN5/3YyHkhYEc u2sHbl24RRDMAHf7H3iTRogqvGcFTPIyoNG3EV2cMUDCKPRRqAlgGWtB4f/GdcodXfUp EBAxZjuCLy1OBsWudyaTRowwKDd/qJUo6C3G0= 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=tA/+Y9/2aJwU6vkwStjbLLfZY+0s5KsUaFdKqCJw6Rw=; b=T+wz5xwbm0oVJcpnFisIk/OV1ksiFhBL3BlREvZzkaTXU/c33wy7gHD+wk0+9YCffl OeT6LF/pLbJi/1bsulZ7HyzaeX2qeUWKxEIPH04pRNGCbwUDwY+pFoyJGm9/ZDYGUhcz ZmOyinB2mkaZ7unXLoiyLiHfi6FJzuhTxRBlENf9w44B86P9dIRlqVMVe1hzcrJ99aMT XD3Yfj+2tunyf73wzL6DOUo+087puE6R+Y+YXJ2wCeLL1O3lgysxf9YqkeTfT5CdIv4v 3gaqju65Ok5WmGZxVWeqQEeOVXMQ7s0tHG85fYksvZjblKccuGreFtombT9jF5+pa9I0 SNGQ== X-Gm-Message-State: AGRZ1gLXqJrI64DTf88ODyYbW/pTBszK65svG7izCAXWMti0e5friN6K o4sSqy5CELkr+I0OcyeqC/SCzg== X-Google-Smtp-Source: AJdET5eVZ8eZKIupKVYYPIbFxQpQwC+dCTVm/4LrRZGaXkGoMcmyCtljn7hVatG0hJwf7L0nmtxo0Q== X-Received: by 2002:a62:52cc:: with SMTP id g195-v6mr986538pfb.241.1540506131936; Thu, 25 Oct 2018 15:22:11 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:c8e0:70d7:4be7:a36]) by smtp.gmail.com with ESMTPSA id x73-v6sm19813778pfk.139.2018.10.25.15.22.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 15:22:11 -0700 (PDT) From: Douglas Anderson To: Sean Paul , Thierry Reding , Sandeep Panda Cc: linux-arm-msm@vger.kernel.org, Laurent Pinchart , 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 v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay Date: Thu, 25 Oct 2018 15:21:32 -0700 Message-Id: <20181025222134.174583-4-dianders@chromium.org> X-Mailer: git-send-email 2.19.1.568.g152ad8e336-goog In-Reply-To: <20181025222134.174583-1-dianders@chromium.org> References: <20181025222134.174583-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 testing 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 (presumably 84 ms would have worked too). 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 hardcoding a 200 ms delay in the panel driver using the patch in this series ("drm/panel: simple: Support panels with HPD where HPD isn't connected"). If we later find a panel that needs to use this bridge where we need HPD then we'll have to come up with some new code to handle it. Given the silly debouncing in the bridge chip, though, it seems unlikely. 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 Reviewed-by: Sean Paul --- Changes in v2: None drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++++++++++++++------------ 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index f8a931cf3665..680566d97adc 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) unsigned int val; 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. - * - * 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. - */ - msleep(70); - /* DSI_A lane config */ val = CHA_DSI_LANES(4 - pdata->dsi->lanes); regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, @@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge) /* configure bridge ref_clk */ ti_sn_bridge_set_refclk_freq(pdata); - /* in case drm_panel is connected then HPD is not supported */ + /* + * HPD on this bridge chip is a bit useless. This is an eDP bridge + * so the HPD is an internal signal that's only there to signal that + * the panel is done powering up. ...but the bridge chip debounces + * this signal by between 100 ms and 400 ms (depending on process, + * voltage, and temperate--I measured it at about 200 ms). One + * particular panel asserted HPD 84 ms after it was powered on meaning + * that we saw HPD 284 ms after power on. ...but the same panel said + * that instead of looking at HPD you could just hardcode a delay of + * 200 ms. We'll assume that the panel driver will have the hardcoded + * delay in its prepare and always disable HPD. + * + * If HPD somehow makes sense on some future panel we'll have to + * change this to be conditional on someone specifying that HPD should + * be used. + */ regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE, HPD_DISABLE); -- 2.19.1.568.g152ad8e336-goog