Hi Harry,
Reverting that on top of the current amd-staging-drm-next seems to have
fixed the issue.
Thanks,
Tom
On 03/14/2018 10:08 AM, Harry Wentland wrote:
> On 2018-03-14 09:54 AM, Tom St Denis wrote:
>> Hi,
>>
>> In the original version of the patch we had:
>>
>> @@ -358,7 +360,9 @@ struct dce_hwseq_registers {
>>
>> Â Â Â Â Â Â Â HWSEQ_PIXEL_RATE_MASK_SH_LIST(mask_sh, OTG0_),\
>> Â Â Â Â Â Â Â HWS_SF1(OTG0_, PHYPLL_PIXEL_RATE_CNTL, PHYPLL_PIXEL_RATE_SOURCE, mask_sh), \
>> Â Â Â Â Â Â Â HWS_SF(, DCHUBBUB_GLOBAL_TIMER_CNTL, DCHUBBUB_GLOBAL_TIMER_ENABLE, mask_sh), \
>> -Â Â Â Â Â Â HWS_SF(, DCFCLK_CNTL, DCFCLK_GATE_DIS, mask_sh)
>>
>> +Â Â Â Â Â Â HWS_SF(, DCFCLK_CNTL, DCFCLK_GATE_DIS, mask_sh),\
>>
>> +Â Â Â Â Â Â HWS_SF(, VGA_TEST_CONTROL, VGA_TEST_ENABLE, mask_sh),\
>>
>> +Â Â Â Â Â Â HWS_SF(, VGA_TEST_CONTROL, VGA_TEST_RENDER_START, mask_sh)
>>
>>
>>
>> Which somehow changed into
>>
>> @@ -404,7 +406,9 @@ struct dce_hwseq_registers {
>> Â Â Â Â Â Â Â HWS_SF(, DOMAIN7_PG_STATUS, DOMAIN7_PGFSM_PWR_STATUS, mask_sh), \
>> Â Â Â Â Â Â Â HWS_SF(, DC_IP_REQUEST_CNTL, IP_REQUEST_EN, mask_sh), \
>> Â Â Â Â Â Â Â HWS_SF(, LVTMA_PWRSEQ_CNTL, LVTMA_BLON, mask_sh), \
>> -Â Â Â Â Â Â HWS_SF(, LVTMA_PWRSEQ_STATE, LVTMA_PWRSEQ_TARGET_STATE_R, mask_sh)
>> +Â Â Â Â Â Â HWS_SF(, LVTMA_PWRSEQ_STATE, LVTMA_PWRSEQ_TARGET_STATE_R, mask_sh), \
>> +Â Â Â Â Â Â HWS_SF(, VGA_TEST_CONTROL, VGA_TEST_ENABLE, mask_sh),\
>> +Â Â Â Â Â Â HWS_SF(, VGA_TEST_CONTROL, VGA_TEST_RENDER_START, mask_sh)
>>
>
> This is just defining the VGA_TEST registers for use by DC. It shouldn't have an impact on that patch.
>
>> And the net result is the display doesn't work (same glitches as before) on a raven1 device.
>>
>
> Can you see if reverting this commit fixes it?
> 1b0ff66bc0bf drm/amd/display: early return if not in vga mode in disable_vga
>
> If introduced a check to see if we're actually in VGA mode and only then applied the workaround. I believe it's to avoid problems resuming from S3.
>
> Harry
>
>> Tom
