Re: [Intel-gfx] [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On Thu, May 20, 2021 at 2:58 PM 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 another _DSM, so add the _DSM and call it
> accordingly.
>
> I also tested some MUX-less and iGPU only laptops with that _DSM, no
> regression was found.
>
> v4:
>  - Rebase.
>  - Change the DSM name to avoid confusion.
>  - Move the function call to intel_opregion.
>
> v3:
>  - Remove BXT from names.
>  - Change the parameter type.
>  - Fold the function into intel_modeset_init_hw().
>
> 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.ma...@intel.com/
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
>  drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
>  drivers/gpu/drm/i915/display/intel_acpi.h |  3 +++
>  drivers/gpu/drm/i915/display/intel_opregion.c |  3 +++
>  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..7cfe91fc05f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
> GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
>   0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> +#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> +
> +static const guid_t intel_dsm_guid2 =
> +   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 +182,19 @@ void intel_unregister_dsm_handler(void)
>  {
>  }
>
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> +{
> +   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> +   acpi_handle dhandle;
> +
> +   dhandle = ACPI_HANDLE(&pdev->dev);
> +   if (!dhandle)
> +   return;
> +
> +   acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 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..9f197401c313 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -11,11 +11,14 @@ struct drm_i915_private;
>  #ifdef CONFIG_ACPI
>  void intel_register_dsm_handler(void);
>  void intel_unregister_dsm_handler(void);
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
>  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_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915) 
> { 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/display/intel_opregion.c 
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index dfd724e506b5..3855fba70980 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private 
> *i915)
> opregion->asle->ardy = ASLE_ARDY_READY;
> }
>
> +   /* Some platforms abuse the _DSM to enable MUX */
> +   intel_dsm_get_bios_data_funcs_supported(i915);
> +
> intel_opregion_notify_adapter(i915, PCI_D0);
>  }
>
> --
> 2.31.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On Fri, Jun 4, 2021 at 11:57 PM Kai-Heng Feng
 wrote:
>
> On Thu, May 20, 2021 at 2:58 PM 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 another _DSM, so add the _DSM and call it
> > accordingly.
> >
> > I also tested some MUX-less and iGPU only laptops with that _DSM, no
> > regression was found.
> >
> > v4:
> >  - Rebase.
> >  - Change the DSM name to avoid confusion.
> >  - Move the function call to intel_opregion.
> >
> > v3:
> >  - Remove BXT from names.
> >  - Change the parameter type.
> >  - Fold the function into intel_modeset_init_hw().
> >
> > 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.ma...@intel.com/
> > Signed-off-by: Kai-Heng Feng 
>
> A gentle ping...

Another gentle ping...

>
> > ---
> >  drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
> >  drivers/gpu/drm/i915/display/intel_acpi.h |  3 +++
> >  drivers/gpu/drm/i915/display/intel_opregion.c |  3 +++
> >  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..7cfe91fc05f2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
> > GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
> >   0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> >
> > +#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > +
> > +static const guid_t intel_dsm_guid2 =
> > +   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 +182,19 @@ void intel_unregister_dsm_handler(void)
> >  {
> >  }
> >
> > +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > +{
> > +   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > +   acpi_handle dhandle;
> > +
> > +   dhandle = ACPI_HANDLE(&pdev->dev);
> > +   if (!dhandle)
> > +   return;
> > +
> > +   acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> > + INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 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..9f197401c313 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> > @@ -11,11 +11,14 @@ struct drm_i915_private;
> >  #ifdef CONFIG_ACPI
> >  void intel_register_dsm_handler(void);
> >  void intel_unregister_dsm_handler(void);
> > +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private 
> > *i915);
> >  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_dsm_get_bios_data_funcs_supported(struct drm_i915_private 
> > *i915) { 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/display/intel_opregion.c 
> > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > index dfd724e506b5..3855fba70980 100644
> > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > @@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private 
> > *i915)
> > opregion->asle->ardy = ASLE_ARDY_READY;
> > }
> >
> > +   /* Some platforms abuse the _DSM to enable MUX */
> > +   intel_dsm_get_bios_data_funcs_supported(i915);
> > +
> > intel_opregion_notify_adapter(i915, PCI_D0);
> >  }
> >
> > --
> > 2.31.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: Use max params for older panels

[Kai-Heng Feng]

Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.

Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either, that means the affected panels only
work with max params.

The panels are all DP 1.1 ones, so apply max params to them to resolve
the issue.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714
Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and 
fall back to the old max strategy on failure")
Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for 
everything")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 75d4ebc669411..e64bab4b016e1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1330,14 +1330,16 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
 
