Re: [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

[Kai-Heng Feng]

Hi Hans,

On Fri, Nov 10, 2023 at 2:19 PM Hans de Goede  wrote:
>
> Hi All,
>
> On 11/10/23 07:09, Kai-Heng Feng wrote:
> > Hi Owen,
> >
> > On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler  wrote:
> >>
> >> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
> >> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
> >> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
> >
> > Thanks for the bug report. Do you prefer to continue the discussion
> > here, on gitlab or on bugzilla?
>
> Owen, as Kai-Heng said thank you for reporting this.
>
> >> ## Reproducing
> >>
> >> 1. Boot system to framebuffer console.
> >> 2. Run `systemctl suspend`. If undocked without secondary display,
> >> suspend fails. If docked with secondary display, suspend succeeds.
> >> 3. Resume from suspend if applicable.
> >> 4. System is now in a broken state.
> >
> > So I guess we need to put those devices to ACPI D3 for suspend. Let's
> > discuss this on your preferred platform.
>
> Ok, so I was already sort of afraid we might see something like this
> happening because of:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0
>
> As I mentioned during the review of that, it might be better to
> not touch the video-card ACPI power-state at all and instead
> only do acpi_device_fix_up_power() on the child devices.

Or the child devices need to be put to D3 during suspend.

>
> Owen, attached are 2 patches which implement only
> calling acpi_device_fix_up_power() on the child devices,
> can you build a v6.6 kernel with these 2 patches added
> on top please and see if that fixes things ?
>
> Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
> is still resolved after applying these patches ?

Yes. Thanks for the patch.

If this patch also fixes Owen's issue, then
Tested-by: Kai-Heng Feng 


>
> Regards,
>
> Hans
>

Re: [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

[Kai-Heng Feng]

Hi Owen,

On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler  wrote:
>
> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124

Thanks for the bug report. Do you prefer to continue the discussion
here, on gitlab or on bugzilla?

>
> ## Reproducing
>
> 1. Boot system to framebuffer console.
> 2. Run `systemctl suspend`. If undocked without secondary display,
> suspend fails. If docked with secondary display, suspend succeeds.
> 3. Resume from suspend if applicable.
> 4. System is now in a broken state.

So I guess we need to put those devices to ACPI D3 for suspend. Let's
discuss this on your preferred platform.

Kai-Heng

>
> ## Testing
>
> - culprit commit is 89c290ea758911e660878e26270e084d862c03b0
> - v6.6 fails
> - v6.6 with culprit commit reverted does not fail
> - Compiled with
> 
>
> ## Hardware
>
> - ThinkPad W530 2438-52U
> - Dock with Nvidia-connected DVI ports
> - Secondary display connected via DVI
> - Nvidia Optimus GPU switching system
>
> ```console
> $ lspci | grep -i vga
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> processor Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro
> K2000M] (rev a1)
> ```
>
> ## Decoded logs from v6.6
>
> - System is not docked and fails to suspend:
> 
> - System is docked and fails after resume:
> 

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Kai-Heng Feng]

On Wed, Mar 29, 2023 at 9:23 PM Mario Limonciello
 wrote:
>
>
> On 3/29/23 04:59, Kai-Heng Feng wrote:
> > When the power is lost due to ACPI power resources being turned off, the
> > driver should reset the GPU so it can work anew.
> >
> > First, _PR3 support of the hierarchy needs to be found correctly. Since
> > the GPU on some discrete GFX cards is behind a PCIe switch, checking the
> > _PR3 on downstream port alone is not enough, as the _PR3 can associate
> > to the root port above the PCIe switch.
>
> I think this should be split into two commits:
>
> * One of them to look at _PR3 further up in hierarchy to fix indication
> for BOCO support.

Yes, this part can be split up.

>
> * One to adjust policy for whether to reset

IIUC, the GPU only needs to be reset when the power status isn't certain?

Assuming power resources in _PR3 are really disabled, GPU is already
reset by itself. That means reset shouldn't be necessary for D3cold,
am I understanding it correctly?

However, this is a desktop plugged with GFX card that has external
power, does that assumption still stand? Perform resetting on D3cold
can cover this scenario.

>
>
> > Once the _PR3 is found and BOCO support is correctly marked, use that
> > information to inform the GPU should be reset. This solves an issue that
> > system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
> > is supported for the GFX slot.
>
> I'm worried this is still papering over an underlying issue with L0s
> handling on ALD + Navi1x/Navi2x.

Is it possible to get the ASIC's ASPM parameter under Windows? Knowing
the difference can be useful.

>
> Also, what about runtime suspend?  If you unplug the monitor from this
> dGPU and interact with it over SSH it should go into runtime suspend.
>
> Is it working properly for that case now?

Thanks for the tip. Runtime resume doesn't work at all:
[ 1087.601631] pcieport :00:01.0: power state changed by ACPI to D0
[ 1087.613820] pcieport :00:01.0: restoring config space at offset
0x2c (was 0x43, writing 0x43)
[ 1087.613835] pcieport :00:01.0: restoring config space at offset
0x28 (was 0x41, writing 0x41)
[ 1087.613841] pcieport :00:01.0: restoring config space at offset
0x24 (was 0xfff10001, writing 0xfff10001)
[ 1087.613978] pcieport :00:01.0: PME# disabled
[ 1087.613984] pcieport :00:01.0: waiting 100 ms for downstream
link, after activation
[ 1089.330956] pcieport :01:00.0: not ready 1023ms after resume; giving up
[ 1089.373036] pcieport :01:00.0: Unable to change power state
from D3cold to D0, device inaccessible

After a short while the whole system froze.

So the upstream port of GFX's PCIe switch cannot be powered on again.

Kai-Heng

>
> >
> > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
> >   3 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 60b1857f469e..407456ac0e84 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
> > *adev)
> >   if (amdgpu_sriov_vf(adev))
> >   return false;
> >
> > + if (amdgpu_device_supports_boco(adev_to_drm(adev)))
> > + return true;
> > +
> >   #if IS_ENABLED(CONFIG_SUSPEND)
> >   return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
> >   #else
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f5658359ff5c..d56b7a2bafa6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
> > amdgpu_device *adev)
> >
> >   if (!(adev->flags & AMD_IS_APU)) {
> >   parent = pci_upstream_bridge(adev->pdev);
> > - adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
> > + do {
> > + if (pci_pr3_present(parent)) {
> > + adev->has_pr3 = true;
> > + break;
> > + }
&

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Kai-Heng Feng]

On Wed, Mar 29, 2023 at 9:21 PM Alex Deucher  wrote:
>
> On Wed, Mar 29, 2023 at 6:00 AM Kai-Heng Feng
>  wrote:
> >
> > When the power is lost due to ACPI power resources being turned off, the
> > driver should reset the GPU so it can work anew.
> >
> > First, _PR3 support of the hierarchy needs to be found correctly. Since
> > the GPU on some discrete GFX cards is behind a PCIe switch, checking the
> > _PR3 on downstream port alone is not enough, as the _PR3 can associate
> > to the root port above the PCIe switch.
> >
> > Once the _PR3 is found and BOCO support is correctly marked, use that
> > information to inform the GPU should be reset. This solves an issue that
> > system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
> > is supported for the GFX slot.
>
> I don't think we need to reset the GPU.  If the power is turned off, a
> reset shouldn't be necessary. The reset is only necessary when the
> power is not turned off to put the GPU into a known good state.  It
> should be in that state already if the power is turn off.  It sounds
> like the device is not actually getting powered off.

I had the impression that the GPU gets reset because S3 turned the
power rail off.

So the actual intention for GPU reset is because S3 doesn't guarantee
the power is being turned off?

Kai-Heng

>
> Alex
>
> >
> > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
> >  3 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 60b1857f469e..407456ac0e84 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
> > *adev)
> > if (amdgpu_sriov_vf(adev))
> > return false;
> >
> > +   if (amdgpu_device_supports_boco(adev_to_drm(adev)))
> > +   return true;
> > +
> >  #if IS_ENABLED(CONFIG_SUSPEND)
> > return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
> >  #else
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f5658359ff5c..d56b7a2bafa6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
> > amdgpu_device *adev)
> >
> > if (!(adev->flags & AMD_IS_APU)) {
> > parent = pci_upstream_bridge(adev->pdev);
> > -   adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
> > +   do {
> > +   if (pci_pr3_present(parent)) {
> > +   adev->has_pr3 = true;
> > +   break;
> > +   }
> > +   } while ((parent = pci_upstream_bridge(parent)));
> > }
> >
> > amdgpu_amdkfd_device_probe(adev);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index ba5def374368..5d81fcac4b0a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -2415,10 +2415,11 @@ static int amdgpu_pmops_suspend(struct device *dev)
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > struct amdgpu_device *adev = drm_to_adev(drm_dev);
> >
> > -   if (amdgpu_acpi_is_s0ix_active(adev))
> > -   adev->in_s0ix = true;
> > -   else if (amdgpu_acpi_is_s3_active(adev))
> > +   if (amdgpu_acpi_is_s3_active(adev) ||
> > +   amdgpu_device_supports_boco(drm_dev))
> > adev->in_s3 = true;
> > +   else if (amdgpu_acpi_is_s0ix_active(adev))
> > +   adev->in_s0ix = true;
> > if (!adev->in_s0ix && !adev->in_s3)
> > return 0;
> > return amdgpu_device_suspend(drm_dev, true);
> > @@ -2449,10 +2450,7 @@ static int amdgpu_pmops_resume(struct device *dev)
> > adev->no_hw_access = true;
> >
> > r = amdgpu_device_resume(drm_dev, true);
> > -   if (amdgpu_acpi_is_s0ix_active(adev))
> > -   adev->in_s0ix = false;
> > -   else
> > -   adev->in_s3 = false;
> > +   adev->in_s0ix = adev->in_s3 = false;
> > return r;
> >  }
> >
> > --
> > 2.34.1
> >

[PATCH 2/2] drm/amdgpu: Remove ASPM workaround on VI and NV

[Kai-Heng Feng]

Since the original issue is resolved by a new fix, the ASPM workaround
can be dropped.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 ---
 drivers/gpu/drm/amd/amdgpu/nv.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c|  2 +-
 4 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8cf2cc50b3de..a19a6489b117 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1248,7 +1248,6 @@ void amdgpu_device_pci_config_reset(struct amdgpu_device 
*adev);
 int amdgpu_device_pci_reset(struct amdgpu_device *adev);
 bool amdgpu_device_need_post(struct amdgpu_device *adev);
 bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
-bool amdgpu_device_aspm_support_quirk(void);
 
 void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64 num_bytes,
  u64 num_vis_bytes);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index d56b7a2bafa6..0cacace2d6c2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -81,10 +81,6 @@
 
 #include 
 
-#if IS_ENABLED(CONFIG_X86)
-#include 
-#endif
-
 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -1377,17 +1373,6 @@ bool amdgpu_device_should_use_aspm(struct amdgpu_device 
*adev)
return pcie_aspm_enabled(adev->pdev);
 }
 
