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

[You-Sheng Yang]

On 9/29/20 4:21 PM, Stefan Bader wrote:
> 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.

Will address this in next revision. Thank you.

> -Stefan
>