Re: vga handover for raven
This diff on top of drm-next works fine
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 4365906b14ee..7688ed5724b9 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -228,6 +228,9 @@ static void disable_vga(
return;
REG_WRITE(D1VGA_CONTROL, 0);
+ REG_WRITE(D2VGA_CONTROL, 0);
+ REG_WRITE(D3VGA_CONTROL, 0);
+ REG_WRITE(D4VGA_CONTROL, 0);
/* HW Engineer's Notes:
* During switch from vga->extended, if we set the
VGA_TEST_ENABLE and
I can't test suspend/resume right now since I don't have the gfxoff
branch handy.
Tom
On 03/14/2018 10:55 AM, Yang, Eric wrote:
If there is no VGA hand over, the change should make no difference. In the VGA
hand over case, the difference introduced is the following, we can try to
revert this part of the commit, which should not break S3.
REG_WRITE(D1VGA_CONTROL, 0);
- REG_WRITE(D2VGA_CONTROL, 0);
- REG_WRITE(D3VGA_CONTROL, 0);
- REG_WRITE(D4VGA_CONTROL, 0);
-Original Message-
From: StDenis, Tom
Sent: Wednesday, March 14, 2018 10:12 AM
To: Wentland, Harry <harry.wentl...@amd.com>; Lakha, Bhawanpreet
<bhawanpreet.la...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Cheng, Tony <tony.ch...@amd.com>; Yang, Eric
<eric.ya...@amd.com>
Subject: Re: vga handover for raven
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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: vga handover for raven
If there is no VGA hand over, the change should make no difference. In the VGA
hand over case, the difference introduced is the following, we can try to
revert this part of the commit, which should not break S3.
REG_WRITE(D1VGA_CONTROL, 0);
- REG_WRITE(D2VGA_CONTROL, 0);
- REG_WRITE(D3VGA_CONTROL, 0);
- REG_WRITE(D4VGA_CONTROL, 0);
-Original Message-
From: StDenis, Tom
Sent: Wednesday, March 14, 2018 10:12 AM
To: Wentland, Harry <harry.wentl...@amd.com>; Lakha, Bhawanpreet
<bhawanpreet.la...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Cheng, Tony <tony.ch...@amd.com>; Yang, Eric
<eric.ya...@amd.com>
Subject: Re: vga handover for raven
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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: vga handover for raven
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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
vga handover for raven
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)
And the net result is the display doesn't work (same glitches as before)
on a raven1 device.
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
