On 7/19/2023 1:34 AM, Limonciello, Mario wrote:
[Public]
[Public]
-Original Message-
From: Limonciello, Mario
Sent: Thursday, July 13, 2023 00:15
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario
Subject: [PATCH] drm/amd: Fix an error handling mistake in psp_sw_init()
If t
drivers/gpu/drm/amd/amdgpu/atom.c: In function ‘amdgpu_atom_parse’:
drivers/gpu/drm/amd/amdgpu/atom.c:1468:6: warning: unused variable ‘idx’
[-Wunused-variable]
1468 | u16 idx;
| ^~~
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/
Convert macros to functions to fix the following & for better readability:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.h:26: Macro argument reuse 'adev' -
possible side-effects?
drivers/gpu/drm/amd/amdgpu/amdgpu_display.h:32: Macro argument reuse 'adev' -
possible side-effects?
drivers/gpu/drm/amd
From: Srinivasan Shanmugam
Fixes the following checkpatch.pl:
WARNING: printk() should include KERN_ facility level
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 10 +-
1 file changed, 5 insertions(+), 5 d
Srinivasan Shanmugam (2):
drm/amd/display: Convert macros to functions in amdgpu_display.c &
amdgpu_display.h
drm/radeon: Prefer dev_warn over printk
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 118 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.h | 46 ++--
driver
[Public]
Please ignore this patch, will send another one after more rework is done.
Regards,
Guchun
> -Original Message-
> From: Chen, Guchun
> Sent: Wednesday, July 19, 2023 12:52 PM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Zhang, Hawking
> ; Koenig, Christian
> ; La
[Public]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, July 19, 2023 12:53 PM
> To: Chen, Guchun ; Zhu, James
> ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kamal, Asad
> ; Zhang, Hawking
> Subject: Re: [PATCH] drm/amdgpu: Update ring scheduler info as needed
On 7/19/2023 10:12 AM, Chen, Guchun wrote:
[Public]
-Original Message-
From: amd-gfx On Behalf Of Lazar,
Lijo
Sent: Wednesday, July 19, 2023 12:13 AM
To: Zhu, James ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhu, James
; Kamal, Asad ; Zhang,
Hawking
Subject: Re: [PATC
amdgpu_test_ring_helper will set sched.ready unconditionally
based on ring test result, this will lead value mismatch between
ring->sched.ready and no_scheduler for those rings without a kernel
scheluer, after they perform ring test. This will be confused as
kernel ring no_scheduler is true, but ri
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Lazar,
> Lijo
> Sent: Wednesday, July 19, 2023 12:13 AM
> To: Zhu, James ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Zhu, James
> ; Kamal, Asad ; Zhang,
> Hawking
> Subject: Re: [PATCH] drm/amdgpu: Update ring sche
[AMD Official Use Only - General]
> -Original Message-
> From: Andrew Lunn
> Sent: Tuesday, July 18, 2023 10:16 PM
> To: Quan, Evan
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolut
[Public]
Hi Jonathan,
Your change looks fine.
Acknowledged-by: Ji, Ruili
Thanks,
Ruili
-Original Message-
From: Kim, Jonathan
Sent: Wednesday, July 19, 2023 6:13 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Ji, Ruili
Subject: RE: [PATCH 1/2] drm/amdkfd: fix trap handlin
[Public]
Thank for your test, Mike. After getting RB for this patch, I will ask
Christian to apply it to corresponding branches like drm-misc-next.
Regards,
Guchun
> -Original Message-
> From: Mikhail Gavrilov
> Sent: Tuesday, July 18, 2023 5:17 PM
> To: Chen, Guchun
> Cc: Koenig, Chr
[Public]
+ Ruiji Li as this is a follow up to
commit 52223c7e74d124bea47beec467e59fdfc77559fc
Author: Ruili Ji
Date: Tue Jun 6 14:06:01 2023 +0800
drm/amdkfd: To enable traps for GC_11_0_4 and up
Flag trap_en should be enabled for trap handler.
Signed-off-by: Ruili Ji
Signe
Am 2023-07-14 um 05:37 schrieb Jonathan Kim:
MES can concurrently schedule queues on the device that require
exclusive device access if marked exclusively_scheduled without the
requirement of GWS. Similar to the F32 HWS, MES will manage
quality of service for these queues.
Use this for coopera
[Public]
> -Original Message-
> From: Limonciello, Mario
> Sent: Thursday, July 13, 2023 00:15
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario
> Subject: [PATCH] drm/amd: Fix an error handling mistake in psp_sw_init()
>
> If the second call to amdgpu_bo_create_kernel() fails
On Tue, Jul 18, 2023 at 2:03 PM Mario Limonciello
wrote:
>
> The VBIOS part number is read both in amdgpu_atom_parse() as well
> as in atom_get_vbios_pn() and stored twice in the `struct atom_context`
> structure. Remove the first unnecessary read and move the `pr_info`
> line from that read into
An instance of for_each_inst() was not changed to match its new
behaviour and is causing a loop.
Fixes: 50c1d81d6365 ("drm/amdgpu: Modify for_each_inst macro")
Signed-off-by: Victor Lu
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm
The VBIOS part number is read both in amdgpu_atom_parse() as well
as in atom_get_vbios_pn() and stored twice in the `struct atom_context`
structure. Remove the first unnecessary read and move the `pr_info`
line from that read into the second.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/
On Mon, Jul 17, 2023 at 03:29:23PM -0700, Samuel Holland wrote:
> clang on RISC-V appears to be unaffected by the bug causing excessive
> stack usage in calculate_bandwidth(). clang 16 with -fstack-usage
> reports a 304 byte stack frame size with CONFIG_ARCH_RV32I, and 512
> bytes with CONFIG_ARCH_
On 7/18/2023 9:39 PM, James Zhu wrote:
On 2023-07-18 11:54, Lazar, Lijo wrote:
On 7/18/2023 8:39 PM, James Zhu wrote:
On 2023-07-18 10:19, Lazar, Lijo wrote:
On 7/18/2023 7:30 PM, James Zhu wrote:
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only u
On 2023-07-18 11:54, Lazar, Lijo wrote:
On 7/18/2023 8:39 PM, James Zhu wrote:
On 2023-07-18 10:19, Lazar, Lijo wrote:
On 7/18/2023 7:30 PM, James Zhu wrote:
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only update scheduler
data for
rings with sche
On 7/18/2023 8:39 PM, James Zhu wrote:
On 2023-07-18 10:19, Lazar, Lijo wrote:
On 7/18/2023 7:30 PM, James Zhu wrote:
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only update scheduler data for
rings with scheduler. It could result in out of bound acce
On Wed, 12 Jul 2023 at 16:25, Kefeng Wang wrote:
>
> Introduce the two helpers for general use.
>
> Signed-off-by: Kefeng Wang
> ---
> include/linux/mm.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1462cf15badf..0bbeb31ac
On 2023-07-18 10:19, Lazar, Lijo wrote:
On 7/18/2023 7:30 PM, James Zhu wrote:
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only update scheduler data for
rings with scheduler. It could result in out of bound access as total
rings are more than those asso
I'm happy to apply these patches, but please check your mailer. The
formatting is messed up and they don't apply cleanly. Please use
git-format-patch and git-send-email to generate and send the patches.
Thanks!
Alex
On Fri, Jul 14, 2023 at 3:15 AM wrote:
>
> Fix four occurrences of the checkp
I'm happy to apply these patches, but please check your mailer. The
formatting is messed up and they don't apply cleanly. Please use
git-format-patch and git-send-email to generate and send the patches.
Thanks!
Alex
On Fri, Jul 14, 2023 at 2:04 AM wrote:
>
> Fix the checkpatch error as open b
> The wbrf_supported_producer and wbrf_supported_consumer APIs seem
> unnecessary for the generic implementation.
I'm happy with these, once the description is corrected. As i said in
another comment, 'can' should be replaced with 'should'. The device
itself knows if it can, only the core knows if
On 7/18/2023 7:30 PM, James Zhu wrote:
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only update scheduler data for
rings with scheduler. It could result in out of bound access as total
rings are more than those associated with particular IPs.
Signed-off-by
On 2023-07-18 08:21, Lijo Lazar wrote:
Not all rings have scheduler associated. Only update scheduler data for
rings with scheduler. It could result in out of bound access as total
rings are more than those associated with particular IPs.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/am
Reviewed-by: Leo Liu
On 2023-07-17 23:20, sguttula wrote:
This patch will enable VCN FW workaround using
DRM KEY INJECT WORKAROUND method,
which is helping in fixing the secure playback.
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message as per veera's feedback
Changes in v
Reviewed-by: Leo Liu
On 2023-07-17 13:27, sguttula wrote:
This patch will enable secure decode playback on VCN4_0_2
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message only enabling for VCN402
-updated the logic as per Leo's feedback
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
Not all rings have scheduler associated. Only update scheduler data for
rings with scheduler. It could result in out of bound access as total
rings are more than those associated with particular IPs.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c | 2 +-
1 file changed,
Hi Thomas,
On 15/07/2023 20:51, Thomas Zimmermann wrote:
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by kzalloc(). So do not
> set it.
>
> Flags should signal differences from the default values. After cleaning
> up all occurrences of
[AMD Official Use Only - General]
Personally I would like to treat the wbrf core as a water pool. Any stream can
flow in. Also any needed can drain water from it at any time.
The way to allow producers to report only when there is consumer existing does
not work. Since the consumer might come af
On Tue, Jul 18, 2023 at 7:13 AM Chen, Guchun wrote:
>
> [Public]
>
> Hello Mike,
>
> I guess this patch can resolve your problem.
> https://patchwork.freedesktop.org/patch/547897/
>
> Regards,
> Guchun
>
Tested-by: Mikhail Gavrilov
Thanks, the issue was gone with this patch.
I didn't say anythi
[why]
User mode driver need to check the sdma ucode version to
see whether the sdma engine supports a new type of PM4 packet.
In SRIOV, sdma is loaded by the host. And, there is no way
to check the sdma ucode version of CHIP_NAVI12 and
CHIP_SIENNA_CICHLID of the host in the guest machine.
[how]
Lo
On 2023/7/17 18:25, David Hildenbrand wrote:
On 12.07.23 16:38, Kefeng Wang wrote:
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
fs/proc/task_mmu.c | 24
fs/proc/task_nommu.c | 15 +--
2 files changed, 5 insertions(+), 34 deletio
clang on RISC-V appears to be unaffected by the bug causing excessive
stack usage in calculate_bandwidth(). clang 16 with -fstack-usage
reports a 304 byte stack frame size with CONFIG_ARCH_RV32I, and 512
bytes with CONFIG_ARCH_RV64I.
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/amd/display
39 matches
Mail list logo
