Am 05.07.23 um 21:57 schrieb Rajneesh Bhardwaj:
Early release TTM BOs when the kernel default setting is init_on_free to
wipe out and reinitialize system memory chunks.
"Delay release the TTM BO when the kernels init_on_free setting is used."
This could potentially
optimize performance when
On 7/5/23 19:28, Zhang, Hawking wrote:
[AMD Official Use Only - General]
The change doesn't make sense at all, especially for some ASIC where it is
allowed enable/disable RAS config through RAS TA. i.e. set ras_enable==0 and
the issue commands to RAS TA to change the RAS config.
It doesn't ma
On 7/5/23 21:58, Quan, Evan wrote:
[AMD Official Use Only - General]
Hi Andrew,
I discussed with Mario about your proposal/concerns here.
We believe some changes below might address your concerns.
- place/move the wbrf_supported_producer check inside
acpi_amd_wbrf_add_exclusion and acpi_amd_wb
[AMD Official Use Only - General]
Hi Andrew,
I discussed with Mario about your proposal/concerns here.
We believe some changes below might address your concerns.
- place/move the wbrf_supported_producer check inside
acpi_amd_wbrf_add_exclusion and acpi_amd_wbrf_add_exclusion
- place the wbrf_sup
[AMD Official Use Only - General]
One small nitpick:
It seems there is missing a default clause for the switch statement.
Will that hit the compile warning about "a switch statement must have a default
clause"?
With that checked, the series is reviewed-by: Evan Quan
Evan
> -Original Message
[AMD Official Use Only - General]
The change doesn't make sense at all, especially for some ASIC where it is
allowed enable/disable RAS config through RAS TA. i.e. set ras_enable==0 and
the issue commands to RAS TA to change the RAS config.
It doesn't matter whether ras code path is enabled or
Since GFX9 GPU has multiple xcc instances, this is to
implement this change in KFD for debugger APIs.
Signed-off-by: Eric Huang
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c| 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_
Eric Huang (1):
drm/amdkfd: add xcc instance for debugger APIs
Jonathan Kim (4):
drm/amdgpu: add kfd2kgd debugger callbacks for GC v9.4.3
drm/amdkfd: restore debugger additional info for gfx v9_4_3
drm/amdkfd: enable watch points globally for gfx943
drm/amdkfd: add multi-process debuggin
From: Jonathan Kim
Similar to GC v9.4.2, GC v9.4.3 should use the 5-Dword extended
MAP_PROCESS packet to support multi-process debugging. Update the
mutli-process debug support list so that the KFD updates the runlist
on debug mode setting and that it allocates enough GTT memory during
KFD devic
From: Jonathan Kim
Set watch points for all xcc instances on GFX943.
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
Signed-off-by: Eric Huang
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c | 6 --
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 16 ++--
2 f
From: Jonathan Kim
The additional information that the KFD reports to the debugger was
destroyed when the following commit was merged:
"drm/amdkfd: convert switches to IP version checking"
Signed-off-by: Jonathan Kim
Reviewed-by: Harish Kasiviswanathan
Signed-off-by: Jonathan Kim
Acked-by: Am
From: Jonathan Kim
Implement the similarities as GC v9.4.2, and the difference
for GC v9.4.3 HW spec.
Signed-off-by: Jonathan Kim
Signed-off-by: Eric Huang
---
.../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 7 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.h | 30
.../drm/amd/amdgpu/
It looks good to me. The series is:
Reviewed-by: Leo Liu
On 2023-06-27 00:48, Lang Yu wrote:
Replace the old ones with psp_execute_load_ip_fw_cmd_buf.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 31 -
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
What Christian says is correct, esp. during the playback or encode, when
suspend/resume happens, it will save the FW context, and after resume,
it will continue the job to where it left during the suspend. Will this
apply to SRIOV case? Since the changes only within the SRIOV code,
please make
Early release TTM BOs when the kernel default setting is init_on_free to
wipe out and reinitialize system memory chunks. This could potentially
optimize performance when an application does a lot of malloc/free style
allocations with unified system memory.
Signed-off-by: Rajneesh Bhardwaj
---
dr
On 7/5/23 14:07, Aurabindo Pillai wrote:
From: Wesley Chalmers
[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
pipe commit can cause underflow.
[HOW]
Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
optimized_required.
This change expects tha
On Wed, Jul 5, 2023 at 2:07 PM Mario Limonciello
wrote:
>
> Sapphire rapids is reported to have problems with Navi3x dGPUs where the
> screen freezes and the following message is in the logs:
> ```
> [CRTC:56:crtc-0] flip_done timed out
> ```
>
> These issues go away when ASPM has been disabled. E
From: Wesley Chalmers
[WHY]
It is possible to commit state multiple times in rapid succession with
FAMS enabled; if each of these commits were to set optimized_required,
then the user may see latency.
[HOW]
fw_based_mclk_switching is currently not used in dc->clk_mgr; use it
to track whether the
From: Wesley Chalmers
[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
pipe commit can cause underflow.
[HOW]
Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
optimized_required.
This change expects that Freesync requests are blocked when
optimi
Sapphire rapids is reported to have problems with Navi3x dGPUs where the
screen freezes and the following message is in the logs:
```
[CRTC:56:crtc-0] flip_done timed out
```
These issues go away when ASPM has been disabled. Extend the disablement
for Sapphire Rapids.
Reported-by: Koba Ko
Closes
More failures are reported across additional products and so it seems
unless we have a handle on the fundmental ASPM incompatibilities with
Intel host and AMD dGPU, we should not allow them on problematic hosts.
Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Signed-off-by: Mario Limonc
On hardware known not to have RAS or in cases that a user has disabled
RAS via kernel module parameter, it makes no sense to try to run code
from psp_ras_initialize(). Furthermore trying to run it shows the
following message on every boot:
`RAS: optional ras ta ucode is not available`
Avoid runn
On Wed, Jul 5, 2023 at 5:17 PM Geert Uytterhoeven
wrote:
>
> On 32-bit:
>
> ../tests/amdgpu/amdgpu_stress.c: In function ‘alloc_bo’:
> ../tests/amdgpu/amdgpu_stress.c:178:49: warning: format ‘%lx’ expects
> argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka
> ‘
Looks good to me.
The patch set is Reviewed-by: Veerabadhran Gopalakrishnan
Regards,
Veera
On 6/27/2023 10:18 AM, Lang Yu wrote:
This function is more general and easy to use by more clients.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 29
On Wed, Jul 5, 2023 at 3:32 AM Michel Dänzer wrote:
>
> On 7/5/23 08:30, Marek Olšák wrote:
> > On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote:
> > On 7/4/23 04:34, Marek Olšák wrote:
> > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > > wrote:
> > > On 6/30/23 22:32, Marek Olšák wr
On 32-bit:
../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../amdgpu/amdgpu_bo.c:554:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
cpu < (void*)((uintptr_t)bo->cpu_ptr + bo->alloc_size))
^
Indeed, as am
On 32-bit:
../tests/amdgpu/amdgpu_stress.c: In function ‘alloc_bo’:
../tests/amdgpu/amdgpu_stress.c:178:49: warning: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Allocated B
On Wed, 05 Jul 2023 14:17:20 +0200,
Alex Deucher wrote:
>
> On Wed, Jul 5, 2023 at 2:26 AM Takashi Iwai wrote:
> >
> > Hi Dave, Alex,
> >
> > it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
> > due to the missing signed tag:
> >
> > https://lore.kernel.org/lkml/CAHk-=wiOCg
Am 04.07.23 um 17:24 schrieb Arnd Bergmann:
On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
Modern AMD GPUs have 16GiB of local memory (VRAM), making those
accessible to a CPU which can only
make clk_mgr_base->clks.zstate_support avoid double assignment.
It looks like the value of new_clocks is unchanged, so there
may be no need for repeated assignments.
Signed-off-by: Minjie Du
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 1 -
1 file changed, 1 deletion(-)
On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
> Am 04.07.23 um 14:24 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
>>> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> Not sure I understand the specific requirement. Do you mean the entire
>> amdgpu driver req
> > What is the purpose of this stage? Why would it not be supported for this
> > device?
> This is needed for wbrf support via ACPI mechanism. If BIOS(AML code) does
> not support the wbrf adding/removing for some device,
> it should speak that out so that the device can be aware of that.
How mu
On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
> Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
>>>
>>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those
>>> accessible to a CPU which can only handle 32bit addresses by resiz
Simulator cannot be changed
To join the meeting on Google Meet, click this link:
https://meet.google.com/ccm-jjwz-ehk
Or open Meet and enter this code: ccm-jjwz-ehk
On Mon, Jul 3, 2023, 11:33 AM André Almeida wrote:
>
>
> Em 03/07/2023 05:38, Pekka Paalanen escreveu:
> > On Fri, 30 Jun 2023 23
On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> From: Arnd Bergmann
>>
>> On 32-bit architectures comparing a resource against a value larger than
>> U32_MAX can cause a warning:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error:
On Wed, Jul 5, 2023 at 2:26 AM Takashi Iwai wrote:
>
> Hi Dave, Alex,
>
> it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
> due to the missing signed tag:
>
> https://lore.kernel.org/lkml/CAHk-=wiOCgiwzVPOwORHPML9eBphnbtM2DhRcv+v=-tnrrg...@mail.gmail.com/
>
> And more impor
On 07/05/ , Matthew Auld wrote:
> On Wed, 5 Jul 2023 at 11:08, Lang Yu wrote:
> >
> > bo->kref is increased once(kref_init()) in ttm_bo_release,
> > but decreased twice(ttm_bo_put()) respectively in
> > ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
> > which is unbalanced.
> >
> > Just clean up b
On Wed, 5 Jul 2023 at 11:08, Lang Yu wrote:
>
> bo->kref is increased once(kref_init()) in ttm_bo_release,
> but decreased twice(ttm_bo_put()) respectively in
> ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
> which is unbalanced.
>
> Just clean up bo resource in one place for a delayed deleted bo
bo->kref is increased once(kref_init()) in ttm_bo_release,
but decreased twice(ttm_bo_put()) respectively in
ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
which is unbalanced.
Just clean up bo resource in one place for a delayed deleted bo.
Fixes: 9bff18d13473 ("drm/ttm: use per BO cleanup worke
On 7/4/23 19:06, Sebastian Wick wrote:
> On Sat, Jul 1, 2023 at 4:09 AM André Almeida wrote:
>>
>> @@ -949,6 +949,15 @@ struct hdr_output_metadata {
>> * Request that the page-flip is performed as soon as possible, ie. with no
>> * delay due to waiting for vblank. This may cause tearing to be
I was just to complain that this is certainly incorrect.
But it's strange that ttm_mem_evict_first causes the warning in the
first place since it should never try to evict a BO which is about to be
destroyed.
Regards,
Christian.
Am 05.07.23 um 10:31 schrieb Lang Yu:
Please ignore this patch
Please ignore this patch, it will cause another issue.
Will send a new one.
Regards,
Lang
On 07/05/ , Lang Yu wrote:
> [ 67.399887] refcount_t: underflow; use-after-free.
> [ 67.399901] WARNING: CPU: 0 PID: 3172 at lib/refcount.c:28
> refcount_warn_saturate+0xc2/0x110
> [ 67.400124] RIP:
On 7/5/23 08:30, Marek Olšák wrote:
> On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote:
> On 7/4/23 04:34, Marek Olšák wrote:
> > On Mon, Jul 3, 2023, 03:12 Michel Dänzer
> wrote:
> > On 6/30/23 22:32, Marek Olšák wrote:
> > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer
[AMD Official Use Only - General]
Reviewed-by: Asad Kamal
-Original Message-
From: Ma, Le
Sent: Wednesday, July 5, 2023 11:52 AM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Gadre, Mangesh
Subject: RE: [PATCH] drm/amdgpu: Rem
44 matches
Mail list logo
