Fix the pwm_mode value error which used for
pwm1_enable setting
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index
[Public]
> -Original Message-
> From: Zhang, Jesse(Jie)
> Sent: Friday, March 1, 2024 12:50 AM
> To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Zhang, Yifan
> Subject: RE: [PATCH] drm/amdkfd: fix shift out of bounds about gpu debug
>
>
[Public]
Hi Jon,
-Original Message-
From: Kim, Jonathan
Sent: Thursday, February 29, 2024 11:58 PM
To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Zhang, Yifan ; Zhang,
Jesse(Jie) ; Zhang, Jesse(Jie)
Subject: RE: [PATCH] drm/amdkfd:
From: Swapnil Patel
[ Upstream commit 27a6c49394b1a203beeb94752c9a1d6318f24ddf ]
[Why]
Currently there is an error while translating input clock sates into
output clock states. The highest fclk setting from output sates is
being dropped because of this error.
[How]
For dcn35 and dcn351, make
Applied. Thanks!
On Thu, Feb 29, 2024 at 1:11 PM Bjorn Helgaas wrote:
>
> From: Bjorn Helgaas
>
> After 4020c2280233 ("drm/amdgpu: don't runtime suspend if there are
> displays attached (v3)"), "ret" is unconditionally set later before being
> used, so there's point in initializing it and the
From: Bjorn Helgaas
After 4020c2280233 ("drm/amdgpu: don't runtime suspend if there are
displays attached (v3)"), "ret" is unconditionally set later before being
used, so there's point in initializing it and the associated comment is no
longer meaningful.
Remove the comment and the unnecessary
On 26/02/2024 17:52, Philip Yang wrote:
On 2024-02-23 08:42, Shashank Sharma wrote:
This patch:
- adds a new list in amdgou_vm to hold the VM PT entries being freed
- waits for the TLB flush using the vm->tlb_flush_fence
- actually frees the PT BOs
V2: rebase
V3: Do not attach the
[Public]
I think this was discussed in another thread.
Exception codes should be range checked prior to applying the mask. Raising
null events to the debugger or runtime isn't useful.
I haven't gotten around to fixing this yet. I should have time this week.
Just to double check, the out of
On Wed, Feb 28, 2024 at 9:45 AM Christian König
wrote:
>
> Am 28.02.24 um 15:23 schrieb Alex Deucher:
> > On Wed, Feb 28, 2024 at 2:03 AM Christian König
> > wrote:
> >> Am 27.02.24 um 19:48 schrieb Alex Deucher:
> >>> This reverts commit e94e787e37b99645e7c02d20d0a1ba0f8a18a82a.
> >>>
> >>>
Applied. Thanks!
On Tue, Feb 27, 2024 at 2:08 PM Melissa Wen wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683
> amdgpu_dm_connector_funcs_force()
> warn: variable dereferenced before check 'dc_link' (see line 6663)
>
> Fixes: 967176179215 ("drm/amd/display: fix
On Thu, Feb 29, 2024 at 9:58 AM Christian König
wrote:
>
> It turned out that executing the SET_Q_MODE packet on every submission
> creates to much overhead.
>
> Implement a workaround which allows skipping the SET_Q_MODE packet if
> subsequent submissions all use the same parameters.
>
>
On 2/29/24 10:43, Daniel Vetter wrote:
On Mon, Feb 26, 2024 at 04:10:14PM -0500, Harry Wentland wrote:
This is an RFC set for a color pipeline API, along with a sample
implementation in VKMS. All the key API bits are here. VKMS now
supports two named transfer function colorops and two matrix
Hi Dave, Sima,
Fixes for 6.8.
The following changes since commit d206a76d7d2726f3b096037f2079ce0bd3ba329b:
Linux 6.8-rc6 (2024-02-25 15:46:06 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.8-2024-02-29
for you to fetch
First of all calculating the number of dw to patch into a
conditional execution is not something HW generation specific.
This is just standard ring buffer calculations. While at it also
reduce the BUG_ON() into WARN_ON().
Then instead of a random bit pattern use 0 as default value for
the number
It turned out that executing the SET_Q_MODE packet on every submission
creates to much overhead.
Implement a workaround which allows skipping the SET_Q_MODE packet if
subsequent submissions all use the same parameters.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
On 2/29/2024 4:40 PM, Ma, Jun wrote:
> Hi Lijo,
>
> On 2/29/2024 3:33 PM, Lazar, Lijo wrote:
>>
>>
>> On 2/29/2024 11:49 AM, Ma Jun wrote:
>>> Check return value of amdgpu_device_baco_enter/exit and print
>>> warning message because these errors may cause runtime resume failure
>>>
>>>
Am 29.02.24 um 06:51 schrieb Jesse.Zhang:
fix the issue:
"amdgpu: Failed to create process VM object".
[Why]when amdgpu initialized, seq64 do mampping and update bo mapping in vm
page table.
But when clifo run. It also initializes a vm for a process device through the
function
Hi Lijo,
On 2/29/2024 3:33 PM, Lazar, Lijo wrote:
>
>
> On 2/29/2024 11:49 AM, Ma Jun wrote:
>> Check return value of amdgpu_device_baco_enter/exit and print
>> warning message because these errors may cause runtime resume failure
>>
>> Signed-off-by: Ma Jun
>> ---
>>
On Mon, Feb 26, 2024 at 04:10:14PM -0500, Harry Wentland wrote:
> This is an RFC set for a color pipeline API, along with a sample
> implementation in VKMS. All the key API bits are here. VKMS now
> supports two named transfer function colorops and two matrix
> colorops. We have IGT tests that
the issue is :
[ 388.151802] UBSAN: shift-out-of-bounds in
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_int_process_v10.c:346:5
[ 388.151807] shift exponent 4294967295 is too large for 64-bit type 'long
long unsigned int'
[ 388.151812] CPU: 6 PID: 347 Comm: kworker/6:1H Tainted: GE
20 matches
Mail list logo
