All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 201763] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0!
Date: Thu, 19 Nov 2020 10:43:13 +0000	[thread overview]
Message-ID: <bug-201763-2300-5K8Bte4LLX@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-201763-2300@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=201763

Vadim Yanitskiy (vyanitskiy@sysmocom.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vyanitskiy@sysmocom.de

--- Comment #12 from Vadim Yanitskiy (vyanitskiy@sysmocom.de) ---
Hello all,

I have a DELL Inspiron 5547 with Radeon R7 M256:

03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT
[Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625 Mobile]

I never experienced any lockups with it, most likely because I was running
quite old kernel most of the time.  About a year ago, I started to use Arch
Linux (thus more or less recent kernels), and also started to see these
messages too:

[ 3916.822707] amdgpu: can't get the mac of 5
[ 3916.824691] amdgpu: VBIOS did not find boot engine clock value in dependency
table. Using Memory DPM level 0!
[ 3923.082543] amdgpu: VI should always have 2 performance levels

It's not like they indicate any problems, the GPU actually works: with hashcat
and proprietary OpenCL run-time on top of open source amdgpu driver I get
nearly the same performance as under Windows; and even OpenGL/Vulkan rendering
seems to work (although performance is significantly worse compared to Intel
Graphics).  Even though I use Intel Graphics most of the time, I was always
interested to investigate the cause of those warnings.

I had a quick look at the kernel's code, and from what I can see they are all
related to the power management (powerplay).  I patched and compiled my own
kernel to get a bit more information, and here is what I managed to understand:

> [ 3916.822707] amdgpu: can't get the mac of 5

According to 'drivers/gpu/drm/amd/powerplay/inc/smumgr.h', the 'mac 5'
corresponds to SMU_MAX_LEVELS_VDDGFX.  This value is neither handled in
iceland_get_mac_definition(), nor it's defined in
'drivers/gpu/drm/amd/powerplay/inc/smu71.h'.  For other GPU families this
constant is used in '*_Discrete_DpmTable', while in 'SMU71_Discrete_DpmTable' I
could not find anything related to VDDGFX.  Therefore I guess this GPU family
(Iceland, SMU71) does not support this kind of power control.

> [57695.583784] amdgpu: VBIOS did not find boot engine clock value in
> dependency table. Using Memory DPM level 0!

This is something I would love to investigate further, but unfortunately have
no time.  The warning itself comes from iceland_populate_smc_boot_level()
defined in 'drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c'.  This
function attempts to get initial clock levels for Graphics DPM and Memory DPM
from VBIOS.

Since we see only one warning, it successfully gets the clock value for
Graphics DPM, but not for Memory DPM.  The function attempts to find value
'data->vbios_boot_state.mclk_bootup_value' in table
'data->dpm_table.mclk_table', which in its turn is populated by
iceland_populate_all_memory_levels().  I need to add some more debug statements
to see the contents of this table and the value that is attampted to be found
in it.

> [ 3923.082543] amdgpu: VI should always have 2 performance levels

I patched the kernel to provide more details in this message, so:

> [ 5312.502812] amdgpu: VI should always have 2 performance levels, however 1
> was detected

This one comes from smu7_apply_state_adjust_rules() defined in
'drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c'.  As far as I can see, the
code is able to handle values !=2, and in some pleces I see checks like ==1, I
most likely this warning can be safely ignored.

As I conclusion, I would say that none of those warnings is critical.

P.S. I am not a kernel developer, and neither I am familiar with amdgpu code
base.  Just had some spare time :)

Best regards,
Vadim.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-11-19 10:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22  6:41 [Bug 201763] New: amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0! bugzilla-daemon
2018-11-22  6:46 ` [Bug 201763] " bugzilla-daemon
2018-11-22 15:52 ` bugzilla-daemon
2018-11-25 12:10 ` bugzilla-daemon
2018-11-25 12:11 ` bugzilla-daemon
2019-02-28 22:31 ` bugzilla-daemon
2019-02-28 22:33 ` bugzilla-daemon
2019-03-01 16:14 ` bugzilla-daemon
2019-03-30  2:22 ` bugzilla-daemon
2019-03-30  2:23 ` bugzilla-daemon
2019-03-30  2:24 ` bugzilla-daemon
2020-11-10 21:46 ` bugzilla-daemon
2020-11-19 10:43 ` bugzilla-daemon [this message]
2020-11-19 14:23 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-201763-2300-5K8Bte4LLX@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.