-   if (intel_dp->use_max_params) {
+   if (intel_dp->use_max_params ||
+   intel_dp->dpcd[DP_DPCD_REV] <= DP_DPCD_REV_11) {
/*
 * Use the maximum clock and number of lanes the eDP panel
 * advertizes being capable of in case the initial fast
-* optimal params failed us. The panels are generally
-* designed to support only a single clock and lane
-* configuration, and typically on older panels these
-* values correspond to the native resolution of the panel.
+* optimal params failed us or the panel is DP 1.1 or earlier.
+* The panels are generally designed to support only a single
+* clock and lane configuration, and typically on older panels
+* these values correspond to the native resolution of the
+* panel.
 */
limits.min_lane_count = limits.max_lane_count;
limits.min_clock = limits.max_clock;
-- 
2.31.1

Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy

[Kai-Heng Feng]

On Tue, Aug 10, 2021 at 10:49 PM Alex Deucher  wrote:
>
> On Tue, Aug 10, 2021 at 4:36 AM Imre Deak  wrote:
> >
> > Hi Kai-Heng, Alex,
> >
> > could you add your ack if the fix looks ok and you're ok if I push it to
> > the i915 tree?
> >
>
> Acked-by: Alex Deucher 

Acked-by: Kai-Heng Feng 

>
> > Thanks,
> > Imre
> >
> > On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > > Atm the EFI FB platform driver gets a runtime PM reference for the
> > > associated GFX PCI device during probing the EFI FB platform device and
> > > releases it only when the platform device gets unbound.
> > >
> > > When fbcon switches to the FB provided by the PCI device's driver (for
> > > instance i915/drmfb), the EFI FB will get only unregistered without the
> > > EFI FB platform device getting unbound, keeping the runtime PM reference
> > > acquired during the platform device probing. This reference will prevent
> > > the PCI driver from runtime suspending the device.
> > >
> > > Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> > > called when the FB gets unregistered.
> > >
> > > While at it assert that pm_runtime_get_sync() didn't fail.
> > >
> > > v2:
> > > - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> > >   race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> > > - Assert that pm_runtime_get_sync() didn't fail.
> > > - Clarify commit message wrt. platform/PCI device/driver and driver
> > >   removal vs. device unbinding.
> > >
> > > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at 
> > > PCI D0")
> > > Cc: Kai-Heng Feng 
> > > Cc: Daniel Vetter 
> > > Reviewed-by: Daniel Vetter  (v1)
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/video/fbdev/efifb.c | 21 ++---
> > >  1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > > index 8ea8f079cde26..edca3703b9640 100644
> > > --- a/drivers/video/fbdev/efifb.c
> > > +++ b/drivers/video/fbdev/efifb.c
> > > @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> > >  static bool request_mem_succeeded = false;
> > >  static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
> > >
> > > +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering 
> > > the efifb */
> > > +
> > >  static struct fb_var_screeninfo efifb_defined = {
> > >   .activate   = FB_ACTIVATE_NOW,
> > >   .height = -1,
> > > @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct 
> > > fb_info *info) {}
> > >
> > >  static void efifb_destroy(struct fb_info *info)
> > >  {
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(&efifb_pci_dev->dev);
> > > +
> > >   if (info->screen_base) {
> > >   if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> > >   iounmap(info->screen_base);
> > > @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
> > >
> > >  static bool pci_dev_disabled;/* FB base matches BAR of a 
> > > disabled device */
> > >
> > > -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering 
> > > the efifb */
> > >  static struct resource *bar_resource;
> > >  static u64 bar_offset;
> > >
> > > @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> > >   pr_err("efifb: cannot allocate colormap\n");
> > >   goto err_groups;
> > >   }
> > > +
> > > + if (efifb_pci_dev)
> > > + WARN_ON(pm_runtime_get_sync(&efifb_pci_dev->dev) < 0);
> > > +
> > >   err = register_framebuffer(info);
> > >   if (err < 0) {
> > >   pr_err("efifb: cannot register framebuffer\n");
> > > - goto err_fb_dealoc;
> > > + goto err_put_rpm_ref;
> > >   }
> > >   fb_info(info, "%s frame buffer device\n", info->fix.id);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_get_sync(&efifb_pci_dev->dev);
> > >   return 0;
> > >
> > > -err_fb_dealoc:
> > > +err_put_rpm_ref:
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(&efifb_pci_dev->dev);
> > > +
> > >   fb_dealloc_cmap(&info->cmap);
> > >  err_groups:
> > >   sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
> > > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > >   unregister_framebuffer(info);
> > >   sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> > >   framebuffer_release(info);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_put(&efifb_pci_dev->dev);
> > >
> > >   return 0;
> > >  }
> > > --
> > > 2.27.0
> > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

[Kai-Heng Feng]

On Tue, May 11, 2021 at 2:06 AM Albert Astals Cid  wrote:
>
> Yes, I also have the same.
>
> I git bisected that and found this to be the cause, i started a new email 
> thread because i couldn't find this email ^_^

Should be fixed by
https://cgit.freedesktop.org/drm-tip/commit/?id=acca7762eb71bc05a8f28d29320d193150051f79

Kai-Heng

>
> Cheers,
>   Albert
>
> El dilluns, 10 de maig de 2021, a les 10:07:33 (CEST), Emanuele Panigati va 
> escriure:
> > Hi,
> >   on my Dell XPS 15 9570 laptop I might have a regression with Arch Linux
> > (kernel 5.12.2-arch1-1: during boot the laptop monitor goes black while
> > external monitors still works...
> >
> >
> > Panich
> >
> >
> > Il giorno lun 11 gen 2021 alle ore 19:28 Ville Syrjälä <
> > ville.syrj...@linux.intel.com> ha scritto:
> >
> > > On Thu, Jan 07, 2021 at 08:20:25PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > >
> > > > Some new eDP panels don't like to operate at the max parameters, and
> > > > instead we need to go for an optimal confiugration. That unfortunately
> > > > doesn't work with older eDP panels which are generally only guaranteed
> > > > to work at the max parameters.
> > > >
> > > > To solve these two conflicting requirements let's start with the optimal
> > > > setup, and if that fails we start again with the max parameters. The
> > > > downside is probably an extra modeset when we switch strategies but
> > > > I don't see a good way to avoid that.
> > > >
> > > > For a bit of history we first tried to go for the fast+narrow in
> > > > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > > > fast and narrow"). but that had to be reverted due to regression
> > > > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > > > to max link rate and lane count on eDP"). So now we try to get
> > > > the best of both worlds by using both strategies.
> > >
> > > Pushed. Fingers crossed for no regressions...
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > >
> >
>
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On Mon, Apr 26, 2021 at 11:24 PM 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 another _DSM, so add the _DSM and call it
> accordingly.
>
> I also tested some MUX-less and iGPU only laptops with that _DSM, no
> regression was found.
>
> v3:
>  - Remove BXT from names.
>  - Change the parameter type.
>  - Fold the function into intel_modeset_init_hw().
>
> 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.ma...@intel.com/
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
>  drivers/gpu/drm/i915/display/intel_acpi.c| 18 ++
>  drivers/gpu/drm/i915/display/intel_acpi.h|  3 +++
>  drivers/gpu/drm/i915/display/intel_display.c |  2 ++
>  3 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..d008d3976261 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -13,12 +13,17 @@
>  #include "intel_display_types.h"
>
>  #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
> +#define INTEL_DSM_FN_PLATFORM_MUX_ENABLE 0 /* No args */
>  #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* 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_dsm_guid2 =
> +   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,19 @@ void intel_unregister_dsm_handler(void)
>  {
>  }
>
> +void intel_dsm_enable_mux(struct drm_i915_private *i915)
> +{
> +   struct pci_dev *pdev = i915->drm.pdev;
> +   acpi_handle dhandle;
> +
> +   dhandle = ACPI_HANDLE(&pdev->dev);
> +   if (!dhandle)
> +   return;
> +
> +   acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_PLATFORM_MUX_ENABLE, 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..def013cf6308 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -11,11 +11,14 @@ struct drm_i915_private;
>  #ifdef CONFIG_ACPI
>  void intel_register_dsm_handler(void);
>  void intel_unregister_dsm_handler(void);
> +void intel_dsm_enable_mux(struct drm_i915_private *i915);
>  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_dsm_enable_mux(struct drm_i915_private *i915) { 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/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a10e26380ef3..d79dae370b20 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11472,6 +11472,8 @@ void intel_modeset_init_hw(struct drm_i915_private 
> *i915)
>  {
> struct intel_cdclk_state *cdclk_state;
>
> +   intel_dsm_enable_mux(i915);
> +
> if (!HAS_DISPLAY(i915))
> return;
>
> --
> 2.30.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On Wed, May 12, 2021 at 2:19 AM Ville Syrjälä
 wrote:
>
> On Mon, Apr 26, 2021 at 11:24:10PM +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 another _DSM, so add the _DSM and call it
> > accordingly.
> >
> > I also tested some MUX-less and iGPU only laptops with that _DSM, no
> > regression was found.
> >
> > v3:
> >  - Remove BXT from names.
> >  - Change the parameter type.
> >  - Fold the function into intel_modeset_init_hw().
> >
> > 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.ma...@intel.com/
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/drm/i915/display/intel_acpi.c| 18 ++
> >  drivers/gpu/drm/i915/display/intel_acpi.h|  3 +++
> >  drivers/gpu/drm/i915/display/intel_display.c |  2 ++
> >  3 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index 833d0c1be4f1..d008d3976261 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -13,12 +13,17 @@
> >  #include "intel_display_types.h"
> >
> >  #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
> > +#define INTEL_DSM_FN_PLATFORM_MUX_ENABLE 0 /* No args */
>
> This block of defines is for the other DSM. We don't want to
> mix these up. We also want to name it according to the spec,
> so something like GET_BIOS_DATA_FUNCS_SUPPORTED. Similarly
> for the intel_dsm_enable_mux() wrapper function. + it needs
> a comment to document that some BIOSes abuse it to do MUX
> initialization and whatnot.

Will do.


>
> We should perhaps rename all the old DSM stuff to
> something a bit less generic as well...

I can rename them as well. But what's the naming scheme you prefer?

>
> >  #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* 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_dsm_guid2 =
> > + 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,19 @@ void intel_unregister_dsm_handler(void)
> >  {
> >  }
> >
> > +void intel_dsm_enable_mux(struct drm_i915_private *i915)
> > +{
> > + struct pci_dev *pdev = i915->drm.pdev;
> > + acpi_handle dhandle;
> > +
> > + dhandle = ACPI_HANDLE(&pdev->dev);
> > + if (!dhandle)
> > + return;
> > +
> > + acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> > +   INTEL_DSM_FN_PLATFORM_MUX_ENABLE, 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..def013cf6308 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> > @@ -11,11 +11,14 @@ struct drm_i915_private;
> >  #ifdef CONFIG_ACPI
> >  void intel_register_dsm_handler(void);
> >  void intel_unregister_dsm_handler(void);
> > +void intel_dsm_enable_mux(struct drm_i915_private *i915);
> >  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_dsm_enable_mux(struct drm_i915_private *i915) { return; }
> > +static inline
> >  void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> >  #endif /* CONFIG_ACPI */
> >

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

[Kai-Heng Feng]

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 another _DSM, so add the _DSM and call it
accordingly.

I also tested some MUX-less and iGPU only laptops with that _DSM, no
regression was found.

v4:
 - Rebase.
 - Change the DSM name to avoid confusion.
 - Move the function call to intel_opregion.

v3:
 - Remove BXT from names.
 - Change the parameter type.
 - Fold the function into intel_modeset_init_hw().

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.ma...@intel.com/
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
 drivers/gpu/drm/i915/display/intel_acpi.h |  3 +++
 drivers/gpu/drm/i915/display/intel_opregion.c |  3 +++
 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..7cfe91fc05f2 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
  0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
 
+#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
+
+static const guid_t intel_dsm_guid2 =
+   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 +182,19 @@ void intel_unregister_dsm_handler(void)
 {
 }
 
+void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   acpi_handle dhandle;
+
+   dhandle = ACPI_HANDLE(&pdev->dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
+ INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 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..9f197401c313 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -11,11 +11,14 @@ struct drm_i915_private;
 #ifdef CONFIG_ACPI
 void intel_register_dsm_handler(void);
 void intel_unregister_dsm_handler(void);
+void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
 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_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915) { 
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/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index dfd724e506b5..3855fba70980 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private *i915)
opregion->asle->ardy = ASLE_ARDY_READY;
}
 
+   /* Some platforms abuse the _DSM to enable MUX */
+   intel_dsm_get_bios_data_funcs_supported(i915);
+
intel_opregion_notify_adapter(i915, PCI_D0);
 }
 
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/dp: Use max params for panels < eDP 1.4

[Kai-Heng Feng]

Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.

Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either, that means the affected eDP 1.2 panels
only work with max params.

So use max params for panels < eDP 1.4 as Windows does to solve the
issue.

v2:
 - Check eDP 1.4 instead of DPCD 1.1 to apply max params

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714
Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and 
fall back to the old max strategy on failure")
Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for 
everything")
Suggested-by: Ville Syrjälä 
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 75d4ebc669411..f87fad78f1a9f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1330,14 +1330,16 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
 
-   if (intel_dp->use_max_params) {
+   if (intel_dp->use_max_params ||
+   intel_dp->edp_dpcd[0] < DP_EDP_14) {
/*
 * Use the maximum clock and number of lanes the eDP panel
 * advertizes being capable of in case the initial fast
-* optimal params failed us. The panels are generally
-* designed to support only a single clock and lane
-* configuration, and typically on older panels these
-* values correspond to the native resolution of the panel.
+* optimal params failed us or the EDP rev is earlier than 1.4.
+* The panels are generally designed to support only a single
+* clock and lane configuration, and typically on older panels
+* these values correspond to the native resolution of the
+* panel.
 */
limits.min_lane_count = limits.max_lane_count;
limits.min_clock = limits.max_clock;
-- 
2.32.0

[Intel-gfx] [PATCH v3] drm/i915/dp: Use max params for panels < eDP 1.4

[Kai-Heng Feng]

Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.

Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either, that means the affected eDP 1.2 panels
only work with max params.

So use max params for panels < eDP 1.4 as Windows does to solve the
issue.

v3:
 - Do the eDP rev check in intel_edp_init_dpcd()

v2:
 - Check eDP 1.4 instead of DPCD 1.1 to apply max params

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714
Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and 
fall back to the old max strategy on failure")
Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for 
everything")
Suggested-by: Ville Syrjälä 
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 75d4ebc669411..e0dbd35ae7bc0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2445,11 +2445,14 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 */
if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
 intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
-sizeof(intel_dp->edp_dpcd))
+sizeof(intel_dp->edp_dpcd)) {
drm_dbg_kms(&dev_priv->drm, "eDP DPCD: %*ph\n",
(int)sizeof(intel_dp->edp_dpcd),
intel_dp->edp_dpcd);
 
+   intel_dp->use_max_params = intel_dp->edp_dpcd[0] < DP_EDP_14;
+   }
+
/*
 * This has to be called after intel_dp->edp_dpcd is filled, PSR checks
 * for SET_POWER_CAPABLE bit in intel_dp->edp_dpcd[1]
-- 
2.32.0

[Intel-gfx] [PATCH] drm/i915/audio: Use BIOS provided value for RKL HDA link

[Kai-Heng Feng]

Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
driver") makes HDMI audio on Lenovo P350 disappear.

So in addition to TGL, extend the logic to RKL to use BIOS provided
value to fix the regression.

Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 532237588511..4e0f96bf6158 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1308,8 +1308,9 @@ static void i915_audio_component_init(struct 
drm_i915_private *dev_priv)
else
aud_freq = aud_freq_init;
 
-   /* use BIOS provided value for TGL unless it is a known bad 
value */
-   if (IS_TIGERLAKE(dev_priv) && aud_freq_init != 
AUD_FREQ_TGL_BROKEN)
+   /* use BIOS provided value for TGL and RKL unless it is a known 
bad value */
+   if ((IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv)) &&
+   aud_freq_init != AUD_FREQ_TGL_BROKEN)
aud_freq = aud_freq_init;
 
drm_dbg_kms(&dev_priv->drm, "use AUD_FREQ_CNTRL of 0x%x (init 
value 0x%x)\n",
-- 
2.32.0

[Intel-gfx] [PATCH] drm/i915/dp: Use slow and wide link training for DPCP rev < 1.4

[Kai-Heng Feng]

Screen flickers on Innolux panel when clock rate 54 is in use.

According to the panel vendor, though clock rate 54 is advertised,
but the max clock rate it really supports is 27.

So use slow and wide training for panels with DPCP rev < 1.4 to resolve
the issue. User also confirmed the new strategy doesn't introduce
regression on XPS 9380.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384
References: https://gitlab.freedesktop.org/drm/intel/-/issues/272
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 775d89b6c3fc..ca73e2179659 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1461,12 +1461,12 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
intel_dp_can_bigjoiner(intel_dp))
pipe_config->bigjoiner = true;
 
-   if (intel_dp_is_edp(intel_dp))
+   if (intel_dp_is_edp(intel_dp) && intel_dp->dpcd[DP_DPCD_REV] > 0x13)
/*
-* Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
-* section A.1: "It is recommended that the minimum number of
-* lanes be used, using the minimum link rate allowed for that
-* lane configuration."
+* Optimize for fast and narrow on DP 1.4. eDP 1.3 section 3.3
+* and eDP 1.4 section A.1: "It is recommended that the minimum
+* number of lanes be used, using the minimum link rate allowed
+* for that lane configuration."
 *
 * Note that we fall back to the max clock and lane count for 
eDP
 * panels that fail with the fast optimal settings (see
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: Use slow and wide link training for everything

[Kai-Heng Feng]

Screen flickers on Innolux eDP 1.3 panel when clock rate 54 is in use.

According to the panel vendor, though clock rate 54 is advertised,
but the max clock rate it really supports is 27.

Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4
panel, so use slow and wide training for all panels to resolve the
issue.

User also confirmed that the new strategy doesn't introduce any
regression on XPS 9380.

v2:
 - Use slow and wide for everything.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384
References: https://gitlab.freedesktop.org/drm/intel/-/issues/272
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 59 +++--
 1 file changed, 5 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 52ea09fc5e70..4ad12dde5938 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1095,44 +1095,6 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
return -EINVAL;
 }
 
-/* Optimize link config in order: max bpp, min lanes, min clock */
-static int
-intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
- const struct link_config_limits *limits)
-{
-   const struct drm_display_mode *adjusted_mode = 
&pipe_config->hw.adjusted_mode;
-   int bpp, clock, lane_count;
-   int mode_rate, link_clock, link_avail;
-
-   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-   int output_bpp = 
intel_dp_output_bpp(pipe_config->output_format, bpp);
-
-   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-  output_bpp);
-
-   for (lane_count = limits->min_lane_count;
-lane_count <= limits->max_lane_count;
-lane_count <<= 1) {
-   for (clock = limits->min_clock; clock <= 
limits->max_clock; clock++) {
-   link_clock = intel_dp->common_rates[clock];
-   link_avail = intel_dp_max_data_rate(link_clock,
-   lane_count);
-
-   if (mode_rate <= link_avail) {
-   pipe_config->lane_count = lane_count;
-   pipe_config->pipe_bpp = bpp;
-   pipe_config->port_clock = link_clock;
-
-   return 0;
-   }
-   }
-   }
-   }
-
-   return -EINVAL;
-}
-
 static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
 {
int i, num_bpc;
@@ -1382,22 +1344,11 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
intel_dp_can_bigjoiner(intel_dp))
pipe_config->bigjoiner = true;
 
-   if (intel_dp_is_edp(intel_dp))
-   /*
-* Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
-* section A.1: "It is recommended that the minimum number of
-* lanes be used, using the minimum link rate allowed for that
-* lane configuration."
-*
-* Note that we fall back to the max clock and lane count for 
eDP
-* panels that fail with the fast optimal settings (see
-* intel_dp->use_max_params), in which case the fast vs. wide
-* choice doesn't matter.
-*/
-   ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, 
&limits);
-   else
-   /* Optimize for slow and wide. */
-   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, 
&limits);
+   /*
+* Optimize for slow and wide for everything, because there are some
+* eDP 1.3 and 1.4 panels don't work well with fast and narrow.
+*/
+   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
 
/* enable compression if the mode doesn't fit available BW */
drm_dbg_kms(&i915->drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Kai-Heng Feng]

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.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
References: 
https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@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 |  2 ++
 drivers/gpu/drm/i915/i915_drv.c   |  5 +
 3 files changed, 24 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)
+{
+   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..0dd456335bd0 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -11,10 +11,12 @@ 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);
+
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);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
 
return 0;
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Kai-Heng Feng]

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.ma...@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)
+{
+   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);
+
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);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
 