-bool amdgpu_device_aspm_support_quirk(void)
-{
-#if IS_ENABLED(CONFIG_X86)
-   struct cpuinfo_x86 *c = _data(0);
-
-   return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
-#else
-   return true;
-#endif
-}
-
 /* if we get transitioned to only one device, take VGA back */
 /**
  * amdgpu_device_vga_set_decode - enable/disable vga decode
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 47420b403871..15f3c6745ea9 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -522,7 +522,7 @@ static int nv_set_vce_clocks(struct amdgpu_device *adev, 
u32 evclk, u32 ecclk)
 
 static void nv_program_aspm(struct amdgpu_device *adev)
 {
-   if (!amdgpu_device_should_use_aspm(adev) || 
!amdgpu_device_aspm_support_quirk())
+   if (!amdgpu_device_should_use_aspm(adev))
return;
 
if (!(adev->flags & AMD_IS_APU) &&
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 531f173ade2d..81dcb1148a60 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1122,7 +1122,7 @@ static void vi_program_aspm(struct amdgpu_device *adev)
bool bL1SS = false;
bool bClkReqSupport = true;
 
-   if (!amdgpu_device_should_use_aspm(adev) || 
!amdgpu_device_aspm_support_quirk())
+   if (!amdgpu_device_should_use_aspm(adev))
return;
 
if (adev->flags & AMD_IS_APU ||
-- 
2.34.1

[PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Kai-Heng Feng]

When the power is lost due to ACPI power resources being turned off, the
driver should reset the GPU so it can work anew.

First, _PR3 support of the hierarchy needs to be found correctly. Since
the GPU on some discrete GFX cards is behind a PCIe switch, checking the
_PR3 on downstream port alone is not enough, as the _PR3 can associate
to the root port above the PCIe switch.

Once the _PR3 is found and BOCO support is correctly marked, use that
information to inform the GPU should be reset. This solves an issue that
system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
is supported for the GFX slot.

Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 60b1857f469e..407456ac0e84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
*adev)
if (amdgpu_sriov_vf(adev))
return false;
 
+   if (amdgpu_device_supports_boco(adev_to_drm(adev)))
+   return true;
+
 #if IS_ENABLED(CONFIG_SUSPEND)
return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
 #else
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f5658359ff5c..d56b7a2bafa6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
 
if (!(adev->flags & AMD_IS_APU)) {
parent = pci_upstream_bridge(adev->pdev);
-   adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
+   do {
+   if (pci_pr3_present(parent)) {
+   adev->has_pr3 = true;
+   break;
+   }
+   } while ((parent = pci_upstream_bridge(parent)));
}
 
amdgpu_amdkfd_device_probe(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index ba5def374368..5d81fcac4b0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2415,10 +2415,11 @@ static int amdgpu_pmops_suspend(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
 
-   if (amdgpu_acpi_is_s0ix_active(adev))
-   adev->in_s0ix = true;
-   else if (amdgpu_acpi_is_s3_active(adev))
+   if (amdgpu_acpi_is_s3_active(adev) ||
+   amdgpu_device_supports_boco(drm_dev))
adev->in_s3 = true;
+   else if (amdgpu_acpi_is_s0ix_active(adev))
+   adev->in_s0ix = true;
if (!adev->in_s0ix && !adev->in_s3)
return 0;
return amdgpu_device_suspend(drm_dev, true);
@@ -2449,10 +2450,7 @@ static int amdgpu_pmops_resume(struct device *dev)
adev->no_hw_access = true;
 
r = amdgpu_device_resume(drm_dev, true);
-   if (amdgpu_acpi_is_s0ix_active(adev))
-   adev->in_s0ix = false;
-   else
-   adev->in_s3 = false;
+   adev->in_s0ix = adev->in_s3 = false;
return r;
 }
 
-- 
2.34.1

[PATCH v2] drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi

[Kai-Heng Feng]

S2idle resume freeze can be observed on Intel ADL + AMD WX5500. This is
caused by commit 0064b0ce85bb ("drm/amd/pm: enable ASPM by default").

The root cause is still not clear for now.

So extend and apply the ASPM quirk from commit e02fe3bc7aba
("drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems"), to
workaround the issue on Navi cards too.

Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
Reviewed-by: Alex Deucher 
Signed-off-by: Kai-Heng Feng 
---
v2:
 - Rename the quirk function.

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/nv.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c| 17 +
 4 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 164141bc8b4a..5f3b139c1f99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1272,6 +1272,7 @@ void amdgpu_device_pci_config_reset(struct amdgpu_device 
*adev);
 int amdgpu_device_pci_reset(struct amdgpu_device *adev);
 bool amdgpu_device_need_post(struct amdgpu_device *adev);
 bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
+bool amdgpu_device_aspm_support_quirk(void);
 
 void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64 num_bytes,
  u64 num_vis_bytes);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c4a4e2fe6681..05a34ff79e78 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -80,6 +80,10 @@
 
 #include 
 
+#if IS_ENABLED(CONFIG_X86)
+#include 
+#endif
+
 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -1356,6 +1360,17 @@ bool amdgpu_device_should_use_aspm(struct amdgpu_device 
*adev)
return pcie_aspm_enabled(adev->pdev);
 }
 
+bool amdgpu_device_aspm_support_quirk(void)
+{
+#if IS_ENABLED(CONFIG_X86)
+   struct cpuinfo_x86 *c = _data(0);
+
+   return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+   return true;
+#endif
+}
+
 /* if we get transitioned to only one device, take VGA back */
 /**
  * amdgpu_device_vga_set_decode - enable/disable vga decode
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 855d390c41de..26733263913e 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -578,7 +578,7 @@ static void nv_pcie_gen3_enable(struct amdgpu_device *adev)
 
 static void nv_program_aspm(struct amdgpu_device *adev)
 {
-   if (!amdgpu_device_should_use_aspm(adev))
+   if (!amdgpu_device_should_use_aspm(adev) || 
!amdgpu_device_aspm_support_quirk())
return;
 
if (!(adev->flags & AMD_IS_APU) &&
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 12ef782eb478..ceab8783575c 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,10 +81,6 @@
 #include "mxgpu_vi.h"
 #include "amdgpu_dm.h"
 
-#if IS_ENABLED(CONFIG_X86)
-#include 
-#endif
-
 #define ixPCIE_LC_L1_PM_SUBSTATE   0x100100C6
 #define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK   
0x0001L
 #define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK   0x0002L
@@ -1138,24 +1134,13 @@ static void vi_enable_aspm(struct amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
 }
 
-static bool aspm_support_quirk_check(void)
-{
-#if IS_ENABLED(CONFIG_X86)
-   struct cpuinfo_x86 *c = _data(0);
-
-   return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
-#else
-   return true;
-#endif
-}
-
 static void vi_program_aspm(struct amdgpu_device *adev)
 {
u32 data, data1, orig;
bool bL1SS = false;
bool bClkReqSupport = true;
 
-   if (!amdgpu_device_should_use_aspm(adev) || !aspm_support_quirk_check())
+   if (!amdgpu_device_should_use_aspm(adev) || 
!amdgpu_device_aspm_support_quirk())
return;
 
if (adev->flags & AMD_IS_APU ||
-- 
2.34.1

[PATCH] drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi

[Kai-Heng Feng]

S2idle resume freeze can be observed on Intel ADL + AMD WX5500. This is
caused by commit 0064b0ce85bb ("drm/amd/pm: enable ASPM by default").

The root cause is still not clear for now.

So extend and apply the ASPM quirk from commit e02fe3bc7aba
("drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems"), to
workaround the issue on Navi cards too.

Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/nv.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c| 15 ---
 4 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 164141bc8b4a..c697580f1ee4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1272,6 +1272,7 @@ void amdgpu_device_pci_config_reset(struct amdgpu_device 
*adev);
 int amdgpu_device_pci_reset(struct amdgpu_device *adev);
 bool amdgpu_device_need_post(struct amdgpu_device *adev);
 bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
+bool aspm_support_quirk_check(void);
 
 void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64 num_bytes,
  u64 num_vis_bytes);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c4a4e2fe6681..c09f19385628 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -80,6 +80,10 @@
 
 #include 
 
+#if IS_ENABLED(CONFIG_X86)
+#include 
+#endif
+
 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -1356,6 +1360,17 @@ bool amdgpu_device_should_use_aspm(struct amdgpu_device 
*adev)
return pcie_aspm_enabled(adev->pdev);
 }
 
+bool aspm_support_quirk_check(void)
+{
+#if IS_ENABLED(CONFIG_X86)
+   struct cpuinfo_x86 *c = _data(0);
+
+   return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
+#else
+   return true;
+#endif
+}
+
 /* if we get transitioned to only one device, take VGA back */
 /**
  * amdgpu_device_vga_set_decode - enable/disable vga decode
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 855d390c41de..921adf66e3c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -578,7 +578,7 @@ static void nv_pcie_gen3_enable(struct amdgpu_device *adev)
 
 static void nv_program_aspm(struct amdgpu_device *adev)
 {
-   if (!amdgpu_device_should_use_aspm(adev))
+   if (!amdgpu_device_should_use_aspm(adev) || !aspm_support_quirk_check())
return;
 
if (!(adev->flags & AMD_IS_APU) &&
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 12ef782eb478..e61ae372d674 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -81,10 +81,6 @@
 #include "mxgpu_vi.h"
 #include "amdgpu_dm.h"
 
-#if IS_ENABLED(CONFIG_X86)
-#include 
-#endif
-
 #define ixPCIE_LC_L1_PM_SUBSTATE   0x100100C6
 #define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK   
0x0001L
 #define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK   0x0002L
@@ -1138,17 +1134,6 @@ static void vi_enable_aspm(struct amdgpu_device *adev)
WREG32_PCIE(ixPCIE_LC_CNTL, data);
 }
 
-static bool aspm_support_quirk_check(void)
-{
-#if IS_ENABLED(CONFIG_X86)
-   struct cpuinfo_x86 *c = _data(0);
-
-   return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
-#else
-   return true;
-#endif
-}
-
 static void vi_program_aspm(struct amdgpu_device *adev)
 {
u32 data, data1, orig;
-- 
2.34.1

Re: [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(>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, _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, _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: [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] 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: [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.
>
> > >
> > > Most users will be fine with ports 

Re: [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(>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, _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, _dsm_guid2,
> > +   INTEL_DSM_REVISION_ID,
> > +   INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > +   NULL);
> > +   if (obj)
> > +   ACPI_FREE(obj);
> > +   }
> >  }
> >
> >  /*
> > --
> > 2.36.1
> >
>

Re: [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);
> > > > >   acpi_handle dhandle;
> > > > 

Re: [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(>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, _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, _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
>

[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(>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, _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, _dsm_guid2,
+   INTEL_DSM_REVISION_ID,
+   INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
+   NULL);
+   if (obj)
+   ACPI_FREE(obj);
+   }
 }
 
 /*
-- 
2.36.1

[PATCH] drm/amdgpu: Ensure HDA function is suspended before ASIC reset

[Kai-Heng Feng]

DP/HDMI audio on AMD PRO VII stops working after S3:
[  149.450391] amdgpu :63:00.0: amdgpu: MODE1 reset
[  149.450395] amdgpu :63:00.0: amdgpu: GPU mode1 reset
[  149.450494] amdgpu :63:00.0: amdgpu: GPU psp mode1 reset
[  149.983693] snd_hda_intel :63:00.1: refused to change power state from 
D0 to D3hot
[  150.003439] amdgpu :63:00.0: refused to change power state from D0 to 
D3hot
...
[  155.432975] snd_hda_intel :63:00.1: CORB reset timeout#2, CORBRP = 65535

The offending commit is daf8de0874ab5b ("drm/amdgpu: always reset the asic in
suspend (v2)"). Commit 34452ac3038a7 ("drm/amdgpu: don't use BACO for
reset in S3 ") doesn't help, so the issue is something different.

Assuming that to make HDA resume to D0 fully realized, it needs to be
successfully put to D3 first. And this guesswork proves working, by
moving amdgpu_asic_reset() to noirq callback, so it's called after HDA
function is in D3.

Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bb1c025d90019..31f7229e7ea89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2323,18 +2323,23 @@ static int amdgpu_pmops_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
-   int r;
 
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
else
adev->in_s3 = true;
-   r = amdgpu_device_suspend(drm_dev, true);
-   if (r)
-   return r;
+   return amdgpu_device_suspend(drm_dev, true);
+}
+
+static int amdgpu_pmops_suspend_noirq(struct device *dev)
+{
+   struct drm_device *drm_dev = dev_get_drvdata(dev);
+   struct amdgpu_device *adev = drm_to_adev(drm_dev);
+
if (!adev->in_s0ix)
-   r = amdgpu_asic_reset(adev);
-   return r;
+   return amdgpu_asic_reset(adev);
+
+   return 0;
 }
 
 static int amdgpu_pmops_resume(struct device *dev)
@@ -2575,6 +2580,7 @@ static const struct dev_pm_ops amdgpu_pm_ops = {
.prepare = amdgpu_pmops_prepare,
.complete = amdgpu_pmops_complete,
.suspend = amdgpu_pmops_suspend,
+   .suspend_noirq = amdgpu_pmops_suspend_noirq,
.resume = amdgpu_pmops_resume,
.freeze = amdgpu_pmops_freeze,
.thaw = amdgpu_pmops_thaw,
-- 
2.34.1

Re: [PATCH] vgaarb: Use ACPI HID name to find integrated GPU

[Kai-Heng Feng]

On Sat, Sep 18, 2021 at 12:55 AM Bjorn Helgaas  wrote:
>
> On Fri, Sep 17, 2021 at 11:49:45AM +0800, Kai-Heng Feng wrote:
> > On Fri, Sep 17, 2021 at 12:38 AM Bjorn Helgaas  wrote:
> > >
> > > [+cc Huacai, linux-pci]
> > >
> > > On Wed, May 19, 2021 at 09:57:23PM +0800, Kai-Heng Feng wrote:
> > > > Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
> > > > the first device is an integrated GPU. However, on AMD platforms an
> > > > integrated GPU can have higher PCI device number than a discrete GPU.
> > > >
> > > > Integrated GPU on ACPI platform generally has _DOD and _DOS method, so
> > > > use that as predicate to find integrated GPU. If the new strategy
> > > > doesn't work, fallback to use the first device as boot VGA.
> > > >
> > > > Signed-off-by: Kai-Heng Feng 
> > > > ---
> > > >  drivers/gpu/vga/vgaarb.c | 31 ++-
> > > >  1 file changed, 26 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > > > index 5180c5687ee5..949fde433ea2 100644
> > > > --- a/drivers/gpu/vga/vgaarb.c
> > > > +++ b/drivers/gpu/vga/vgaarb.c
> > > > @@ -50,6 +50,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >
> > > >  #include 
> > > >
> > > > @@ -1450,9 +1451,23 @@ static struct miscdevice vga_arb_device = {
> > > >   MISC_DYNAMIC_MINOR, "vga_arbiter", _arb_device_fops
> > > >  };
> > > >
> > > > +#if defined(CONFIG_ACPI)
> > > > +static bool vga_arb_integrated_gpu(struct device *dev)
> > > > +{
> > > > + struct acpi_device *adev = ACPI_COMPANION(dev);
> > > > +
> > > > + return adev && !strcmp(acpi_device_hid(adev), ACPI_VIDEO_HID);
> > > > +}
> > > > +#else
> > > > +static bool vga_arb_integrated_gpu(struct device *dev)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > > > +
> > > >  static void __init vga_arb_select_default_device(void)
> > > >  {
> > > > - struct pci_dev *pdev;
> > > > + struct pci_dev *pdev, *found = NULL;
> > > >   struct vga_device *vgadev;
> > > >
> > > >  #if defined(CONFIG_X86) || defined(CONFIG_IA64)
> > > > @@ -1505,20 +1520,26 @@ static void __init 
> > > > vga_arb_select_default_device(void)
> > > >  #endif
> > > >
> > > >   if (!vga_default_device()) {
> > > > - list_for_each_entry(vgadev, _list, list) {
> > > > + list_for_each_entry_reverse(vgadev, _list, list) {
> > >
> > > Hi Kai-Heng, do you remember why you changed the order of this list
> > > traversal?
> >
> > The descending order is to keep the original behavior.
> >
> > Before this patch, it breaks out of the loop as early as possible, so
> > the lower numbered device is picked.
> > This patch makes it only break out of the loop when ACPI_VIDEO_HID
> > device is found.
> > So if there are more than one device that meet "cmd & (PCI_COMMAND_IO
> > | PCI_COMMAND_MEMORY)", higher numbered device will be selected.
> > So the traverse order reversal is to keep the original behavior.
>
> Can you give an example of what you mean?  I don't quite follow how it
> keeps the original behavior.
>
> If we have this:
>
>   0  PCI_COMMAND_MEMORY set   ACPI_VIDEO_HID
>   1  PCI_COMMAND_MEMORY set   ACPI_VIDEO_HID
>
> Previously we didn't look for ACPI_VIDEO_HID, so we chose 0, now we
> choose 1, which seems wrong.  In the absence of other information, I
> would prefer the lower-numbered device.
>
> Or this:
>
>   0  PCI_COMMAND_MEMORY set
>   1  PCI_COMMAND_MEMORY set   ACPI_VIDEO_HID
>
> Previously we chose 0; now we choose 1, which does seem right, but
> we'd choose 1 regardless of the order.
>
> Or this:
>
>   0  PCI_COMMAND_MEMORY set   ACPI_VIDEO_HID
>   1  PCI_COMMAND_MEMORY set
>
> Previously we chose 0, now we still choose 0, which seems right but
> again doesn't depend on the order.
>
> The first case, where both devices are ACPI_VIDEO_HID, is the only one
> where the order matters, and I suggest that we should be using the
> original order, not the reversed order.

C

Re: [PATCH] vgaarb: Use ACPI HID name to find integrated GPU

[Kai-Heng Feng]

On Fri, Sep 17, 2021 at 12:38 AM Bjorn Helgaas  wrote:
>
> [+cc Huacai, linux-pci]
>
> On Wed, May 19, 2021 at 09:57:23PM +0800, Kai-Heng Feng wrote:
> > Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
> > the first device is an integrated GPU. However, on AMD platforms an
> > integrated GPU can have higher PCI device number than a discrete GPU.
> >
> > Integrated GPU on ACPI platform generally has _DOD and _DOS method, so
> > use that as predicate to find integrated GPU. If the new strategy
> > doesn't work, fallback to use the first device as boot VGA.
> >
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/vga/vgaarb.c | 31 ++-
> >  1 file changed, 26 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > index 5180c5687ee5..949fde433ea2 100644
> > --- a/drivers/gpu/vga/vgaarb.c
> > +++ b/drivers/gpu/vga/vgaarb.c
> > @@ -50,6 +50,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >
> > @@ -1450,9 +1451,23 @@ static struct miscdevice vga_arb_device = {
> >   MISC_DYNAMIC_MINOR, "vga_arbiter", _arb_device_fops
> >  };
> >
> > +#if defined(CONFIG_ACPI)
> > +static bool vga_arb_integrated_gpu(struct device *dev)
> > +{
> > + struct acpi_device *adev = ACPI_COMPANION(dev);
> > +
> > + return adev && !strcmp(acpi_device_hid(adev), ACPI_VIDEO_HID);
> > +}
> > +#else
> > +static bool vga_arb_integrated_gpu(struct device *dev)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> >  static void __init vga_arb_select_default_device(void)
> >  {
> > - struct pci_dev *pdev;
> > + struct pci_dev *pdev, *found = NULL;
> >   struct vga_device *vgadev;
> >
> >  #if defined(CONFIG_X86) || defined(CONFIG_IA64)
> > @@ -1505,20 +1520,26 @@ static void __init 
> > vga_arb_select_default_device(void)
> >  #endif
> >
> >   if (!vga_default_device()) {
> > - list_for_each_entry(vgadev, _list, list) {
> > + list_for_each_entry_reverse(vgadev, _list, list) {
>
> Hi Kai-Heng, do you remember why you changed the order of this list
> traversal?

The descending order is to keep the original behavior.

Before this patch, it breaks out of the loop as early as possible, so
the lower numbered device is picked.
This patch makes it only break out of the loop when ACPI_VIDEO_HID
device is found.
So if there are more than one device that meet "cmd & (PCI_COMMAND_IO
| PCI_COMMAND_MEMORY)", higher numbered device will be selected.
So the traverse order reversal is to keep the original behavior.

>
> I guess the list_add_tail() in vga_arbiter_add_pci_device() means
> vga_list is generally ordered with small device numbers first and
> large ones last.
>
> So you pick the integrated GPU with the largest device number.  Are
> there systems with more than one integrated GPU?  If so, I would
> naively expect that in the absence of an indication otherwise, we'd
> want the one with the *smallest* device number.

There's only one integrated GPU on the affected system.

The approach is to keep the list traversal in one pass.
Is there any regression introduce by this patch?
If that's the case, we can separate the logic and find the
ACPI_VIDEO_HID in second pass.

Kai-Heng

>
> >   struct device *dev = >pdev->dev;
> >   u16 cmd;
> >
> >   pdev = vgadev->pdev;
> >   pci_read_config_word(pdev, PCI_COMMAND, );
> >   if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
> > - vgaarb_info(dev, "setting as boot device (VGA 
> > legacy resources not available)\n");
> > - vga_set_default_device(pdev);
> > - break;
> > + found = pdev;
> > + if (vga_arb_integrated_gpu(dev))
> > + break;
> >   }
> >   }
> >   }
> >
> > + if (found) {
> > + vgaarb_info(>dev, "setting as boot device (VGA legacy 
> > resources not available)\n");
> > + vga_set_default_device(found);
> > + return;
> > + }
> > +
> >   if (!vga_default_device()) {
> >   vgadev = list_first_entry_or_null(_list,
> > struct vga_device, list);
> > --
> > 2.31.1
> >

[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(_priv->drm, "use AUD_FREQ_CNTRL of 0x%x (init 
value 0x%x)\n",
-- 
2.32.0

[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(_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(_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

[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

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(_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(_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(_pci_dev->dev);
> > >   return 0;
> > >
> > > -err_fb_dealoc:
> > > +err_put_rpm_ref:
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(_pci_dev->dev);
> > > +
> > >   fb_dealloc_cmap(>cmap);
> > >  err_groups:
> > >   sysfs_remove_groups(>dev.kobj, efifb_groups);
> > > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > >   unregister_framebuffer(info);
> > >   sysfs_remove_groups(>dev.kobj, efifb_groups);
> > >   framebuffer_release(info);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_put(_pci_dev->dev);
> > >
> > >   return 0;
> > >  }
> > > --
> > > 2.27.0
> > >

[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

[PATCH] drm/amdgpu/acp: Make PM domain really work

[Kai-Heng Feng]

75 hwmon_vid drm ip_tables x_tables autofs4 dm_mirror dm_region_hash 
dm_log hid_generic usbhid hid uas usb_storage r8169 crc32_pclmul realtek ahci 
xhci_pci i2c_piix4
[   56.979521]  xhci_pci_renesas libahci video
[   56.979541] ---[ end trace cb8f6a346f18da7b ]---

Instead of finding MFD hotplugged device by its name, simply iterate
over the child devices to avoid the issue.

BugLink: https://bugs.launchpad.net/bugs/1920674
Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 49 +
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index b8655ff73a658..8522f46d5d725 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -160,17 +160,28 @@ static int acp_poweron(struct generic_pm_domain *genpd)
return 0;
 }
 
-static struct device *get_mfd_cell_dev(const char *device_name, int r)
+static int acp_genpd_add_device(struct device *dev, void *data)
 {
-   char auto_dev_name[25];
-   struct device *dev;
+   struct generic_pm_domain *gpd = data;
+   int ret;
+
+   ret = pm_genpd_add_device(gpd, dev);
+   if (ret)
+   dev_err(dev, "Failed to add dev to genpd %d\n", ret);
 
-   snprintf(auto_dev_name, sizeof(auto_dev_name),
-"%s.%d.auto", device_name, r);
-   dev = bus_find_device_by_name(_bus_type, NULL, auto_dev_name);
-   dev_info(dev, "device %s added to pm domain\n", auto_dev_name);
+   return ret;
+}
 
-   return dev;
+static int acp_genpd_remove_device(struct device *dev, void *data)
+{
+   int ret;
+
+   ret = pm_genpd_remove_device(dev);
+   if (ret)
+   dev_err(dev, "Failed to remove dev from genpd %d\n", ret);
+
+   /* Continue to remove */
+   return 0;
 }
 
 /**
@@ -341,15 +352,10 @@ static int acp_hw_init(void *handle)
if (r)
goto failure;
 
-   for (i = 0; i < ACP_DEVS ; i++) {
-   dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
-   r = pm_genpd_add_device(>acp.acp_genpd->gpd, dev);
-   if (r) {
-   dev_err(dev, "Failed to add dev to genpd\n");
-   goto failure;
-   }
-   }
-
+   r = device_for_each_child(adev->acp.parent, >acp.acp_genpd->gpd,
+ acp_genpd_add_device);
+   if (r)
+   goto failure;
 
/* Assert Soft reset of ACP */
val = cgs_read_register(adev->acp.cgs_device, mmACP_SOFT_RESET);
@@ -458,13 +464,8 @@ static int acp_hw_fini(void *handle)
udelay(100);
}
 
