From patchwork Tue Nov 28 03:30:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Bowler X-Patchwork-Id: 10078971 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BBD4F6056A for ; Tue, 28 Nov 2017 08:13:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9FB3129149 for ; Tue, 28 Nov 2017 08:13:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 94C56291AA; Tue, 28 Nov 2017 08:13:41 +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=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0EE5629149 for ; Tue, 28 Nov 2017 08:13:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 939296E515; Tue, 28 Nov 2017 08:12:11 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id BF96F6E434 for ; Tue, 28 Nov 2017 03:30:50 +0000 (UTC) Received: by mail-io0-x229.google.com with SMTP id z74so38781796iof.12 for ; Mon, 27 Nov 2017 19:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jazMf6IciTYpjA9NEhWYwbj4vRcIyuO+T/zPaRu9SFM=; b=FkWc3Kq02xdU/F8K+pa8SPkm/F+G8ZdM/1HaRgQLK80B+wPJFweGYM3bHmeF+loLfj HXrqxJmCqyUHMzu1zTgqg7UiUg2y8dydMORb059XDX1mdsK8RT1wVDPcmOGIXSX+hFqI 5Qh7kmEXP5tIcRGTJ22umvz94EeeGagLsiE3ZbhH8iJ8VI6bk670oaburhEBOo589v+t izmfl2tgC2BYDoYfEUriuyQI0r0g0g8zkreQWGgPas+NpEuN7vXXA8AI0IIuc4gJlga5 JiSN2eGxyLVL7b+2WuSNXz5qam7dnH4c5rpHeVsH1QCmeLzmVzZFZb7y0SJv8pC7WCIE 6dDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jazMf6IciTYpjA9NEhWYwbj4vRcIyuO+T/zPaRu9SFM=; b=o28axxH21VRQoY3BqPatyUDsJNIlnAHdAEpu+737/L1viIILd4ThRcPnsRB21eE0Ox R+4D9gzyLLjUFma8jtcVgPkBfOTaST2WtHrs9fVq55dTbSIUPcPrUgP0RjvV0343+rVL zgSMmpXu02QcYJj8UziwFgdkW2eTA1+uaShbFPnMFD/MwEsrZEcRb0jvJPQ4rzouFBNo Z8j2IaAHnsr+a05gw3Pv2U4L2CiUQj9oDFyxJGFNCzFDJyfSvr52s7n4/bb/JCKENkUm 11RQpITmj9zGDnjnTvuKU00DRurGhj95HgrEHdrod7NvVEnqwNQFa8VeSUpunsCYAIFh De8A== X-Gm-Message-State: AJaThX7skT9SqmuDFzPCcjMixsXQeTHcHrWh1R0CvLiqyIUVXurpZmGr 1Sery6607lAHwCpLdxNBRJTpi198wWY= X-Google-Smtp-Source: AGs4zMYDFqULXICd1ehnNsd0uRaK1TR98IxyJr33Yhqk0HPdrocbN25Fa0EbkjDlapGibkxlB/mCuw== X-Received: by 10.107.141.199 with SMTP id p190mr44933801iod.269.1511839849830; Mon, 27 Nov 2017 19:30:49 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id l34sm12638699ioi.16.2017.11.27.19.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 19:30:48 -0800 (PST) Date: Mon, 27 Nov 2017 22:30:44 -0500 From: Nick Bowler To: Laurent Pinchart Subject: Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression) Message-ID: <20171128033044.bw4jwps2gya2vbig@aura.draconx.ca> References: <20171116062811.g27zgeejizfxu6oc@aura.draconx.ca> <269ce21a-3685-30e8-fcc8-65070bc59eea@codeaurora.org> <13872912.d01MB1IQ9u@avalon> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <13872912.d01MB1IQ9u@avalon> User-Agent: NeoMutt/20171027 X-Mailman-Approved-At: Tue, 28 Nov 2017 08:11:00 +0000 Cc: Laurent Pinchart , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Dave Airlie , Linus Torvalds X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 2017-11-27 11:00 +0200, Laurent Pinchart wrote: > On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote: > > On 2017-11-05 11:41 -0500, Nick Bowler wrote: [...] > > > Bisection implicates the following commit: > > > > > > 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit > > > commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46 > > > Author: Laurent Pinchart > > > Date: Mon Mar 6 01:35:57 2017 +0200 > > > > > > drm: bridge: dw-hdmi: Fix the PHY power up sequence [...] > > > > The two main things the commit below does it to a) correctly wait on the > > TX_PHY_LOCK bit to be asserted and b) use usleep_range() instead of > > udelay(). > > Another difference is that the PWDN and TMDS signals, in theory needed for > Gen1 PHYs only, are not set anymore for Gen2 PHYs. Nick, could you test the > following change to see if it makes a difference ? I do not notice any difference with this change applied on top of Linux 4.15-rc1. A note about the test setup: I had to remove the test equipment so I no longer have any information about the video mode from the sink side (like in the photos). Thus, with the current setup, I am using the presense or absense of audio to determine whether the issue is present or not. The test procedure is: boot up, start music, then hotplug the hdmi four times. If sound is heard after all four connections, PASS; otherwise FAIL. - I retested on 4.15-rc1 to confirm that the issue is still present (it is). - I applied the functional revert from earlier on top of 4.15-rc1 and the problem is fixed. - Returning to 4.15-rc1 and applying this next patch -- the issue is present again (no change in behaviour compared to 4.15-rc1). > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/ > bridge/synopsys/dw-hdmi.c > index b172139502d6..1c18ff1bf24a 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1104,14 +1104,14 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi) > unsigned int i; > u8 val; > > - if (phy->gen == 1) { > - dw_hdmi_phy_enable_powerdown(hdmi, false); > + dw_hdmi_phy_enable_powerdown(hdmi, false); > > - /* Toggle TMDS enable. */ > - dw_hdmi_phy_enable_tmds(hdmi, 0); > - dw_hdmi_phy_enable_tmds(hdmi, 1); > + /* Toggle TMDS enable. */ > + dw_hdmi_phy_enable_tmds(hdmi, 0); > + dw_hdmi_phy_enable_tmds(hdmi, 1); > + > + if (phy->gen == 1) > return 0; > - } > > dw_hdmi_phy_gen2_txpwron(hdmi, 1); > dw_hdmi_phy_gen2_pddq(hdmi, 0); > > > I don't see (b) being a problem. About (a), it's possible that the bit above > > is interpreted differently on a rockchip SoC versus a renesas chip. Could > > you print the value of HDMI_PHY_STAT0 that's read back? [...] > > As an experiment, could you forcefully return 0 instead of -ETIMEDOUT and > > see if things return back to normal? I did both of these tests at once by applying the below patch on top of 4.15-rc1. There is no change in behaviour compared to 4.15-rc1 (except for the added printouts). With this, every time after inserting the cable the following is printed: [ 128.002965] dwhdmi-rockchip ff980000.hdmi: 0: HDMI_PHY_STAT0: f2 [ 128.004614] dwhdmi-rockchip ff980000.hdmi: 1: HDMI_PHY_STAT0: f3 [ 128.013752] dwhdmi-rockchip ff980000.hdmi: 0: HDMI_PHY_STAT0: f2 [ 128.015605] dwhdmi-rockchip ff980000.hdmi: 1: HDMI_PHY_STAT0: f3 And there is no difference in output between working and non-working cases. I've attached the full log; I manually logged extra messages to give context from the test procedure: "hdmi (not) working" - after bootup or connecting the cable (indicating test pass/fail) "hdmi disconnect" - after unplugging the cable. Let me know if there's anything else I should try. Thanks, Nick diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index bf14214fa464..0358f6020fb4 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1118,7 +1118,11 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi) /* Wait for PHY PLL lock */ for (i = 0; i < 5; ++i) { - val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK; + val = hdmi_readb(hdmi, HDMI_PHY_STAT0); + + dev_info(hdmi->dev, "%u: HDMI_PHY_STAT0: %.2hhx\n", i, val); + + val &= HDMI_PHY_TX_PHY_LOCK; if (val) break; @@ -1127,7 +1131,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi) if (!val) { dev_err(hdmi->dev, "PHY PLL failed to lock\n"); - return -ETIMEDOUT; + return 0; } dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);