[PATCH 0/2][SRU][F/OEM-5.6/G/U] Enable PSR on HP ZBook Studio G7

Stefan Bader stefan.bader at canonical.com
Tue Sep 29 08:21:27 UTC 2020


On 29.09.20 06:08, You-Sheng Yang wrote:
> BugLink: https://bugs.launchpad.net/bugs/1897501
> 
> [Impact]
> 
> On some OEM platforms equipped PSR eanbled panels, i915 renders screen
> half occupied and corrupted, and restore PSR previously disabled in
> LP: #1849947 fixes this issue.
> 
> [Fix]
> 
> While PSR has been disabled currently in Ubuntu kernels from oem-osp1
> 5.0 to current unstable 5.9, there is no guaranteed PSR support in
> Focal, and PSR is actually planned for v5.10 or later kernels, reverting
> the disabling commit ("UBUNTU: SAUCE: drm/i915: Disable PSR by default
> on all platforms") doesn't seem a viable solution here.
> 
> This patchset introduces a new, Ubuntu only, EDID quirk
> 'DP_QUIRK_FORCE_PSR_ENABLE' to identify the target panel and overrides
> `enable_psr` to -1(chip defaults) when it's set to 0(disabled).
> 
> [Test Case]
> 
> On the target device, the PSR value should be 0 by default:
> 
>   $ sudo cat /sys/module/i915/parameters/enable_psr
>   0
> 
> When applied, the PSR should be -1 even if no "i915.enable_psr=-1" is
> passed as kernel boot parameter, and .
> 
>   $ sudo cat /sys/module/i915/parameters/enable_psr
>   -1
> 
> With drm.debug=0x04, one should also find following message in dmesg:
> 
>   [drm:intel_psr_enable_locked [i915]] Enabling PSR2
> 
> [Regression Potential]
> Low. This affects only the target panel with EDID mfg CMN prod-ID 19-15.
> 
> You-Sheng Yang (2):
>   UBUNTU: SAUCE: drm/i915/psr: allow overriding PSR disable param by
>     quirk
>   UBUNTU: SAUCE: drm/dp: add DP_QUIRK_FORCE_PSR_ENABLE quirk to CMN
>     prod-ID 19-15
> 
>  drivers/gpu/drm/drm_dp_helper.c          | 5 +++++
>  drivers/gpu/drm/i915/display/intel_psr.c | 8 ++++++++
>  include/drm/drm_dp_helper.h              | 8 ++++++++
>  3 files changed, 21 insertions(+)
> 

Somehow this appears a bit like maybe the initial decision to change the default
should be thought over again. Even with accepting it as is, the quirk name
suggests it does always forcfully enable this, while in reality this is just
restoring the old default of doing what the chip reports.
Naively I would think the HW should be right or be called out if not. Though
probably a discussion that would lead too far.
However I would rather like to see the quirk being something like
DP_QUIRK_FORCE_PSR_CHIP_DEFAULT or so.

-Stefan



More information about the kernel-team mailing list