return 0;
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [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 3:35 PM Jani Nikula  wrote:
>
> 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.ma...@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?

If there's no oppose, I'll change it to intel_hp_dsm_detect() in v2.
So far, I've only seen that DSM in HP platform.

>
> > +{
> > + 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
> > +

Re: [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ä
 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.ma...@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);
> > +
>
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Kai-Heng Feng]

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 another _DSM, so add the _DSM and call it
accordingly.

I also tested some MUX-less and iGPU only laptops with that _DSM, no
regression was found.

v3:
 - Remove BXT from names.
 - Change the parameter type.
 - Fold the function into intel_modeset_init_hw().

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.ma...@intel.com/
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_acpi.c| 18 ++
 drivers/gpu/drm/i915/display/intel_acpi.h|  3 +++
 drivers/gpu/drm/i915/display/intel_display.c |  2 ++
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 833d0c1be4f1..d008d3976261 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -13,12 +13,17 @@
 #include "intel_display_types.h"
 
 #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
+#define INTEL_DSM_FN_PLATFORM_MUX_ENABLE 0 /* No args */
 #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* 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_dsm_guid2 =
+   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,19 @@ void intel_unregister_dsm_handler(void)
 {
 }
 
+void intel_dsm_enable_mux(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = i915->drm.pdev;
+   acpi_handle dhandle;
+
+   dhandle = ACPI_HANDLE(&pdev->dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
+ INTEL_DSM_FN_PLATFORM_MUX_ENABLE, 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..def013cf6308 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -11,11 +11,14 @@ struct drm_i915_private;
 #ifdef CONFIG_ACPI
 void intel_register_dsm_handler(void);
 void intel_unregister_dsm_handler(void);
+void intel_dsm_enable_mux(struct drm_i915_private *i915);
 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_dsm_enable_mux(struct drm_i915_private *i915) { 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/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index a10e26380ef3..d79dae370b20 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11472,6 +11472,8 @@ void intel_modeset_init_hw(struct drm_i915_private 
*i915)
 {
struct intel_cdclk_state *cdclk_state;
 
+   intel_dsm_enable_mux(i915);
+
if (!HAS_DISPLAY(i915))
return;
 
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
dGFX so external monitors are routed to dGFX, and more monitors can be
supported as result.

To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
on intel_dsm_guid2. This method is described in Intel document 632107.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f077..3bd5930e2769b 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
  0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
 
 #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
+#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
 
 static const guid_t intel_dsm_guid2 =
GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
@@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
drm_i915_private *i915)
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
acpi_handle dhandle;
union acpi_object *obj;
+   int supported = 0;
 
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
@@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
drm_i915_private *i915)
 
obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, 
INTEL_DSM_REVISION_ID,
INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 
NULL);
-   if (obj)
+   if (obj) {
+   if (obj->type == ACPI_TYPE_INTEGER)
+   supported = obj->integer.value;
+
ACPI_FREE(obj);
+   }
+
+   /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
+   if (supported & BIT(20)) {
+   obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
+   INTEL_DSM_REVISION_ID,
+   INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
+   NULL);
+   if (obj)
+   ACPI_FREE(obj);
+   }
 }
 
 /*
-- 
2.36.1

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula  wrote:
>
> On Tue, 16 Aug 2022, Kai-Heng Feng  wrote:
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > on intel_dsm_guid2. This method is described in Intel document 632107.
>
> Is this the policy decision that we want to unconditionally make,
> though?

I believes so, so more external monitors can be supported at the same time.

Kai-Heng

>
> BR,
> Jani.
>
> >
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index e78430001f077..3bd5930e2769b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> >
> >  #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> >
> >  static const guid_t intel_dsm_guid2 =
> >   GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
> > drm_i915_private *i915)
> >   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> >   acpi_handle dhandle;
> >   union acpi_object *obj;
> > + int supported = 0;
> >
> >   dhandle = ACPI_HANDLE(&pdev->dev);
> >   if (!dhandle)
> > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
> > drm_i915_private *i915)
> >
> >   obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, 
> > INTEL_DSM_REVISION_ID,
> >   INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 
> > NULL);
> > - if (obj)
> > + if (obj) {
> > + if (obj->type == ACPI_TYPE_INTEGER)
> > + supported = obj->integer.value;
> > +
> >   ACPI_FREE(obj);
> > + }
> > +
> > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > + if (supported & BIT(20)) {
> > + obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
> > + INTEL_DSM_REVISION_ID,
> > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > + NULL);
> > + if (obj)
> > + ACPI_FREE(obj);
> > + }
> >  }
> >
> >  /*
>
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 2:24 AM Lyude Paul  wrote:
>
> On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula  
> > wrote:
> > >
> > > On Tue, 16 Aug 2022, Kai-Heng Feng  wrote:
> > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > supported as result.
> > > >
> > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > > on intel_dsm_guid2. This method is described in Intel document 632107.
>
> Is this documentation released anywhere? We've been wondering about these
> interfaces for quite a long time, and it would be good to know if there's docs
> for this we haven't really been seeing.
>
> > >
> > > Is this the policy decision that we want to unconditionally make,
> > > though?
> >
> > I believes so, so more external monitors can be supported at the same time.
> >
> > Kai-Heng
>
> Is this for systems with dual Intel GPUs? I ask because if this affects
> Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able to
> support these systems, but at a limited capacity. This would imply that we are
> making external displays work for users of the nvidia proprietary driver, at
> the expense making external display support for mainline kernel users
> substantially worse for people who are using the mainline kernel. Which isn't
> a choice we should be making, because nvidia's OOT driver is not a mainline
> kernel driver.

Yes it's for Intel/NVIDIA hybrid systems.

The problem is that hardware vendor design the systems to use NVIDIA
for external displays, so using external displays on Intel are never
tested by the vendors.
I don't think that's any good either.

Kai-Heng

>
> If this is just for Intel/Intel systems though that's probably fine, and it
> might also be fine for AMD systems.
>
> >
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kai-Heng Feng 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > index e78430001f077..3bd5930e2769b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > > >
> > > >  #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > > >
> > > >  static const guid_t intel_dsm_guid2 =
> > > >   GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
> > > > drm_i915_private *i915)
> > > >   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > >   acpi_handle dhandle;
> > > >   union acpi_object *obj;
> > > > + int supported = 0;
> > > >
> > > >   dhandle = ACPI_HANDLE(&pdev->dev);
> > > >   if (!dhandle)
> > > > @@ -194,8 +196,22 @@ void 
> > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > >
> > > >   obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, 
> > > > INTEL_DSM_REVISION_ID,
> > > >   
> > > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> > > > - if (obj)
> > > > + if (obj) {
> > > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > > + supported = obj->integer.value;
> > > > +
> > > >   ACPI_FREE(obj);
> > > > + }
> > > > +
> > > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > > + if (supported & BIT(20)) {
> > > > + obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
> > > > + INTEL_DSM_REVISION_ID,
> > > > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > > > + NULL);
> > > > + if (obj)
> > > > + ACPI_FREE(obj);
> > > > + }
> > > >  }
> > > >
> > > >  /*
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 2:36 AM Lyude Paul  wrote:
>
> On Tue, 2022-08-16 at 14:24 -0400, Lyude Paul wrote:
> > On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote:
> > > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula  
> > > wrote:
> > > >
> > > > On Tue, 16 Aug 2022, Kai-Heng Feng  wrote:
> > > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch 
> > > > > to
> > > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > > supported as result.
> > > > >
> > > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 
> > > > > 20
> > > > > on intel_dsm_guid2. This method is described in Intel document 632107.
> >
> > Is this documentation released anywhere? We've been wondering about these
> > interfaces for quite a long time, and it would be good to know if there's 
> > docs
> > for this we haven't really been seeing.
> >
> > > >
> > > > Is this the policy decision that we want to unconditionally make,
> > > > though?
> > >
> > > I believes so, so more external monitors can be supported at the same 
> > > time.
> > >
> > > Kai-Heng
> >
> > Is this for systems with dual Intel GPUs? I ask because if this affects
> > Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able 
> > to
> > support these systems, but at a limited capacity. This would imply that we 
> > are
> > making external displays work for users of the nvidia proprietary driver, at
> > the expense making external display support for mainline kernel users
> > substantially worse for people who are using the mainline kernel. Which 
> > isn't
> > a choice we should be making, because nvidia's OOT driver is not a mainline
> > kernel driver.
>
> Doing some quick research, unless the models mentioned in the commit message
> are unreleased some of them are definitely Intel/Nvidia hybrids. So I'm going
> to say:
>
> NAK-by: Lyude Paul 
>
> If you'd like to resubmit this for systems with amdgpus and Intel only, that's
> perfectly fine with me if the Intel folks are ok with it. But please hold off
> on this for Nvidia systems, at least until we've got GSP reworks functional in
> nouveau. If nvidia's interested in making this work for their driver, they're
> welcome to do the work there. For reference: the main limitations you would
> hit as a result of this patch would be lagginess on the external displays as a
> result of us not being able to reclock the GPU, which means PCIe bandwidth
> will be pretty limited.

The change should be agnostic to any discrete GPU, so I don't think
it's easy to make i915 be aware of the presence of AMD or NVIDIA.
As I replied in previous mail, the external displays may not even work
on Intel GPU, so I really hope we can get this merged.

Will the 'GSP rework' finish anytime soon?

Kai-Heng

>
> >
> > If this is just for Intel/Intel systems though that's probably fine, and it
> > might also be fine for AMD systems.
> >
> > >
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kai-Heng Feng 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > index e78430001f077..3bd5930e2769b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > > > >
> > > > >  #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > > > >
> > > > >  static const guid_t intel_dsm_guid2 =
> > > > >   GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > > > @@ -187,6 +188,7 @@ void 
> > > > > intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> > > > >   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 2:50 AM Karol Herbst  wrote:
>
> On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng
>  wrote:
> >
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > on intel_dsm_guid2. This method is described in Intel document 632107.
> >
>
> Can we please not do things like this just because?

I there's a very good reason to support more external monitors,
especially when eDP is already 4K so iGPU don't have enough buffer for
more displays.

>
> It forces the discrete GPU to be on leading to higher thermal pressure
> and power consumption of the system. Lower battery runtime or higher
> fan noise is the result. Not everybody wants to use an AC simply just
> because they attach an external display.

The system is designed in this way.

And many (if not all) gaming laptops and mobile workstations use
discrete GPU for external monitors.
We just recently found out we have to use a switch to make it work.

>
> If the problem is "we run out of displays" then can we have something
> more dynamic, where we are doing this only and only if we run out of
> resources to drive as that many displays.

This is a boot-time switch, so it's not possible to switch it dynamically.

>
> Most users will be fine with ports being driven by the iGPU. Why hurt
> most users, because of some weird special case with mostly only
> drawbacks?

This is a use case that hardware vendor never bother to test.
And this is not a special case - the system is designed to use dGPU
for external monitors.

Kai-Heng

>
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index e78430001f077..3bd5930e2769b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> >   0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> >
> >  #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> >
> >  static const guid_t intel_dsm_guid2 =
> > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
> > drm_i915_private *i915)
> > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > acpi_handle dhandle;
> > union acpi_object *obj;
> > +   int supported = 0;
> >
> > dhandle = ACPI_HANDLE(&pdev->dev);
> > if (!dhandle)
> > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct 
> > drm_i915_private *i915)
> >
> > obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, 
> > INTEL_DSM_REVISION_ID,
> > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, 
> > NULL);
> > -   if (obj)
> > +   if (obj) {
> > +   if (obj->type == ACPI_TYPE_INTEGER)
> > +   supported = obj->integer.value;
> > +
> > ACPI_FREE(obj);
> > +   }
> > +
> > +   /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > +   if (supported & BIT(20)) {
> > +   obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
> > +   INTEL_DSM_REVISION_ID,
> > +   INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > +   NULL);
> > +   if (obj)
> > +   ACPI_FREE(obj);
> > +   }
> >  }
> >
> >  /*
> > --
> > 2.36.1
> >
>

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 9:49 AM Karol Herbst  wrote:
>
> On Wed, Aug 17, 2022 at 3:18 AM Kai-Heng Feng
>  wrote:
> >
> > On Wed, Aug 17, 2022 at 2:50 AM Karol Herbst  wrote:
> > >
> > > On Tue, Aug 16, 2022 at 4:53 AM Kai-Heng Feng
> > >  wrote:
> > > >
> > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > supported as result.
> > > >
> > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > > on intel_dsm_guid2. This method is described in Intel document 632107.
> > > >
> > >
> > > Can we please not do things like this just because?
> >
> > I there's a very good reason to support more external monitors,
> > especially when eDP is already 4K so iGPU don't have enough buffer for
> > more displays.
> >
>
> well.. they do have it. What's the limit? 3 or 4 4K displays with gen
> 11th+? I find conflicting information, but 3 4K displays are no
> problem. It might be if you get to higher refresh rates or something.
>
> I know that 2 work quite reliably and I know I can put even more on
> the Intel GPU.

More monitors can be supported via a thunderbolt dock.

>
> > >
> > > It forces the discrete GPU to be on leading to higher thermal pressure
> > > and power consumption of the system. Lower battery runtime or higher
> > > fan noise is the result. Not everybody wants to use an AC simply just
> > > because they attach an external display.
> >
> > The system is designed in this way.
> >
>
> ?!? This makes no sense. If the discrete GPU is turned on, it means
> the system has to cool away more heat, because it consumes more power.
> It then causes louder fans. No idea how a "system design" can just go
> around simple physics...

The spec from HP [1] says:
Multi Display Support
Without HP Thunderbolt™ Dock G2
UMA Graphics: Unit supports up to 4 independent displays. Any
combination of displays outputs may be used except one of
Thunderbolt™ 4 and HDMI.
Hybrid Graphics: Unit supports up 5 simultaneous displays (4 from dGPU
+ 1 from iGPU). Any combination of displays outputs may
be used except when using one USBC and HDMI are exclusive

With HP Thunderbolt™ Dock G2
UMA Graphics: Unit supports up to 4 simultaneous displays. Any
combination of displays outputs may be used except one of
Thunderbolt™ 4 and HDMI.
Hybrid Graphics (NVIDIA): Unit supports up to 5 simultaneous displays
(4 from dGPU + 1 from iGPU). Any combination of displays
outputs may be used except when using one USBC and HDMI are exclusive
Hybrid Graphics (AMD): Unit supports up to 5 simultaneous displays (5
from dGPU + 1 from iGPU). Any combination of displays
outputs may be used except when using one USBC and HDMI are exclusive

So it's "designed" to use dGPU on the hybrid configs.

Let's hope the copper tubes have can dissipate the heat fast enough.

>
> Even the CPU consumes more power, because on some systems it prevents
> deeper package sleeping modes due to the active PCIe bridge
> controller.
>
> But if you have certain systems where you want to enable this behavior
> despite the drawbacks, maybe maintain a list of systems where to apply
> this method?

The behavior will be enabled only when _DSM function 20 is present.
So it's already a selected few.

>
> > And many (if not all) gaming laptops and mobile workstations use
> > discrete GPU for external monitors.
> > We just recently found out we have to use a switch to make it work.
> >
>
> yeah some do, and if people buy those, they already deal with loud
> fans and just accept this fact.
>
> Others might want silent fans... and why do you have to switch? Out of
> the box Intel GPUs support 3 4K displays. I want to see the general
> use case for 4 4K displays.

It's not for us to decide.
When a user buys a laptop according to the spec, the expectation is to
have those supported.

>
> So what systems are actually affected and do users have the option to
> disable it, if they prefer a more silent system?

Maybe adding a new i915 option to override the default behavior? But
it depends on i915 maintainers' opinion.

>
> > >
> > > If the problem is "we run out of displays" then can we have something
> > > more dynamic, where we are doing this only and only if we run out of
> > > resources to drive as that many displays.
> >
> > This is a boot-time switch, so it's not possible to switch it dynamically.
> >
>
> This makes it even worse.
>
> > >

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä
 wrote:

[snipped]

> I had a quick trawl through some Windows stuff for this and
> it does seem to do a few extra checks:
> - platform must be TGL-H (nothing else has the DPin stuff I guess)
> - OpRegion header must indicate dGPU presence

Is the dGPU presence denoted by the return bitmask of
INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED?

IIUC the mask 20 won't be set when dGPU is not present.

>
> Otherwise it does call this DSM uncoditionally on boot/S4 resume
> so seems like that is the only really validated configuration.
> Although it does seem to explicitly turn off displays prior to
> the DSM so that does perhaps indicate that those ports might have
> also been enabled via the iGPU by the BIOS. Not sure if disabling
> the ports would work correctly after the DSM or not. If not then
> the DSM call would need to happen after state readout/sanitization
> so that we can shut things down gracefully.
>
> Additionally after the DSM call it scans the FIA TC live state
> bits to check for DPin usage. Looks like its trying to make sure
> the driver stops poking at the relevant power wells once in DPin
> mode. i915 doesn't check that stuff atm so we might end up
> mangling something while the dGPU is driving the port.

Thanks for investigating this. I am not really familiar with other
stuffs you mentioned, but I am happy to test any follow-up patch.

Kai-Heng

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

Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported

[Kai-Heng Feng]

On Sat, Aug 20, 2022 at 1:01 AM Karol Herbst  wrote:
>
> On Thu, Aug 18, 2022 at 2:09 PM Lukas Wunner  wrote:
> >
> > On Tue, Aug 16, 2022 at 11:06:18AM +0300, Jani Nikula wrote:
> > > On Tue, 16 Aug 2022, Kai-Heng Feng  wrote:
> > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > > supported as result.
> > > >
> > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > > on intel_dsm_guid2. This method is described in Intel document 632107.
> > >
> > > Is this the policy decision that we want to unconditionally make,
> > > though?
> >
> > In general, we handle switching of outputs between GPUs in vga_switcheroo.c
> > upon a request from user space via sysfs (well, debugfs currently).
> > It's up to users to decide which policy suits their needs best.
> >
> > That said, we never grew support to allow different switching policies for
> > the built-in panel and external outputs.  Laptops supporting this are
> > rare.  Older MacBook Pros introduced between 2008 and 2010 are among them:
> > They have separate muxes for the panel and external DP port.  Our policy
> > is documented in a code comment in drivers/platform/x86/apple-gmux.c:
> >
> >  * The external DP port is only fully switchable on the first two unibody
> >  * MacBook Pro generations, MBP5 2008/09 and MBP6 2010. This is done by an
> >  * `NXP CBTL06141`_ which is controlled by gmux.
> >  [...]
> >  * Our switching policy for the external port is that on those generations
> >  * which are able to switch it fully, the port is switched together with the
> >  * panel when IGD / DIS commands are issued to vga_switcheroo. It is thus
> >  * possible to drive e.g. a beamer on battery power with the integrated GPU.
> >  * The user may manually switch to the discrete GPU if more performance is
> >  * needed.
> >  *
> >  * On all newer generations, the external port can only be driven by the
> >  * discrete GPU. If a display is plugged in while the panel is switched to
> >  * the integrated GPU, *both* GPUs will be in use for maximum performance.
> >  * To decrease power consumption, the user may manually switch to the
> >  * discrete GPU, thereby suspending the integrated GPU.
> >
> > In other words, on these older MacBook Pros, we switch the panel and
> > external DP port in unison, thus always allowing one of the two GPUs
> > to runtime suspend and save power.
> >
> > Thanks,
> >
> > Lukas
> >
>
> sure, but this is changing now. I do have a laptop with a muxable
> internal display. But this is considered to be a dynamic on demand
> switching thing not a boot time switch.
>
> Anyway, I am still not convinced that doing that unconditionally is
> what we want, especially as userspace has to support dynamic switching
> regardless.
>

According to the doc, there's no MUX in TGL-H DP-IN. The dGPU outputs
are routed through TGL-H TCSS directly.
That's probably the reason why it can't be dynamic.

Kai-Heng

Re: [Intel-gfx] [PATCH v2] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Kai-Heng Feng]

> On Dec 24, 2019, at 01:36, Jani Nikula  wrote:
> 
> On Tue, 24 Dec 2019, Kai-Heng Feng  wrote:
>> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
>> becomes useless and never responds to cable hotplugging:
>> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on 
>> port D
>> 
>> Seems like the lspcon chip on the system in question only gets powered
>> after the cable is plugged.
>> 
>> So let's call lspcon_init() dynamically to properly initialize the
>> lspcon chip and make HDMI port work.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v2: 
>>  - Move lspcon_init() inside of intel_dp_hpd_pulse().
>> 
>> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index fe31bbfd6c62..eb395b45527e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -6573,6 +6573,7 @@ enum irqreturn
>> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>> {
>>  struct intel_dp *intel_dp = &intel_dig_port->dp;
>> +struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> 
>>  if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
>>  /*
>> @@ -6592,11 +6593,14 @@ intel_dp_hpd_pulse(struct intel_digital_port 
>> *intel_dig_port, bool long_hpd)
>>intel_dig_port->base.base.name,
>>long_hpd ? "long" : "short");
>> 
>> -if (long_hpd) {
>> +if (long_hpd && intel_dig_port->base.type != INTEL_OUTPUT_DDI) {
> 
> With this change, long hpd handling for DDI on platforms that do not
> have LSPCON, or has an active LSPCON, falls through to the short hpd
> handling. That's not what you're after, is it?

You are right, no :(

I'll send a V3.

Kai-Heng

> 
> 
> BR,
> Jani.
> 
> 
>>  intel_dp->reset_link_params = true;
>>  return IRQ_NONE;
>>  }
>> 
>> +if (long_hpd && HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
>> +lspcon_init(intel_dig_port);
>> +
>>  if (intel_dp->is_mst) {
>>  if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
>>  /*
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.

So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng 
---
v3:
 - Make sure it's handled under long HPD case.

v2: 
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe31bbfd6c62..a72c9c041c60 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6573,6 +6573,7 @@ enum irqreturn
 intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 {
struct intel_dp *intel_dp = &intel_dig_port->dp;
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  long_hpd ? "long" : "short");
 
if (long_hpd) {
-   intel_dp->reset_link_params = true;
+   if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
+   HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
+   lspcon_init(intel_dig_port);
+   else
+   intel_dp->reset_link_params = true;
+
return IRQ_NONE;
}
 
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Kai-Heng Feng]

Hi Jani,

> On Dec 24, 2019, at 16:42, Kai-Heng Feng  wrote:
> 
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port 
> D
> 
> Seems like the lspcon chip on the system in question only gets powered
> after the cable is plugged.
> 
> So let's call lspcon_init() dynamically to properly initialize the
> lspcon chip and make HDMI port work.

Do you have any further suggestion for this patch?

Kai-Heng

> 
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
> Signed-off-by: Kai-Heng Feng 
> ---
> v3:
> - Make sure it's handled under long HPD case.
> 
> v2: 
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> 
> drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fe31bbfd6c62..a72c9c041c60 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6573,6 +6573,7 @@ enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> {
>   struct intel_dp *intel_dp = &intel_dig_port->dp;
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> 
>   if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
>   /*
> @@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
> long_hpd ? "long" : "short");
> 
>   if (long_hpd) {
> - intel_dp->reset_link_params = true;
> + if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
> + HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
> + lspcon_init(intel_dig_port);
> + else
> + intel_dp->reset_link_params = true;
> +
>   return IRQ_NONE;
>   }
> 
> -- 
> 2.17.1
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.

So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index fc29046d48ea..e2862e36d0bf 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -28,6 +28,7 @@
 #include "i915_drv.h"
 #include "intel_display_types.h"
 #include "intel_hotplug.h"
+#include "intel_lspcon.h"
 
 /**
  * DOC: Hotplug
@@ -336,6 +337,8 @@ static void i915_digport_work_func(struct work_struct *work)
continue;
 
dig_port = enc_to_dig_port(&encoder->base);
+   if (HAS_LSPCON(dev_priv) && !dig_port->lspcon.active)
+   lspcon_init(dig_port);
 
ret = dig_port->hpd_pulse(dig_port, long_hpd);
if (ret == IRQ_NONE) {
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.

So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.

Signed-off-by: Kai-Heng Feng 
---
v2: 
  - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe31bbfd6c62..eb395b45527e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6573,6 +6573,7 @@ enum irqreturn
 intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 {
struct intel_dp *intel_dp = &intel_dig_port->dp;
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -6592,11 +6593,14 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  intel_dig_port->base.base.name,
  long_hpd ? "long" : "short");
 
-   if (long_hpd) {
+   if (long_hpd && intel_dig_port->base.type != INTEL_OUTPUT_DDI) {
intel_dp->reset_link_params = true;
return IRQ_NONE;
}
 
+   if (long_hpd && HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
+   lspcon_init(intel_dig_port);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

> On Feb 15, 2020, at 01:56, Kai-Heng Feng  wrote:
> 
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port 
> D
> 
> Seems like the lspcon chip on the system in question only gets powered
> after the cable is plugged.
> 
> So let's call lspcon_init() dynamically to properly initialize the
> lspcon chip and make HDMI port work.
> 
> Signed-off-by: Kai-Heng Feng 

A gentle ping.

> ---
> v4:
> - Trust VBT in intel_infoframe_init().
> - Init lspcon in intel_dp_detect().
> 
> v3:
> - Make sure it's handled under long HPD case.
> 
> v2: 
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> 
> drivers/gpu/drm/i915/display/intel_ddi.c  | 17 +
> drivers/gpu/drm/i915/display/intel_dp.c   | 13 -
> drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
> 3 files changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 33f1dc3d7c1a..ca717434b406 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4741,7 +4741,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   &dev_priv->vbt.ddi_port_info[port];
>   struct intel_digital_port *intel_dig_port;
>   struct intel_encoder *encoder;
> - bool init_hdmi, init_dp, init_lspcon = false;
> + bool init_hdmi, init_dp;
>   enum phy phy = intel_port_to_phy(dev_priv, port);
> 
>   init_hdmi = port_info->supports_dvi || port_info->supports_hdmi;
> @@ -4754,7 +4754,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>* is initialized before lspcon.
>*/
>   init_dp = true;
> - init_lspcon = true;
>   init_hdmi = false;
>   DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
>   }
> @@ -4833,20 +4832,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   goto err;
>   }
> 
> - if (init_lspcon) {
> - if (lspcon_init(intel_dig_port))
> - /* TODO: handle hdmi info frame part */
> - DRM_DEBUG_KMS("LSPCON init success on port %c\n",
> - port_name(port));
> - else
> - /*
> -  * LSPCON init faied, but DP init was success, so
> -  * lets try to drive as DP++ port.
> -  */
> - DRM_ERROR("LSPCON init failed on port %c\n",
> - port_name(port));
> - }
> -
>   intel_infoframe_init(intel_dig_port);
> 
>   return;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7424e2a04a3..43117aa86292 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5663,8 +5663,19 @@ intel_dp_detect(struct drm_connector *connector,
>   /* Can't disconnect eDP */
>   if (intel_dp_is_edp(intel_dp))
>   status = edp_detect(intel_dp);
> - else if (intel_digital_port_connected(encoder))
> + else if (intel_digital_port_connected(encoder)) {
> + if (intel_bios_is_lspcon_present(dev_priv, dig_port->base.port) 
> &&
> + !dig_port->lspcon.active) {
> + if (lspcon_init(dig_port))
> + DRM_DEBUG_KMS("LSPCON init success on port 
> %c\n",
> +   port_name(dig_port->base.port));
> + else
> + DRM_DEBUG_KMS("LSPCON init failed on port %c\n",
> +   port_name(dig_port->base.port));
> + }
> +
>   status = intel_dp_detect_dpcd(intel_dp);
> + }
>   else
>   status = connector_status_disconnected;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 93ac0f296852..27a5aa8cefc9 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3100,7 +3100,7 @@ void intel_infoframe_init(struct intel_digital_port 
> *intel_dig_port)
>   

[Intel-gfx] [PATCH v4] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.

So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.

Signed-off-by: Kai-Heng Feng 
---
v4:
 - Trust VBT in intel_infoframe_init().
 - Init lspcon in intel_dp_detect().

v3:
 - Make sure it's handled under long HPD case.

v2: 
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_ddi.c  | 17 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 13 -
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 3 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 33f1dc3d7c1a..ca717434b406 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4741,7 +4741,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
&dev_priv->vbt.ddi_port_info[port];
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
-   bool init_hdmi, init_dp, init_lspcon = false;
+   bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
 
init_hdmi = port_info->supports_dvi || port_info->supports_hdmi;
@@ -4754,7 +4754,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 * is initialized before lspcon.
 */
init_dp = true;
-   init_lspcon = true;
init_hdmi = false;
DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
}
@@ -4833,20 +4832,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
goto err;
}
 
