Comment # 96
on bug 110674
from Tom B
Created attachment 145047 [details]
logging anywhere the number of screens is set
Again, no closer to a fix but another thing to rule out. In addition to
SMU_MSG_NumOfDisplays, PPSMC_MSG_NumOfDisplays is also used.
I put a debug message anywhere PPSMC_MSG_NumOfDisplays or SMU_MSG_NumOfDisplays
is set end put else blocks in places where it may have been set:
if ((data->water_marks_bitmap & WaterMarksExist) &&
data->smu_features[GNLD_DPM_DCEFCLK].supported &&
data->smu_features[GNLD_DPM_SOCCLK].supported) {
pr_err("vega20_display_configuration_changed_task setting
PPSMC_MSG_NumOfDisplays to %d\n", hwmgr->display_config->num_display);
result = smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_NumOfDisplays,
hwmgr->display_config->num_display);
}
else {
pr_err("vega20_display_configuration_changed_task not setting
PPSMC_MSG_NumOfDisplays\n");
}
return result;
}
Here's what I found:
- The functions dealing with screesn in vega20_ppt.c are never used (
vega20_display_config_changed, vega20_pre_display_config_changed) and can be
ignored for our further tests
- The line:
result = smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_NumOfDisplays, hwmgr->display_config->num_display);
Is never executed, it always triggers the else block so PPSMC_MSG_NumOfDisplays
is never set using num_display.
- The same thing happens in 5.0.13, when I saw the above result I had hoped
that the problem was that smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_NumOfDisplays, hwmgr->display_config->num_display); was never called
with the correct number of displays. Unfortunately the behaviour is the same on
5.0.13, PPSMC_MSG_NumOfDisplays is only ever set to zero in both versions of
the kernel.
Unfortunately this doesn't get us any closer.
The instruction is sent a lot more in 5.0.13 though.
5.0.13:
[ 3.475471] amdgpu 0000:44:00.0: ring vce1 uses VM inv eng 13 on hub 1
[ 3.475472] amdgpu 0000:44:00.0: ring vce2 uses VM inv eng 14 on hub 1
[ 3.475508] amdgpu: [powerplay] vega20_display_configuration_changed_task
not setting PPSMC_MSG_NumOfDisplays
[ 3.794037] amdgpu: [powerplay]
vega20_pre_display_configuration_changed_task setting PPSMC_MSG_NumOfDisplays
to 0
[ 3.800180] amdgpu: [powerplay] vega20_display_configuration_changed_task
not setting PPSMC_MSG_NumOfDisplays
[ 3.833502] amdgpu: [powerplay]
vega20_pre_display_configuration_changed_task setting PPSMC_MSG_NumOfDisplays
to 0
[ 3.833647] amdgpu: [powerplay] vega20_display_configuration_changed_task
not setting PPSMC_MSG_NumOfDisplays
[ 4.153232] [drm] Initialized amdgpu 3.27.0 20150101 for 0000:44:00.0 on
minor 0
[ 4.664044] amdgpu: [powerplay]
vega20_pre_display_configuration_changed_task setting PPSMC_MSG_NumOfDisplays
to 0
5.2.7
[ 3.711028] amdgpu 0000:44:00.0: ring vce1 uses VM inv eng 13 on hub 1
[ 3.711028] amdgpu 0000:44:00.0: ring vce2 uses VM inv eng 14 on hub 1
[ 4.086310] amdgpu: [powerplay]
vega20_pre_display_configuration_changed_task setting PPSMC_MSG_NumOfDisplays
to 0
[ 4.385470] [drm] Initialized amdgpu 3.32.0 20150101 for 0000:44:00.0 on
minor 0
[ 4.522398] amdgpu: [powerplay] Failed to send message 0x28, response 0x0
Notice that vega20_pre_display_configuration_changed_task is run 5 times
between the ring lines and initilization line in 5.0.13 and only once in 5.2.7.
This might not mean anything, but it could be another clue that initilization
is happening before the card is really ready.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
