Re: [PATCH] drm/amdgpu: Fix uvd ib test timeout when use pre-allocated BO

Am 16.09.21 um 08:19 schrieb xinhui pan: Now we use same BO for create/destroy msg. So destroy will wait for the fence returned from create to be signaled. The default timeout value in destroy is 10ms which is too short. Lets wait both fences with the specific timeout. Signed-off-by: xinhui pan

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

Good morning, for the background I advised to contact you Michel since we couldn't find an explanation. Alex explanation might be correct, but the CS seems to come from the X server and is always roughly 60 seconds after going into power save. Any idea what that could be? Thanks, Christian

[PATCH] drm/amdgpu: Fix uvd ib test timeout when use pre-allocated BO

Now we use same BO for create/destroy msg. So destroy will wait for the fence returned from create to be signaled. The default timeout value in destroy is 10ms which is too short. Lets wait both fences with the specific timeout. Signed-off-by: xinhui pan --- drivers/gpu/drm/amd/amdgpu/amdgpu_uv

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 thos

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 PRIMARY_SU

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 s

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 J

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 para

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 para

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] vce_v4_0_hw_fini+0x95/0xa

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: htt

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 doesn't

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 s

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 patc

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 it

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 technolo

[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 break

[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 a/drivers/g

[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 cate

[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 drm_debug_enabl

[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 cre

[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", _DD_c

[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 @@ -5

[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 form

[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 insertions(

[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 insertions(+

[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 eac6c6

[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 insertions

[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 multi-c

[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 +++ b/lib/dynamic_de

[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 i

[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 N

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 kern

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 w

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 wo

[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: te

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: https://lore.kern

[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(&adev->grbm_idx_mutex); --> Line 250 (Lock A)   mutex_lock(&adev->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 Deuche

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 08:22:2

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 runtim