Am 18.01.22 um 00:43 schrieb Jonathan Kim:
drm_dev_enter returns true when accessiable so correct the error check.
Source VRAM buffer is reserved by TTM but not pinned so the gpu offset
fetch throws a warning.
Well it throws a warning because what you try to do here won't work.
Get the
Am 18.01.22 um 00:43 schrieb Jonathan Kim:
Move the debug sdma vram bounce buffer GART map on device init after when
GART is ready to avoid warnings and non-access to SDMA.
Well that doesn't seem to make sense the GART is initialized by the code
around the allocation so that should work fine.
Am 2022-01-10 um 8:39 p.m. schrieb Daniel Phillips:
> Add an ioctl to inquire memory available for allocation by libhsakmt
> per node, allowing for space consumed by page translation tables.
>
> This ioctl is the underlying mechanism for the new memory availability
> library call posted for
From: Daniel Phillips
Using DefaultGPUNode now instead of system memory, usage similar to
other tests. Also cleaned up pSmall, which I originally intended to
just let float away on the mistaken assumption that it would be
cleaned up automatically at the end of the test.
Basic test for the new
From: Zongmin Zhou
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]
Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
after add this patch,the
Am 2022-01-17 um 6:43 p.m. schrieb Jonathan Kim:
> drm_dev_enter returns true when accessiable so correct the error check.
>
> Source VRAM buffer is reserved by TTM but not pinned so the gpu offset
> fetch throws a warning. Get the gpu offset without a check and then
> double check to make sure
From: Zongmin Zhou
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]
Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
after add this patch,the
From: Marina Nikolic
[ Upstream commit 11c9cc95f818f0f187e9b579a7f136f532b42445 ]
== Description ==
Setting values of pm attributes through sysfs
should not be allowed in SRIOV mode.
These calls will not be processed by FW anyway,
but error handling on sysfs level should be improved.
==
From: Zongmin Zhou
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]
Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
after add this patch,the
From: Alex Deucher
[ Upstream commit 92020e81ddbeac351ea4a19bcf01743f32b9c800 ]
Disable vblanks immediately to save power. I think this was
missed when we merged DC support.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
From: Yang Li
[ Upstream commit a689e8d1f80012f90384ebac9dcfac4201f9f77e ]
Clang static analysis reports this error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
Dereference of null pointer [clang-analyzer-core.NullDereference]
if
From: Marina Nikolic
[ Upstream commit 11c9cc95f818f0f187e9b579a7f136f532b42445 ]
== Description ==
Setting values of pm attributes through sysfs
should not be allowed in SRIOV mode.
These calls will not be processed by FW anyway,
but error handling on sysfs level should be improved.
==
From: Zongmin Zhou
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]
Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
after add this patch,the
From: Rajneesh Bhardwaj
[ Upstream commit fbcdbfde87509d523132b59f661a355c731139d0 ]
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied.
From: Jingwen Chen
[ Upstream commit 948e7ce01413b71395723aaf846015062aea3a43 ]
[Why]
gmc bo will be pinned during loading amdgpu and reset in SRIOV while
only unpinned in unload amdgpu
[How]
add amdgpu_in_reset and sriov judgement to skip pin bo
v2: fix wrong judgement
Signed-off-by:
From: Jingwen Chen
[ Upstream commit 85dfc1d692c9434c37842e610be37cd4ae4e0081 ]
[Why]
psp tmr bo will be pinned during loading amdgpu and reset in SRIOV while
only unpinned in unload amdgpu
[How]
add amdgpu_in_reset and sriov judgement to skip pin bo
v2: fix wrong judgement
Signed-off-by:
From: Felix Kuehling
[ Upstream commit 726be40607264b180a2b336c81e1dcff941de618 ]
Add null-pointer check after the last svm_range_new call. This was
originally reported by Zhou Qingyang based on a
static analyzer.
To avoid duplicating the unwinding code from svm_range_handle_overlap,
I merged
From: Martin Leung
[ Upstream commit 11dff0e871037a6ad978e52f826a2eb7f5fb274a ]
[Why & How]
when changing some code we accidentally
changed else if-> if. reverting that.
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
Signed-off-by: Martin Leung
Tested-by: Daniel Wheeler
Signed-off-by: Alex
From: Alex Deucher
[ Upstream commit 92020e81ddbeac351ea4a19bcf01743f32b9c800 ]
Disable vblanks immediately to save power. I think this was
missed when we merged DC support.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
From: Yang Li
[ Upstream commit a689e8d1f80012f90384ebac9dcfac4201f9f77e ]
Clang static analysis reports this error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
Dereference of null pointer [clang-analyzer-core.NullDereference]
if
From: Marina Nikolic
[ Upstream commit 11c9cc95f818f0f187e9b579a7f136f532b42445 ]
== Description ==
Setting values of pm attributes through sysfs
should not be allowed in SRIOV mode.
These calls will not be processed by FW anyway,
but error handling on sysfs level should be improved.
==
From: Zongmin Zhou
[ Upstream commit 11544d77e3974924c5a9c8a8320b996a3e9b2f8b ]
Some boards(like RX550) seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
after add this patch,the
From: Rajneesh Bhardwaj
[ Upstream commit fbcdbfde87509d523132b59f661a355c731139d0 ]
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied.
From: Jingwen Chen
[ Upstream commit 948e7ce01413b71395723aaf846015062aea3a43 ]
[Why]
gmc bo will be pinned during loading amdgpu and reset in SRIOV while
only unpinned in unload amdgpu
[How]
add amdgpu_in_reset and sriov judgement to skip pin bo
v2: fix wrong judgement
Signed-off-by:
From: Jingwen Chen
[ Upstream commit 85dfc1d692c9434c37842e610be37cd4ae4e0081 ]
[Why]
psp tmr bo will be pinned during loading amdgpu and reset in SRIOV while
only unpinned in unload amdgpu
[How]
add amdgpu_in_reset and sriov judgement to skip pin bo
v2: fix wrong judgement
Signed-off-by:
From: Isabella Basso
[ Upstream commit 929bb8e200412da36aca4b61209ec26283f9c184 ]
This commit fixes the compile-time warning below:
warning: no previous prototype for ‘amdgpu_ras_mca_query_error_status’
[-Wmissing-prototypes]
Changes since v1:
- As suggested by Alexander Deucher:
1. Make
From: Felix Kuehling
[ Upstream commit 726be40607264b180a2b336c81e1dcff941de618 ]
Add null-pointer check after the last svm_range_new call. This was
originally reported by Zhou Qingyang based on a
static analyzer.
To avoid duplicating the unwinding code from svm_range_handle_overlap,
I merged
From: Vlad Zahorodnii
[ Upstream commit 69cb56290d9d10cdcc461aa2685e67e540507a96 ]
dm_check_crtc_cursor() doesn't take into account plane transforms when
calculating plane scaling, this can result in false positives.
For example, if there's an output with resolution 3840x2160 and the
output is
From: Martin Leung
[ Upstream commit 11dff0e871037a6ad978e52f826a2eb7f5fb274a ]
[Why & How]
when changing some code we accidentally
changed else if-> if. reverting that.
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
Signed-off-by: Martin Leung
Tested-by: Daniel Wheeler
Signed-off-by: Alex
From: Alex Deucher
[ Upstream commit 92020e81ddbeac351ea4a19bcf01743f32b9c800 ]
Disable vblanks immediately to save power. I think this was
missed when we merged DC support.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
From: Yang Li
[ Upstream commit a689e8d1f80012f90384ebac9dcfac4201f9f77e ]
Clang static analysis reports this error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
Dereference of null pointer [clang-analyzer-core.NullDereference]
if
[Public]
Thanks for your quick fix, Jonathan.
I wonder if it's better to encapsulate the bo creation into a function and put
the function definition in amdgpu_sdma or amdgpu_ttm?
Regards,
Guchun
-Original Message-
From: Kim, Jonathan
Sent: Tuesday, January 18, 2022 7:43 AM
To:
[AMD Official Use Only]
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Marina
Nikolic
Sent: Tuesday, January 18, 2022 12:21 AM
To: amd-gfx@lists.freedesktop.org
Cc: Mitrovic, Milan ; Veljkovic, Nikola
; Nikolic, Marina ; Kitchen,
[AMD Official Use Only]
Acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Marina Nikolic
> Sent: Tuesday, January 18, 2022 12:22 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Mitrovic, Milan ; Veljkovic, Nikola
> ; Nikolic, Marina ;
> Kitchen, Greg
> Subject:
drm_dev_enter returns true when accessiable so correct the error check.
Source VRAM buffer is reserved by TTM but not pinned so the gpu offset
fetch throws a warning. Get the gpu offset without a check and then
double check to make sure the source buffer hasn't fallen into a hole.
Otherwise use
Move the debug sdma vram bounce buffer GART map on device init after when
GART is ready to avoid warnings and non-access to SDMA.
Also move bounce buffer tear down after the memory manager has flushed
queued work for safety.
Signed-off-by: Jonathan Kim
---
From: Leo Li
eDP 1.5 specification defines PSR version 4.
It defines PSR1 and PSR2 support with selective-update (SU)
capabilities, with additional support for Y-coordinate and Early
Transport of the selective-update region.
This differs from PSR version 3 in that early transport is supported
On Fri, Jan 14, 2022 at 4:57 AM Vincent Whitchurch
wrote:
>
> On Fri, Jan 07, 2022 at 06:29:24AM +0100, Jim Cromie wrote:
> > #ifdef CONFIG_JUMP_LABEL
> > - if (dp->flags & _DPRINTK_FLAGS_PRINT) {
> > - if (!(modifiers->flags &
> >
Am 2022-01-17 um 9:50 a.m. schrieb Bhardwaj, Rajneesh:
>
> [Public]
>
>
>
>
>
>
>
> *From:* amd-gfx *On Behalf Of
> *Deucher, Alexander
> *Sent:* Monday, January 10, 2022 4:11 PM
> *To:* Phillips, Daniel ;
> amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> *Subject:* Re:
On 2022-01-17 2:47 a.m., Qiang Ma wrote:
I met a bug recently and the kernel log:
[ 330.171875] radeon :03:00.0: couldn't schedule ib
[ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-22)!
In radeon drivers, using UVD suspend is as follows:
if
On 2022-01-17 2:17 p.m., Christian König wrote:
Am 17.01.22 um 20:14 schrieb Andrey Grodzovsky:
Ping on the question
Oh, my! That was already more than a week ago and is completely
swapped out of my head again.
Andrey
On 2022-01-05 1:11 p.m., Andrey Grodzovsky wrote:
Also, what about
Am 17.01.22 um 20:14 schrieb Andrey Grodzovsky:
Ping on the question
Oh, my! That was already more than a week ago and is completely swapped
out of my head again.
Andrey
On 2022-01-05 1:11 p.m., Andrey Grodzovsky wrote:
Also, what about having the reset_active or in_reset flag in the
Ping on the question
Andrey
On 2022-01-05 1:11 p.m., Andrey Grodzovsky wrote:
Also, what about having the reset_active or in_reset flag in the
reset_domain itself?
Of hand that sounds like a good idea.
What then about the adev->reset_sem semaphore ? Should we also move
this to
On Mon, Jan 17, 2022 at 4:38 AM Christian König
wrote:
>
> The return value was never initialized so the cleanup code executed when
> it isn't even necessary.
>
> Just add proper error handling.
>
> Fixes: 2ad5d8fca195 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference
> in
[Public]
Yes, that's part of why I want to make sure there are explicit warnings to
users about using this flow.
When not enabled in ACPI then also the LPS0 device is not exported and AMD_PMC
won't load or be used.
I think from amdgpu perspective it should behave relatively similar to an
Any problem with PMFW sequence in the way Linux handles s2idle when it's not
enabled in ACPI?
Thanks,
Lijo
From: Limonciello, Mario
Sent: Monday, January 17, 2022 10:45:44 PM
To: amd-gfx@lists.freedesktop.org ; Lazar, Lijo
Cc: Bjoren Dasse
Subject: RE: [PATCH
[Public]
This has been sitting a week or so.
Bump on review for this patch.
> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, January 11, 2022 14:00
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario ; Bjoren Dasse
>
> Subject: [PATCH v2] drm/amd: Warn users
Am 17.01.22 um 15:50 schrieb Marek Olšák:
I don't think fork() would work with userspace where all buffers are
shared. It certainly doesn't work now. The driver needs to be notified
that a buffer or texture is shared to ensure data coherency between
processes, and the driver must execute
Enable power level, power limit and fan speed
information retrieval in one VF mode.
This is required so that tool ROCM-SMI
can provide this information to users.
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 17 ++---
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +-
2
On 2022-01-14 5:37 p.m., Felix Kuehling
wrote:
Am 2022-01-14 um 3:38 p.m. schrieb Philip Yang:
After GPU page fault is recovered, output timestamp when fault is
received, duration to recover the fault, if migration or only
GPU page table is
Hi Amarnath,
not a bad idea, but that won't work either because you really need to
return to make sure that a potential next reset can run.
What could be done is to have a work item which does that, but then I
think it would just be easier to teach the udev function a GFP mask.
Regards,
[Public]
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Monday, January 10, 2022 4:11 PM
To: Phillips, Daniel ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 1/1] Add available memory ioctl for libhsakmt
[Public]
[Public]
This is missing your
I don't think fork() would work with userspace where all buffers are
shared. It certainly doesn't work now. The driver needs to be notified that
a buffer or texture is shared to ensure data coherency between processes,
and the driver must execute decompression and other render passes when a
buffer
Am 2022-01-17 um 9:21 a.m. schrieb Christian König:
> Am 17.01.22 um 15:17 schrieb Felix Kuehling:
>> Am 2022-01-17 um 6:44 a.m. schrieb Christian König:
>>> Am 14.01.22 um 18:40 schrieb Felix Kuehling:
Am 2022-01-14 um 12:26 p.m. schrieb Christian König:
> Am 14.01.22 um 17:44 schrieb
Am 17.01.22 um 15:17 schrieb Felix Kuehling:
Am 2022-01-17 um 6:44 a.m. schrieb Christian König:
Am 14.01.22 um 18:40 schrieb Felix Kuehling:
Am 2022-01-14 um 12:26 p.m. schrieb Christian König:
Am 14.01.22 um 17:44 schrieb Daniel Vetter:
Top post because I tried to catch up on the entire
Hi Christian,
if sending udev event during reset is going to create problem, we can
move this code from reset sequence to re-int (after GPU reset succeeded).
Regards,
S.Amarnath
On 1/17/2022 5:27 PM, Christian König wrote:
Am 17.01.22 um 12:43 schrieb Sharma, Shashank:
Hello Christian,
Am 2022-01-17 um 6:44 a.m. schrieb Christian König:
> Am 14.01.22 um 18:40 schrieb Felix Kuehling:
>> Am 2022-01-14 um 12:26 p.m. schrieb Christian König:
>>> Am 14.01.22 um 17:44 schrieb Daniel Vetter:
Top post because I tried to catch up on the entire discussion here.
So
On Mon, Jan 17, 2022 at 08:16:09AM +0100, Christian König wrote:
> Interesting to see that even that old stuff is still used.
Well, "used" is a stretch.
This is my way of testing on K8 as pretty much all the big K8 boxes to
which I had access to, got decommissioned so this baby is the only K8
On Mon, Jan 17, 2022 at 10:38 AM Christian König
wrote:
>
> The return value was never initialized so the cleanup code executed when
> it isn't even necessary.
>
> Just add proper error handling.
>
> Fixes: 2ad5d8fca195 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference
> in
On Mon, Jan 17, 2022 at 08:16:09AM +0100, Christian König wrote:
Hi Borislav,
Am 15.01.22 um 17:11 schrieb Borislav Petkov:
Hi folks,
so this is a *very* old K8 laptop - yap, you read it right, family 0xf.
[ 31.353032] powernow_k8: fid 0xa (1800 MHz), vid 0xa
[ 31.353569] powernow_k8:
Am 17.01.22 um 12:43 schrieb Sharma, Shashank:
Hello Christian,
On 1/17/2022 11:37 AM, Christian König wrote:
Am 17.01.22 um 11:34 schrieb Somalapuram, Amaranath:
[SNIP]
Any suggestion how we can notify user space during this situation.
Well trace points should work. They use a ring buffer
On 1/17/2022 12:03 PM, Somalapuram Amaranath wrote:
AMDGPURESET uevent added to notify userspace, collect dump_stack and trace
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/nv.c | 45 +
1 file changed, 45 insertions(+)
diff --git
Am 14.01.22 um 18:40 schrieb Felix Kuehling:
Am 2022-01-14 um 12:26 p.m. schrieb Christian König:
Am 14.01.22 um 17:44 schrieb Daniel Vetter:
Top post because I tried to catch up on the entire discussion here.
So fundamentally I'm not opposed to just close this fork() hole once and
for all.
Hello Christian,
On 1/17/2022 11:37 AM, Christian König wrote:
Am 17.01.22 um 11:34 schrieb Somalapuram, Amaranath:
[SNIP]
Any suggestion how we can notify user space during this situation.
Well trace points should work. They use a ring buffer and are specially
made to work in such
Am 17.01.22 um 11:34 schrieb Somalapuram, Amaranath:
[SNIP]
Any suggestion how we can notify user space during this situation.
Well trace points should work. They use a ring buffer and are specially
made to work in such situations.
Alternative would be to audit the udev code and allow
On 1/17/2022 3:49 PM, Christian König wrote:
Am 17.01.22 um 11:09 schrieb Somalapuram, Amaranath:
[AMD Official Use Only]
-Original Message-
From: Koenig, Christian
Sent: Monday, January 17, 2022 3:33 PM
To: Somalapuram, Amaranath ;
amd-gfx@lists.freedesktop.org
Cc: Deucher,
Am 17.01.22 um 11:09 schrieb Somalapuram, Amaranath:
[AMD Official Use Only]
-Original Message-
From: Koenig, Christian
Sent: Monday, January 17, 2022 3:33 PM
To: Somalapuram, Amaranath ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Sharma, Shashank
Subject: Re: [PATCH
[AMD Official Use Only]
-Original Message-
From: Koenig, Christian
Sent: Monday, January 17, 2022 3:33 PM
To: Somalapuram, Amaranath ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Sharma, Shashank
Subject: Re: [PATCH 2/2] drm/amdgpu: add AMDGPURESET uevent on AMD GPU
Am 17.01.22 um 11:01 schrieb Somalapuram, Amaranath:
[AMD Official Use Only]
-Original Message-
From: Koenig, Christian
Sent: Monday, January 17, 2022 12:57 PM
To: Somalapuram, Amaranath ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Sharma, Shashank
Subject: Re: [PATCH
[AMD Official Use Only]
-Original Message-
From: Koenig, Christian
Sent: Monday, January 17, 2022 12:57 PM
To: Somalapuram, Amaranath ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Sharma, Shashank
Subject: Re: [PATCH 2/2] drm/amdgpu: add AMDGPURESET uevent on AMD GPU
The return value was never initialized so the cleanup code executed when
it isn't even necessary.
Just add proper error handling.
Fixes: 2ad5d8fca195 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in
radeon_driver_open_kms()")
Signed-off-by: Christian König
---
Am 17.01.22 um 09:42 schrieb Jan Stancek:
On Mon, Jan 17, 2022 at 08:16:09AM +0100, Christian König wrote:
Hi Borislav,
Am 15.01.22 um 17:11 schrieb Borislav Petkov:
Hi folks,
so this is a *very* old K8 laptop - yap, you read it right, family 0xf.
[ 31.353032] powernow_k8: fid 0xa
hi Tareque,
On Fri, Jan 14, 2022 at 6:09 PM Tareque Md Hanif
wrote:
>
> Hi Hsin-Yi,
>
> On 1/12/22 16:58, Hsin-Yi Wang wrote:
>
> Can you help provide logs if we apply
> 5a7b95fb993ec399c8a685552aa6a8fc995c40bd but revert
> 8d35a2596164c1c9d34d4656fd42b445cd1e247f?
>
> Issue still exists.
I met a bug recently and the kernel log:
[ 330.171875] radeon :03:00.0: couldn't schedule ib
[ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-22)!
In radeon drivers, using UVD suspend is as follows:
if (rdev->has_uvd) {
uvd_v1_0_fini(rdev);
74 matches
Mail list logo
