On 10/20/2021 2:18 PM, Das, Nirmoy wrote:
On 10/20/2021 8:49 AM, Christian König wrote:
Am 19.10.21 um 20:14 schrieb Nirmoy Das:
Do not allow exported amdgpu_gtt_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
On 10/19/2021 11:44 PM, Nirmoy Das wrote:
Get rid off pin/unpin of gart BO at resume/suspend and
instead pin only once and try to recover gart content
at resume time. This is much more stable in case there
is OOM situation at 2nd call to amdgpu_device_evict_resources()
while evicting GART
On 10/19/2021 9:45 AM, Luben Tuikov wrote:
On 2021-10-18 23:38, Lazar, Lijo wrote:
On 10/19/2021 5:19 AM, Luben Tuikov wrote:
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
On 10/19/2021 5:19 AM, Luben Tuikov wrote:
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
On 10/18/2021 3:21 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Monday, October 18, 2021 3:58 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; b...@alien8.de
Subject: Re: [PATCH] drm/amdgpu: fix the hang
On 10/18/2021 2:38 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Monday, October 18, 2021 4:05 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Grodzovsky,
Andrey
Subject: Re: [PATCH] drm/amdgpu: fix Polaris12
On 10/18/2021 1:06 PM, Quan, Evan wrote:
[AMD Official Use Only]
Ping..
-Original Message-
From: Quan, Evan
Sent: Monday, October 11, 2021 4:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Grodzovsky,
Andrey ; Quan, Evan
Subject: [PATCH] drm/amdgpu: fix Polaris12
On 10/18/2021 1:04 PM, Evan Quan wrote:
It's confirmed that on some APUs the interaction with SMU(about DPM disablement)
will power off the UVD. That will make the succeeding interactions with UVD on
the
suspend path impossible. And the system will hang due to that. To workaround the
issue,
ijo
From: Tuikov, Luben
Sent: Wednesday, October 13, 2021 9:52:09 PM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 0/5] 0 MHz is not a valid current frequency
On 2021-10-13 00:14, Lazar, Lijo wrote:
>
> On 10/13/2021 8:40 AM, Luben Tuikov wrote
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
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
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 /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 0Mhz *
2: 2200Mhz
$_
On 10/11/2021 2:01 PM, Lang Yu wrote:
Query default sclk instead of hard code.
Signed-off-by: Lang Yu
---
.../gpu/drm/amd/pm/swsmu/smu11/cyan_skillfish_ppt.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
On 10/6/2021 10:36 AM, Darren Powell wrote:
=== Description ===
Add limit_type to (pptable_funcs)->set_power_limit signature
plus small patch
Fix for incorrect power limit readback in smu11 if POWER_SOURCE_DC
v2
add check for SMU_DEFAULT_PPT_LIMIT
dropped patch: Explicit
On 10/6/2021 3:21 PM, Nirmoy Das wrote:
Check first if debugfs is initialized before creating
amdgpu debugfs files.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3
On 10/6/2021 12:05 PM, Christian König wrote:
Am 06.10.21 um 08:32 schrieb Lazar, Lijo:
On 10/6/2021 11:49 AM, Christian König wrote:
Am 06.10.21 um 06:51 schrieb Lazar, Lijo:
On 10/5/2021 10:15 PM, Christian König wrote:
Am 05.10.21 um 15:49 schrieb Das, Nirmoy:
On 10/5/2021 3:22
On 10/6/2021 11:49 AM, Christian König wrote:
Am 06.10.21 um 06:51 schrieb Lazar, Lijo:
On 10/5/2021 10:15 PM, Christian König wrote:
Am 05.10.21 um 15:49 schrieb Das, Nirmoy:
On 10/5/2021 3:22 PM, Christian König wrote:
Am 05.10.21 um 15:11 schrieb Nirmoy Das:
Debugfs core APIs
On 10/5/2021 10:15 PM, Christian König wrote:
Am 05.10.21 um 15:49 schrieb Das, Nirmoy:
On 10/5/2021 3:22 PM, Christian König wrote:
Am 05.10.21 um 15:11 schrieb Nirmoy Das:
Debugfs core APIs will throw -EPERM when user disables debugfs
using CONFIG_DEBUG_FS_ALLOW_NONE or with kernel
On 10/5/2021 7:19 PM, Das, Nirmoy wrote:
On 10/5/2021 3:22 PM, Christian König wrote:
Am 05.10.21 um 15:11 schrieb Nirmoy Das:
Debugfs core APIs will throw -EPERM when user disables debugfs
using CONFIG_DEBUG_FS_ALLOW_NONE or with kernel param. We shouldn't
see that as an error. Also
s API returning
0 value), then better to do in sw_init.
Thanks,
Lijo
/* seed the cached smu power limit values iff get_power_limit is
defined, otherwise they remain 0 */
Thanks
Darren
----
*From:* Lazar, Lijo
*Sent:* Mond
On 10/3/2021 10:16 AM, Darren Powell wrote:
Code appears to initialize values but macro will exit without error
or initializing value if function is not implmented
Signed-off-by: Darren Powell
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4
1 file changed, 4 insertions(+)
diff
On 10/3/2021 10:16 AM, Darren Powell wrote:
modify (pptable_funcs)->set_power_limit signature
modify smu11 set_power_limit signature (arcturus, navi10, sienna_cichlid)
modify smu13 set_power_limit signature (aldabaran)
modify vangogh_set_power_limit signature (vangogh)
=== Test ===
ference or some more details in the comments?
Thanks,
Lijo
-Original Message-
From: Alex Deucher
Sent: Thursday, September 23, 2021 6:21 PM
To: Lazar, Lijo
Cc: amd-gfx list ; Deucher, Alexander
; Zhang, Hawking ; Wang,
Yang(Kevin) ; Feng, Kenneth ;
Quan, Evan
Subject: Re: [PATCH
On 9/21/2021 11:37 PM, Alex Deucher wrote:
For new chips with no explicit entry in the PCI ID list.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
On 9/22/2021 9:47 PM, Alex Deucher wrote:
On Wed, Sep 22, 2021 at 5:08 AM Lazar, Lijo wrote:
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Allow us to query instances versions more cleanly.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2
ressed in patch 54 of the series.
Thanks Guchun! Saw that after a while :)
Alex,
Please ignore the comment. Apart from a few comments here and there, the
patch series in general looks good to me.
Thanks,
Lijo
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Lazar, Lij
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Allow us to query instances versions more cleanly.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 262 +-
On 9/22/2021 2:06 PM, Lazar, Lijo wrote:
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Use the instance to increment the entry in the table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Use the instance to increment the entry in the table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 22 +++
1 file changed, 13 insertions(+), 9 deletions(-)
diff
On 9/21/2021 11:37 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 41 ++-
1 file changed, 18 insertions(+), 23 deletions(-)
diff
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Hardcode the IP versions for asics without IP discovery tables
and then enumerate the asics based on the IP versions.
TODO: fix SR-IOV support
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 417 --
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Hardcode the IP versions for asics without IP discovery tables
and then enumerate the asics based on the IP versions.
TODO: fix SR-IOV support
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 417 --
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 194 ++
1 file changed, 109 insertions(+), 85 deletions(-)
diff
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
v2: rebase
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 94 +--
1 file changed, 55 insertions(+), 39
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 75 +
1 file changed, 38 insertions(+), 37 deletions(-)
diff
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Use IP versions rather than asic_type to differentiate
IP version specific features.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 48 +-
1 file changed, 24 insertions(+), 24 deletions(-)
diff
On 9/21/2021 11:36 PM, Alex Deucher wrote:
Once we claim all 0x1002 PCI display class devices, we will
need to filter out devices owned by radeon.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 561 +++-
1 file changed, 560 insertions(+), 1
, 2021 9:47:41 PM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Pan, Xinhui ; Deucher,
Alexander
Subject: Re: [PATCH] drm/amdgpu: Fix crash on device remove/driver unload
On 2021-09-16 11:51 a.m., Lazar, Lijo wrote:
>
>
> On 9/16/2021 9:15 PM, Andrey Grodzov
On 9/16/2021 9:15 PM, Andrey Grodzovsky wrote:
On 2021-09-16 4:20 a.m., Lazar, Lijo wrote:
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
Crash:
BUG: unable to handle page fault for address: 10e1
RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu]
Call
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
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
/13/2021 12:53 PM, Pan, Xinhui wrote:
[AMD Official Use Only]
Of source IB test can hang the GPU.
But it wait fence with one specific timeout. and it not depends on gpu
scheduler.
So IB test must can return.
发件人: Lazar, Lijo
发送时间: 2021年9月13日 15:15
收件人
a hang and need to trigger a reset? Will there be chance
for the lock to be released (whether a submit call will hang
indefinitely) for the actual reset to be executed?
Thanks,
Lijo
Regards,
Christian.
Am 13.09.21 um 08:43 schrieb Lazar, Lijo:
There are other interfaces to emulate the exact
interface emulates parts of the reset procedure for testing
and we absolutely need to take the same locks as the reset to avoid
corruption of the involved objects.
Regards,
Christian.
Am 13.09.21 um 08:25 schrieb Lazar, Lijo:
This is a debugfs interface and adding another writer contention
of adding one amdgpu_ring.direct_access_mutex before we
issue test_ib on each ring.
发件人: Lazar, Lijo
发送时间: 2021年9月13日 12:00
收件人: Pan, Xinhui; amd-gfx@lists.freedesktop.org
抄送: Deucher, Alexander; Koenig, Christian
主题: Re: [PATCH v2] drm/amdgpu: Fix a race
On 9/13/2021 5:18 AM, xinhui pan wrote:
Direct IB submission should be exclusive. So use write lock.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 9/10/2021 8:47 AM, Evan Quan wrote:
Current RUNPM mechanism relies on PMFW to master the timing for BACO
in/exit. And that needs cooperation from sound driver for dstate
change notification for function 1(audio). Otherwise(on sound driver
missing), BACO cannot be kicked in correctly and
On 9/9/2021 1:31 PM, Christian König wrote:
Am 09.09.21 um 05:28 schrieb Lazar, Lijo:
On 9/9/2021 8:13 AM, Yu, Lang wrote:
[AMD Official Use Only]
So the final decision is rollback to scnprintf().
If we can define our own helper functions like sysfs_emit/sysfs_emit_at
but without page
. Maybe, you can make the intention
explicit by keeping the offset and buf start calculations in a separate
inline function.
smu_get_sysfs_buf()
Thanks,
Lijo
Regards,
Lang
*From:* Powell, Darren
*Sent:* Thursday, September 9, 2021 6:18 AM
*To:* Christian König ; Lazar, Lijo
; Yu
On 9/8/2021 3:08 PM, Christian König wrote:
Am 08.09.21 um 11:29 schrieb Lazar, Lijo:
On 9/8/2021 2:32 PM, Yu, Lang wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, September 8, 2021 4:55 PM
To: Yu, Lang ; Christian König
; amd-gfx
On 9/8/2021 2:32 PM, Yu, Lang wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, September 8, 2021 4:55 PM
To: Yu, Lang ; Christian König
; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray
; Tian Tao
Subject: Re: [PATCH] drm
On 9/8/2021 1:14 PM, Yu, Lang wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, September 8, 2021 3:36 PM
To: Christian König ; Yu, Lang
; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray
; Tian Tao
Subject: Re: [PATCH] drm
On 9/8/2021 12:07 PM, Christian König wrote:
Am 08.09.21 um 07:56 schrieb Lang Yu:
sysfs_emit and sysfs_emit_at requrie a page boundary
aligned buf address. Make them happy!
Warning Log:
[ 492.545174] invalid sysfs_emit_at: buf:f19bdfde at:0
[ 492.546416] WARNING: CPU: 7 PID: 1304
Thanks Felix for the detailed explanation.
Thanks,
Lijo
On 9/1/2021 10:17 PM, Felix Kuehling wrote:
Am 2021-09-01 um 12:30 p.m. schrieb Lazar, Lijo:
[Public]
What I wanted to ask was -
Whether user mode application relies only on link properties alone to
assume atomic ops are supported
of exposing atomic capability in link properties
and whether that can be utilised by upper mode applications just based on PCIe
atomics support?
Thanks,
Lijo
From: Kuehling, Felix
Sent: Wednesday, September 1, 2021 8:24:56 PM
To: Lazar, Lijo ; amd-gfx
On 9/1/2021 3:26 AM, Felix Kuehling wrote:
On some GPUs the PCIe atomic requirement for KFD depends on the MEC
firmware version. Add a firmware version check for this. The minimum
firmware version that works without atomics can be updated in the
device_info structure for each GPU type.
threads racing operations WITH the lock in place just means the userspace
gets undefined outputs which from the kernel is fine.
Tom
From: Lazar, Lijo
Sent: Thursday, August 26, 2021 08:19
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re
unlikely to happen since umr is the
only likely user of this it's still ideal to avoid potential race conditions as
a matter of correctness.
Tom
From: Lazar, Lijo
Sent: Thursday, August 26, 2021 08:12
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject
Reviewed-by: Lijo Lazar
Thanks,
Lijo
On 8/26/2021 4:58 PM, Nirmoy Das wrote:
Currently AMDGPU_RING_PRIO_MAX is redefinition of a
max gfx hwip priority, this won't work well when we will
have a hwip with different set of priorities than gfx.
Also, HW ring priorities are different from ring
On 8/25/2021 10:56 PM, Tom St Denis wrote:
This new debugfs interface uses an IOCTL interface in order to pass
along state information like SRBM and GRBM bank switching. This
new interface also allows a full 32-bit MMIO address range which
the previous didn't. With this new design we have
On 8/26/2021 12:43 PM, Satyajit Sahu wrote:
Schedule the encode job in VCE/VCN encode ring
based on the priority set by UMD.
Signed-off-by: Satyajit Sahu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 30 +
1 file changed, 30 insertions(+)
diff --git
On 8/26/2021 4:21 PM, Das, Nirmoy wrote:
On 8/26/2021 12:48 PM, Christian König wrote:
Am 26.08.21 um 12:08 schrieb Nirmoy Das:
Currently AMDGPU_RING_PRIO_MAX is redefinition of a
max gfx hwip priority, this won't work well when we will
have a hwip with different set of priorities than
On 8/26/2021 3:24 PM, Koba Ko wrote:
On Thu, Aug 26, 2021 at 5:34 PM Koba Ko wrote:
On Thu, Aug 26, 2021 at 5:07 PM Lazar, Lijo wrote:
On 8/26/2021 7:05 AM, Koba Ko wrote:
AMD polaris GPUs have an issue about audio noise on RKL platform,
they provide a commit to fix but for SMU7
On 8/25/2021 9:12 PM, Nirmoy Das wrote:
Currently AMDGPU_RING_PRIO_MAX is redefinition of a
max gfx hwip priority, this won't work well when we will
have a hwip with different set of priorities than gfx.
Also, HW ring priorities are different from ring priorities.
Create a global enum for
On 8/26/2021 7:05 AM, Koba Ko wrote:
AMD polaris GPUs have an issue about audio noise on RKL platform,
they provide a commit to fix but for SMU7-based GPU still
need another module parameter,
modprobe amdgpu ppfeaturemask=0xfff7bffb
to avoid the module parameter, switch PCI_DPM by
On 8/25/2021 4:46 PM, Koba Ko wrote:
On Wed, Aug 25, 2021 at 6:24 PM Jani Nikula wrote:
On Wed, 25 Aug 2021, Koba Ko wrote:
On Wed, Aug 25, 2021 at 5:22 PM Jani Nikula wrote:
On Wed, 25 Aug 2021, Koba Ko wrote:
AMD polaris GPUs have an issue about audio noise on RKL platform,
they
On 8/25/2021 4:52 PM, Nirmoy Das wrote:
To get a hardware queue priority for a context, we are currently
mapping AMDGPU_CTX_PRIORITY_* to DRM_SCHED_PRIORITY_* and then
to hardware queue priority, which is not the right way to do that
as DRM_SCHED_PRIORITY_* is software scheduler's priority
On 8/24/2021 3:12 PM, Borislav Petkov wrote:
From: Borislav Petkov
Building a randconfig here triggered:
ERROR: modpost: "pm_suspend_target_state"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
because the module export of that symbol happens in
kernel/power/suspend.c which is
On 8/24/2021 7:10 PM, Borislav Petkov wrote:
On Tue, Aug 24, 2021 at 06:38:41PM +0530, Lazar, Lijo wrote:
Without CONFIG_PM_SLEEP and with CONFIG_SUSPEND
Can you even create such a .config?
The description of "(drm/amdgpu: fix checking pmops when PM_SLEEP is
not enabled)&
On 8/24/2021 3:12 PM, Borislav Petkov wrote:
From: Borislav Petkov
Building a randconfig here triggered:
ERROR: modpost: "pm_suspend_target_state"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
because the module export of that symbol happens in
kernel/power/suspend.c which is
On 8/24/2021 1:26 PM, Greathouse, Joseph wrote:
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, August 24, 2021 2:24 AM
To: Greathouse, Joseph ; Kuehling, Felix
; amd-
g...@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/amdkfd: Allocate SDMA engines more fairly
On 8/24
On 8/24/2021 12:19 PM, Greathouse, Joseph wrote:
-Original Message-
From: Lazar, Lijo
Sent: Monday, August 23, 2021 11:37 PM
To: Kuehling, Felix ; Greathouse, Joseph
; amd-
g...@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/amdkfd: Allocate SDMA engines more fairly
On 8/23
On 8/23/2021 10:34 PM, Felix Kuehling wrote:
Am 2021-08-23 um 3:08 a.m. schrieb Lazar, Lijo:
On 8/20/2021 11:02 AM, Joseph Greathouse wrote:
Give every process at most one queue from each SDMA engine.
Previously, we allocated all SDMA engines and queues on a first-
come-first-serve basis
On 8/20/2021 11:02 AM, Joseph Greathouse wrote:
Give every process at most one queue from each SDMA engine.
Previously, we allocated all SDMA engines and queues on a first-
come-first-serve basis. This meant that it was possible for two
processes racing on their allocation requests to each
Thanks Kees!
Reviewed-by: Lijo Lazar
Thanks,
Lijo
On 8/20/2021 1:44 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
The "Board
@lists.freedesktop.org
Cc: Deucher, Alexander ; Chen, Guchun
; Lazar, Lijo ; Pan, Xinhui
Subject: Re: [PATCH] drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on
suspend
[AMD Official Use Only]
Why not move changes into hw_fini?
Best Regards!
James Zhu
On 8/19/2021 5:29 AM, Kees Cook wrote:
On Wed, Aug 18, 2021 at 05:12:28PM +0530, Lazar, Lijo wrote:
On 8/18/2021 11:34 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
On 8/18/2021 11:34 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
Use struct_group() in structs:
struct
On 8/18/2021 2:15 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, August 17, 2021 6:09 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org; Liu,
Leo
Cc: Deucher, Alexander ; Chen, Guchun
; Pan, Xinhui
Subject: Re: [PATCH] drm
On 8/17/2021 5:19 PM, Lazar, Lijo wrote:
On 8/17/2021 4:36 PM, Michel Dänzer wrote:
On 2021-08-17 12:37 p.m., Lazar, Lijo wrote:
On 8/17/2021 3:29 PM, Michel Dänzer wrote:
On 2021-08-17 11:37 a.m., Lazar, Lijo wrote:
On 8/17/2021 2:56 PM, Michel Dänzer wrote:
On 2021-08-17 11:12
On 8/17/2021 4:36 PM, Michel Dänzer wrote:
On 2021-08-17 12:37 p.m., Lazar, Lijo wrote:
On 8/17/2021 3:29 PM, Michel Dänzer wrote:
On 2021-08-17 11:37 a.m., Lazar, Lijo wrote:
On 8/17/2021 2:56 PM, Michel Dänzer wrote:
On 2021-08-17 11:12 a.m., Lazar, Lijo wrote:
On 8/17/2021 1:53
On 8/17/2021 3:29 PM, Michel Dänzer wrote:
On 2021-08-17 11:37 a.m., Lazar, Lijo wrote:
On 8/17/2021 2:56 PM, Michel Dänzer wrote:
On 2021-08-17 11:12 a.m., Lazar, Lijo wrote:
On 8/17/2021 1:53 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back
On 8/17/2021 3:13 PM, Quan, Evan wrote:
[AMD Official Use Only]
+Leo to share his insights
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, August 17, 2021 3:28 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Chen, Guchun
; Pan, Xinhui
Subject: Re
On 8/17/2021 2:56 PM, Michel Dänzer wrote:
On 2021-08-17 11:12 a.m., Lazar, Lijo wrote:
On 8/17/2021 1:53 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
On 8/17/2021 1:53 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and
On 8/17/2021 1:21 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: amd-gfx On Behalf Of
Michel Dänzer
Sent: Monday, August 16, 2021 6:35 PM
To: Deucher, Alexander ; Koenig, Christian
Cc: Liu, Leo ; Zhu, James ; amd-
g...@lists.freedesktop.org;
On 8/17/2021 12:10 PM, Evan Quan wrote:
If the powergating of UVD/VCE is in process, wait for its completion
before proceeding(suspending). This can fix some hangs observed on
suspending when UVD/VCE still using(e.g. issue "pm-suspend" when video
is still playing).
Change-Id:
On 8/16/2021 4:05 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and
On 8/13/2021 9:30 PM, Michel Dänzer wrote:
On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
On 8/13/2021 8:10 PM, Michel Dänzer wrote:
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
On 8/13/2021 3:59 PM
On 8/13/2021 8:10 PM, Michel Dänzer wrote:
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work
On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and
On 8/13/2021 4:01 PM, Michel Dänzer wrote:
On 2021-08-13 6:23 a.m., Lazar, Lijo wrote:
On 8/12/2021 10:24 PM, Michel Dänzer wrote:
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan
On 8/12/2021 10:24 PM, Michel Dänzer wrote:
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical section is active the work should not be
active.
When you handle only one ring you can
On 8/12/2021 3:03 PM, Evan Quan wrote:
As the relationship "PWM = RPM / smu->fan_max_rpm" between fan speed
PWM and RPM is not true for SMU11 ASICs. So, both the RPM and PWM
settings need to be saved.
Change-Id: I318c134d442273d518b805339cdf383e151b935d
Signed-off-by: Evan Quan
--
v1->v2:
On 8/12/2021 2:19 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 3:53 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: nils.wallmen...@gmail.com; Chen, Guchun
Subject: Re: [PATCH V2 2/7] drm/amd/pm: record
On 8/12/2021 1:49 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 3:38 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: nils.wallmen...@gmail.com; Chen, Guchun
Subject: Re: [PATCH V2 6/7] drm/amd/pm: drop
On 8/12/2021 12:21 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 2:05 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: nils.wallmen...@gmail.com; Chen, Guchun
Subject: Re: [PATCH V2 2/7] drm/amd/pm: record
On 8/12/2021 12:16 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 2:16 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: nils.wallmen...@gmail.com; Chen, Guchun
Subject: Re: [PATCH V2 6/7] drm/amd/pm: drop
701 - 800 of 973 matches
Mail list logo
