DRM IOCTLS come regularly(every minute) still even after screen off

[AMD Official Use Only] Hi Michel, After the system idle for a while, the screen will be off(blank out) and AMD GPU will be put into a very low power state(BACO) due to runpm. However, I found there will be still DRM IOCTLS(which I paste below) coming regularly. And those IOCTLS(especially

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

Ah, I forgot about 4K. It looks good. Thanks! Marek On Wed, Sep 15, 2021 at 8:23 PM Joshua Ashton wrote: > > > On 9/16/21 01:11, Marek Olšák wrote: > > Based on the discussions we had about displayable DCC internally, only > > MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEPENDENT_64B_BLOCKS and

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

On 9/16/21 01:11, Marek Olšák wrote: Based on the discussions we had about displayable DCC internally, only MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEPENDENT_64B_BLOCKS and DCC_INDEPENDENT_128B_BLOCKS is supported by DCN on RDNA 2. From my testing: It works fine when setting

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

On Thu, Sep 16, 2021, 2:12 AM Marek Olšák wrote: > Based on the discussions we had about displayable DCC internally, only > MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEPENDENT_64B_BLOCKS and > DCC_INDEPENDENT_128B_BLOCKS is supported by DCN on RDNA 2. > > Is there something new on the hardware

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

Based on the discussions we had about displayable DCC internally, only MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEPENDENT_64B_BLOCKS and DCC_INDEPENDENT_128B_BLOCKS is supported by DCN on RDNA 2. Is there something new on the hardware side that I missed? Marek On Tue, Sep 14, 2021 at 7:59 PM

Re: [3/4] drm/amd/display: Fix rest of pass-by-value structs in DML

Hi Harry, This patch fixes the following CID's. Thanks. Addresses-Coverity-ID: 1424031: ("Big parameter passed by value") Addresses-Coverity-ID: 1424055: ("Big parameter passed by value") Addresses-Coverity-ID: 1424072: ("Big parameter passed by value") Addresses-Coverity-ID: 1423779: ("Big

Re: [2/4] drm/amd/display: Pass all structs in display_rq_dlg_helpers by pointer

Hi Harry, This patch fixes the following CID's. Thanks. Addresses-Coverity-ID: 1423868: ("Big parameter passed by value") Addresses-Coverity-ID: 1423870: ("Big parameter passed by value") -- Anson

Re: [1/4] drm/amd/display: Pass display_pipe_params_st as const in DML

Hi Harry, This patch fixes the following CID's. Thanks. Addresses-Coverity-ID: 1424031: ("Big parameter passed by value") Addresses-Coverity-ID: 1423970: ("Big parameter passed by value") Addresses-Coverity-ID: 1423941: ("Big parameter passed by value") Addresses-Coverity-ID: 1451742: ("Big

Re: [PATCH 0/4] Fix stack usage of DML

On 2021-09-08 21:00, Harry Wentland wrote: With the '-Werror' enablement patch the amdgpu build was failing on clang builds because a bunch of functions were blowing past the 1024 byte stack frame default. Due to this we also noticed that a lot of functions were passing large structs by value

Re: [PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

I fixed 2 regressions and latest code, applied your patch on top and passed libdrm tests on Vega 10. You can pickup those 2 patches and try too if you have time. In any case - Reviewed-and-tested-by: Andrey Grodzovsky Andrey On 2021-09-15 2:37 a.m., xinhui pan wrote: We hit soft hang while

Re: [PATCH] drm/amd/display: Fix crash on device remove/driver unload

On 2021-09-15 16:11, Andrey Grodzovsky wrote: > Why: > DC core is being released from DM before it's referenced > from hpd_rx wq destruction code. > > How: Move hpd_rx destruction before DC core destruction. > > Signed-off-by: Andrey Grodzovsky Reviewed-by: Harry Wentland Harry > --- >

[PATCH] drm/amd/display: Fix crash on device remove/driver unload

Why: DC core is being released from DM before it's referenced from hpd_rx wq destruction code. How: Move hpd_rx destruction before DC core destruction. Signed-off-by: Andrey Grodzovsky --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 +-- 1 file changed, 12 insertions(+),

[PATCH] drm/amdgpu: Fix crash on device remove/driver unload

Crash: BUG: unable to handle page fault for address: 10e1 RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu] Call Trace: pp_set_powergating_by_smu+0x16a/0x2b0 [amdgpu] amdgpu_dpm_set_powergating_by_smu+0x92/0xf0 [amdgpu] amdgpu_dpm_enable_vce+0x2e/0xc0 [amdgpu]

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote: > Could you please provide more explicit explanation why inlining such an > helper is considered as bad practice and messy ? Tom already told you to look at the previous threads. Let's read them together. This one, for example:

Re: [PATCH 1/2] drm/sched: fix the bug of time out calculation(v4)

Pushed Andrey On 2021-09-15 7:45 a.m., Christian König wrote: Yes, I think so as well. Andrey can you push this? Christian. Am 15.09.21 um 00:59 schrieb Grodzovsky, Andrey: AFAIK this one is independent. Christian, can you confirm ? Andrey

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

Applied. Thanks! Alex On Wed, Sep 15, 2021 at 2:02 PM Harry Wentland wrote: > > On 2021-09-14 19:59, Joshua Ashton wrote: > > Some games, ie. Doom Eternal, present from compute following compute > > post-fx and would benefit from having DCC image stores available. > > > > DCN on gfx10_3

Re: [PATCH 3/3] drm/amd/display: Add modifiers capable of DCC image stores for gfx10_3

On 2021-09-14 19:59, Joshua Ashton wrote: > Some games, ie. Doom Eternal, present from compute following compute > post-fx and would benefit from having DCC image stores available. > > DCN on gfx10_3 doesn't need INDEPENDENT_128B_BLOCKS = 0 so we can expose > these modifiers capable of DCC image

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

On 9/15/21 9:46 AM, Borislav Petkov wrote: Sathya, if you want to prepare the Intel variant intel_cc_platform_has() ontop of those and send it to me, that would be good because then I can integrate it all in one branch which can be used to base future work ontop. I have a Intel variant

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

Le 15/09/2021 à 12:08, Borislav Petkov a écrit : On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote: I don't love it, a new C file and an out-of-line call to then call back to a static inline that for most configuration will return false ... but whatever :) Yeah, hch thinks

Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function

On Wed, Sep 08, 2021 at 05:58:31PM -0500, Tom Lendacky wrote: > This patch series provides a generic helper function, cc_platform_has(), > to replace the sme_active(), sev_active(), sev_es_active() and > mem_encrypt_active() functions. > > It is expected that as new confidential computing

[PATCH v8 15/16] amdgpu_ucode: reduce number of pr_debug calls

There are blocks of DRM_DEBUG calls, consolidate their args into single calls. With dynamic-debug in use, each callsite consumes 56 bytes of callsite data, and this patch removes about 65 calls, so it saves ~3.5kb. no functional changes. RFC: this creates multi-line log messages, does that

[PATCH v8 16/16] nouveau: fold multiple DRM_DEBUG_DRIVERs together

With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes. We can combine 12 into one here and save ~620 bytes. Signed-off-by: Jim Cromie --- drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +-- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git

[PATCH v8 13/16] drm_print: add choice to use dynamic debug in drm-debug

drm's debug system writes 10 distinct categories of messages to syslog using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names), DRM_DEBUG*(8 names). There are thousands of these callsites, each categorized in this systematized way. These callsites can be enabled at runtime by their

[PATCH v8 14/16] drm_print: instrument drm_debug_enabled

Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" branch. Then convert the "dyndbg" branch's code to a macro, so that the pr_debug() get its callsite info from the invoking function, instead of from

[PATCH v8 12/16] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES on existing prdbgs

logger_types.h defines many DC_LOG_*() categorized debug wrappers. Most of these already use DRM debug API, so are controllable using drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13 different class-prefixes matching ~/^\[[_A-Z]+\]:/ Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to

[PATCH v8 11/16] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES for existing prdbgs

The gvt component of this driver has ~120 pr_debugs, in 9 categories quite similar to those in DRM. Following the interface model of drm.debug, add a parameter to map bits to these categorizations. DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug, "dyndbg bitmap desc",

[PATCH v8 09/16] drm: fix doc grammar error

no code changes, good for rc Signed-off-by: Jim Cromie --- include/drm/drm_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index b439ae1921b8..ebb22166ace1 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@

[PATCH v8 10/16] i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes

Taking embedded spaces out of existing prefixes makes them better class-prefixes; simplifying the extra quoting needed otherwise: $> echo format "^gvt: core:" +p >control Dropping the internal spaces means any trailing space in a query will more clearly terminate the prefix being searched for.

[PATCH v8 08/16] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES bitmap and callbacks

DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, var, bitmap_desc, @bit_descs) allows users to create a drm.debug style (bitmap) sysfs interface, mapping each bit to a pr_debug "category". Unlike drm, dyndbg has no coding of "category", but it can select a set of pr_debugs with a substr match on their