-   for (i = 0; i < ACP_DEVS ; i++) {
-   dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
-   ret = pm_genpd_remove_device(dev);
-   /* If removal fails, dont giveup and try rest */
-   if (ret)
-   dev_err(dev, "remove dev from genpd failed\n");
-   }
+   device_for_each_child(adev->acp.parent, NULL,
+ acp_genpd_remove_device);
 
mfd_remove_devices(adev->acp.parent);
kfree(adev->acp.acp_res);
-- 
2.31.1

Re: [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(>dev);
> > +   if (!dhandle)
> > +   return;
> > +
> > +   acpi_evaluate_dsm(dhandle, _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
> >

Re: [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(>dev);
> +   if (!dhandle)
> +   return;
> +
> +   acpi_evaluate_dsm(dhandle, _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
>

[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(>dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, _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

[PATCH] vgaarb: Use ACPI HID name to find integrated GPU

[Kai-Heng Feng]

Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
the first device is an integrated GPU. However, on AMD platforms an
integrated GPU can have higher PCI device number than a discrete GPU.

Integrated GPU on ACPI platform generally has _DOD and _DOS method, so
use that as predicate to find integrated GPU. If the new strategy
doesn't work, fallback to use the first device as boot VGA.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/vga/vgaarb.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 5180c5687ee5..949fde433ea2 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1450,9 +1451,23 @@ static struct miscdevice vga_arb_device = {
MISC_DYNAMIC_MINOR, "vga_arbiter", _arb_device_fops
 };
 
+#if defined(CONFIG_ACPI)
+static bool vga_arb_integrated_gpu(struct device *dev)
+{
+   struct acpi_device *adev = ACPI_COMPANION(dev);
+
+   return adev && !strcmp(acpi_device_hid(adev), ACPI_VIDEO_HID);
+}
+#else
+static bool vga_arb_integrated_gpu(struct device *dev)
+{
+   return false;
+}
+#endif
+
 static void __init vga_arb_select_default_device(void)
 {
-   struct pci_dev *pdev;
+   struct pci_dev *pdev, *found = NULL;
struct vga_device *vgadev;
 
 #if defined(CONFIG_X86) || defined(CONFIG_IA64)
@@ -1505,20 +1520,26 @@ static void __init vga_arb_select_default_device(void)
 #endif
 
if (!vga_default_device()) {
-   list_for_each_entry(vgadev, _list, list) {
+   list_for_each_entry_reverse(vgadev, _list, list) {
struct device *dev = >pdev->dev;
u16 cmd;
 
pdev = vgadev->pdev;
pci_read_config_word(pdev, PCI_COMMAND, );
if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
-   vgaarb_info(dev, "setting as boot device (VGA 
legacy resources not available)\n");
-   vga_set_default_device(pdev);
-   break;
+   found = pdev;
+   if (vga_arb_integrated_gpu(dev))
+   break;
}
}
}
 
+   if (found) {
+   vgaarb_info(>dev, "setting as boot device (VGA legacy 
resources not available)\n");
+   vga_set_default_device(found);
+   return;
+   }
+
if (!vga_default_device()) {
vgadev = list_first_entry_or_null(_list,
  struct vga_device, list);
-- 
2.31.1

Re: [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(>dev);
> > + if (!dhandle)
> > + return;
> > +
> > + acpi_evaluate_dsm(dhandle, _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/driv

Re: [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(>dev);
> +   if (!dhandle)
> +   return;
> +
> +   acpi_evaluate_dsm(dhandle, _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
>

Re: [PATCH v2] drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected

[Kai-Heng Feng]

On Fri, Apr 30, 2021 at 12:57 PM Kai-Heng Feng
 wrote:
>
> Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue
> doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and
> another one is 4K 30Hz (pixelclock 297MHz).
>
> The issue is gone after setting "power_dpm_force_performance_level" to
> "high". Following the indication, we found that the issue occurs when
> sclk is too low.
>
> So resolve the issue by disabling sclk switching when there are two
> monitors requires high pixelclock (> 297MHz).
>
> v2:
>  - Only apply the fix to Oland.
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
>  drivers/gpu/drm/radeon/radeon.h| 1 +
>  drivers/gpu/drm/radeon/radeon_pm.c | 8 
>  drivers/gpu/drm/radeon/si_dpm.c| 3 +++
>  3 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 42281fce552e6..56ed5634cebef 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1549,6 +1549,7 @@ struct radeon_dpm {
> void*priv;
> u32 new_active_crtcs;
> int new_active_crtc_count;
> +   int high_pixelclock_count;
> u32 current_active_crtcs;
> int current_active_crtc_count;
> bool single_display;
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 0c1950f4e146f..3861c0b98fcf3 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -1767,6 +1767,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
> radeon_device *rdev)
> struct drm_device *ddev = rdev->ddev;
> struct drm_crtc *crtc;
> struct radeon_crtc *radeon_crtc;
> +   struct radeon_connector *radeon_connector;
>
> if (!rdev->pm.dpm_enabled)
> return;
> @@ -1776,6 +1777,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
> radeon_device *rdev)
> /* update active crtc counts */
> rdev->pm.dpm.new_active_crtcs = 0;
> rdev->pm.dpm.new_active_crtc_count = 0;
> +   rdev->pm.dpm.high_pixelclock_count = 0;
> if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
> list_for_each_entry(crtc,
> >mode_config.crtc_list, head) {
> @@ -1783,6 +1785,12 @@ static void radeon_pm_compute_clocks_dpm(struct 
> radeon_device *rdev)
> if (crtc->enabled) {
> rdev->pm.dpm.new_active_crtcs |= (1 << 
> radeon_crtc->crtc_id);
> rdev->pm.dpm.new_active_crtc_count++;
> +   if (!radeon_crtc->connector)
> +   continue;
> +
> +   radeon_connector = 
> to_radeon_connector(radeon_crtc->connector);
> +   if (radeon_connector->pixelclock_for_modeset 
> > 297000)
> +   rdev->pm.dpm.high_pixelclock_count++;
> }
> }
> }
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index 9186095518047..3cc2b96a7f368 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -2979,6 +2979,9 @@ static void si_apply_state_adjust_rules(struct 
> radeon_device *rdev,
> (rdev->pdev->device == 0x6605)) {
> max_sclk = 75000;
> }
> +
> +   if (rdev->pm.dpm.high_pixelclock_count > 1)
> +   disable_sclk_switching = true;
> }
>
> if (rps->vce_active) {
> --
> 2.30.2
>

Re: [PATCH] drm/radeon/si_dpm: Fix SMU power state load

[Kai-Heng Feng]

On Mon, May 10, 2021 at 6:54 AM Gustavo A. R. Silva
 wrote:
>
> Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL, instead.
>
> Currently, the code fails because flexible array _levels_ in
> struct SISLANDS_SMC_SWSTATE doesn't allow for code that access
> the first element of initialState.levels and ACPIState.levels
> arrays:
>
> 4353 table->initialState.levels[0].mclk.vDLL_CNTL =
> 4354 cpu_to_be32(si_pi->clock_registers.dll_cntl);
> ...
> 4555 table->ACPIState.levels[0].mclk.vDLL_CNTL =
> 4556 cpu_to_be32(dll_cntl);
>
> because such element cannot exist without previously allocating
> any dynamic memory for it (which never actually happens).
>
> That's why struct SISLANDS_SMC_SWSTATE should only be used as type
> for object driverState and new struct SISLANDS_SMC_SWSTATE_SINGLE is
> created as type for objects initialState, ACPIState and ULVState.
>
> Also, with the change from one-element array to flexible-array member
> in commit 96e27e8d919e ("drm/radeon/si_dpm: Replace one-element array
> with flexible-array in struct SISLANDS_SMC_SWSTATE"), the size of
> dpmLevels in struct SISLANDS_SMC_STATETABLE should be fixed to be
> SISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE instead of
> SISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1583
> Fixes: 96e27e8d919e ("drm/radeon/si_dpm: Replace one-element array with 
> flexible-array in struct SISLANDS_SMC_SWSTATE")
> Cc: sta...@vger.kernel.org
> Reported-by: Kai-Heng Feng 
> Signed-off-by: Gustavo A. R. Silva 

Tested-by: Kai-Heng Feng 

> ---
>  drivers/gpu/drm/radeon/si_dpm.c   | 174 +-
>  drivers/gpu/drm/radeon/sislands_smc.h |  34 +++--
>  2 files changed, 109 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index 91bfc4762767..2a8b9680cf6b 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -4350,70 +4350,70 @@ static int si_populate_smc_initial_state(struct 
> radeon_device *rdev,
> u32 reg;
> int ret;
>
> -   table->initialState.levels[0].mclk.vDLL_CNTL =
> +   table->initialState.level.mclk.vDLL_CNTL =
> cpu_to_be32(si_pi->clock_registers.dll_cntl);
> -   table->initialState.levels[0].mclk.vMCLK_PWRMGT_CNTL =
> +   table->initialState.level.mclk.vMCLK_PWRMGT_CNTL =
> cpu_to_be32(si_pi->clock_registers.mclk_pwrmgt_cntl);
> -   table->initialState.levels[0].mclk.vMPLL_AD_FUNC_CNTL =
> +   table->initialState.level.mclk.vMPLL_AD_FUNC_CNTL =
> cpu_to_be32(si_pi->clock_registers.mpll_ad_func_cntl);
> -   table->initialState.levels[0].mclk.vMPLL_DQ_FUNC_CNTL =
> +   table->initialState.level.mclk.vMPLL_DQ_FUNC_CNTL =
> cpu_to_be32(si_pi->clock_registers.mpll_dq_func_cntl);
> -   table->initialState.levels[0].mclk.vMPLL_FUNC_CNTL =
> +   table->initialState.level.mclk.vMPLL_FUNC_CNTL =
> cpu_to_be32(si_pi->clock_registers.mpll_func_cntl);
> -   table->initialState.levels[0].mclk.vMPLL_FUNC_CNTL_1 =
> +   table->initialState.level.mclk.vMPLL_FUNC_CNTL_1 =
> cpu_to_be32(si_pi->clock_registers.mpll_func_cntl_1);
> -   table->initialState.levels[0].mclk.vMPLL_FUNC_CNTL_2 =
> +   table->initialState.level.mclk.vMPLL_FUNC_CNTL_2 =
> cpu_to_be32(si_pi->clock_registers.mpll_func_cntl_2);
> -   table->initialState.levels[0].mclk.vMPLL_SS =
> +   table->initialState.level.mclk.vMPLL_SS =
> cpu_to_be32(si_pi->clock_registers.mpll_ss1);
> -   table->initialState.levels[0].mclk.vMPLL_SS2 =
> +   table->initialState.level.mclk.vMPLL_SS2 =
> cpu_to_be32(si_pi->clock_registers.mpll_ss2);
>
> -   table->initialState.levels[0].mclk.mclk_value =
> +   table->initialState.level.mclk.mclk_value =
> cpu_to_be32(initial_state->performance_levels[0].mclk);
>
> -   table->initialState.levels[0].sclk.vCG_SPLL_FUNC_CNTL =
> +   table->initialState.level.sclk.vCG_SPLL_FUNC_CNTL =
> cpu_to_be32(si_pi->clock_registers.cg_spll_func_cntl);
> -   table->initialState.levels[0].sclk.vCG_SPLL_FUNC_CNTL_2 =
> +   table->initialState.level.sclk.vCG_SPLL_FUNC_CNTL_2 =
> 

[PATCH v2] drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected

[Kai-Heng Feng]

Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue
doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and
another one is 4K 30Hz (pixelclock 297MHz).

The issue is gone after setting "power_dpm_force_performance_level" to
"high". Following the indication, we found that the issue occurs when
sclk is too low.

So resolve the issue by disabling sclk switching when there are two
monitors requires high pixelclock (> 297MHz).

v2:
 - Only apply the fix to Oland.
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_pm.c | 8 
 drivers/gpu/drm/radeon/si_dpm.c| 3 +++
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 42281fce552e6..56ed5634cebef 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1549,6 +1549,7 @@ struct radeon_dpm {
void*priv;
u32 new_active_crtcs;
int new_active_crtc_count;
+   int high_pixelclock_count;
u32 current_active_crtcs;
int current_active_crtc_count;
bool single_display;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0c1950f4e146f..3861c0b98fcf3 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1767,6 +1767,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
struct drm_device *ddev = rdev->ddev;
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
+   struct radeon_connector *radeon_connector;
 
if (!rdev->pm.dpm_enabled)
return;
@@ -1776,6 +1777,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
/* update active crtc counts */
rdev->pm.dpm.new_active_crtcs = 0;
rdev->pm.dpm.new_active_crtc_count = 0;
+   rdev->pm.dpm.high_pixelclock_count = 0;
if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
list_for_each_entry(crtc,
>mode_config.crtc_list, head) {
@@ -1783,6 +1785,12 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
if (crtc->enabled) {
rdev->pm.dpm.new_active_crtcs |= (1 << 
radeon_crtc->crtc_id);
rdev->pm.dpm.new_active_crtc_count++;
+   if (!radeon_crtc->connector)
+   continue;
+
+   radeon_connector = 
to_radeon_connector(radeon_crtc->connector);
+   if (radeon_connector->pixelclock_for_modeset > 
297000)
+   rdev->pm.dpm.high_pixelclock_count++;
}
}
}
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 9186095518047..3cc2b96a7f368 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2979,6 +2979,9 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
(rdev->pdev->device == 0x6605)) {
max_sclk = 75000;
}
+
+   if (rdev->pm.dpm.high_pixelclock_count > 1)
+   disable_sclk_switching = true;
}
 
if (rps->vce_active) {
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/dpm: Disable sclk switching when two 4K 60Hz monitors are connected

[Kai-Heng Feng]

Screen flickers rapidly when two 4K 60Hz monitors are connected to an
Oland card. This issue doesn't happen when one monitor is 4K 60Hz
(pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz).

The issue is gone after setting "power_dpm_force_performance_level" to
"high". Following the lead, we found that the issue only occurs when
sclk is too low.

So resolve the issue by disabling sclk switching when there are two
monitors that requires high pixelclock (> 297MHz).

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_pm.c | 8 
 drivers/gpu/drm/radeon/si_dpm.c| 3 +++
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 42281fce552e6..56ed5634cebef 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1549,6 +1549,7 @@ struct radeon_dpm {
void*priv;
u32 new_active_crtcs;
int new_active_crtc_count;
+   int high_pixelclock_count;
u32 current_active_crtcs;
int current_active_crtc_count;
bool single_display;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0c1950f4e146f..3861c0b98fcf3 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1767,6 +1767,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
struct drm_device *ddev = rdev->ddev;
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
+   struct radeon_connector *radeon_connector;
 
if (!rdev->pm.dpm_enabled)
return;
@@ -1776,6 +1777,7 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
/* update active crtc counts */
rdev->pm.dpm.new_active_crtcs = 0;
rdev->pm.dpm.new_active_crtc_count = 0;
+   rdev->pm.dpm.high_pixelclock_count = 0;
if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
list_for_each_entry(crtc,
>mode_config.crtc_list, head) {
@@ -1783,6 +1785,12 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
if (crtc->enabled) {
rdev->pm.dpm.new_active_crtcs |= (1 << 
radeon_crtc->crtc_id);
rdev->pm.dpm.new_active_crtc_count++;
+   if (!radeon_crtc->connector)
+   continue;
+
+   radeon_connector = 
to_radeon_connector(radeon_crtc->connector);
+   if (radeon_connector->pixelclock_for_modeset > 
297000)
+   rdev->pm.dpm.high_pixelclock_count++;
}
}
}
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 9186095518047..be6fa3257d1bc 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2995,6 +2995,9 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
ni_dpm_vblank_too_short(rdev))
disable_mclk_switching = true;
 
+   if (rdev->pm.dpm.high_pixelclock_count > 1)
+   disable_sclk_switching = true;
+
if (rps->vclk || rps->dclk) {
disable_mclk_switching = true;
disable_sclk_switching = true;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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(>dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, _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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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(>dev);
> > + if (!dhandle)
> > + return;
> > +
> > + acpi_evaluate_dsm(dhandle, _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
> > @@

[PATCH v2] drm/amdgpu: Register VGA clients after init can no longer fail

[Kai-Heng Feng]

When an amdgpu device fails to init, it makes another VGA device cause
kernel splat:
kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
kernel: amdgpu: probe of :08:00.0 failed with error -110
...
kernel: amdgpu :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=none
kernel: BUG: kernel NULL pointer dereference, address: 0018
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops:  [#1] SMP NOPTI
kernel: CPU: 6 PID: 1080 Comm: Xorg Tainted: GW 5.12.0-rc8+ #12
kernel: Hardware name: HP HP EliteDesk 805 G6/872B, BIOS S09 Ver. 02.02.00 
12/30/2020
kernel: RIP: 0010:amdgpu_device_vga_set_decode+0x13/0x30 [amdgpu]
kernel: Code: 06 31 c0 c3 b8 ea ff ff ff 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 
90 0f 1f 44 00 00 55 48 8b 87 90 06 00 00 48 89 e5 53 89 f3 <48> 8b 40 18 40 0f 
b6 f6 e8 40 58 39 fd 80 fb 01 5b 5d 19 c0 83 e0
kernel: RSP: 0018:ae3c0246bd68 EFLAGS: 00010002
kernel: RAX:  RBX:  RCX: 
kernel: RDX: 8dd1af5a8560 RSI:  RDI: 8dce8c16
kernel: RBP: ae3c0246bd70 R08: 8dd1af5985c0 R09: ae3c0246ba38
kernel: R10: 0001 R11: 0001 R12: 0246
kernel: R13:  R14: 0003 R15: 8dce8149
kernel: FS:  7f9303d8fa40() GS:8dd1af58() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 0018 CR3: 000103cfa000 CR4: 00350ee0
kernel: Call Trace:
kernel:  vga_arbiter_notify_clients.part.0+0x4a/0x80
kernel:  vga_get+0x17f/0x1c0
kernel:  vga_arb_write+0x121/0x6a0
kernel:  ? apparmor_file_permission+0x1c/0x20
kernel:  ? security_file_permission+0x30/0x180
kernel:  vfs_write+0xca/0x280
kernel:  ksys_write+0x67/0xe0
kernel:  __x64_sys_write+0x1a/0x20
kernel:  do_syscall_64+0x38/0x90
kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
kernel: RIP: 0033:0x7f93041e02f7
kernel: Code: 75 05 48 83 c4 58 c3 e8 f7 33 ff ff 0f 1f 80 00 00 00 00 f3 0f 1e 
fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 
77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
kernel: RSP: 002b:7fff60e49b28 EFLAGS: 0246 ORIG_RAX: 0001
kernel: RAX: ffda RBX: 000b RCX: 7f93041e02f7
kernel: RDX: 000b RSI: 7fff60e49b40 RDI: 000f
kernel: RBP: 7fff60e49b40 R08:  R09: 7fff60e499d0
kernel: R10: 7f93049350b5 R11: 0246 R12: 56111d45e808
kernel: R13:  R14: 56111d45e7f8 R15: 56111d46c980
kernel: Modules linked in: nls_iso8859_1 snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel 
snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq 
input_leds snd_seq_device snd_timer snd soundcore joydev kvm_amd serio_raw 
k10temp mac_hid hp_wmi ccp kvm sparse_keymap wmi_bmof ucsi_acpi efi_pstore 
typec_ucsi rapl typec video wmi sch_fq_codel parport_pc ppdev lp parport 
ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor 
raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log 
hid_generic usbhid hid amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched 
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt 
crc32_pclmul fb_sys_fops ghash_clmulni_intel cec rc_core aesni_intel 
crypto_simd psmouse cryptd r8169 i2c_piix4 drm ahci xhci_pci realtek libahci 
xhci_pci_renesas gpio_amdpt gpio_generic
kernel: CR2: 0018
kernel: ---[ end trace 76d04313d4214c51 ]---

Commit 4192f7b57689 ("drm/amdgpu: unmap register bar on device init
failure") makes amdgpu_driver_unload_kms() skips amdgpu_device_fini(),
so the VGA clients remain registered. So when
vga_arbiter_notify_clients() iterates over registered clients, it causes
NULL pointer dereference.

Since there's no reason to register VGA clients that early, so solve
the issue by putting them after all the goto cleanups.

v2:
 - Remove redundant vga_switcheroo cleanup in failed: label.

Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 28 ++
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b4ad1c055c70..7d3b54615147 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3410,19 +3410,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* doorbell bar mapping and doorbell index init*/

[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(>dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, _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(>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(_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(_priv->runtime_pm);
 
return 0;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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(>dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, _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(>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(_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(_priv->runtime_pm);
 
return 0;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Register VGA clients after init can no longer fail

[Kai-Heng Feng]

When an amdgpu device fails to init, it makes another VGA device cause
kernel splat:
kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
kernel: amdgpu: probe of :08:00.0 failed with error -110
...
kernel: amdgpu :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=none
kernel: BUG: kernel NULL pointer dereference, address: 0018
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops:  [#1] SMP NOPTI
kernel: CPU: 6 PID: 1080 Comm: Xorg Tainted: GW 5.12.0-rc8+ #12
kernel: Hardware name: HP HP EliteDesk 805 G6/872B, BIOS S09 Ver. 02.02.00 
12/30/2020
kernel: RIP: 0010:amdgpu_device_vga_set_decode+0x13/0x30 [amdgpu]
kernel: Code: 06 31 c0 c3 b8 ea ff ff ff 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 
90 0f 1f 44 00 00 55 48 8b 87 90 06 00 00 48 89 e5 53 89 f3 <48> 8b 40 18 40 0f 
b6 f6 e8 40 58 39 fd 80 fb 01 5b 5d 19 c0 83 e0
kernel: RSP: 0018:ae3c0246bd68 EFLAGS: 00010002
kernel: RAX:  RBX:  RCX: 
kernel: RDX: 8dd1af5a8560 RSI:  RDI: 8dce8c16
kernel: RBP: ae3c0246bd70 R08: 8dd1af5985c0 R09: ae3c0246ba38
kernel: R10: 0001 R11: 0001 R12: 0246
kernel: R13:  R14: 0003 R15: 8dce8149
kernel: FS:  7f9303d8fa40() GS:8dd1af58() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 0018 CR3: 000103cfa000 CR4: 00350ee0
kernel: Call Trace:
kernel:  vga_arbiter_notify_clients.part.0+0x4a/0x80
kernel:  vga_get+0x17f/0x1c0
kernel:  vga_arb_write+0x121/0x6a0
kernel:  ? apparmor_file_permission+0x1c/0x20
kernel:  ? security_file_permission+0x30/0x180
kernel:  vfs_write+0xca/0x280
kernel:  ksys_write+0x67/0xe0
kernel:  __x64_sys_write+0x1a/0x20
kernel:  do_syscall_64+0x38/0x90
kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
kernel: RIP: 0033:0x7f93041e02f7
kernel: Code: 75 05 48 83 c4 58 c3 e8 f7 33 ff ff 0f 1f 80 00 00 00 00 f3 0f 1e 
fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 
77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
kernel: RSP: 002b:7fff60e49b28 EFLAGS: 0246 ORIG_RAX: 0001
kernel: RAX: ffda RBX: 000b RCX: 7f93041e02f7
kernel: RDX: 000b RSI: 7fff60e49b40 RDI: 000f
kernel: RBP: 7fff60e49b40 R08:  R09: 7fff60e499d0
kernel: R10: 7f93049350b5 R11: 0246 R12: 56111d45e808
kernel: R13:  R14: 56111d45e7f8 R15: 56111d46c980
kernel: Modules linked in: nls_iso8859_1 snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel 
snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq 
input_leds snd_seq_device snd_timer snd soundcore joydev kvm_amd serio_raw 
k10temp mac_hid hp_wmi ccp kvm sparse_keymap wmi_bmof ucsi_acpi efi_pstore 
typec_ucsi rapl typec video wmi sch_fq_codel parport_pc ppdev lp parport 
ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor 
raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log 
hid_generic usbhid hid amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched 
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt 
crc32_pclmul fb_sys_fops ghash_clmulni_intel cec rc_core aesni_intel 
crypto_simd psmouse cryptd r8169 i2c_piix4 drm ahci xhci_pci realtek libahci 
xhci_pci_renesas gpio_amdpt gpio_generic
kernel: CR2: 0018
kernel: ---[ end trace 76d04313d4214c51 ]---

Commit 4192f7b57689 ("drm/amdgpu: unmap register bar on device init
failure") makes amdgpu_driver_unload_kms() skips amdgpu_device_fini(),
so the VGA clients remain registered. So when
vga_arbiter_notify_clients() iterates over registered clients, it causes
NULL pointer dereference.

Since there's no reason to register VGA clients that early, so solve
the issue by putting them after all the goto cleanups.

Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++---
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b4ad1c055c70..115a7699e11e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3410,19 +3410,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* doorbell bar mapping and doorbell index init*/
amdgpu_device_doorbell_init(adev);
 
-   /* if we have > 1 VGA cards, th

[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 = 
_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, 
);
-   else
-   /* Optimize for slow and wide. */
-   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, 
);
+   /*
+* 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, );
 
/* enable compression if the mode doesn't fit available BW */
drm_dbg_kms(>drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efifb: Fix runtime pm calls for non PCI efifb device

[Kai-Heng Feng]

Hi Sudeep,

On Tue, Apr 20, 2021 at 3:53 PM Sudeep Holla  wrote:
>
> Gentle Ping! There is boot failure because of this issue with linux-next
> on few arm platforms with non PCIe efifb. Please review and get the fix
> merged ASAP so the testing on these platforms can continue with linux-next.

It was merged in drm-tip as d510c88cfbb2 ("efifb: Check efifb_pci_dev
before using it").

Kai-Heng

>
> On Thu, Apr 15, 2021 at 11:22:24AM +0100, Sudeep Holla wrote:
> > Commit a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI 
> > D0")
> > added runtime pm calls to probe and remove routines to ensure the PCI
> > device for efifb stays in D0 state. However not ever efifb is based on
> > PCI device and efifb_pci_dev can be NULL if that is the case.
> >
> > In such cases, we will get a boot splat like below due to NULL dereference:
> > -->8
> >  Console: switching to colour frame buffer device 240x67
> >  fb0: EFI VGA frame buffer device
> >  Unable to handle kernel NULL pointer dereference at virtual address 
> > 0270
> >  Mem abort info:
> >ESR = 0x9604
> >EC = 0x25: DABT (current EL), IL = 32 bits
> >SET = 0, FnV = 0
> >EA = 0, S1PTW = 0
> >  Data abort info:
> >ISV = 0, ISS = 0x0004
> >CM = 0, WnR = 0
> >  [0270] user address but active_mm is swapper
> >  Internal error: Oops: 9604 [#1] PREEMPT SMP
> >  Modules linked in:
> >  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc7-next-20210413 #1
> >  Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development 
> > Platform
> >  pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> >  pc : pm_runtime_drop_link+0x12c/0x338
> >  lr : efifb_probe+0x7bc/0x7f0
> >  Call trace:
> >   pm_runtime_drop_link+0x12c/0x338
> >   efifb_probe+0x7bc/0x7f0
> >   platform_probe+0x68/0xd8
> >   really_probe+0xe4/0x3a8
> >   driver_probe_device+0x64/0xc8
> >   device_driver_attach+0x74/0x80
> >   __driver_attach+0x64/0xf0
> >   bus_for_each_dev+0x70/0xc0
> >   driver_attach+0x24/0x30
> >   bus_add_driver+0x150/0x1f8
> >   driver_register+0x64/0x120
> >   __platform_driver_register+0x28/0x38
> >   efifb_driver_init+0x1c/0x28
> >   do_one_initcall+0x48/0x2b0
> >   kernel_init_freeable+0x1e8/0x258
> >   kernel_init+0x14/0x118
> >   ret_from_fork+0x10/0x30
> >  Code: 88027c01 35a2 17fff706 f9800051 (885f7c40)
> >  ---[ end trace 17d8da630bf8ff77 ]---
> >  Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> > -->8
> >
> > Fix the issue by checking for non-NULL efifb_pci_dev before dereferencing
> > for runtime pm calls in probe and remove routines.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI 
> > D0")
> > Cc: Kai-Heng Feng 
> > Cc: Alex Deucher 
> > Cc: Thomas Zimmermann 
> > Cc: Peter Jones 
> > Signed-off-by: Sudeep Holla 
> > ---
> >  drivers/video/fbdev/efifb.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index f58a545b3bf3..8ea8f079cde2 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
> >   goto err_fb_dealoc;
> >   }
> >   fb_info(info, "%s frame buffer device\n", info->fix.id);
> > - pm_runtime_get_sync(_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_get_sync(_pci_dev->dev);
> >   return 0;
> >
> >  err_fb_dealoc:
> > @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
> >   unregister_framebuffer(info);
> >   sysfs_remove_groups(>dev.kobj, efifb_groups);
> >   framebuffer_release(info);
> > - pm_runtime_put(_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_put(_pci_dev->dev);
> >
> >   return 0;
> >  }
> > --
> > 2.25.1
> >
>
> --
> Regards,
> Sudeep
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] efifb: Check efifb_pci_dev before using it

[Kai-Heng Feng]

On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
a PCI device.

So make sure efifb_pci_dev is found before using it.

Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0")
BugLink: https://bugs.launchpad.net/bugs/1922403
Signed-off-by: Kai-Heng Feng 
---
 drivers/video/fbdev/efifb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index f58a545b3bf3..8ea8f079cde2 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
-   pm_runtime_get_sync(_pci_dev->dev);
+   if (efifb_pci_dev)
+   pm_runtime_get_sync(_pci_dev->dev);
return 0;
 
 err_fb_dealoc:
@@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
sysfs_remove_groups(>dev.kobj, efifb_groups);
framebuffer_release(info);
-   pm_runtime_put(_pci_dev->dev);
+   if (efifb_pci_dev)
+   pm_runtime_put(_pci_dev->dev);
 
return 0;
 }
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efifb: Ensure graphics device for efifb stays at PCI D0

[Kai-Heng Feng]

On Mon, Feb 1, 2021 at 11:21 PM Alex Deucher  wrote:
>
> On Sat, Jan 30, 2021 at 6:27 AM Kai-Heng Feng
>  wrote:
> >
> > We are seeing root ports on some desktop boards support D3cold for
> > discrete graphics card. So when efifb is in use while graphics device
> > isn't bound to a driver, PCI and ACPI will put the graphics to D3cold
> > when runtime suspend kicks in, makes efifb stop working.
> >
> > So ensure the graphics device won't be runtime suspended, to keep efifb
> > work all the time.
> >
> > Signed-off-by: Kai-Heng Feng 
>
> Reviewed-by: Alex Deucher 

A gentle ping...

>
> > ---
> >  drivers/video/fbdev/efifb.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index e57c00824965..19edd7206409 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include  /* For drm_get_panel_orientation_quirk */
> > @@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev)
> > goto err_fb_dealoc;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > +   pm_runtime_get_sync(_pci_dev->dev);
> > return 0;
> >
> >  err_fb_dealoc:
> > @@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev)
> > unregister_framebuffer(info);
> > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > framebuffer_release(info);
> > +   pm_runtime_put(_pci_dev->dev);
> >
> > return 0;
> >  }
> > --
> > 2.29.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] efifb: Ensure graphics device for efifb stays at PCI D0

[Kai-Heng Feng]

We are seeing root ports on some desktop boards support D3cold for
discrete graphics card. So when efifb is in use while graphics device
isn't bound to a driver, PCI and ACPI will put the graphics to D3cold
when runtime suspend kicks in, makes efifb stop working.

So ensure the graphics device won't be runtime suspended, to keep efifb
work all the time.

Signed-off-by: Kai-Heng Feng 
---
 drivers/video/fbdev/efifb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index e57c00824965..19edd7206409 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* For drm_get_panel_orientation_quirk */
@@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev)
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
+   pm_runtime_get_sync(_pci_dev->dev);
return 0;
 
 err_fb_dealoc:
@@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
sysfs_remove_groups(>dev.kobj, efifb_groups);
framebuffer_release(info);
+   pm_runtime_put(_pci_dev->dev);
 
return 0;
 }
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 = _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(_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(_dp->desc, intel_dp->edid_quirks,
>> -  DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
>> +i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
>>  drm_info(>drm,
>>   "Panel advertises DPCD backlight support, but "
>>   "VBT disagrees. If your backlight controls "
> -- 
> Sincerely,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 = _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(_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(_dp->desc, intel_dp->edid_quirks,
- DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
+   i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
drm_info(>drm,
 "Panel advertises DPCD backlight support, but "
 "VBT disagrees. If your backlight controls "
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100

[Kai-Heng Feng]

> On Apr 8, 2020, at 15:22, Jani Nikula  wrote:
> 
> On Tue, 07 Apr 2020, Kai-Heng Feng  wrote:
>>> On Mar 27, 2020, at 19:03, Kai-Heng Feng  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>>> On Mar 23, 2020, at 13:35, Kai-Heng Feng  
>>>> wrote:
>>>> 
>>>> There's another OLED panel needs to use DPCD aux interface to control
>>>> backlight.
>>>> 
>>>> BugLink: https://bugs.launchpad.net/bugs/1860303
>>>> Signed-off-by: Kai-Heng Feng 
>>> 
>>> Would it be possible to review this?
>>> I'd like to send a similar quirk for a new panel, and I want to avoid 
>>> causing any merge conflict.
>> 
>> Another gentle ping...
> 
> Can't really review, but if you say that's needed...
> 
> Acked-by: Jani Nikula 

David, 

Can you please merge this patch? Thanks.

Kai-Heng

> 
>> 
>>> 
>>> Kai-Heng
>>> 
>>>> ---
>>>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>> 
>>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>>>> b/drivers/gpu/drm/drm_dp_helper.c
>>>> index 8ba4531e808d..a0d4314663de 100644
>>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>>> @@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>>>> * only supports DPCD backlight controls
>>>> */
>>>>{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
>>>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>>>> +  /* HP Spectre x360 Convertible 13t-aw100 */
>>>> +  { MFG(0x4c, 0x83), PROD_ID(0x42, 0x41), 
>>>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>>>>/*
>>>> * Some Dell CML 2020 systems have panels support both AUX and PWM
>>>> * backlight control, and some only support AUX backlight control. All
>>>> -- 
>>>> 2.17.1
>>>> 
>>> 
>> 
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/dp: HP DreamColor panel brigntness fix

[Kai-Heng Feng]

HP DreamColor panel, which is used by new HP ZBook Studio, needs to use
DPCD to control brightness.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_dp_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 092c8c985911..b3d0ea1b082b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1321,6 +1321,7 @@ static const struct edid_quirk edid_quirk_list[] = {
 */
{ MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   { MFG(0x30, 0xe4), PROD_ID(0x61, 0x06), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Force DPCD backlight mode for HP CML 2020 system

[Kai-Heng Feng]

> On Apr 8, 2020, at 15:23, Jani Nikula  wrote:
> 
> On Tue, 07 Apr 2020, Kai-Heng Feng  wrote:
>> There's another Samsung OLED panel needs to use DPCD aux interface to
>> control backlight.
> 
> Acked-by: Jani Nikula 

David, 

Can you please merge this patch? Thanks.

Kai-Heng

> 
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index c6fbe6e6bc9d..d0cfee3b7a65 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1299,6 +1299,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>>   * only supports DPCD backlight controls
>>   */
>>  { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>> +/* HP CML 2020 system */
>> +{ MFG(0x4c, 0x83), PROD_ID(0x45, 0x41), 
>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>>  /*
>>   * Some Dell CML 2020 systems have panels support both AUX and PWM
>>   * backlight control, and some only support AUX backlight control. All
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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(_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(_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(_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
>>

Re: [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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware

[Kai-Heng Feng]

> On Sep 2, 2020, at 00:30, Alex Deucher  wrote:
> 
> On Tue, Sep 1, 2020 at 12:21 PM Kai-Heng Feng
>  wrote:
>> 
>> 
>> 
>>> On Sep 1, 2020, at 22:19, Alex Deucher  wrote:
>>> 
>>> On Tue, Sep 1, 2020 at 3:32 AM Kai-Heng Feng
>>>  wrote:
>>>> 
>>>> Suspend with s2idle or by the following steps cause screen frozen:
>>>> # echo devices > /sys/power/pm_test
>>>> # echo freeze > /sys/power/mem
>>>> 
>>>> [  289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait 
>>>> timed out.
>>>> [  289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed 
>>>> testing IB on ring 5 (-110).
>>>> 
>>>> The issue doesn't happen on traditional S3, probably because firmware or
>>>> hardware provides extra power management.
>>>> 
>>>> Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
>>>> can fix the issue.
>>> 
>>> It doesn't actually fix the issue.  The device is never powered down
>>> so you are using more power than you would if you did not suspend in
>>> the first place.  The reset just works around the fact that the device
>>> is never powered down.
>> 
>> So how do we properly suspend/resume the device without help from platform 
>> firmware?
> 
> I guess you don't?

Unfortunate but I guess we need to accept reality and use the default suspend 
method.

Kai-Heng

> 
> Alex
> 
> 
>> 
>> Kai-Heng
>> 
>>> 
>>> Alex
>>> 
>>>> 
>>>> [1] https://patchwork.freedesktop.org/patch/335839/
>>>> 
>>>> Signed-off-by: Kai-Heng Feng 
>>>> ---
>>>> drivers/gpu/drm/radeon/radeon_device.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>> 
>>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
>>>> b/drivers/gpu/drm/radeon/radeon_device.c
>>>> index 266e3cbbd09b..df823b9ad79f 100644
>>>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>>>> @@ -33,6 +33,7 @@
>>>> #include 
>>>> #include 
>>>> #include 
>>>> +#include 
>>>> 
>>>> #include 
>>>> #include 
>>>> @@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
>>>> suspend,
>>>>   rdev->asic->asic_reset(rdev, true);
>>>>   pci_restore_state(dev->pdev);
>>>>   } else if (suspend) {
>>>> +   if (pm_suspend_no_platform())
>>>> +   rdev->asic->asic_reset(rdev, true);
>>>>   /* Shut down the device */
>>>>   pci_disable_device(dev->pdev);
>>>>   pci_set_power_state(dev->pdev, PCI_D3hot);
>>>> --
>>>> 2.17.1
>>>> 
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware

[Kai-Heng Feng]

> On Sep 1, 2020, at 22:19, Alex Deucher  wrote:
> 
> On Tue, Sep 1, 2020 at 3:32 AM Kai-Heng Feng
>  wrote:
>> 
>> Suspend with s2idle or by the following steps cause screen frozen:
>> # echo devices > /sys/power/pm_test
>> # echo freeze > /sys/power/mem
>> 
>> [  289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait 
>> timed out.
>> [  289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed 
>> testing IB on ring 5 (-110).
>> 
>> The issue doesn't happen on traditional S3, probably because firmware or
>> hardware provides extra power management.
>> 
>> Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
>> can fix the issue.
> 
> It doesn't actually fix the issue.  The device is never powered down
> so you are using more power than you would if you did not suspend in
> the first place.  The reset just works around the fact that the device
> is never powered down.

So how do we properly suspend/resume the device without help from platform 
firmware?

Kai-Heng

> 
> Alex
> 
>> 
>> [1] https://patchwork.freedesktop.org/patch/335839/
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/radeon/radeon_device.c | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 266e3cbbd09b..df823b9ad79f 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -33,6 +33,7 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> 
>> #include 
>> #include 
>> @@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
>> suspend,
>>rdev->asic->asic_reset(rdev, true);
>>pci_restore_state(dev->pdev);
>>} else if (suspend) {
>> +   if (pm_suspend_no_platform())
>> +   rdev->asic->asic_reset(rdev, true);
>>/* Shut down the device */
>>pci_disable_device(dev->pdev);
>>pci_set_power_state(dev->pdev, PCI_D3hot);
>> --
>> 2.17.1
>> 
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Reset ASIC if suspend is not managed by platform firmware

[Kai-Heng Feng]

Suspend with s2idle or by the following steps cause screen frozen:
 # echo devices > /sys/power/pm_test
 # echo freeze > /sys/power/mem

[  289.625461] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait timed 
out.
[  289.625494] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed 
testing IB on ring 5 (-110).

The issue doesn't happen on traditional S3, probably because firmware or
hardware provides extra power management.

Inspired by Daniel Drake's patch [1] on amdgpu, using a similar approach
can fix the issue.

[1] https://patchwork.freedesktop.org/patch/335839/

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/radeon/radeon_device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09b..df823b9ad79f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1643,6 +1644,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend,
rdev->asic->asic_reset(rdev, true);
pci_restore_state(dev->pdev);
} else if (suspend) {
+   if (pm_suspend_no_platform())
+   rdev->asic->asic_reset(rdev, true);
/* Shut down the device */
pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Prefer lower feedback dividers

[Kai-Heng Feng]

Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
fixed screen flicker for HP Compaq nx9420 but breaks other laptops like
Asus X50SL.

Turns out we also need to favor lower feedback dividers.

Users confirmed this change fixes the regression and doesn't regress the
original fix.

Fixes: 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
BugLink: https://bugs.launchpad.net/bugs/1791312
BugLink: https://bugs.launchpad.net/bugs/1861554
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/radeon/radeon_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index e0ae911ef427..7b69d6dfe44a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -933,7 +933,7 @@ static void avivo_get_fb_ref_div(unsigned nom, unsigned 
den, unsigned post_div,
 
/* get matching reference and feedback divider */
*ref_div = min(max(den/post_div, 1u), ref_div_max);
-   *fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den);
+   *fb_div = max(nom * *ref_div * post_div / den, 1u);
 
/* limit fb divider to its maximum */
if (*fb_div > fb_div_max) {
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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(_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(_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(_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)
>> -

Re: [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(_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(_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(_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);
> +   

[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(_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(_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(_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 100644
--- a/drivers/gpu/drm/i915/di

Re: [PATCH v5] drm/i915: Init lspcon chip dynamically

[Kai-Heng Feng]

> On May 6, 2020, at 18:28, 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.
> 
> 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 

A gentle ping...

> ---
> 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(_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(_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(_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;
> 

[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(_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(_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(_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/intel_hdmi.c
@@ -3155,7 +3155,8 @@ void int

[PATCH 1/1] drm/nouveau: Use generic helper to check _PR3 presence

[Kai-Heng Feng]

Replace nouveau_pr3_present() in favor of a more generic one,
pci_pr3_present().

Also the presence of upstream bridge _PR3 doesn't need to go hand in
hand with device's _DSM, so check _PR3 before _DSM.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 44 ++
 1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index fe3a10255c36..b84dff1b0f28 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -212,37 +212,6 @@ static const struct vga_switcheroo_handler 
nouveau_dsm_handler = {
.get_client_id = nouveau_dsm_get_client_id,
 };
 
-/*
- * Firmware supporting Windows 8 or later do not use _DSM to put the device 
into
- * D3cold, they instead rely on disabling power resources on the parent.
- */
-static bool nouveau_pr3_present(struct pci_dev *pdev)
-{
-   struct pci_dev *parent_pdev = pci_upstream_bridge(pdev);
-   struct acpi_device *parent_adev;
-
-   if (!parent_pdev)
-   return false;
-
-   if (!parent_pdev->bridge_d3) {
-   /*
-* Parent PCI bridge is currently not power managed.
-* Since userspace can change these afterwards to be on
-* the safe side we stick with _DSM and prevent usage of
-* _PR3 from the bridge.
-*/
-   pci_d3cold_disable(pdev);
-   return false;
-   }
-
-   parent_adev = ACPI_COMPANION(_pdev->dev);
-   if (!parent_adev)
-   return false;
-
-   return parent_adev->power.flags.power_resources &&
-   acpi_has_method(parent_adev->handle, "_PR3");
-}
-
 static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle 
*dhandle_out,
  bool *has_mux, bool *has_opt,
  bool *has_opt_flags, bool *has_pr3)
@@ -250,6 +219,16 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev, 
acpi_handle *dhandle_out
acpi_handle dhandle;
bool supports_mux;
int optimus_funcs;
+   struct pci_dev *parent_pdev;
+
+   *has_pr3 = false;
+   parent_pdev = pci_upstream_bridge(pdev);
+   if (parent_pdev) {
+   if (parent_pdev->bridge_d3)
+   *has_pr3 = pci_pr3_present(parent_pdev);
+   else
+   pci_d3cold_disable(pdev);
+   }
 
dhandle = ACPI_HANDLE(>dev);
if (!dhandle)
@@ -270,7 +249,6 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev, 
acpi_handle *dhandle_out
*has_mux = supports_mux;
*has_opt = !!optimus_funcs;
*has_opt_flags = optimus_funcs & (1 << NOUVEAU_DSM_OPTIMUS_FLAGS);
-   *has_pr3 = false;
 
if (optimus_funcs) {
uint32_t result;
@@ -280,8 +258,6 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev, 
acpi_handle *dhandle_out
 (result & OPTIMUS_ENABLED) ? "enabled" : "disabled",
 (result & OPTIMUS_DYNAMIC_PWR_CAP) ? "dynamic power, " 
: "",
 (result & OPTIMUS_HDA_CODEC_MASK) ? "hda bios codec 
supported" : "");
-
-   *has_pr3 = nouveau_pr3_present(pdev);
}
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Force DPCD backlight mode for HP CML 2020 system

[Kai-Heng Feng]

There's another Samsung OLED panel needs to use DPCD aux interface to
control backlight.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c6fbe6e6bc9d..d0cfee3b7a65 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1299,6 +1299,8 @@ static const struct edid_quirk edid_quirk_list[] = {
 * only supports DPCD backlight controls
 */
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   /* HP CML 2020 system */
+   { MFG(0x4c, 0x83), PROD_ID(0x45, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
/*
 * Some Dell CML 2020 systems have panels support both AUX and PWM
 * backlight control, and some only support AUX backlight control. All
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100

[Kai-Heng Feng]

> On Mar 27, 2020, at 19:03, Kai-Heng Feng  wrote:
> 
> Hi,
> 
>> On Mar 23, 2020, at 13:35, Kai-Heng Feng  wrote:
>> 
>> There's another OLED panel needs to use DPCD aux interface to control
>> backlight.
>> 
>> BugLink: https://bugs.launchpad.net/bugs/1860303
>> Signed-off-by: Kai-Heng Feng 
> 
> Would it be possible to review this?
> I'd like to send a similar quirk for a new panel, and I want to avoid causing 
> any merge conflict.

Another gentle ping...

> 
> Kai-Heng
> 
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 8ba4531e808d..a0d4314663de 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>>   * only supports DPCD backlight controls
>>   */
>>  { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>> +/* HP Spectre x360 Convertible 13t-aw100 */
>> +{ MFG(0x4c, 0x83), PROD_ID(0x42, 0x41), 
>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>>  /*
>>   * Some Dell CML 2020 systems have panels support both AUX and PWM
>>   * backlight control, and some only support AUX backlight control. All
>> -- 
>> 2.17.1
>> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100

[Kai-Heng Feng]

Hi,

> On Mar 23, 2020, at 13:35, Kai-Heng Feng  wrote:
> 
> There's another OLED panel needs to use DPCD aux interface to control
> backlight.
> 
> BugLink: https://bugs.launchpad.net/bugs/1860303
> Signed-off-by: Kai-Heng Feng 

Would it be possible to review this?
I'd like to send a similar quirk for a new panel, and I want to avoid causing 
any merge conflict.

Kai-Heng

> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8ba4531e808d..a0d4314663de 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>* only supports DPCD backlight controls
>*/
>   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> + /* HP Spectre x360 Convertible 13t-aw100 */
> + { MFG(0x4c, 0x83), PROD_ID(0x42, 0x41), 
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>   /*
>* Some Dell CML 2020 systems have panels support both AUX and PWM
>* backlight control, and some only support AUX backlight control. All
> -- 
> 2.17.1
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100

[Kai-Heng Feng]

There's another OLED panel needs to use DPCD aux interface to control
backlight.

BugLink: https://bugs.launchpad.net/bugs/1860303
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8ba4531e808d..a0d4314663de 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
 * only supports DPCD backlight controls
 */
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+   /* HP Spectre x360 Convertible 13t-aw100 */
+   { MFG(0x4c, 0x83), PROD_ID(0x42, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
/*
 * Some Dell CML 2020 systems have panels support both AUX and PWM
 * backlight control, and some only support AUX backlight control. All
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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)
>   _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->s

[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)
_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;
intel_dig_port->set_infof

Re: [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 = _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
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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(>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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 = _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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 = _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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 = _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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50

[Kai-Heng Feng]

> On Jun 6, 2019, at 16:04, Kai-Heng Feng  wrote:
> 
> Hi,
> 
> at 11:30, Kai-Heng Feng  wrote:
> 
>> Another panel that needs 6BPC quirk.
> 
> Please include this patch if possible.

Another gentle ping.

> 
> Kai-Heng
> 
>> 
>> BugLink: https://bugs.launchpad.net/bugs/1819968
>> Cc:  # v4.8+
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/drm_edid.c | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 990b1909f9d7..1cb4d0052efe 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -166,6 +166,9 @@ static const struct edid_quirk {
>>  /* Medion MD 30217 PG */
>>  { "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
>> 
>> +/* Lenovo G50 */
>> +{ "SDC", 18514, EDID_QUIRK_FORCE_6BPC },
>> +
>>  /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
>>  { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
>> 
>> -- 
>> 2.17.1
> 
> 

[PATCH] drm/amd/display: Restore backlight brightness after system resume

[Kai-Heng Feng]

Laptops with AMD APU doesn't restore display backlight brightness after
system resume.

This issue started when DC was introduced.

Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
update_status callback after system resume to restore the backlight
level.

Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495
(Raven Ridge).

Cc: 
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1b0949dd7808..183ef18ac6f3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2111,6 +2111,7 @@ static int amdgpu_dm_backlight_get_brightness(struct 
backlight_device *bd)
 }
 
 static const struct backlight_ops amdgpu_dm_backlight_ops = {
+   .options = BL_CORE_SUSPENDRESUME,
.get_brightness = amdgpu_dm_backlight_get_brightness,
.update_status  = amdgpu_dm_backlight_update_status,
 };
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Add APTX quirk for Dell Latitude 5495

[Kai-Heng Feng]

Needs ATPX rather than _PR3 to really turn off the dGPU. This can save
~5W when dGPU is runtime-suspended.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index 92b11de19581..354c8b6106dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -575,6 +575,7 @@ static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] 
= {
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
+   { 0x1002, 0x699f, 0x1028, 0x0814, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1025, 0x125A, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x17AA, 0x3806, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Apply flags after amdgpu_device_ip_init()

[Kai-Heng Feng]

at 21:33, Deucher, Alexander  wrote:

Thanks for finding this!  I think the attached patch should fix the issue  
and it's much less invasive.


Yes it also fix the issue, please add by tested-by:
Tested-by: Kai-Heng Feng 

I took this more or less future proof approach because I think this won’t  
be the last chip that needs firmware information, which isn’t available in  
early init, to decides its flags.


Yes it’s intrusive to carve out all flags from early init callbacks, but I  
don’t think it’s that ugly.


Kai-Heng



Alex
From: Kai-Heng Feng 
Sent: Thursday, August 15, 2019 1:11 AM
To: Deucher, Alexander ; Koenig, Christian  
; Zhou, David(ChunMing) 
Cc: Huang, Ray ; anthony.w...@canonical.com  
; amd-...@lists.freedesktop.org  
; dri-devel@lists.freedesktop.org  
; linux-ker...@vger.kernel.org  
; Kai-Heng Feng  


Subject: [PATCH] drm/amdgpu: Apply flags after amdgpu_device_ip_init()

After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven
series (v2)"), some Raven Ridge systems start to have rendering
corruption in browser [1].

Chip specific flags like cg_flags and pg_flags are applied in
amdgpu_device_ip_early_init(). For Raven Ridge, the flags may depend on
pp_feature's PP_GFXOFF_MASK bit, which can be negated in
amdgpu_device_ip_init() based on firmware information. At that time it's
already too late, since cg_flags and pg_flags are already set.

Apply flags after amdgpu_device_ip_init() and consolidate all flags to
one place, to solve the issue.

[1]  
https://lore.kernel.org/lkml/3eb0e920-31d7-4c91-a360-dbfb4417a...@canonical.com/


Fixes: 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series  
(v2)")

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 589 +
 drivers/gpu/drm/amd/amdgpu/cik.c   |  87 ---
 drivers/gpu/drm/amd/amdgpu/nv.c|  50 --
 drivers/gpu/drm/amd/amdgpu/si.c|  83 ---
 drivers/gpu/drm/amd/amdgpu/soc15.c | 140 -
 drivers/gpu/drm/amd/amdgpu/vi.c| 162 --
 6 files changed, 589 insertions(+), 522 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 275277364a8a..10ea4899c338 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1852,6 +1852,591 @@ static int amdgpu_device_ip_init(struct  
amdgpu_device *adev)

 return r;
 }

+#define CZ_REV_BRISTOL(rev) \
+   ((rev >= 0xC8 && rev <= 0xCE) || (rev >= 0xE1 && rev <= 0xE6))
+
+static int amdgpu_device_apply_flags(struct amdgpu_device *adev)
+{
+   switch (adev->asic_type) {
+   case CHIP_TAHITI:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   /*AMD_CG_SUPPORT_GFX_CGCG |*/
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_BIF_LS |
+   AMD_CG_SUPPORT_VCE_MGCG |
+   AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_HDP_LS |
+   AMD_CG_SUPPORT_HDP_MGCG;
+   adev->pg_flags = 0;
+   break;
+   case CHIP_PITCAIRN:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   /*AMD_CG_SUPPORT_GFX_CGCG |*/
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_GFX_RLC_LS |
+   AMD_CG_SUPPORT_MC_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_BIF_LS |
+   AMD_CG_SUPPORT_VCE_MGCG |
+   AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_HDP_LS |
+   AMD_CG_SUPPORT_HDP_MGCG;
+   adev->pg_flags = 0;
+   break;
+   case CHIP_VERDE:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CGTS_LS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_MC_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_SDMA_LS |
+   AMD_C

[PATCH] drm/amdgpu: Apply flags after amdgpu_device_ip_init()

[Kai-Heng Feng]

After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven
series (v2)"), some Raven Ridge systems start to have rendering
corruption in browser [1].

Chip specific flags like cg_flags and pg_flags are applied in
amdgpu_device_ip_early_init(). For Raven Ridge, the flags may depend on
pp_feature's PP_GFXOFF_MASK bit, which can be negated in
amdgpu_device_ip_init() based on firmware information. At that time it's
already too late, since cg_flags and pg_flags are already set.

Apply flags after amdgpu_device_ip_init() and consolidate all flags to
one place, to solve the issue.

[1] 
https://lore.kernel.org/lkml/3eb0e920-31d7-4c91-a360-dbfb4417a...@canonical.com/

Fixes: 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series (v2)")
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 589 +
 drivers/gpu/drm/amd/amdgpu/cik.c   |  87 ---
 drivers/gpu/drm/amd/amdgpu/nv.c|  50 --
 drivers/gpu/drm/amd/amdgpu/si.c|  83 ---
 drivers/gpu/drm/amd/amdgpu/soc15.c | 140 -
 drivers/gpu/drm/amd/amdgpu/vi.c| 162 --
 6 files changed, 589 insertions(+), 522 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 275277364a8a..10ea4899c338 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1852,6 +1852,591 @@ static int amdgpu_device_ip_init(struct amdgpu_device 
*adev)
return r;
 }
 
+#define CZ_REV_BRISTOL(rev) \
+   ((rev >= 0xC8 && rev <= 0xCE) || (rev >= 0xE1 && rev <= 0xE6))
+
+static int amdgpu_device_apply_flags(struct amdgpu_device *adev)
+{
+   switch (adev->asic_type) {
+   case CHIP_TAHITI:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   /*AMD_CG_SUPPORT_GFX_CGCG |*/
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_BIF_LS |
+   AMD_CG_SUPPORT_VCE_MGCG |
+   AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_HDP_LS |
+   AMD_CG_SUPPORT_HDP_MGCG;
+   adev->pg_flags = 0;
+   break;
+   case CHIP_PITCAIRN:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   /*AMD_CG_SUPPORT_GFX_CGCG |*/
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_GFX_RLC_LS |
+   AMD_CG_SUPPORT_MC_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_BIF_LS |
+   AMD_CG_SUPPORT_VCE_MGCG |
+   AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_HDP_LS |
+   AMD_CG_SUPPORT_HDP_MGCG;
+   adev->pg_flags = 0;
+   break;
+   case CHIP_VERDE:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CGTS_LS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_MC_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_SDMA_LS |
+   AMD_CG_SUPPORT_BIF_LS |
+   AMD_CG_SUPPORT_VCE_MGCG |
+   AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_HDP_LS |
+   AMD_CG_SUPPORT_HDP_MGCG;
+   adev->pg_flags = 0;
+   //???
+   break;
+   case CHIP_OLAND:
+   adev->cg_flags =
+   AMD_CG_SUPPORT_GFX_MGCG |
+   AMD_CG_SUPPORT_GFX_MGLS |
+   /*AMD_CG_SUPPORT_GFX_CGCG |*/
+   AMD_CG_SUPPORT_GFX_CGLS |
+   AMD_CG_SUPPORT_GFX_CGTS |
+   AMD_CG_SUPPORT_GFX_CP_LS |
+   AMD_CG_SUPPORT_GFX_RLC_LS |
+   AMD_CG_SUPPORT_MC_LS |
+   AMD_CG_SUPPORT_MC_MGCG |
+   AMD_CG_SUPPORT_SDMA_MGCG |
+   AMD_CG_SUPPORT_BIF_LS |
+  

[Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"

[Kai-Heng Feng]

Hi,

After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series  
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:

https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png

Firmwares for Raven Ridge is up-to-date.

Kai-Heng
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"

[Kai-Heng Feng]

at 14:29, Huang, Ray  wrote:


-Original Message-
From: Kai-Heng Feng 
Sent: Thursday, August 08, 2019 1:45 AM
To: Huang, Ray 
Cc: Deucher, Alexander ; Koenig, Christian
; Zhou, David(ChunMing)
; amd-gfx list ;
dri-devel@lists.freedesktop.org; LKML ;
Anthony Wong 
Subject: Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series
(v2)"

Hi Ray,

at 00:03, Huang, Ray  wrote:


May I know the all firmware version in your system?


Seems to the issue we encountered with IOMMU enabled. Could you please  
disable iommu in SBIOS or GRUB?


Yes, "amd_iommu=off" can workaround the issue.

Kai-Heng



Thanks,
Ray


# cat amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 40, firmware version: 0x0099
PFP feature version: 40, firmware version: 0x00ae
CE feature version: 40, firmware version: 0x004d
RLC feature version: 1, firmware version: 0x0213
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 40, firmware version: 0x018b
MEC2 feature version: 40, firmware version: 0x018b
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x001ad4d4
TA XGMI feature version: 0, firmware version: 0x
TA RAS feature version: 0, firmware version: 0x
SMC feature version: 0, firmware version: 0x1e44
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x0110901c
DMCU feature version: 0, firmware version: 0x
VBIOS version: 113-RAVEN-103

Kai-Heng


Thanks,
Ray

From: Kai-Heng Feng 
Sent: Wednesday, August 7, 2019 8:50 PM
To: Huang, Ray
Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); amd-

gfx

list; dri-devel@lists.freedesktop.org; LKML; Anthony Wong
Subject: [Regression] "drm/amdgpu: enable gfxoff again on raven series
(v2)"

Hi,

After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven

series
(v2)”), browsers on Raven Ridge systems cause serious corruption like  
this:

https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-

08-07%2004-20-34.png

Firmwares for Raven Ridge is up-to-date.

Kai-Heng



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"

[Kai-Heng Feng]

Hi Ray,

at 00:03, Huang, Ray  wrote:


May I know the all firmware version in your system?


# cat amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 40, firmware version: 0x0099
PFP feature version: 40, firmware version: 0x00ae
CE feature version: 40, firmware version: 0x004d
RLC feature version: 1, firmware version: 0x0213
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 40, firmware version: 0x018b
MEC2 feature version: 40, firmware version: 0x018b
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x001ad4d4
TA XGMI feature version: 0, firmware version: 0x
TA RAS feature version: 0, firmware version: 0x
SMC feature version: 0, firmware version: 0x1e44
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x0110901c
DMCU feature version: 0, firmware version: 0x
VBIOS version: 113-RAVEN-103

Kai-Heng



Thanks,
Ray

From: Kai-Heng Feng 
Sent: Wednesday, August 7, 2019 8:50 PM
To: Huang, Ray
Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); amd-gfx  
list; dri-devel@lists.freedesktop.org; LKML; Anthony Wong
Subject: [Regression] "drm/amdgpu: enable gfxoff again on raven series  
(v2)"


Hi,

After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:
https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png

Firmwares for Raven Ridge is up-to-date.

Kai-Heng



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Kai-Heng Feng]

at 16:26, Jani Nikula  wrote:


On Tue, 23 Jul 2019, Kai-Heng Feng  wrote:

Hi,

Currently, OLED panel brightness [1] is not supported.


As a general statement this is not true, and not backed up by the
referenced bug. We just don't know how brightness is controlled on that
particular laptop, because it apparently uses a properietary mechanism.

If it used the brightness control mechamism specified in the VESA eDP
spec, it should work just fine with the i915 aux backlight support, and
we should also export the regular backlight sysfs for this.


I am told that Windows introduced “NitsBrightness” [1] to support OLED panel.
I don’t know how it’s plumbed to the aux interface though.

Is it possible to ask Windows graphics team how Windows handle OLED panel?

[1]  
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmdt/ns-d3dkmdt-_dxgk_brightness_caps


Kai-Heng



BR,
Jani.



We have a similar Dell system that also affect by lack of OLED brightness
support.

I’ve investigated both kernel and user space but I haven’t found a good
general solution yet.
Dell systems use EDID descriptor 4 as Dell specific descriptor, which
reports its panel type and we can know it’s an OLED panel or not.

My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to
let userspace like clutter [3] to control the brightness.
However other DEs may need to implement their own OLED brightness support
which isn’t ideal.

So I’d like to know if there’s any good way to support OLED brightness in
good old backlight sysfs, to let userspace keep to the current interface.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=97883
[2] https://pastebin.ubuntu.com/p/QYrRBppVT9/
[3]
https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-brightness-contrast-effect.c#L559

Kai-Heng


--
Jani Nikula, Intel Open Source Graphics Center



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Kai-Heng Feng]

at 00:03,   wrote:


-Original Message-
From: Daniel Vetter  On Behalf Of Daniel Vetter
Sent: Wednesday, July 24, 2019 6:49 AM
To: Kai-Heng Feng
Cc: dri-devel@lists.freedesktop.org; Anthony Wong; Limonciello, Mario
Subject: Re: OLED panel brightness support


[EXTERNAL EMAIL]

On Tue, Jul 23, 2019 at 06:46:55PM +0800, Kai-Heng Feng wrote:

Hi,

Currently, OLED panel brightness [1] is not supported.
We have a similar Dell system that also affect by lack of OLED brightness
support.

I’ve investigated both kernel and user space but I haven’t found a good
general solution yet.
Dell systems use EDID descriptor 4 as Dell specific descriptor, which
reports its panel type and we can know it’s an OLED panel or not.

My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to
let userspace like clutter [3] to control the brightness.
However other DEs may need to implement their own OLED brightness support
which isn’t ideal.

So I’d like to know if there’s any good way to support OLED brightness in
good old backlight sysfs, to let userspace keep to the current interface.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=97883
[2] https://pastebin.ubuntu.com/p/QYrRBppVT9/
[3] https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-

brightness-contrast-effect.c#L559

I think the Most Proper Solution would be to integrate the backlight
support into drm, by adding the backlight knobs as kms properties to the
correct connector. This would fix a whole bag of issue:
- no more ill-defined magic for userspace to find the right backlight
- we could have well-defined semantics what happens with the backlight
  across a kms modeset
- issues like this could be solved with a small helper and a bit of code
  in the kernel (there's also other DDC knobs to control backlight, which
  we also don't really expose in a consistent way).

Downside is how to roll this out in a backward compatible way, without
breaking the world:
- fbcon/fbdev needs to be taught to not do it's own backlight wrangling
  for kms drivers which handle backlight natively
- we might need an opt-in magic for this, if it turns out that the kms
  driver handling the backlight breaks stuff
- userspace ofc needs to fall back to its current pile of hacks if the
  backlight stuff isn't supported natively.

Adding more ill-defined sysfs files, or more magice ordering rules, or
anything else like that doesn't sound too appealing.


Where are you thinking that the opt in magic would occur then?  Userspace?

As KH said, at least on Dell it's a known location in EDID to indicate  
panel
is OLED, so it seems like this could be a kernel time documented magic at  
least

to turn this on in the important scenarios.


I think what Daniel says is to keep a uniform backlight interface.

The next question is, how do we change the brightness level for OLED  
displays? Is changing gamma value a good way to do it?


Kai-Heng




-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

OLED panel brightness support

[Kai-Heng Feng]

Hi,

Currently, OLED panel brightness [1] is not supported.
We have a similar Dell system that also affect by lack of OLED brightness  
support.


I’ve investigated both kernel and user space but I haven’t found a good  
general solution yet.
Dell systems use EDID descriptor 4 as Dell specific descriptor, which  
reports its panel type and we can know it’s an OLED panel or not.


My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to  
let userspace like clutter [3] to control the brightness.
However other DEs may need to implement their own OLED brightness support  
which isn’t ideal.


So I’d like to know if there’s any good way to support OLED brightness in  
good old backlight sysfs, to let userspace keep to the current interface.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=97883
[2] https://pastebin.ubuntu.com/p/QYrRBppVT9/
[3]  
https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-brightness-contrast-effect.c#L559


Kai-Heng
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50

[Kai-Heng Feng]

Hi,

at 11:30, Kai-Heng Feng  wrote:


Another panel that needs 6BPC quirk.


Please include this patch if possible.

Kai-Heng



BugLink: https://bugs.launchpad.net/bugs/1819968
Cc:  # v4.8+
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b1909f9d7..1cb4d0052efe 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -166,6 +166,9 @@ static const struct edid_quirk {
/* Medion MD 30217 PG */
{ "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },

+   /* Lenovo G50 */
+   { "SDC", 18514, EDID_QUIRK_FORCE_6BPC },
+
/* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
{ "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },

--
2.17.1

[PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50

[Kai-Heng Feng]

Another panel that needs 6BPC quirk.

BugLink: https://bugs.launchpad.net/bugs/1819968
Cc:  # v4.8+
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b1909f9d7..1cb4d0052efe 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -166,6 +166,9 @@ static const struct edid_quirk {
/* Medion MD 30217 PG */
{ "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
 
+   /* Lenovo G50 */
+   { "SDC", 18514, EDID_QUIRK_FORCE_6BPC },
+
/* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
{ "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

[Kai-Heng Feng]

There's another panel that reports "DFP 1.x compliant TMDS" but it
supports 6bpc instead of 8 bpc.

Apply 6 bpc quirk for the panel to fix it.

BugLink: https://bugs.launchpad.net/bugs/1794387
Cc:  # v4.8+
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9fc99648b7..1e2b9407c8d0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -113,6 +113,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
 
+   /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc 
panel */
+   { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC },
+
/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
{ "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80

[Kai-Heng Feng]

Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc
instead of 8 bpc.

Apply 6 bpc quirk for the panel to fix it.

BugLink: https://bugs.launchpad.net/bugs/1788308
Cc:  # v4.8+
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5dc742b27ca0..3c9fc99648b7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -116,6 +116,9 @@ static const struct edid_quirk {
/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
{ "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
 
+   /* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
+   { "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

[Kai-Heng Feng]

Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.

Hence, use 6 bpc quirk for this panel.

Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp 
when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.f...@canonical.com>
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd537914575..d9c8d718e261 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -113,6 +113,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
 
+   /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+   { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: add new device to use atpx quirk

[Kai-Heng Feng]

The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.

Signed-off-by: Kai-Heng Feng <kai.heng.f...@canonical.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index e2c3c5ec42d1..c53095b3b0fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] 
= {
/* HG _PR3 doesn't seem to work on this A+A weston board */
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
+   { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
 };
 
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel