QHD Bug (FDO #108940) - possible solution, need validation / information

H.Habighorst h.habighorst at protonmail.com
Sun Apr 7 21:00:47 UTC 2019


Hi,

this bug: https://bugs.freedesktop.org/show_bug.cgi?id=108940#add_comment has annoyed a lot of people...

I'm neither an C programmer nor an "expert" in driver programming, so my "solution" is based on experience in other programming languages...

My code is - I guess - crappy as hell, sorry for that. My mainboard is an AsRock B450M Pro4, with latest BIOS P3.10 03/07/2019 and an AMD Ryzen 5 2400G.

When looking at the dmesg output, I noticed that reading the clock values in function dcn_bw_update_from_pplib changed from kernel version to kernel version.

In 5.1+, both FCLK and DCFCLK are printed correctly.

In 5.0, FCLK is printed correctly, DCFCLK is printed as "Invalid clock".

In < 5.0, only DCFCLK is printed (as "Invalid clock")

--
5.0.7:

DM_PPLIB: values for Invalid clock
DM_PPLIB:        0 in kHz
DM_PPLIB:        0 in kHz
DM_PPLIB:        0 in kHz
DM_PPLIB:        1600000 in kHz
WARNING: CPU: 2 PID: 276 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1380 dcn_bw_update_from_pplib+0x171/0x290 [amdgpu]
RIP: 0010:dcn_bw_update_from_pplib+0x171/0x290 [amdgpu]
DM_PPLIB: values for Invalid clock
DM_PPLIB:        300000 in kHz
DM_PPLIB:        600000 in kHz
DM_PPLIB:        626000 in kHz
DM_PPLIB:        654000 in kHz

--
5.1_rc3
DM_PPLIB: values for F clock
DM_PPLIB:        0 in kHz
DM_PPLIB:        0 in kHz
DM_PPLIB:        0 in kHz
DM_PPLIB:        1600000 in kHz
WARNING: CPU: 6 PID: 292 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1373 dcn_bw_update_from_pplib+0x174/0x2a0 [amdgpu]
RIP: 0010:dcn_bw_update_from_pplib+0x174/0x2a0 [amdgpu]
DM_PPLIB: values for DCF clock
DM_PPLIB:        300000 in kHz
DM_PPLIB:        600000 in kHz
DM_PPLIB:        626000 in kHz
DM_PPLIB:        654000 in kHz

--

After a bit of try and error, I found out that deep in the bios is an option to set the "System configuration" to 6 possible values and that this relates to the cTDP settings.

(3 Commercial, 3 Customer).

Each of these settings lead to different results - depending on the number of levels set.

With the 45W TDP commercial setting, I got the following F clock results:

DM_PPLIB: values for F clock
DM_PPLIB:   0 in kHz
DM_PPLIB:   400000 in kHz
DM_PPLIB:   933000 in kHz
DM_PPLIB:   1067000 in kHz

Then, I took a deeper look at the source code - and changed the validation in verify_clock_values (drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c)

Before, every khz setting == 0 was regarded as an "fatal" error, leading to no possible initialization.

I guess that this isn't entirely wrong as 0 makes no sense. But in my case - and when I understood the code correctly - it's not entirely right, too, as there are some levels that could be used.

My assumption is that the BIOS should provide these values in a fixed order, but (as I even had to change bios settings to just get the basic clock values right) - the ASRock BIOS simply does nothing right...

>From my understanding, the previous code in dcn_bw_update_from_pplib is already based on the assumption that there is no fixed number of levels provided, but that there must be at least 3 and a maximum of 4 levels provided.

Instead of taking the results directly from the "dm_pp_clock_levels_with_voltage" struct, I gathered the valid clock KHz values and converted them to hertz in the validation function, returning the clocks as an array. An additional parameter to the function contains the actual (not maximum) number of correct values gathered.

This fixes the initialization and removes the annoying BREAK_TO_DEBUGGER output.

I think it is still not correct, as the FCLK values are not provided by the BIOS - and the approach to just bail out, because something is not provided by the bios, seems wrong to me.


There is a comment in the function that suggests that there is a better way, which sounds more sane to me:

/* TODO: This is not the proper way to obtain fabric_and_dram_bandwidth, should be min(fclk, memclk) */

Is memclk DFCLK? Or how can one get the memclk values?

I hope that someone could fix this properly or at least verify that my assumptions are correct - so I can maybe work out a better patch.

Thanks in advance,

Henning










-------------- next part --------------
A non-text attachment was scrubbed...
Name: amdgpu_dcn_calc_rework_validation.patch
Type: text/x-patch
Size: 4399 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20190407/4eb564f3/attachment.bin>


More information about the amd-gfx mailing list