Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp9613042ybl; Fri, 17 Jan 2020 15:23:24 -0800 (PST) X-Google-Smtp-Source: APXvYqzxuA6RX8meKy3HdnClbPSubQIy/e3qa6QgDr0QHIbmHE82YMQcbffC6fRNsUiOC+inpDOA X-Received: by 2002:a9d:1c95:: with SMTP id l21mr7888749ota.271.1579303404748; Fri, 17 Jan 2020 15:23:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579303404; cv=none; d=google.com; s=arc-20160816; b=n0thEO/Iwoev11VoBWLkGUdV1ZI0S5TXX0nBUTp7jI+MmMv8HFBOsuiokJjwZxS/XP p5G6sy1yVyvwICAMgVud0wxbiVUtzEeXg8mPj879ZOeA6YJaAklryLtP0QWmhVfqTFkS P9ohmINiGntmINMHE2rkakeisDoP96NyMKlDkIuZQaavInqivD+jX1O49aU9VR95/iNT o/wiDEgAHBT+1L8s0DtNLXxNSwaHqmhnTF0YQFbW+jXZLlWwjw9rNnBsDYbsvtY7q8Rh BdeNQjy1VpOYQw53vQm2GBYn3JiLeIqIeG7WEI/8KiLRQaI0pGSjOM+SxfaLlcTE6MQh U7ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=3/SHYbTc4mVQlnGSSRKlNXBA4512ItBob86hriSAwCo=; b=R4XsGUlZHVvShEmj2xlMTvSYPj/43aZv7cjj4aVAwdmDwGXn1nHjdRROMsQgWyZoLw mNX4rA4l4ZxQvEzMGAN0klAvdV8z3RYvyjDHS/ahhXY91a1ucujHUsTBKmFWCpsecnKw YTQOfRGPJgsAmkbdZhJWCTpJM0iFxNoakSEL93eNn7ZvO+Nru1FCfAgC1lisKOIb+fC8 zCbws1ab00dZuN2TDwMHXa9pWpSAnciPM9zVkjB+jrn66MpKGHzrVD/GMdU/rbr/imBS 4bJhoOBIcQXXcSUXywemvu8OhHQlI5dck5DoMUflBOOStJphZyrrgWq8Tj6Brhw60ITu 4KzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PQQUb8An; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r26si16721465otc.163.2020.01.17.15.23.12; Fri, 17 Jan 2020 15:23:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PQQUb8An; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730184AbgAQXWP (ORCPT + 99 others); Fri, 17 Jan 2020 18:22:15 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:47665 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730075AbgAQXWP (ORCPT ); Fri, 17 Jan 2020 18:22:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579303334; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3/SHYbTc4mVQlnGSSRKlNXBA4512ItBob86hriSAwCo=; b=PQQUb8Anov88HLEqj9Uurmi51e/cPPe+8QtSPPQux6A2J4I2Tjz7Jvnx/OR16wRM7cXJIa Oc3UAOR38Seq3iiBIFsAezzWfYtyIkTTKrB5nEYlceD7q1ros9AY2eNfYkLgi3CAD0Jf/d LW4UbpJCJelGeU330ImargskCpQcNBE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-169-W9xSDrvmNN6DIb-3p0VLUw-1; Fri, 17 Jan 2020 18:22:11 -0500 X-MC-Unique: W9xSDrvmNN6DIb-3p0VLUw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 980228017CC; Fri, 17 Jan 2020 23:22:08 +0000 (UTC) Received: from malachite.bss.redhat.com (dhcp-10-20-1-90.bss.redhat.com [10.20.1.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7315A5C1D8; Fri, 17 Jan 2020 23:22:03 +0000 (UTC) From: Lyude Paul To: intel-gfx@lists.freedesktop.org, Jani Nikula Cc: Perry Yuan , AceLan Kao , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , Chris Wilson , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Lee Shawn C , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v4] drm/i915: Don't use VBT for detecting DPCD backlight controls Date: Fri, 17 Jan 2020 18:21:54 -0500 Message-Id: <20200117232155.135579-1-lyude@redhat.com> In-Reply-To: <20200116211623.53799-5-lyude@redhat.com> References: <20200116211623.53799-5-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Despite the fact that the VBT appears to have a field for specifying that a system is equipped with a panel that supports standard VESA backlight controls over the DP AUX channel, so far every system we've spotted DPCD backlight control support on doesn't actually set this field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI. While we don't know the exact reason for this VBT misuse, talking with some vendors indicated that there's a good number of laptop panels out there that supposedly support both PWM backlight controls and DPCD backlight controls as a workaround until Intel supports DPCD backlight controls across platforms universally. This being said, the X1 Extreme 2nd Gen that I have here (note that Lenovo is not the hardware vendor that informed us of this) PWM backlight controls are advertised, but only DPCD controls actually function. I'm going to make an educated guess here and say that on systems like this one, it's likely that PWM backlight controls might have been intended to work but were never really tested by QA. Since we really need backlights to work without any extra module parameters, let's take the risk here and rely on the standard DPCD caps to tell us whether AUX backlight controls are supported or not. We still check the VBT, just so we can print a debugging message on systems that advertise DPCD backlight support on the panel but not in the VBT. Changes since v3: * Print a debugging message if we enable DPCD backlight control on a device which doesn't report DPCD backlight controls in it's VBT, instead of warning on custom panel backlight interfaces. Signed-off-by: Lyude Paul Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D112376 Cc: Jani Nikula Cc: Perry Yuan Cc: AceLan Kao --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/driv= ers/gpu/drm/i915/display/intel_dp_aux_backlight.c index 77a759361c5c..0f8edc775375 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -328,15 +328,16 @@ intel_dp_aux_display_control_capable(struct intel_c= onnector *connector) int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_conn= ector) { struct intel_panel *panel =3D &intel_connector->panel; - struct drm_i915_private *dev_priv =3D to_i915(intel_connector->base.dev= ); + enum intel_backlight_type type =3D + to_i915(intel_connector->base.dev)->vbt.backlight.type; =20 if (i915_modparams.enable_dpcd_backlight =3D=3D 0 || (i915_modparams.enable_dpcd_backlight =3D=3D -1 && - dev_priv->vbt.backlight.type !=3D INTEL_BACKLIGHT_VESA_EDP_AUX_INTE= RFACE)) + !intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV; =20 - if (!intel_dp_aux_display_control_capable(intel_connector)) - return -ENODEV; + if (type !=3D INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE) + DRM_DEBUG_DRIVER("Ignoring VBT backlight type\n"); =20 panel->backlight.setup =3D intel_dp_aux_setup_backlight; panel->backlight.enable =3D intel_dp_aux_enable_backlight; --=20 2.24.1