On Wed, Oct 13, 2021 at 10:29 PM Quan, Evan wrote:
>
> [AMD Official Use Only]
>
>
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Thursday, October 14, 2021 10:00 AM
> > To: Quan, Evan
> > Cc: Deucher, Alexander ; amd-
> > g...@lists.freedesktop.org
> > Subject: Re: [PATCH
[AMD Official Use Only]
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, October 14, 2021 10:00 AM
> To: Quan, Evan
> Cc: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 3/3] drm/amdgpu/psp: add some missing cases to
>
[AMD Official Use Only]
> -Original Message-
> From: Borislav Petkov
> Sent: Wednesday, October 13, 2021 5:26 PM
> To: Quan, Evan
> Cc: Alex Deucher ; amd-gfx list g...@lists.freedesktop.org>; LKML ; Deucher,
> Alexander ; Pan, Xinhui
> ; Chen, Guchun
> Subject: Re: bf756fb833cb
On Wed, Oct 13, 2021 at 9:41 PM Quan, Evan wrote:
>
> [AMD Official Use Only]
>
> I assume IP_VERSION(11, 0, 0) and IP_VERSION(11, 0, 5) are for Navi10 and
> Navi14 respectively.
> Then according to the code comment that " pmfw_centralized_cstate_management
> support is available for Navi12 and
[AMD Official Use Only]
I assume IP_VERSION(11, 0, 0) and IP_VERSION(11, 0, 5) are for Navi10 and
Navi14 respectively.
Then according to the code comment that " pmfw_centralized_cstate_management
support is available for Navi12 and onwards only", I think they should be
handled by "default"
Am 2021-10-13 um 7:18 p.m. schrieb Philip Yang:
> When creating unregistered new svm range to recover retry fault, avoid
> new svm range to overlap with ranges or userptr ranges managed by TTM,
> otherwise svm migration will trigger TTM or userptr eviction, to evict
> user queues unexpectedly.
>
>
When creating unregistered new svm range to recover retry fault, avoid
new svm range to overlap with ranges or userptr ranges managed by TTM,
otherwise svm migration will trigger TTM or userptr eviction, to evict
user queues unexpectedly.
Change helper amdgpu_ttm_tt_affect_userptr to return
On 2021-10-13 6:33 p.m., Felix Kuehling
wrote:
Am 2021-10-13 um 6:05 p.m. schrieb Philip Yang:
When creating unregistered new svm range to recover retry fault, avoid
new svm range to overlap with ranges or userptr ranges managed by TTM,
Am 2021-10-13 um 6:05 p.m. schrieb Philip Yang:
> When creating unregistered new svm range to recover retry fault, avoid
> new svm range to overlap with ranges or userptr ranges managed by TTM,
> otherwise svm migration will trigger TTM or userptr eviction, to evict
> user queues unexpectedly.
>
When creating unregistered new svm range to recover retry fault, avoid
new svm range to overlap with ranges or userptr ranges managed by TTM,
otherwise svm migration will trigger TTM or userptr eviction, to evict
user queues unexpectedly.
Change helper amdgpu_ttm_tt_affect_userptr to return
The previous patch removed drm_modeset_{lock,unlock}_all, which were the
only users of this field inside the drm_mode_config structure.
Signed-off-by: Fernando Ramos
---
include/drm/drm_mode_config.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_mode_config.h
Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no
longer used anywhere and can be removed.
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_modeset_lock.c | 94 +-
include/drm/drm_modeset_lock.h | 2 -
2 files changed, 3 insertions(+), 93
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
While this change is similar to the one done two commits ago, it
contains an important extra nuances that I'm going to explain next.
Refactor places using drm_modeset_{lock,unlock}_all() so that they only
appear once per function.
This is needed so that in the next commit I can replace those functions
by the new macros (which use labels that can only appear once per
function).
Signed-off-by: Fernando Ramos
---
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 ++---
1 file changed, 14 insertions(+),
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/gma500/psb_device.c | 18 --
1 file changed, 12 insertions(+), 6
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
While the previous two commits were a simple "search and replace", this
time I had to do a bit of refactoring as only one call to
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
I separated this change from the rest of modifications to the i915
driver to point out something special explained next.
The only
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_audio.c| 16 ---
.../drm/i915/display/intel_display_debugfs.c
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
1 file changed, 10
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/omapdrm/omap_fb.c | 9 ++---
1 file changed, 6 insertions(+),
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/radeon/radeon_device.c | 21 +++--
drivers/gpu/drm/radeon/radeon_dp_mst.c
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 --
1 file changed, 4
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
drivers/gpu/drm/tegra/dsi.c | 6 --
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 +++
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_client_modeset.c | 5 +++--
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_display.c | 18
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_client_modeset.c | 9 +++--
1 file changed, 3 insertions(+),
Hi all,
One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
"use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
patch series is about.
You will find two types of changes here:
- Replacing "drm_modeset_lock_all_ctx()" (and surrounding
On Wed, Oct 13, 2021 at 4:04 PM T. Williams wrote:
>
The description and s-o-b should go here and the patch seems to be
mangled. I've manually applied this. Please fix up your mailer in
the future.
Thanks for the fix.
Alex
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 87daa78a32b8..17f2756a64dc 100644
---
Ping.
On Tue, Oct 12, 2021 at 12:40 PM Alex Deucher wrote:
>
> Check was incorrectly converted to IP version checking.
>
> Fixes: 4b0ad8425498ba ("drm/amdgpu/gfx10: convert to IP version checking")
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 5 +++--
> 1 file
Ping on this series.
On Tue, Oct 12, 2021 at 11:53 AM Alex Deucher wrote:
>
> VEGA20 is 11.0.2, but it's handled by powerplay, not
> swsmu.
>
> Fixes: a8967967f6a554 ("drm/amdgpu/amdgpu_smu: convert to IP version
> checking")
> Signed-off-by: Alex Deucher
> ---
>
Ping on this series.
On Mon, Oct 11, 2021 at 11:02 AM Alex Deucher wrote:
>
> hawaii_device_info is not used when CONFIG_DRM_AMDGPU_CIK is not
> set.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
On Fri, Oct 1, 2021 at 4:34 PM Sean Paul wrote:
>
> On Wed, Sep 29, 2021 at 03:39:25PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in the new CRTC state, allowing any invalid
On 10/13/2021 2:29 PM, Christian König wrote:
Am 12.10.21 um 15:12 schrieb Das, Nirmoy:
On 10/12/2021 1:58 PM, Stanley.Yang wrote:
Test scenario:
modprobe amdgpu -> rmmod amdgpu -> modprobe amdgpu
Error log:
[ 54.396807] debugfs: File 'page_pool' in directory 'amdttm'
already
Port Intel buddy manager to drm root folder
Implemented range allocation support for the provided order
Implemented TOP-DOWN support
Implemented freeing up unused pages on contiguous allocation
Moved range allocation and freelist pickup into a single function
Signed-off-by: Arunpravin
---
On Wed, Oct 13, 2021 at 1:06 PM Lazar, Lijo wrote:
>
> [AMD Official Use Only]
>
>
> >Or maybe just a list without default hint, i.e. no asterisk?
>
> I think this is also fine meaning we are having trouble in determining the
> current frequency or DPM level. Evan/Alex? Don't know if this will
On Wed, Oct 13, 2021 at 3:12 AM Quan, Evan wrote:
>
> [AMD Official Use Only]
>
> Reviewed-by: Evan Quan
Is this for just this patch or the series?
Alex
>
> > -Original Message-
> > From: amd-gfx On Behalf Of Alex
> > Deucher
> > Sent: Tuesday, October 12, 2021 11:53 PM
> > To:
[AMD Official Use Only]
>Or maybe just a list without default hint, i.e. no asterisk?
I think this is also fine meaning we are having trouble in determining the
current frequency or DPM level. Evan/Alex? Don't know if this will crash the
tools.
Thanks,
Lijo
On 2021-10-13 00:14, Lazar, Lijo wrote:
>
> On 10/13/2021 8:40 AM, Luben Tuikov wrote:
>> Some ASIC support low-power functionality for the whole ASIC or just
>> an IP block. When in such low-power mode, some sysfs interfaces would
>> report a frequency of 0, e.g.,
>>
>> $cat
By usage: read freq_values[x] to freq_value[x].
Cc: Alex Deucher
Signed-off-by: Luben Tuikov
---
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 16
.../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 18 +-
2 files changed, 17 insertions(+), 17 deletions(-)
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible operating (non-zero)
frequencies of the block requested. So, if the
current clock value is 0, then report as the
current clock
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible operating (non-zero)
frequencies of the block requested. So, if the
current clock value is 0, then report as the
current clock
Some ASIC support low-power functionality for the whole ASIC or just
an IP block. When in such low-power mode, some sysfs interfaces would
report a frequency of 0, e.g.,
$cat /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 0Mhz *
2: 2200Mhz
$_
An operating frequency of 0 MHz doesn't make
Rename "cur_value", which stands for "cursor
value" to "curr_value", which stands for "current
value".
Cc: Alex Deucher
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 12 ++--
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 15 ---
2
Rename
sienna_cichlid_is_support_fine_grained_dpm() to
sienna_cichlid_supports_fine_grained_dpm().
Rename
navi10_is_support_fine_grained_dpm() to
navi10_supports_fine_grained_dpm().
v2: Fix function name in commit message to reflect
the change being done: add a missing 's'.
Cc: Alex Deucher
On Wed, Oct 13, 2021 at 11:06 AM Alex Deucher wrote:
>
> The extended bits were not available for use on navi1x, but
> navi2x only have 2 sdma instances so we won't conflict with
This should say navi1x. Fixed locally.
Alex
> firmware anyway.
>
> Fixes: 468e994c41ecb3 ("drm/amdgpu/nbio2.3:
Hi,
Acked-by: Rodrigo Siqueira
Thanks a lot, I'm going to apply this patch.
On 2021-10-08 5:21 p.m., Harry Wentland wrote:
He's been helping maintain it for quite a while now. Make
it official.
Signed-off-by: Harry Wentland
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff
Am 2021-10-11 um 4:58 a.m. schrieb Lang Yu:
> Currently, all kfd BOs use same destruction routine. But pinned
> BOs are not unpinned properly. Separate them from general routine.
>
> Signed-off-by: Lang Yu
I think the general idea is right. However, we need another safeguard
for the signal BO,
Please ignore this!
On 10/13/2021 5:04 PM, Nirmoy Das wrote:
When gart size is < gtt size this test will fail with
-ENOMEM as we are not freeing gtt bo after each move test.
This is generally not an issue when gart size >= gtt size.
Reported-by: zhang
Signed-off-by: Nirmoy Das
---
GTT BO cleanup code is with in the test for loop and
we would skip cleaning up GTT BO on success.
Reported-by: zhang
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 25
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git
On 10/13/2021 12:42 PM, Das, Nirmoy wrote:
On 10/13/2021 3:22 AM, zhang wrote:
Hi . Nirmoy
If you let continue to unpin. this will allways test a same va for gtt
I think we should rafresh calculate the value n
Right, I guess then the test should only run till gart size.
Actually
The extended bits were not available for use on navi1x, but
navi2x only have 2 sdma instances so we won't conflict with
firmware anyway.
Fixes: 468e994c41ecb3 ("drm/amdgpu/nbio2.3: don't use GPU_HDP_FLUSH bit 12")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c |
When gart size is < gtt size this test will fail with
-ENOMEM as we are not freeing gtt bo after each move test.
This is generally not an issue when gart size >= gtt size.
Reported-by: zhang
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +-
1 file changed, 1
On 2021-10-13 10:50, Russell, Kent wrote:
> [AMD Official Use Only]
>
> Pedantic tiny thing:
>
>> -Original Message-
>> From: amd-gfx On Behalf Of Luben
>> Tuikov
>> Sent: Tuesday, October 12, 2021 11:11 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander ; Tuikov, Luben
>>
[AMD Official Use Only]
Pedantic tiny thing:
> -Original Message-
> From: amd-gfx On Behalf Of Luben
> Tuikov
> Sent: Tuesday, October 12, 2021 11:11 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Tuikov, Luben
>
> Subject: [PATCH 1/5] drm/amd/pm: Slight function
From: Arnd Bergmann
It appears that the wrong argument was removed in this call:
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function
'apply_degamma_for_user_regamma':
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1694:36:
error: implicit
Am 2021-10-13 um 3:28 a.m. schrieb Lang Yu:
> We should unreference a gem object instead of an amdgpu bo here.
>
> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
I think the Fixes tag is incorrect. At that time there was no gobj in
this function.
If anything I'd attribute the
On 10/13/2021 7:28 PM, Alex Deucher wrote:
On Wed, Oct 13, 2021 at 12:14 AM Lazar, Lijo wrote:
On 10/13/2021 8:40 AM, Luben Tuikov wrote:
Some ASIC support low-power functionality for the whole ASIC or just
an IP block. When in such low-power mode, some sysfs interfaces would
report a
On Wed, Oct 13, 2021 at 12:14 AM Lazar, Lijo wrote:
>
>
>
> On 10/13/2021 8:40 AM, Luben Tuikov wrote:
> > Some ASIC support low-power functionality for the whole ASIC or just
> > an IP block. When in such low-power mode, some sysfs interfaces would
> > report a frequency of 0, e.g.,
> >
> > $cat
On Wed, Oct 13, 2021 at 07:05:34PM +0530, Arunpravin wrote:
> Port Intel buddy manager to drm root folder
One patch to move it 1:1, then follow-up patches to change it. Not
everything in one.
Also i915 needs to be adopted to use this too, or this just doesn't make
sense.
I'm also wondering
Add drm buddy allocator support for vram memory management
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 251 ++
3 files changed,
Move vram related defines and inline functions into
a separate header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 72
1 file changed, 72 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git
On Tue, Oct 12, 2021 at 03:56:29PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> > On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
> >
> > > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> > > owned by a device that
On Wed, Oct 13, 2021 at 09:19:45AM +, Quan, Evan wrote:
> So, I need your help to confirm the last two patches(I sent you) do not
> affect the fix for the bug above.
> Please follow the steps below to verify it:
> 1. Launch a video playing
> 2. open another terminal and issue "sudo
LGTM as we create a gem object 1st and retrieve amdgpu_bo from the gem
object.
Acked-by: Nirmoy Das
On 10/13/2021 9:28 AM, Lang Yu wrote:
We should unreference a gem object instead of an amdgpu bo here.
Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
Signed-off-by: Lang Yu
Reviewed-by:JamesZhufortheseries.
When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.
Reported-by: youling
Tested-by: youling
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
Am 12.10.21 um 15:12 schrieb Das, Nirmoy:
On 10/12/2021 1:58 PM, Stanley.Yang wrote:
Test scenario:
modprobe amdgpu -> rmmod amdgpu -> modprobe amdgpu
Error log:
[ 54.396807] debugfs: File 'page_pool' in directory 'amdttm'
already present!
[ 54.396833] debugfs: File
On 10/13/2021 3:22 AM, zhang wrote:
Hi . Nirmoy
If you let continue to unpin. this will allways test a same va for gtt
I think we should rafresh calculate the value n
Right, I guess then the test should only run till gart size.
Regards,
Nirmoy
On 2021/10/12 20:10, Nirmoy Das
[AMD Official Use Only]
Thanks Boris.
There is another thing which needs your help.
The change of bf756fb833cb was introduced to fix the bug below:
"some hangs observed on suspending when UVD/VCE still using".
So, I need your help to confirm the last two patches(I sent you) do not affect
the
[AMD Official Use Only]
>-Original Message-
>From: Lazar, Lijo
>Sent: Wednesday, October 13, 2021 4:07 PM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org; Kuehling,
>Felix
>Cc: Deucher, Alexander ; Huang, Ray
>
>Subject: Re: [PATCH] drm/amdkfd: Fix a __user pointer dereference in
On 10/13/2021 1:03 PM, Lang Yu wrote:
We should not dereference __user pointers directly.
https://yarchive.net/comp/linux/user_pointers.html
Fixes: 482f07775cf5
("drm/amdkfd: Simplify event ID and signal slot management")
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c
We should not dereference __user pointers directly.
https://yarchive.net/comp/linux/user_pointers.html
Fixes: 482f07775cf5
("drm/amdkfd: Simplify event ID and signal slot management")
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 +-
1 file changed, 1 insertion(+), 1
We should unreference a gem object instead of an amdgpu bo here.
Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, October 12, 2021 11:53 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/3] drm/amdgpu/smu11: fix firmware version check
[AMD Official Use Only]
I agree with Lijo.
Reporting a "round to the smallest operating frequency" just makes user more
confusing.
As per designed, the frequency marked with "*" should reflect the current clock
frequency.
BR
Evan
> -Original Message-
> From: amd-gfx On Behalf Of
>
When IOMMU disabled in sbios and kfd in iommuv2 path,
IOMMU resume failure blocks system resume. Don't allow kfd to
use iommu v2 when iommu is disabled.
Reported-by: youling
Tested-by: youling
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1
When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.
Reported-by: youling
Tested-by: youling
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
83 matches
Mail list logo