-   if (init_lspcon) {
-   if (lspcon_init(intel_dig_port))
-   /* TODO: handle hdmi info frame part */
-   DRM_DEBUG_KMS("LSPCON init success on port %c\n",
-   port_name(port));
-   else
-   /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
-   DRM_ERROR("LSPCON init failed on port %c\n",
-   port_name(port));
-   }
-
intel_infoframe_init(intel_dig_port);
 
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..43117aa86292 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5663,8 +5663,19 @@ intel_dp_detect(struct drm_connector *connector,
/* Can't disconnect eDP */
if (intel_dp_is_edp(intel_dp))
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(encoder))
+   else if (intel_digital_port_connected(encoder)) {
+   if (intel_bios_is_lspcon_present(dev_priv, dig_port->base.port) 
&&
+   !dig_port->lspcon.active) {
+   if (lspcon_init(dig_port))
+   DRM_DEBUG_KMS("LSPCON init success on port 
%c\n",
+ port_name(dig_port->base.port));
+   else
+   DRM_DEBUG_KMS("LSPCON init failed on port %c\n",
+ port_name(dig_port->base.port));
+   }
+
status = intel_dp_detect_dpcd(intel_dp);
+   }
else
status = connector_status_disconnected;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 93ac0f296852..27a5aa8cefc9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3100,7 +3100,7 @@ void intel_infoframe_init(struct intel_digital_port 
*intel_dig_port)
intel_dig_port->set_infoframes = g4x_set_infoframes;
intel_dig_port->infoframes_enabled = g4x_infoframes_enabled;
} else if (HAS_DDI(dev_priv)) {
-   if (intel_dig_port->lspcon.active) {
+   if (intel_bios_is_lspcon_present(dev_priv, 
intel_dig_port->base.port)) {
intel_dig_port->write_infoframe = 
lspcon_write_infoframe;
intel_dig_port->read_infoframe = lspcon_read_infoframe;
inte

[Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk

[Kai-Heng Feng]

HP DreamColor panel needs to be controlled via AUX interface. However,
it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
intel_dp_aux_display_control_capable() test.

Skip the test if the panel has force DPCD quirk.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe..acf2e1c65290 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *intel_connector)
struct intel_panel *panel = &intel_connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool force_dpcd;
+
+   force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
+ DP_QUIRK_FORCE_DPCD_BACKLIGHT);
 
if (i915->params.enable_dpcd_backlight == 0 ||
-   !intel_dp_aux_display_control_capable(intel_connector))
+   (!force_dpcd && 
!intel_dp_aux_display_control_capable(intel_connector)))
return -ENODEV;
 
/*
@@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *intel_connector)
 */
if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
-   i915->params.enable_dpcd_backlight != 1 &&
-   !drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
- DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
+   i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
drm_info(&i915->drm,
 "Panel advertises DPCD backlight support, but "
 "VBT disagrees. If your backlight controls "
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk

[Kai-Heng Feng]

Hi Lyude,

> On Oct 8, 2020, at 05:53, Lyude Paul  wrote:
> 
> Hi! I thought this patch rang a bell, we actually already had some discussion
> about this since there's a couple of other systems this was causing issues 
> for.
> Unfortunately it never seems like that patch got sent out. Satadru?
> 
> (if I don't hear back from them soon, I'll just send out a patch for this
> myself)
> 
> JFYI - the proper fix here is to just drop the
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long 
> as
> the backlight supports AUX_SET_CAP, that should be enough for us to control 
> it.

Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?

Kai-Heng

> 
> 
> On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
>> HP DreamColor panel needs to be controlled via AUX interface. However,
>> it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
>> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
>> intel_dp_aux_display_control_capable() test.
>> 
>> Skip the test if the panel has force DPCD quirk.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index acbd7eb66cbe..acf2e1c65290 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>>  struct intel_panel *panel = &intel_connector->panel;
>>  struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
>>  struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> +bool force_dpcd;
>> +
>> +force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
>> +  DP_QUIRK_FORCE_DPCD_BACKLIGHT);
>> 
>>  if (i915->params.enable_dpcd_backlight == 0 ||
>> -!intel_dp_aux_display_control_capable(intel_connector))
>> +(!force_dpcd &&
>> !intel_dp_aux_display_control_capable(intel_connector)))
>>  return -ENODEV;
>> 
>>  /*
>> @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>>   */
>>  if (i915->vbt.backlight.type !=
>>  INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
>> -i915->params.enable_dpcd_backlight != 1 &&
>> -!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
>> -  DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
>> +i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
>>  drm_info(&i915->drm,
>>   "Panel advertises DPCD backlight support, but "
>>   "VBT disagrees. If your backlight controls "
> -- 
> Sincerely,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

> On Sep 3, 2020, at 14:26, Kai-Heng Feng  wrote:
> 
> 
> 
>> On Aug 26, 2020, at 21:05, Ville Syrjälä  
>> wrote:
>> 
>> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
>>> Hi,
>>> 
>>>> On Aug 25, 2020, at 02:46, Runyan, Arthur J  
>>>> wrote:
>>>> 
>>>> I remember some strangeness about the blnclegdisbl.  I'll see if I can dig 
>>>> up some more.
>>> 
>>> 
>>> The register read can be found at [1] and [2].
>>> 
>>> [1] 
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/119
>>> [2] 
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/120
>> 
>> Looks like it's using the 400mV/0dB setting. Can we get the same dumps
>> with the driver loaded just to confirm whether we're using different
>> settings? 
>> 
>> Also a dump of /sys/kernel/debug/dri/0/i915_vbt would be good
>> to have.
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/124
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/125
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/126

A gentle ping...

> 
> Kai-Heng
> 
>> 
>>> 
>>> Kai-Heng
>>> 
>>>> 
>>>> -Original Message-----
>>>> From: Ville Syrjälä  
>>>> Sent: Monday, August 24, 2020 11:05 AM
>>>> To: Kai-Heng Feng 
>>>> Cc: Runyan, Arthur J ; Vivi, Rodrigo 
>>>> ; intel-gfx 
>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks 
>>>> HDMI on ASUS GL552VW
>>>> 
>>>> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>>>>> 
>>>>> 
>>>>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J  
>>>>>> wrote:
>>>>>> 
>>>>>> You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 
>>>>>> registers at boot before i915 programs them and compare with what driver 
>>>>>> programs.  
>>>>>> Rodrigo can probably show you how. 
>>>>> 
>>>>> Right, I'll wait for a patch then :)
>>>> 
>>>> To grab the BIOS reg values we just have to make sure the driver doesn't 
>>>> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to 
>>>> the kernel cmdline (+ whatever other magic ubuntu might require). Confirm 
>>>> with something like "lsmod | grep i915" to make sure the driver didn't 
>>>> sneak in despite our best efforts.
>>>> 
>>>> Then we can dump the registers with intel_reg from igt-gpu-tools:
>>>> intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80 
>>>> intel_reg read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
>>>> 
>>>> The only somewhat suspicious thing I noticed is that we treat 
>>>> DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A, bit 24 
>>>> -> DDI B, etc.) whereas the spec seems to be saying that we should just 
>>>> zero out all the bits of tx_blnclegdisbl when any DDI needs iboost. Art, 
>>>> is our interpretation of the bits correct or just a fairy tale?
>>>> 
>>>>> 
>>>>> Kai-Heng
>>>>> 
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Kai-Heng Feng 
>>>>>> Sent: Thursday, August 13, 2020 10:14 PM
>>>>>> To: Runyan, Arthur J 
>>>>>> Cc: Vivi, Rodrigo ; Ville Syrjälä 
>>>>>> ; intel-gfx 
>>>>>> 
>>>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>>>>>> breaks HDMI on ASUS GL552VW
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>> On Aug 14, 2020, at 01:56, Runyan, Arthur J  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> The workaround is freeing up stuck vswing values to let new vswing 
>>>>>>> programming kick in.  Maybe the new vswing values are wrong.
>>>>>>> Try checking the vswing that driver programs against what BIOS/GOP 
>>>>>>> programs.
>>>>>> 
>>>>>> Do you mean to print out value of I915_READ()?
>>>>>> val = I915

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

> On Oct 13, 2020, at 19:50, Saarinen, Jani  wrote:
> 
> Hi, 
>> -Original Message-
>> From: Intel-gfx  On Behalf Of Ville
>> Syrjälä
>> Sent: tiistai 13. lokakuuta 2020 14.16
>> To: Kai-Heng Feng 
>> Cc: intel-gfx ; Runyan, Arthur J
>> 
>> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143"
>> breaks HDMI on ASUS GL552VW
>> 
>> On Tue, Oct 13, 2020 at 01:20:35PM +0800, Kai-Heng Feng wrote:
>>> 
>>> 
>>>> On Sep 3, 2020, at 14:26, Kai-Heng Feng 
>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Aug 26, 2020, at 21:05, Ville Syrjälä 
>> wrote:
>>>>> 
>>>>> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
>>>>>> Hi,
>>>>>> 
>>>>>>> On Aug 25, 2020, at 02:46, Runyan, Arthur J
>>  wrote:
>>>>>>> 
>>>>>>> I remember some strangeness about the blnclegdisbl.  I'll see if I can 
>>>>>>> dig
>> up some more.
>>>>>> 
>>>>>> 
>>>>>> The register read can be found at [1] and [2].
>>>>>> 
>>>>>> [1]
>>>>>> 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
>>>>>> nts/119 [2]
>>>>>> 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
>>>>>> nts/120
>>>>> 
>>>>> Looks like it's using the 400mV/0dB setting. Can we get the same
>>>>> dumps with the driver loaded just to confirm whether we're using
>>>>> different settings?
>>>>> 
>>>>> Also a dump of /sys/kernel/debug/dri/0/i915_vbt would be good to
>>>>> have.
>>>> 
>>>> 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
>>>> s/124
>>>> 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
>>>> s/125
>>>> 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
>>>> s/126
>>> 
>>> A gentle ping...
>> 
>> I cooked up some hacks for you to try:
>> git://github.com/vsyrjala/linux.git skl_vswing_wa_hacks
>> 
>> An upstream bug report would probably be a good idea so that the
>> communication doesn't have to go through a middle man over email...
> Agree, please make gitlab issue on this. 

It was filed two months ago:
https://gitlab.freedesktop.org/drm/intel/-/issues/2181


> 
>> 
>>> 
>>>> 
>>>> Kai-Heng
>>>> 
>>>>> 
>>>>>> 
>>>>>> Kai-Heng
>>>>>> 
>>>>>>> 
>>>>>>> -Original Message-
>>>>>>> From: Ville Syrjälä 
>>>>>>> Sent: Monday, August 24, 2020 11:05 AM
>>>>>>> To: Kai-Heng Feng 
>>>>>>> Cc: Runyan, Arthur J ; Vivi, Rodrigo
>>>>>>> ; intel-gfx
>>>>>>> 
>>>>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143"
>>>>>>> breaks HDMI on ASUS GL552VW
>>>>>>> 
>>>>>>> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J
>>  wrote:
>>>>>>>>> 
>>>>>>>>> You'll need to read out the DDI_BUF_TRANS_* and
>> DISPIO_CR_TX_BMU_CR0 registers at boot before i915 programs them and
>> compare with what driver programs.
>>>>>>>>> Rodrigo can probably show you how.
>>>>>>>> 
>>>>>>>> Right, I'll wait for a patch then :)
>>>>>>> 
>>>>>>> To grab the BIOS reg values we just have to make sure the driver doesn't
>> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to 
>> the
>> kernel cmdline (+ whatever other magic ubuntu might require). Confirm with
>> something like "lsmod | grep i915" to make sure the driver didn't sneak in
>> despite our best efforts.
>>>>>>> 
>>>>>>> Then we can dump the registers with intel_reg from igt-gpu-tools:
>>>>>>> intel_reg read --count 20 0x64E00 0x64E60

[Intel-gfx] [PATCH v5] drm/i915: Init lspcon chip dynamically

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system only gets powered after the
cable is plugged.

Consolidate lspcon_init() into lspcon_resume() to dynamically init
lspcon chip, and make HDMI port work.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng 
---
v5:
 - Consolidate lspcon_resume() with lspcon_init().
 - Move more logic into lspcon code.

v4:
 - Trust VBT in intel_infoframe_init().
 - Init lspcon in intel_dp_detect().

v3:
 - Make sure it's handled under long HPD case.

v2: 
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
 drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
 drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
 drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
 5 files changed, 43 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5601673c3f30..798fd640da54 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4770,7 +4770,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 {
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
-   bool init_hdmi, init_dp, init_lspcon = false;
+   bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
 
init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
@@ -4784,7 +4784,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 * is initialized before lspcon.
 */
init_dp = true;
-   init_lspcon = true;
init_hdmi = false;
drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
port_name(port));
@@ -4869,22 +4868,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
goto err;
}
 
