Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1133888pxy; Fri, 23 Apr 2021 00:37:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxitsBQqflTHLBSlOfN3FXrYF+CQ6OvfwQDR5oZknAmEUmj0rQqv3z9OKm+fGU4MpadW/JQ X-Received: by 2002:a17:906:b118:: with SMTP id u24mr2740130ejy.331.1619163421541; Fri, 23 Apr 2021 00:37:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619163421; cv=none; d=google.com; s=arc-20160816; b=fspaIJfrbtH9C6On4vGcKi/2x+Vnmiqa3PfVBr9BXFKaRljKoS58ACCyI7qrvhcUwF y2MppHeTBWmEqriD1aa3uuTyg2A+RaygqrDaLEGvj2ycfZEQsJqL8g00XfDuedkbMd+M wjAJ1Vxe+Bh15kXi2X5th1dVVGxgYxeUNQE5u0jzixe9dc2N+hGs9u9beSmdpuOkuT3O vUAWjhdLtI66J9L636L5TeGShNUEi2apSvhr+aXT0bNQmLlaWIW2Lr9LUUSnBS+D0Oc7 nYGMKfL8PBDqKdRgufEmNBE/hS2NDFVWvaX91PDY25ybXFguKj0SkFPdEHj9sAXkWoHj H5Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:ironport-sdr :ironport-sdr; bh=zoReuptsk4lkla+8MnoFG6+6Jj/siwSPwberIwu3ShY=; b=pcwBUWBeNABJxspgeHF5hCnzawcdRa5+6PpuU8OnJ85XYOpm+oog2pDRM6Py0gVKh5 5X3qD55aiiyzpBsAPNh5o2Fa19eb8pkWRB0BosjFAvLEYfuAvcdU+0VeAB0kjLzQCFsN 9SdY71nqy0SwMysUA9LLvmiVaVs9szKbxj4xo9gD0Fdrk7OH58oFrb72JI+HpPf8oE1B 6puYJBaHpLE7yjK84UuMQYjdv4s4CuLWOeNErWh1fNxSmro4cK1pSNohwkxXop2NYA0J fMEWgKZ5LYYVyXyeY+8vFphMiH//yovJ3S/vbTWa3DKCYfMjAelNoiCkUtqnfYK/K1Bx a2xw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g23si4520276edv.289.2021.04.23.00.36.37; Fri, 23 Apr 2021 00:37:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230191AbhDWHfh (ORCPT + 99 others); Fri, 23 Apr 2021 03:35:37 -0400 Received: from mga03.intel.com ([134.134.136.65]:55203 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbhDWHfh (ORCPT ); Fri, 23 Apr 2021 03:35:37 -0400 IronPort-SDR: XMlerdNn/h3V3+8RkC+biKHsAfeDsAF9WxKglxhlGmIIwX0SSoJoSze/fvhirpsjiNMIm+yGXg p6WHj+GUeH+w== X-IronPort-AV: E=McAfee;i="6200,9189,9962"; a="196087944" X-IronPort-AV: E=Sophos;i="5.82,245,1613462400"; d="scan'208";a="196087944" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 00:34:59 -0700 IronPort-SDR: 4P03s7UO9HcxPFGvheeryshu172MwTYVsbHjpEbzdxW9OlqjpJw665d/fAMPwg7FMYe6/KBk3P 3YQh60RcbrbA== X-IronPort-AV: E=Sophos;i="5.82,245,1613462400"; d="scan'208";a="428284454" Received: from oyanai-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.48.237]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 00:34:55 -0700 From: Jani Nikula To: Kai-Heng Feng , joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com, ville.syrjala@linux.intel.com Cc: Kai-Heng Feng , David Airlie , Daniel Vetter , Takashi Iwai , intel-gfx@lists.freedesktop.org, "open list\:DRM DRIVERS" , open list Subject: Re: [PATCH v2] drm/i915: Invoke BXT _DSM to enable MUX on HP Workstation laptops In-Reply-To: <20210423044700.247359-1-kai.heng.feng@canonical.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20210423044700.247359-1-kai.heng.feng@canonical.com> Date: Fri, 23 Apr 2021 10:34:52 +0300 Message-ID: <87fszh78tf.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Apr 2021, Kai-Heng Feng wrote: > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX > to discrete GFX after S3. This is not desirable, because userspace will > treat connected display as a new one, losing display settings. > > The expected behavior is to let discrete GFX drives all external > displays. > > The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX. > The method is inside the BXT _DSM, so add the _DSM and call it > accordingly. > > I also tested some MUX-less and iGPU only laptops with the BXT _DSM, no > regression was found. I don't know whether this change is the right thing to do. I don't know if it isn't either. Need to look into it. However, I have some general comments, inline. > > v2: > - Forward declare struct pci_dev. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113 > References: https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.manna@intel.com/ > Signed-off-by: Kai-Heng Feng > --- > drivers/gpu/drm/i915/display/intel_acpi.c | 17 +++++++++++++++++ > drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++ > drivers/gpu/drm/i915/i915_drv.c | 5 +++++ > 3 files changed, 25 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c > index 833d0c1be4f1..c7b57c22dce3 100644 > --- a/drivers/gpu/drm/i915/display/intel_acpi.c > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c > @@ -14,11 +14,16 @@ > > #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */ > #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */ > +#define INTEL_DSM_FN_PLATFORM_BXT_MUX_INFO 0 /* No args */ > > static const guid_t intel_dsm_guid = > GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f, > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c); > > +static const guid_t intel_bxt_dsm_guid = > + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260, > + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14); > + > static char *intel_dsm_port_name(u8 id) > { > switch (id) { > @@ -176,6 +181,18 @@ void intel_unregister_dsm_handler(void) > { > } > > +void intel_bxt_dsm_detect(struct pci_dev *pdev) Please leave out bxt from the naming and make the argument struct drm_i915_private *i915. Mmh, then it conflicts with existing intel_dsm_detect(), maybe we need a more descriptive name altogether? > +{ > + acpi_handle dhandle; > + > + dhandle = ACPI_HANDLE(&pdev->dev); > + if (!dhandle) > + return; > + > + acpi_evaluate_dsm(dhandle, &intel_bxt_dsm_guid, INTEL_DSM_REVISION_ID, > + INTEL_DSM_FN_PLATFORM_BXT_MUX_INFO, NULL); > +} > + > /* > * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All Devices > * Attached to the Display Adapter). > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h b/drivers/gpu/drm/i915/display/intel_acpi.h > index e8b068661d22..d2d560d63bb3 100644 > --- a/drivers/gpu/drm/i915/display/intel_acpi.h > +++ b/drivers/gpu/drm/i915/display/intel_acpi.h > @@ -6,15 +6,18 @@ > #ifndef __INTEL_ACPI_H__ > #define __INTEL_ACPI_H__ > > +struct pci_dev; > struct drm_i915_private; > > #ifdef CONFIG_ACPI > void intel_register_dsm_handler(void); > void intel_unregister_dsm_handler(void); > +void intel_bxt_dsm_detect(struct pci_dev *pdev); > void intel_acpi_device_id_update(struct drm_i915_private *i915); > #else > static inline void intel_register_dsm_handler(void) { return; } > static inline void intel_unregister_dsm_handler(void) { return; } > +static inline void intel_bxt_dsm_detect(struct pci_dev *pdev) { return; } > static inline > void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; } > #endif /* CONFIG_ACPI */ > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 785dcf20c77b..57b12068aab4 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -853,6 +853,8 @@ int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (ret) > goto out_cleanup_gem; > > + intel_bxt_dsm_detect(pdev); > + The call sites in i915_driver_probe() and i915_drm_resume() seem rather arbitrary. Long term, I'd like most or all of the display stuff like this placed in appropriate intel_modeset_*() functions in display/intel_display.c. I'm not keen on having new and very specific calls in the higher levels. At probe, feels like the routing should happen earlier, before output setup? In intel_modeset_init_nogem()? > i915_driver_register(i915); > > enable_rpm_wakeref_asserts(&i915->runtime_pm); > @@ -1215,6 +1217,7 @@ int i915_suspend_switcheroo(struct drm_i915_private *i915, pm_message_t state) > static int i915_drm_resume(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = to_i915(dev); > + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev); > int ret; > > disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); > @@ -1271,6 +1274,8 @@ static int i915_drm_resume(struct drm_device *dev) > > intel_gvt_resume(dev_priv); > > + intel_bxt_dsm_detect(pdev); > + In intel_display_resume() perhaps? (Yay for confusing naming wrt display and modeset, it's a work-in-progress.) BR, Jani. > enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); > > return 0; -- Jani Nikula, Intel Open Source Graphics Center