From patchwork Sun Dec 24 21:45:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Stefan_Br=C3=BCns?= X-Patchwork-Id: 10132187 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 A62AF6037D for ; Sun, 24 Dec 2017 21:56:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BA4E28BDA for ; Sun, 24 Dec 2017 21:56:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7F0FE28BDC; Sun, 24 Dec 2017 21:56:02 +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.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham 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 1C07D28BDA for ; Sun, 24 Dec 2017 21:56:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2198E6E004; Sun, 24 Dec 2017 21:56:00 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org X-Greylist: delayed 618 seconds by postgrey-1.35 at gabe; Sun, 24 Dec 2017 21:55:57 UTC Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [134.130.5.47]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2C4796E004; Sun, 24 Dec 2017 21:55:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CPCQDFH0Ba/54agoZdHAEBAQQBAQoBA?= =?us-ascii?q?YM+ZoEbB4N/mTSBWpllCiOFGIRQQhUBAQEBAQEBAQFrKIVNBAsBRjUCJgJfCgQ?= =?us-ascii?q?Fii4EDKY9gW06iEiCAwEBAQEBBQEBAQEBHgUJAYEFgn2CEoM/KQyGKRiCIoIOD?= =?us-ascii?q?DGCZQWKSIlIjzyBE4Zwj0mJfSmHQI0kiTICAgICCQIagTw1I4FPcIJ6glQcgWh?= =?us-ascii?q?3AYlJAYEVAQEB?= X-IPAS-Result: =?us-ascii?q?A2CPCQDFH0Ba/54agoZdHAEBAQQBAQoBAYM+ZoEbB4N/mTS?= =?us-ascii?q?BWpllCiOFGIRQQhUBAQEBAQEBAQFrKIVNBAsBRjUCJgJfCgQFii4EDKY9gW06i?= =?us-ascii?q?EiCAwEBAQEBBQEBAQEBHgUJAYEFgn2CEoM/KQyGKRiCIoIODDGCZQWKSIlIjzy?= =?us-ascii?q?BE4Zwj0mJfSmHQI0kiTICAgICCQIagTw1I4FPcIJ6glQcgWh3AYlJAYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,451,1508796000"; d="scan'208";a="30936550" Received: from rwthex-w2-a.rwth-ad.de ([134.130.26.158]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 24 Dec 2017 22:45:36 +0100 Received: from pebbles.fritz.box (84.155.102.158) by rwthex-w2-a.rwth-ad.de (2002:8682:1a9e::8682:1a9e) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Sun, 24 Dec 2017 22:45:32 +0100 From: =?UTF-8?q?Stefan=20Br=C3=BCns?= To: Subject: [PATCH v1] drm/i915: Try EDID bitbanging on HDMI after failed read Date: Sun, 24 Dec 2017 22:45:24 +0100 X-Mailer: git-send-email 2.15.1 MIME-Version: 1.0 X-Originating-IP: [84.155.102.158] X-ClientProxiedBy: rwthex-s2-b.rwth-ad.de (2002:8682:1a9b::8682:1a9b) To rwthex-w2-a.rwth-ad.de (2002:8682:1a9e::8682:1a9e) Message-ID: <013b6732-f3d7-41e0-9710-97c0c7133f47@rwthex-w2-a.rwth-ad.de> Cc: David Airlie , intel-gfx@lists.freedesktop.org, Joonas Lahtinen , linux-kernel@vger.kernel.org, Rodrigo Vivi , =?UTF-8?q?Stefan=20Br=C3=BCns?= 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 The ACK/NACK implementation as found in e.g. the G965 has the falling clock edge and the release of the data line to ACK the received byte happen at the same time. Some HDMI-to-VGA converters apparently read the ACK not in the middle of the clock high phase, but at the rising clock edge, so instead of an ACK sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the transfer. The bitbanging releases the data line for the ACK only 1/4 bit time after the falling clock edge, so a slave will see the correct value no matter if is samples at the rising or the falling clock edge or in the center. Fallback to bitbanging is already done for the CRT connector. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685 Signed-off-by: Stefan BrĂ¼ns --- drivers/gpu/drm/i915/intel_hdmi.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 4dea833f9d1b..847cda4c017c 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector) struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); struct edid *edid; bool connected = false; + struct i2c_adapter *i2c; intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); - edid = drm_get_edid(connector, - intel_gmbus_get_adapter(dev_priv, - intel_hdmi->ddc_bus)); + i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); + + edid = drm_get_edid(connector, i2c); + + if (!edid && !intel_gmbus_is_forced_bit(i2c)) { + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n"); + intel_gmbus_force_bit(i2c, true); + edid = drm_get_edid(connector, i2c); + intel_gmbus_force_bit(i2c, false); + } intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);