-   if (init_lspcon) {
-   if (lspcon_init(intel_dig_port))
-   /* TODO: handle hdmi info frame part */
-   drm_dbg_kms(&dev_priv->drm,
-   "LSPCON init success on port %c\n",
-   port_name(port));
-   else
-   /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
-   drm_err(&dev_priv->drm,
-   "LSPCON init failed on port %c\n",
-   port_name(port));
-   }
-
intel_infoframe_init(intel_dig_port);
 
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6952b0295096..e26aa35d6e37 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5938,15 +5938,14 @@ static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
u8 *dpcd = intel_dp->dpcd;
u8 type;
 
if (WARN_ON(intel_dp_is_edp(intel_dp)))
return connector_status_connected;
 
-   if (lspcon->active)
-   lspcon_resume(lspcon);
+   lspcon_resume(dig_port);
 
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
@@ -7198,14 +7197,13 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
-   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
intel_wakeref_t wakeref;
 
if (!HAS_DDI(dev_priv))
intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
 
-   if (lspcon->active)
-   lspcon_resume(lspcon);
+   lspcon_resume(dig_port);
 
intel_dp->reset_link_params = true;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 010f37240710..643ad2127931 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/inte

[Intel-gfx] [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system only gets powered after the
cable is plugged.

Consilidate lspcon_init() into lspcon_resume() to dynamically init
lspcon chip, and make HDMI port work.

Signed-off-by: Kai-Heng Feng 
---
v6:
 - Rebase on latest for-linux-next.

v5:
 - Consolidate lspcon_resume() with lspcon_init().
 - Move more logic into lspcon code.

v4:
 - Trust VBT in intel_infoframe_init().
 - Init lspcon in intel_dp_detect().

v3:
 - Make sure it's handled under long HPD case.

v2: 
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
 drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
 drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
 drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
 5 files changed, 43 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index aa22465bb56e..af755b1aa24b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4805,7 +4805,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 {
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
-   bool init_hdmi, init_dp, init_lspcon = false;
+   bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
 
init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
@@ -4819,7 +4819,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 * is initialized before lspcon.
 */
init_dp = true;
-   init_lspcon = true;
init_hdmi = false;
drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
port_name(port));
@@ -4904,22 +4903,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
goto err;
}
 
