[Intel-gfx] [PATCH v2] drm/i915: Invoke BXT _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On Fri, Apr 23, 2021 at 8:41 PM Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>
> On Fri, Apr 23, 2021 at 12:46:54PM +0800, 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.
> >
> > 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 <kai.heng.feng at canonical.com>
> > ---
> >  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);
> > +
>
> I think this dsm is just supposed to be more or less an
> alternative to the opregion SCI stuff. Why there are two
> ways to do the same things I have no idea. The opregion
> spec does not tell us such mundane details.

Right now I think it's HP specific and from what I can see it doesn't
touch opregion.

>
> It's also not documented to do anything except list the
> supported functions:
> "Get BIOS Data Functions Supported “Function #0"
>  This function can be called to discover which “_DSM” Functions are
>  supported. It may only return success if the return value accurately
>  lists supported Functions."
>
> But what you're apparently saying is that calling this changes
> the behaviour of the system somehow? That is troubling.

It flips a bit in BIOS-reserved Intel GPIO, and EC/hardware will
change the MUX based on the GPIO bit.

We can add a DMI check to match "HP" to minimize the potential
regression factor.

Kai-Heng

>
> --
> Ville Syrjälä
> Intel