[PATCH v8 06/16] dyndbg: no vpr-info on empty queries

when `echo $cmd > control` contains multiple queries, extra query separators (;\n) can parse as empty statements. This is normal, and pr-info on empty command is just noise. Also change varname. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 13 +++-- 1 file changed, 7

[PATCH v8 07/16] dyndbg-doc: fix bootparam usage example

This example uses dyndbg as a core/kernel param; it is a (fake) module param. Using it as given gets an "Unknown command line parameters:" warning. Fix the broken example. Signed-off-by: Jim Cromie --- Documentation/admin-guide/dynamic-debug-howto.rst | 6 ++ 1 file changed, 2

[PATCH v8 05/16] dyndbg: vpr-info on remove-module complete, not starting

On qemu --smp 3 runs, remove-module can get called 3 times. Instead, print once at end, if entry was found and removed. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index

[PATCH v8 04/16] dyndbg: use alt-quotes in vpr-infos, not those user might use

`echo $cmd > control` can be finicky with respect to quoting (mostly wrt * expansion), so lets not complicate things by adding our own in debug messages. Quote as <%s> instead of '%s' or \"%s\" Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 16 1 file changed, 8

[PATCH v8 03/16] dyndbg: rationalize verbosity

change current v*pr_info() calls to fit this new scheme: -1 module add/remove, callsite counts - a few v2s here now -2 command ingest, splitting -3 command parsing - many v1s here now -4 per-site changes - was v2 2 is new, to isolate a problem where a stress-test script (which feeds large

[PATCH v8 02/16] dyndbg: pr-info in boot-param should say so

add "bootparam" to format. no functional changes. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index dfe1e6a857bc..da91ff507117 100644 --- a/lib/dynamic_debug.c +++

[PATCH v8 01/16] dyndbg: add module to a vpr-info in dd-exec-queries

dd-exec-queries accepts a separate module arg (so it can support $module.dyndbg cmdline arg), add it to the vpr-info for more context. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c

[PATCH v8 00/16] use DYNAMIC_DEBUG to implement DRM.debug

Hi Jason, Greg, Daniel, DRM folks, In DRM-debug currently, drm_debug_enabled() is called a lot to decide whether or not to write debug messages. Each test is cheap, but costs continue with uptime. DYNAMIC_DEBUG "dyndbg", when built with JUMP_LABEL, replaces each of those tests with a patchable

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Wed, 2021-09-15 at 17:01 +0300, Pekka Paalanen wrote: > On Fri, 30 Jul 2021 16:41:29 -0400 > Harry Wentland wrote: > > > Use the new DRM RFC doc section to capture the RFC previously only > > described in the cover letter at > > https://patchwork.freedesktop.org/series/89506/ > > > > v3: > >

Re: [PATCH] drm/radeon: make array encoded_lanes static

On Wed, Sep 15, 2021 at 7:36 AM Colin King wrote: > > From: Colin Ian King > > Don't populate the read-only array encoded_lanes on the stack but instead it > static. Also makes the object code smaller by 97 bytes: > > Before: >textdatabss dechex filename > 388998064

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Mon, 16 Aug 2021 15:37:23 +0200 sebast...@sebastianwick.net wrote: > On 2021-08-16 14:40, Harry Wentland wrote: > > On 2021-08-16 7:10 a.m., Brian Starkey wrote: > >> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote: > >>> Hello Brian, > >>> (+Uma in cc) > >>> > >>> Thanks

Re: 回复: [PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

On 2021-09-15 9:57 a.m., Christian König wrote: Am 15.09.21 um 15:52 schrieb Andrey Grodzovsky: On 2021-09-15 2:42 a.m., Pan, Xinhui wrote: [AMD Official Use Only] Andrey I hit panic with this plug/unplug test without this patch. Can you please tell which ASIC you are using and which

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Fri, 30 Jul 2021 16:41:29 -0400 Harry Wentland wrote: > Use the new DRM RFC doc section to capture the RFC previously only > described in the cover letter at > https://patchwork.freedesktop.org/series/89506/ > > v3: > * Add sections on single-plane and multi-plane HDR > * Describe approach

Re: 回复: [PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

Am 15.09.21 um 15:52 schrieb Andrey Grodzovsky: On 2021-09-15 2:42 a.m., Pan, Xinhui wrote: [AMD Official Use Only] Andrey I hit panic with this plug/unplug test without this patch. Can you please tell which ASIC you are using and which kernel branch and what is the tip commit ? But as

Re: 回复: [PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

On 2021-09-15 2:42 a.m., Pan, Xinhui wrote: [AMD Official Use Only] Andrey I hit panic with this plug/unplug test without this patch. Can you please tell which ASIC you are using and which kernel branch and what is the tip commit ? But as we add enter/exit in all its callers. maybe it

[PATCH] drm/radeon: make array encoded_lanes static

From: Colin Ian King Don't populate the read-only array encoded_lanes on the stack but instead it static. Also makes the object code smaller by 97 bytes: Before: textdatabss dechex filename 388998064 0 46963 b773 ./drivers/gpu/drm/radeon/r600_dpm.o After:

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote: > I don't love it, a new C file and an out-of-line call to then call back > to a static inline that for most configuration will return false ... but > whatever :) Yeah, hch thinks it'll cause a big mess otherwise:

[BUG] gpu: drm: amd: amdgpu: possible ABBA deadlock in amdgpu_set_power_dpm_force_performance_level() and amdgpu_debugfs_process_reg_op()

Hello, My static analysis tool reports a possible ABBA deadlock in the amdgpu driver in Linux 5.10: amdgpu_debugfs_process_reg_op()   mutex_lock(>grbm_idx_mutex); --> Line 250 (Lock A)   mutex_lock(>pm.mutex); --> Line 259 (Lock B) amdgpu_set_power_dpm_force_performance_level()  

Re: [BUG] VAAPI encoder cause kernel panic if encoded video in 4K

Am 15.09.21 um 12:36 schrieb Mikhail Gavrilov: On Wed, 15 Sept 2021 at 14:55, Christian König wrote: Yes, absolutely. You should see GPU resets and recovery in the system log after that. Unfortunately, not one DE will survive a GPU reset. All applications will terminate abnormally in fact

Re: [PATCH 1/2] drm/sched: fix the bug of time out calculation(v4)

Yes, I think so as well. Andrey can you push this? Christian. Am 15.09.21 um 00:59 schrieb Grodzovsky, Andrey: AFAIK this one is independent. Christian, can you confirm ? Andrey *From:* amd-gfx on behalf of Alex

Re: [BUG] VAAPI encoder cause kernel panic if encoded video in 4K

On Wed, 15 Sept 2021 at 14:55, Christian König wrote: > > Yes, absolutely. You should see GPU resets and recovery in the system log > after that. Unfortunately, not one DE will survive a GPU reset. All applications will terminate abnormally in fact this would be equivalent to reboot (and denial

Re: [resend PATCH] drm/ttm: Fix a deadlock if the target BO is not idle during swap

Am 14.09.21 um 15:50 schrieb Daniel Vetter: On Thu, Sep 09, 2021 at 09:10:39AM +0200, Christian König wrote: Am 08.09.21 um 20:27 schrieb Daniel Vetter: On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König wrote: Am 07.09.21 um 11:05 schrieb Daniel Vetter: On Tue, Sep 07, 2021 at

Re: [BUG] VAAPI encoder cause kernel panic if encoded video in 4K

Am 14.09.21 um 20:19 schrieb Mikhail Gavrilov: On Wed, 14 Apr 2021 at 11:48, Christian König > wrote: That is expected behavior, the application is just buggy and causing a page fault on the GPU. The kernel should just not crash with a

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote: > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote: > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote: > > > Hi, > > > Re-sending this patch-set following the release of our user-space TPC > > > compiler and

回复: [PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

[AMD Official Use Only] Andrey I hit panic with this plug/unplug test without this patch. But as we add enter/exit in all its callers. maybe it would not impact plug/unplug. [ 1109.041095] BUG: unable to handle page fault for address: 10e1 [ 1109.086353] RIP:

[PATCH v2] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

We hit soft hang while doing memory pressure test on one numa system. After a qucik look, this is because kfd invalid/valid userptr memory frequently with process_info lock hold. Looks like update page table mapping use too much cpu time. perf top says below, 75.81% [kernel] [k]