linux-kernel - Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171201001146.fezhkf5c3zrbqjlj@aura.draconx.ca>
Date:   Thu, 30 Nov 2017 19:11:46 -0500
From:   Nick Bowler <nbowler@...conx.ca>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Archit Taneja <architt@...eaurora.org>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Airlie <airlied@...hat.com>,
        Andrzej Hajda <a.hajda@...sung.com>
Subject: Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug
 (regression)

Hi,

On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> 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 [Laurent Pinchart's] patch --
>    the issue is present again (no change in behaviour compared to
>    4.15-rc1).

Another data point... the following patch appears sufficient to restore
working behaviour.

Cheers,
  Nick

---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..3118fbd8433d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1101,8 +1101,6 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 {
 	const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-	unsigned int i;
-	u8 val;
 
 	if (phy->gen == 1) {
 		dw_hdmi_phy_enable_powerdown(hdmi, false);
@@ -1116,21 +1114,6 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 	dw_hdmi_phy_gen2_txpwron(hdmi, 1);
 	dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-	/* Wait for PHY PLL lock */
-	for (i = 0; i < 5; ++i) {
-		val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-		if (val)
-			break;
-
-		usleep_range(1000, 2000);
-	}
-
-	if (!val) {
-		dev_err(hdmi->dev, "PHY PLL failed to lock\n");
-		return -ETIMEDOUT;
-	}
-
-	dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
 	return 0;
 }
 
-- 
2.13.6