From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu] Date: Thu, 17 Oct 2019 12:12:56 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1674320961==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C7266EA60 for ; Thu, 17 Oct 2019 12:12:57 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1674320961== Content-Type: multipart/alternative; boundary="15713143772.b2FDC3Be.5399" Content-Transfer-Encoding: 7bit --15713143772.b2FDC3Be.5399 Date: Thu, 17 Oct 2019 12:12:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D107296 Janpieter Sollie changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144689|0 |1 is obsolete| | --- Comment #21 from Janpieter Sollie --- Created attachment 145764 --> https://bugs.freedesktop.org/attachment.cgi?id=3D145764&action=3Dedit dmesg of PPLIB error still present on linux 5.3, with the following exceptions: - the values in mV seem to be initialized, - DRM does not complain about 'Cannot find any crtc or sizes' after GPU add= ing - DRM: construct error is gone So it's going the good way, I guess ... I investigated the source around dcn_bw_update_from_pplib And I saw the following code in gpu/drm/amd/display/dc/calcs/dcn_calcs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bool res; /* TODO: This is not the proper way to obtain fabric_and_dram_bandwidth, should be min(fclk, memclk) */ res =3D dm_pp_get_clock_levels_by_type_with_voltage( ctx, DM_PP_CLOCK_TYPE_FCLK, &fclks); kernel_fpu_begin(); if (res) res =3D verify_clock_values(&fclks); if (res) { //unimportant, left out } else BREAK_TO_DEBUGGER(); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D which probably explains what happens: fclks gets a number of clock values f= rom dm_pp_get_clock_levels_by_type_with_voltage, setting res to true. It tries to validate the clock values then, which fails because of the inva= lid numbers After that, it breaks to debugger. Is it possible the vega11 needs more time to initialize its clock limits? --=20 You are receiving this mail because: You are the assignee for the bug.= --15713143772.b2FDC3Be.5399 Date: Thu, 17 Oct 2019 12:12:57 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated Janpieter Sollie changed bug 10729= 6
What Removed Added
Attachment #144689 is obsolete   1

Comme= nt # 21 on bug 10729= 6 from Janpieter Sollie 
Created attachment 145764 [details]
dmesg of PPLIB error

still present on linux 5.3, with the following exceptions:
- the values in mV seem to be initialized,
- DRM does not complain about 'Cannot find any crtc or sizes' after GPU add=
ing
- DRM: construct error is gone

So it's going the good way, I guess ...
I investigated the source around dcn_bw_update_from_pplib

And I saw the following code in gpu/drm/amd/display/dc/calcs/dcn_calcs.c

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
        bool res;

        /* TODO: This is not the proper way to obtain
fabric_and_dram_bandwidth, should be min(fclk, memclk) */
        res =3D dm_pp_get_clock_levels_by_type_with_voltage(
                        ctx, DM_PP_CLOCK_TYPE_FCLK, &fclks);

        kernel_fpu_begin();

        if (res)
                res =3D verify_clock_values(&fclks);

        if (res) {
//unimportant, left out
        } else
                BREAK_TO_DEBUGGER();
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

which probably explains what happens: fclks gets a number of clock values f=
rom
dm_pp_get_clock_levels_by_type_with_voltage, setting res to true.
It tries to validate the clock values then, which fails because of the inva=
lid
numbers
After that, it breaks to debugger.

Is it possible the vega11 needs more time to initialize its clock limits?

You are receiving this mail because:
  • You are the assignee for the bug.
= --15713143772.b2FDC3Be.5399-- --===============1674320961== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1674320961==--