-   if (init_lspcon) {
-   if (lspcon_init(intel_dig_port))
-   /* TODO: handle hdmi info frame part */
-   drm_dbg_kms(&dev_priv->drm,
-   "LSPCON init success on port %c\n",
-   port_name(port));
-   else
-   /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
-   drm_err(&dev_priv->drm,
-   "LSPCON init failed on port %c\n",
-   port_name(port));
-   }
-
if (INTEL_GEN(dev_priv) >= 11) {
if (intel_phy_is_tc(dev_priv, phy))
intel_dig_port->connected = intel_tc_port_connected;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ed9e53c373a7..398a104158a8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5962,15 +5962,14 @@ static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
u8 *dpcd = intel_dp->dpcd;
u8 type;
 
if (WARN_ON(intel_dp_is_edp(intel_dp)))
return connector_status_connected;
 
-   if (lspcon->active)
-   lspcon_resume(lspcon);
+   lspcon_resume(dig_port);
 
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
@@ -7056,14 +7055,13 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
-   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
intel_wakeref_t wakeref;
 
if (!HAS_DDI(dev_priv))
intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
 
-   if (lspcon->active)
-   lspcon_resume(lspcon);
+   lspcon_resume(dig_port);
 
intel_dp->reset_link_params = true;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 010f37240710..643ad2127931 1

Re: [Intel-gfx] [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

> On Jun 10, 2020, at 15:55, Kai-Heng Feng  wrote:
> 
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port 
> D
> 
> Seems like the lspcon chip on the system only gets powered after the
> cable is plugged.
> 
> Consilidate lspcon_init() into lspcon_resume() to dynamically init
> lspcon chip, and make HDMI port work.
> 
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
> v6:
> - Rebase on latest for-linux-next.
> 
> v5:
> - Consolidate lspcon_resume() with lspcon_init().
> - Move more logic into lspcon code.
> 
> v4:
> - Trust VBT in intel_infoframe_init().
> - Init lspcon in intel_dp_detect().
> 
> v3:
> - Make sure it's handled under long HPD case.
> 
> v2: 
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> 
> drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
> drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
> 5 files changed, 43 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa22465bb56e..af755b1aa24b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4805,7 +4805,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
> {
>   struct intel_digital_port *intel_dig_port;
>   struct intel_encoder *encoder;
> - bool init_hdmi, init_dp, init_lspcon = false;
> + bool init_hdmi, init_dp;
>   enum phy phy = intel_port_to_phy(dev_priv, port);
> 
>   init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
> @@ -4819,7 +4819,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>* is initialized before lspcon.
>*/
>   init_dp = true;
> - init_lspcon = true;
>   init_hdmi = false;
>   drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
>   port_name(port));
> @@ -4904,22 +4903,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   goto err;
>   }
> 
> - if (init_lspcon) {
> - if (lspcon_init(intel_dig_port))
> - /* TODO: handle hdmi info frame part */
> - drm_dbg_kms(&dev_priv->drm,
> - "LSPCON init success on port %c\n",
> - port_name(port));
> - else
> - /*
> -  * LSPCON init faied, but DP init was success, so
> -  * lets try to drive as DP++ port.
> -  */
> - drm_err(&dev_priv->drm,
> - "LSPCON init failed on port %c\n",
> - port_name(port));
> - }
> -
>   if (INTEL_GEN(dev_priv) >= 11) {
>   if (intel_phy_is_tc(dev_priv, phy))
>   intel_dig_port->connected = intel_tc_port_connected;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ed9e53c373a7..398a104158a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5962,15 +5962,14 @@ static enum drm_connector_status
> intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   u8 *dpcd = intel_dp->dpcd;
>   u8 type;
> 
>   if (WARN_ON(intel_dp_is_edp(intel_dp)))
>   return connector_status_connected;
> 
> - if (lspcon->active)
> - lspcon_resume(lspcon);
> + lspcon_resume(dig_port);
> 
>   if (!intel_dp_get_dpcd(intel_dp))
>   return connector_status_disconnected;
> @@ -7056,14 +7055,13 @@ void intel_dp_encoder_reset(struct drm_encoder 
> *encoder)
> {
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
> - struct intel_lspcon *lspcon = dp_

Re: [Intel-gfx] [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

> On Jun 30, 2020, at 16:37, Kai-Heng Feng  wrote:
> 
> 
>> On Jun 10, 2020, at 15:55, Kai-Heng Feng  wrote:
>> 
>> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
>> becomes useless and never responds to cable hotplugging:
>> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on 
>> port D
>> 
>> Seems like the lspcon chip on the system only gets powered after the
>> cable is plugged.
>> 
>> Consilidate lspcon_init() into lspcon_resume() to dynamically init
>> lspcon chip, and make HDMI port work.
>> 
>> Signed-off-by: Kai-Heng Feng 
> 
> A gentle ping...

Another gentle ping...

> 
>> ---
>> v6:
>> - Rebase on latest for-linux-next.
>> 
>> v5:
>> - Consolidate lspcon_resume() with lspcon_init().
>> - Move more logic into lspcon code.
>> 
>> v4:
>> - Trust VBT in intel_infoframe_init().
>> - Init lspcon in intel_dp_detect().
>> 
>> v3:
>> - Make sure it's handled under long HPD case.
>> 
>> v2: 
>> - Move lspcon_init() inside of intel_dp_hpd_pulse().
>> 
>> drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
>> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
>> drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
>> drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
>> 5 files changed, 43 insertions(+), 55 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index aa22465bb56e..af755b1aa24b 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -4805,7 +4805,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
>> enum port port)
>> {
>>  struct intel_digital_port *intel_dig_port;
>>  struct intel_encoder *encoder;
>> -bool init_hdmi, init_dp, init_lspcon = false;
>> +bool init_hdmi, init_dp;
>>  enum phy phy = intel_port_to_phy(dev_priv, port);
>> 
>>  init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
>> @@ -4819,7 +4819,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
>> enum port port)
>>   * is initialized before lspcon.
>>   */
>>  init_dp = true;
>> -init_lspcon = true;
>>  init_hdmi = false;
>>  drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
>>  port_name(port));
>> @@ -4904,22 +4903,6 @@ void intel_ddi_init(struct drm_i915_private 
>> *dev_priv, enum port port)
>>  goto err;
>>  }
>> 
>> -if (init_lspcon) {
>> -if (lspcon_init(intel_dig_port))
>> -/* TODO: handle hdmi info frame part */
>> -drm_dbg_kms(&dev_priv->drm,
>> -"LSPCON init success on port %c\n",
>> -port_name(port));
>> -else
>> -/*
>> - * LSPCON init faied, but DP init was success, so
>> - * lets try to drive as DP++ port.
>> - */
>> -drm_err(&dev_priv->drm,
>> -"LSPCON init failed on port %c\n",
>> -port_name(port));
>> -}
>> -
>>  if (INTEL_GEN(dev_priv) >= 11) {
>>  if (intel_phy_is_tc(dev_priv, phy))
>>  intel_dig_port->connected = intel_tc_port_connected;
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index ed9e53c373a7..398a104158a8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -5962,15 +5962,14 @@ static enum drm_connector_status
>> intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>> {
>>  struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> -struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>> +struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>  u8 *dpcd = intel_dp->dpcd;
>>  u8 type;
>> 
>>  if (WARN_ON(intel_dp_is_edp(intel_dp)))
>>  return connector_status_connected;
>> 
>> -if (lspcon->acti

[Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

Hi,

There's a regression reported that HDMI output stops working after os upgrade:
https://bugs.launchpad.net/bugs/1871721

Here's the bisect result:
0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit
commit 0519c102f5285476d7868a387bdb6c58385e4074
Author: Ville Syrjälä 
Date:   Mon Jan 22 19:41:31 2018 +0200

drm/i915: Implement display w/a #1143

Apparently SKL/KBL/CFL need some manual help to get the
programmed HDMI vswing to stick. Implement the relevant
workaround (display w/a #1143).

Note that the relevant chicken bits live in a transcoder register
even though the bits affect a specific DDI port rather than a
specific transcoder. Hence we must pick the correct transcoder
register instance based on the port rather than based on the
cpu_transcoder.

Also note that for completeness I included support for DDI A/E
in the code even though we never have HDMI on those ports.

v2: CFL needs the w/a as well (Rodrigo and Art)

Cc: Rodrigo Vivi 
Cc: Art Runyan 
Signed-off-by: Ville Syrjälä 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrj...@linux.intel.com
Reviewed-by: Rodrigo Vivi 


dmesg from drm-tip with drm.debug=0xe can be found here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/64

Kai-Heng
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

Hi,

> On Aug 14, 2020, at 01:56, Runyan, Arthur J  wrote:
> 
> The workaround is freeing up stuck vswing values to let new vswing 
> programming kick in.  Maybe the new vswing values are wrong.
> Try checking the vswing that driver programs against what BIOS/GOP programs.

Do you mean to print out value of I915_READ()?
val = I915_READ(CHICKEN_TRANS(transcoder));

Kai-Heng

> 
> -Original Message-
> From: Vivi, Rodrigo  
> Sent: Thursday, August 13, 2020 9:50 AM
> To: Kai-Heng Feng ; Runyan, Arthur J 
> 
> Cc: Ville Syrjälä ; intel-gfx 
> 
> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI 
> on ASUS GL552VW
> 
> Art, any comment here?
> 
> I just checked and the  W/a 1143 is implemented as described, but it is 
> failing HDMI on this hybrid system.
> 
>> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng  
>> wrote:
>> 
>> Hi,
>> 
>> There's a regression reported that HDMI output stops working after os 
>> upgrade:
>> https://bugs.launchpad.net/bugs/1871721
>> 
>> Here's the bisect result:
>> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit 
>> commit 0519c102f5285476d7868a387bdb6c58385e4074
>> Author: Ville Syrjälä 
>> Date:   Mon Jan 22 19:41:31 2018 +0200
>> 
>>   drm/i915: Implement display w/a #1143
>> 
>>   Apparently SKL/KBL/CFL need some manual help to get the
>>   programmed HDMI vswing to stick. Implement the relevant
>>   workaround (display w/a #1143).
>> 
>>   Note that the relevant chicken bits live in a transcoder register
>>   even though the bits affect a specific DDI port rather than a
>>   specific transcoder. Hence we must pick the correct transcoder
>>   register instance based on the port rather than based on the
>>   cpu_transcoder.
>> 
>>   Also note that for completeness I included support for DDI A/E
>>   in the code even though we never have HDMI on those ports.
>> 
>>   v2: CFL needs the w/a as well (Rodrigo and Art)
>> 
>>   Cc: Rodrigo Vivi 
>>   Cc: Art Runyan 
>>   Signed-off-by: Ville Syrjälä 
>>   Link: 
>> https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrj...@linux.intel.com
>>   Reviewed-by: Rodrigo Vivi 
>> 
>> 
>> dmesg from drm-tip with drm.debug=0xe can be found here:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/
>> 64
>> 
>> Kai-Heng
> 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

> On Aug 17, 2020, at 00:22, Runyan, Arthur J  wrote:
> 
> You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 
> registers at boot before i915 programs them and compare with what driver 
> programs.  
> Rodrigo can probably show you how. 

Right, I'll wait for a patch then :)

Kai-Heng

> 
> -----Original Message-
> From: Kai-Heng Feng  
> Sent: Thursday, August 13, 2020 10:14 PM
> To: Runyan, Arthur J 
> Cc: Vivi, Rodrigo ; Ville Syrjälä 
> ; intel-gfx 
> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI 
> on ASUS GL552VW
> 
> Hi,
> 
>> On Aug 14, 2020, at 01:56, Runyan, Arthur J  
>> wrote:
>> 
>> The workaround is freeing up stuck vswing values to let new vswing 
>> programming kick in.  Maybe the new vswing values are wrong.
>> Try checking the vswing that driver programs against what BIOS/GOP programs.
> 
> Do you mean to print out value of I915_READ()?
> val = I915_READ(CHICKEN_TRANS(transcoder));
> 
> Kai-Heng
> 
>> 
>> -Original Message-
>> From: Vivi, Rodrigo 
>> Sent: Thursday, August 13, 2020 9:50 AM
>> To: Kai-Heng Feng ; Runyan, Arthur J 
>> 
>> Cc: Ville Syrjälä ; intel-gfx 
>> 
>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>> breaks HDMI on ASUS GL552VW
>> 
>> Art, any comment here?
>> 
>> I just checked and the  W/a 1143 is implemented as described, but it is 
>> failing HDMI on this hybrid system.
>> 
>>> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> There's a regression reported that HDMI output stops working after os 
>>> upgrade:
>>> https://bugs.launchpad.net/bugs/1871721
>>> 
>>> Here's the bisect result:
>>> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit 
>>> commit 0519c102f5285476d7868a387bdb6c58385e4074
>>> Author: Ville Syrjälä 
>>> Date:   Mon Jan 22 19:41:31 2018 +0200
>>> 
>>>  drm/i915: Implement display w/a #1143
>>> 
>>>  Apparently SKL/KBL/CFL need some manual help to get the
>>>  programmed HDMI vswing to stick. Implement the relevant
>>>  workaround (display w/a #1143).
>>> 
>>>  Note that the relevant chicken bits live in a transcoder register
>>>  even though the bits affect a specific DDI port rather than a
>>>  specific transcoder. Hence we must pick the correct transcoder
>>>  register instance based on the port rather than based on the
>>>  cpu_transcoder.
>>> 
>>>  Also note that for completeness I included support for DDI A/E
>>>  in the code even though we never have HDMI on those ports.
>>> 
>>>  v2: CFL needs the w/a as well (Rodrigo and Art)
>>> 
>>>  Cc: Rodrigo Vivi 
>>>  Cc: Art Runyan 
>>>  Signed-off-by: Ville Syrjälä 
>>>  Link: 
>>> https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrj...@linux.intel.com
>>>  Reviewed-by: Rodrigo Vivi 
>>> 
>>> 
>>> dmesg from drm-tip with drm.debug=0xe can be found here:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments
>>> /
>>> 64
>>> 
>>> Kai-Heng
>> 
>> 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

Hi,

> On Aug 25, 2020, at 02:46, Runyan, Arthur J  wrote:
> 
> I remember some strangeness about the blnclegdisbl.  I'll see if I can dig up 
> some more.


The register read can be found at [1] and [2].

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/119
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/120

Kai-Heng

> 
> -Original Message-
> From: Ville Syrjälä  
> Sent: Monday, August 24, 2020 11:05 AM
> To: Kai-Heng Feng 
> Cc: Runyan, Arthur J ; Vivi, Rodrigo 
> ; intel-gfx 
> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI 
> on ASUS GL552VW
> 
> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>> 
>> 
>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J  
>>> wrote:
>>> 
>>> You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 
>>> registers at boot before i915 programs them and compare with what driver 
>>> programs.  
>>> Rodrigo can probably show you how. 
>> 
>> Right, I'll wait for a patch then :)
> 
> To grab the BIOS reg values we just have to make sure the driver doesn't 
> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to 
> the kernel cmdline (+ whatever other magic ubuntu might require). Confirm 
> with something like "lsmod | grep i915" to make sure the driver didn't sneak 
> in despite our best efforts.
> 
> Then we can dump the registers with intel_reg from igt-gpu-tools:
> intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80 intel_reg 
> read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
> 
> The only somewhat suspicious thing I noticed is that we treat 
> DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A, bit 24 -> 
> DDI B, etc.) whereas the spec seems to be saying that we should just zero out 
> all the bits of tx_blnclegdisbl when any DDI needs iboost. Art, is our 
> interpretation of the bits correct or just a fairy tale?
> 
>> 
>> Kai-Heng
>> 
>>> 
>>> -Original Message-
>>> From: Kai-Heng Feng 
>>> Sent: Thursday, August 13, 2020 10:14 PM
>>> To: Runyan, Arthur J 
>>> Cc: Vivi, Rodrigo ; Ville Syrjälä 
>>> ; intel-gfx 
>>> 
>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>>> breaks HDMI on ASUS GL552VW
>>> 
>>> Hi,
>>> 
>>>> On Aug 14, 2020, at 01:56, Runyan, Arthur J  
>>>> wrote:
>>>> 
>>>> The workaround is freeing up stuck vswing values to let new vswing 
>>>> programming kick in.  Maybe the new vswing values are wrong.
>>>> Try checking the vswing that driver programs against what BIOS/GOP 
>>>> programs.
>>> 
>>> Do you mean to print out value of I915_READ()?
>>> val = I915_READ(CHICKEN_TRANS(transcoder));
>>> 
>>> Kai-Heng
>>> 
>>>> 
>>>> -Original Message-
>>>> From: Vivi, Rodrigo 
>>>> Sent: Thursday, August 13, 2020 9:50 AM
>>>> To: Kai-Heng Feng ; Runyan, Arthur J 
>>>> 
>>>> Cc: Ville Syrjälä ; intel-gfx 
>>>> 
>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>>>> breaks HDMI on ASUS GL552VW
>>>> 
>>>> Art, any comment here?
>>>> 
>>>> I just checked and the  W/a 1143 is implemented as described, but it is 
>>>> failing HDMI on this hybrid system.
>>>> 
>>>>> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng  
>>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> There's a regression reported that HDMI output stops working after os 
>>>>> upgrade:
>>>>> https://bugs.launchpad.net/bugs/1871721
>>>>> 
>>>>> Here's the bisect result:
>>>>> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit 
>>>>> commit 0519c102f5285476d7868a387bdb6c58385e4074
>>>>> Author: Ville Syrjälä 
>>>>> Date:   Mon Jan 22 19:41:31 2018 +0200
>>>>> 
>>>>> drm/i915: Implement display w/a #1143
>>>>> 
>>>>> Apparently SKL/KBL/CFL need some manual help to get the  
>>>>> programmed HDMI vswing to stick. Implement the relevant  
>>>>> workaround (display w/a #1143).
>>>>> 
>>>>> Note that the relevant chicken bits liv

[Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai-Heng Feng]

LSPCON only supports 8 bpc for RGB/YCbCr444.

Set the correct bpp otherwise it renders blank screen.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index b781bf469644..c7a44fcaade8 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector *connector,
crtc_state->port_clock /= 2;
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
crtc_state->lspcon_downsampling = true;
-   }
+   } else
+   crtc_state->pipe_bpp = 24;
 }
 
 static bool lspcon_probe(struct intel_lspcon *lspcon)
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai Heng Feng]

Hi Ville,

> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä  
> wrote:
> 
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>> 
>> Set the correct bpp otherwise it renders blank screen.
> 
> Hmm. Does 
> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> work?
> 
> Actually better make that dp_downstream_ports_5^^^ aka.
> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> converters") to avoid the experiments and hacks I have sitting on top.

Can you please rebase it to mainline master or drm-tip?

I am getting errors on the branch:

  DESCEND  objtool
  CALLscripts/atomic/check-atomics.sh
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  Building modules, stage 2.
  MODPOST 166 modules
  LD  arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of 
`__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined 
here
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only 
section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
make[2]: *** [arch/x86/boot/compressed/Makefile:119: 
arch/x86/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux] 
Error 2
make: *** [arch/x86/Makefile:284: bzImage] Error 2
make: *** Waiting for unfinished jobs

Kai-Heng

> 
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> index b781bf469644..c7a44fcaade8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector 
>> *connector,
>>  crtc_state->port_clock /= 2;
>>  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>>  crtc_state->lspcon_downsampling = true;
>> -}
>> +} else
>> +crtc_state->pipe_bpp = 24;
>> }
>> 
>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>> -- 
>> 2.17.1
> 
> -- 
> Ville Syrjälä
> Intel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai-Heng Feng]

> On Sep 1, 2020, at 03:48, Ville Syrjälä  wrote:
> 
> On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
>> Hi Ville,
>> 
>>> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä  
>>> wrote:
>>> 
>>> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>>>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>>>> 
>>>> Set the correct bpp otherwise it renders blank screen.
>>> 
>>> Hmm. Does 
>>> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
>>> work?
>>> 
>>> Actually better make that dp_downstream_ports_5^^^ aka.
>>> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
>>> converters") to avoid the experiments and hacks I have sitting on top.
>> 
>> Can you please rebase it to mainline master or drm-tip?
> 
> git://github.com/vsyrjala/linux.git dp_downstream_ports_6

Yes this solves the issue. Thanks a lot!

Any timeline this will get merged?

Kai-Heng 

> 
> I threw out the hacks/experimental stuff.
> 
>> 
>> I am getting errors on the branch:
>> 
>>  DESCEND  objtool
>>  CALLscripts/atomic/check-atomics.sh
>>  CALLscripts/checksyscalls.sh
>>  CHK include/generated/compile.h
>>  Building modules, stage 2.
>>  MODPOST 166 modules
>>  LD  arch/x86/boot/compressed/vmlinux
>> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of 
>> `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first 
>> defined here
>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only 
>> section `.head.text'
>> ld: warning: creating DT_TEXTREL in a PIE
>> make[2]: *** [arch/x86/boot/compressed/Makefile:119: 
>> arch/x86/boot/compressed/vmlinux] Error 1
>> make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux] 
>> Error 2
>> make: *** [arch/x86/Makefile:284: bzImage] Error 2
>> make: *** Waiting for unfinished jobs
>> 
>> Kai-Heng
>> 
>>> 
>>>> 
>>>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>>>> Signed-off-by: Kai-Heng Feng 
>>>> ---
>>>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
>>>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>>>> index b781bf469644..c7a44fcaade8 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>>>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector 
>>>> *connector,
>>>>crtc_state->port_clock /= 2;
>>>>crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>>>>crtc_state->lspcon_downsampling = true;
>>>> -  }
>>>> +  } else
>>>> +  crtc_state->pipe_bpp = 24;
>>>> }
>>>> 
>>>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>>>> -- 
>>>> 2.17.1
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel
> 
> -- 
> Ville Syrjälä
> Intel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Kai-Heng Feng]

> On Aug 26, 2020, at 21:05, Ville Syrjälä  
> wrote:
> 
> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
>> Hi,
>> 
>>> On Aug 25, 2020, at 02:46, Runyan, Arthur J  
>>> wrote:
>>> 
>>> I remember some strangeness about the blnclegdisbl.  I'll see if I can dig 
>>> up some more.
>> 
>> 
>> The register read can be found at [1] and [2].
>> 
>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/119
>> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/120
> 
> Looks like it's using the 400mV/0dB setting. Can we get the same dumps
> with the driver loaded just to confirm whether we're using different
> settings? 
> 
> Also a dump of /sys/kernel/debug/dri/0/i915_vbt would be good
> to have.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/124
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/125
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/126

Kai-Heng

> 
>> 
>> Kai-Heng
>> 
>>> 
>>> -Original Message-
>>> From: Ville Syrjälä  
>>> Sent: Monday, August 24, 2020 11:05 AM
>>> To: Kai-Heng Feng 
>>> Cc: Runyan, Arthur J ; Vivi, Rodrigo 
>>> ; intel-gfx 
>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks 
>>> HDMI on ASUS GL552VW
>>> 
>>> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>>>> 
>>>> 
>>>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J  
>>>>> wrote:
>>>>> 
>>>>> You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 
>>>>> registers at boot before i915 programs them and compare with what driver 
>>>>> programs.  
>>>>> Rodrigo can probably show you how. 
>>>> 
>>>> Right, I'll wait for a patch then :)
>>> 
>>> To grab the BIOS reg values we just have to make sure the driver doesn't 
>>> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to 
>>> the kernel cmdline (+ whatever other magic ubuntu might require). Confirm 
>>> with something like "lsmod | grep i915" to make sure the driver didn't 
>>> sneak in despite our best efforts.
>>> 
>>> Then we can dump the registers with intel_reg from igt-gpu-tools:
>>> intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80 intel_reg 
>>> read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
>>> 
>>> The only somewhat suspicious thing I noticed is that we treat 
>>> DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A, bit 24 
>>> -> DDI B, etc.) whereas the spec seems to be saying that we should just 
>>> zero out all the bits of tx_blnclegdisbl when any DDI needs iboost. Art, is 
>>> our interpretation of the bits correct or just a fairy tale?
>>> 
>>>> 
>>>> Kai-Heng
>>>> 
>>>>> 
>>>>> -Original Message-
>>>>> From: Kai-Heng Feng 
>>>>> Sent: Thursday, August 13, 2020 10:14 PM
>>>>> To: Runyan, Arthur J 
>>>>> Cc: Vivi, Rodrigo ; Ville Syrjälä 
>>>>> ; intel-gfx 
>>>>> 
>>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>>>>> breaks HDMI on ASUS GL552VW
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On Aug 14, 2020, at 01:56, Runyan, Arthur J  
>>>>>> wrote:
>>>>>> 
>>>>>> The workaround is freeing up stuck vswing values to let new vswing 
>>>>>> programming kick in.  Maybe the new vswing values are wrong.
>>>>>> Try checking the vswing that driver programs against what BIOS/GOP 
>>>>>> programs.
>>>>> 
>>>>> Do you mean to print out value of I915_READ()?
>>>>> val = I915_READ(CHICKEN_TRANS(transcoder));
>>>>> 
>>>>> Kai-Heng
>>>>> 
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Vivi, Rodrigo 
>>>>>> Sent: Thursday, August 13, 2020 9:50 AM
>>>>>> To: Kai-Heng Feng ; Runyan, Arthur J 
>>>>>> 
>>>>>> Cc: Ville Syrjälä ; intel-gfx 
>>>>>> 
>>>>>> Subject: Re: [Regression] "drm/i91

Re: [Intel-gfx] [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

Hi Jani,

> On Jul 10, 2020, at 23:48, Kai-Heng Feng  wrote:
> 
> 
> 
>> On Jun 30, 2020, at 16:37, Kai-Heng Feng  wrote:
>> 
>> 
>>> On Jun 10, 2020, at 15:55, Kai-Heng Feng  
>>> wrote:
>>> 
>>> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
>>> becomes useless and never responds to cable hotplugging:
>>> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>>> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on 
>>> port D
>>> 
>>> Seems like the lspcon chip on the system only gets powered after the
>>> cable is plugged.
>>> 
>>> Consilidate lspcon_init() into lspcon_resume() to dynamically init
>>> lspcon chip, and make HDMI port work.
>>> 
>>> Signed-off-by: Kai-Heng Feng 
>> 
>> A gentle ping...
> 
> Another gentle ping...

Can you please help reviewing this? Thanks!

Kai-Heng

> 
>> 
>>> ---
>>> v6:
>>> - Rebase on latest for-linux-next.
>>> 
>>> v5:
>>> - Consolidate lspcon_resume() with lspcon_init().
>>> - Move more logic into lspcon code.
>>> 
>>> v4:
>>> - Trust VBT in intel_infoframe_init().
>>> - Init lspcon in intel_dp_detect().
>>> 
>>> v3:
>>> - Make sure it's handled under long HPD case.
>>> 
>>> v2: 
>>> - Move lspcon_init() inside of intel_dp_hpd_pulse().
>>> 
>>> drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
>>> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
>>> drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
>>> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
>>> drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
>>> 5 files changed, 43 insertions(+), 55 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> index aa22465bb56e..af755b1aa24b 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> @@ -4805,7 +4805,7 @@ void intel_ddi_init(struct drm_i915_private 
>>> *dev_priv, enum port port)
>>> {
>>> struct intel_digital_port *intel_dig_port;
>>> struct intel_encoder *encoder;
>>> -   bool init_hdmi, init_dp, init_lspcon = false;
>>> +   bool init_hdmi, init_dp;
>>> enum phy phy = intel_port_to_phy(dev_priv, port);
>>> 
>>> init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
>>> @@ -4819,7 +4819,6 @@ void intel_ddi_init(struct drm_i915_private 
>>> *dev_priv, enum port port)
>>>  * is initialized before lspcon.
>>>  */
>>> init_dp = true;
>>> -   init_lspcon = true;
>>> init_hdmi = false;
>>> drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
>>> port_name(port));
>>> @@ -4904,22 +4903,6 @@ void intel_ddi_init(struct drm_i915_private 
>>> *dev_priv, enum port port)
>>> goto err;
>>> }
>>> 
>>> -   if (init_lspcon) {
>>> -   if (lspcon_init(intel_dig_port))
>>> -   /* TODO: handle hdmi info frame part */
>>> -   drm_dbg_kms(&dev_priv->drm,
>>> -   "LSPCON init success on port %c\n",
>>> -   port_name(port));
>>> -   else
>>> -   /*
>>> -* LSPCON init faied, but DP init was success, so
>>> -* lets try to drive as DP++ port.
>>> -*/
>>> -   drm_err(&dev_priv->drm,
>>> -   "LSPCON init failed on port %c\n",
>>> -   port_name(port));
>>> -   }
>>> -
>>> if (INTEL_GEN(dev_priv) >= 11) {
>>> if (intel_phy_is_tc(dev_priv, phy))
>>> intel_dig_port->connected = intel_tc_port_connected;
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>>> b/drivers/gpu/drm/i915/display/intel_dp.c
>>> index ed9e53c373a7..398a104158a8 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -5962,15 +5962,14 @@ static enum drm_co

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Kai Heng Feng]

Hi,

> On 24 Jan 2018, at 5:25 PM, Jani Nikula  wrote:
> A bit too fast IMO. The bug report doesn't include the vbt dump which
> you should *always* look at before making workarounds for vbt.

I didn’t have access to the machine in question until now, I can provide
VBT dump as well as i915_opregion requested by Ville.

But how do I make a VBT dump?

Kai-Heng 

> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Kai Heng Feng]

> On 24 Jan 2018, at 6:03 PM, Jani Nikula  wrote:
> 
> On Wed, 24 Jan 2018, Kai Heng Feng  wrote:
>> Hi,
>> 
>>> On 24 Jan 2018, at 5:25 PM, Jani Nikula  wrote:
>>> A bit too fast IMO. The bug report doesn't include the vbt dump which
>>> you should *always* look at before making workarounds for vbt.
>> 
>> I didn’t have access to the machine in question until now, I can provide
>> VBT dump as well as i915_opregion requested by Ville.
>> 
>> But how do I make a VBT dump?
> 
> Copy /sys/kernel/debug/dri/0/i915_vbt
> 
> I don't think the opregion will be necessary, I think Ville asks for it
> for the vbt, which on most platforms is contained in the opregion.
> 

Thanks for the tip.

Attached i915_vbt:
https://bugs.freedesktop.org/attachment.cgi?id=136935

Kai-Heng

> BR,
> Jani.
> 
> 
>> 
>> Kai-Heng 
>> 
>>> 
>>> -- 
>>> Jani Nikula, Intel Open Source Technology Center
>> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Kai Heng Feng]

> On 25 Jan 2018, at 2:56 AM, Rodrigo Vivi  wrote:
> 
> If the table result is out of bounds on the array map
> there is something really wrong with VBT pin so we don't
> return that vbt_pin, but only return 0 instead.
> 
> This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> Ignore VBT request for know invalid DDC pin.")'
> 
> Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> Map VBT DDC Pin to BSpec DDC Pin.")
> 
> Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC 
> pin.")
> Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> Cc: Radhakrishna Sripada 
> Cc: Jani Nikula 
> Cc: Kai Heng Feng 
> Signed-off-by: Rodrigo Vivi 

Tested-by: Kai-Heng Feng 

> ---
> drivers/gpu/drm/i915/intel_bios.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 95f0b310d656..844c1e8f574f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1115,16 +1115,11 @@ static const u8 cnp_ddc_pin_map[] = {
> 
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
> - if (HAS_PCH_CNP(dev_priv)) {
> - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> - return cnp_ddc_pin_map[vbt_pin];
> - if (vbt_pin > GMBUS_PIN_4_CNP) {
> - DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
> pin %d, which is not valid for this platform\n", vbt_pin);
> - return 0;
> - }
> - }
> + if (HAS_PCH_CNP(dev_priv) &&
> + vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> + return cnp_ddc_pin_map[vbt_pin];
> 
> - return vbt_pin;
> + return 0;
> }
> 
> static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
> -- 
> 2.13.6
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Kai Heng Feng]

> On 26 Jan 2018, at 6:25 AM, Rodrigo Vivi  wrote:
> 
> If the table result is out of bounds on the array map
> there is something really wrong with VBT pin so we don't
> return that vbt_pin, but only return 0 instead.
> 
> This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> Ignore VBT request for know invalid DDC pin.")'
> 
> Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> Map VBT DDC Pin to BSpec DDC Pin.")
> 
> v2: Do in a way that we don't break other platforms. (Jani)
> 
> v3: Keep debug message (Jani)
> 
> v4: Don't mess with 0 mapping was noticed by Jani and
>addressed with a simple solution suggested by Lucas
>that makes this even simpler.
> 
> Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC 
> pin.")
> Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> Cc: Radhakrishna Sripada 
> Cc: Jani Nikula 
> Cc: Kai Heng Feng 
> Cc: Lucas De Marchi 
> Suggested-by: Lucas De Marchi 
> Signed-off-by: Rodrigo Vivi 

Tested-by: Kai-Heng Feng 

> ---
> drivers/gpu/drm/i915/intel_bios.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 95f0b310d656..cf3f8f1ba6f7 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1107,6 +1107,7 @@ static void sanitize_aux_ch(struct drm_i915_private 
> *dev_priv,
> }
> 
> static const u8 cnp_ddc_pin_map[] = {
> + [0] = 0, /* N/A */
>   [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
>   [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
>   [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
> @@ -1116,9 +1117,9 @@ static const u8 cnp_ddc_pin_map[] = {
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
>   if (HAS_PCH_CNP(dev_priv)) {
> - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> + if (vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
>   return cnp_ddc_pin_map[vbt_pin];
> - if (vbt_pin > GMBUS_PIN_4_CNP) {
> + } else {
>   DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
> pin %d, which is not valid for this platform\n", vbt_pin);
>   return 0;
>   }
> -- 
> 2.13.6
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 00/22] drm/i915: Init DDI ports in VBT order

[Kai-Heng Feng]

On Wed, Feb 22, 2023 at 7:02 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> I just wanted to init DDI ports in VBT child device order
> without any up front assumptions about which conflicting
> child device defition is valid. That is pretty much what
> we need to do for the ADL laptops with the phantom eDP vs.
> native HDMI on DDI B.
>
> However that approach doesn't work for some of the weird
> SKL boards that have a phantom eDP on DDI A+AUX A and
> and a real DP->VGA converter on DDI E+AUX A. For those
> I had to introduce HPD live status check during eDP init.
>
> One of the remaining concerns I still have is what happens
> when we encounter VBTs with more AUX CH/DDC pin conflicts?
> I think what we might want to do eventually is ignore the
> conflicts as much as possible, and just init everything
> based on VBT, trusting HPD to take care of things in the
> end. That of course does have certain issues wrt. connector
> forcing, but dunno if we can avoid those at all.
>
> Also I think we need to nuke all the platform default AUX
> CH/DDC pin stuff, or at least only try to utilize those
> only once we've consumed the VBT fully.
>
> v2: Fix SKL DDI A HPD live state
> v3: Replace AUX CH/DDC pin sanitation with availability checks

The series can solve HDMI detection issue on an ADL laptop.
The caveat is that it can't be cleanly applied to current drm-tip, so
the test was conducted on older drm tag.

Tested-by: Kai-Heng Feng 

> Ville Syrjälä (22):
>   drm/i915: Populate dig_port->connected() before connector init
>   drm/i915: Fix SKL DDI A digital port .connected()
>   drm/i915: Get rid of the gm45 HPD live state nonsense
>   drm/i915: Introduce _hotplug_mask()
>   drm/i915: Introduce intel_hpd_detection()
>   drm/i915: Check HPD live state during eDP probe
>   drm/i915: Sanitize child devices later
>   drm/i915: Split map_aux_ch() into per-platform arrays
>   drm/i915: Flip VBT DDC pin maps around
>   drm/i915: Nuke intel_bios_is_port_dp_dual_mode()
>   drm/i915: Remove bogus DDI-F from hsw/bdw output init
>   drm/i915: Introduce device info port_mask
>   drm/i915: Assert that device info bitmasks have enough bits
>   drm/i915: Assert that the port being initialized is valid
>   drm/i915: Beef up SDVO/HDMI port checks
>   drm/i915: Init DDI outputs based on port_mask on skl+
>   drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child
> device
>   drm/i915: Convert HSW/BDW to use VBT driven DDI probe
>   drm/i915: Remove DDC pin sanitation
>   drm/i915: Remove AUX CH sanitation
>   drm/i915: Initialize dig_port->aux_ch to NONE to be sure
>   drm/i915: Only populate aux_ch is really needed
>
>  drivers/gpu/drm/i915/display/g4x_dp.c |  39 +-
>  drivers/gpu/drm/i915/display/g4x_hdmi.c   |  26 +-
>  drivers/gpu/drm/i915/display/icl_dsi.c|  11 +-
>  drivers/gpu/drm/i915/display/icl_dsi.h|   6 +-
>  drivers/gpu/drm/i915/display/intel_bios.c | 422 +++---
>  drivers/gpu/drm/i915/display/intel_bios.h |  12 +-
>  drivers/gpu/drm/i915/display/intel_crt.c  |   2 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 148 --
>  drivers/gpu/drm/i915/display/intel_ddi.h  |   5 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  89 +---
>  drivers/gpu/drm/i915/display/intel_display.h  |   2 +
>  .../gpu/drm/i915/display/intel_display_core.h |   2 -
>  drivers/gpu/drm/i915/display/intel_dp.c   |  28 ++
>  drivers/gpu/drm/i915/display/intel_dp_aux.c   |  51 ++-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |   2 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  78 +++-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  20 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 365 ---
>  drivers/gpu/drm/i915/i915_irq.h   |   2 +
>  drivers/gpu/drm/i915/i915_pci.c   |  31 ++
>  drivers/gpu/drm/i915/i915_reg.h   |  13 +-
>  drivers/gpu/drm/i915/intel_device_info.c  |   9 +
>  drivers/gpu/drm/i915/intel_device_info.h  |   1 +
>  23 files changed, 843 insertions(+), 521 deletions(-)
>
> --
> 2.39.2
>
>