Am 22.02.24 um 18:28 schrieb Michel Dänzer:
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Thinking more about it I don't think we can do this.
Using the BO in a ping/pong fashion for scanout and DMA-buf is actually
This patch fixes a MES firmware boot failure issue
when backdoor loading the MES firmware.
MES firmware runtime DRAM size is changed to 512k,
the driver needs to reserve this amount of memory in
FB, otherwise adjacent memory will be overwritten by
the MES firmware startup code.
Signed-off-by:
On devices which have multi-partition nodes, keep partition id in
location_id[31:28].
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 45
[AMD Official Use Only - General]
> From: Alex Deucher
> Sent: Friday, February 23, 2024 1:03 AM
> To: Liang, Prike
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>
> Subject: Re: [PATCH] drm/amdgpu: Enable gpu reset for S3 abort cases on
> Raven series
>
> On Thu, Feb 22, 2024 at
Hi Dave, Sima,
Fixes for 6.8.
The following changes since commit b401b621758e46812da61fa58a67c3fd8d91de0d:
Linux 6.8-rc5 (2024-02-18 12:56:25 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.8-2024-02-22
for you to fetch
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1] [2].
In this case, the memory allocated to store RADEONFB_CONN_LIMIT pointers
to "drm_connector" structures can be avoided. This is because this
memory area is never accessed.
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Also keep file_priv->prime.lock locked until after bumping bo->num_fbs
in amdgpu_display_user_framebuffer_create, so that the checks there and
in amdgpu_dma_buf_attach are
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10635
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 38 ++---
1
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
On Thu, Feb 22, 2024 at 8:41 AM Prike Liang wrote:
>
> Currently, GPU resets can now be performed successfully on the Raven
> series. While GPU reset is required for the S3 suspend abort case.
> So now can enable gpu reset for S3 abort cases on the Raven series.
>
> Signed-off-by: Prike Liang
>
From: Maíra Canal
Explain how to run the KUnit tests present in the AMDGPU's Display
Core and clarify which architectures and tools can be used to run
the tests. Moreover, explains how to add new tests to the existing
tests.
Signed-off-by: Maíra Canal
---
From: Magali Lemes
This commit adds unit tests to the functions dcn20_cap_soc_clocks and
dcn21_update_bw_bounding_box from dcn20/dcn20_fpu.
Signed-off-by: Magali Lemes
Signed-off-by: Maíra Canal
---
.../gpu/drm/amd/display/test/kunit/Makefile | 3 +-
From: Maíra Canal
Add a unit test to the SubVP feature in order to avoid possible
regressions and ensure code robustness. In particular, this new test
validates the expected parameters when using 4k144 and 4k240 displays.
Signed-off-by: Maíra Canal
Co-developed-by: Rodrigo Siqueira
From: Maíra Canal
The display_mode_vba_20 deals with hundreds of display parameters for
the DCN20 and sometimes does it in odd ways. The addition of unit tests
intends to assure the quality of the code delivered by HW engineers and,
also make it possible to refactor the code decreasing concerns
From: Maíra Canal
The display_mode_vba library deals with hundreds of display parameters
and sometimes does it in odd ways. The addition of unit tests intends to
assure the quality of the code delivered by HW engineers and, also make
it possible to refactor the code decreasing concerns about
From: Maíra Canal
KUnit unifies the test structure and provides helper tools that simplify
the development of tests. Basic use case allows running tests as regular
processes, which makes easier to run unit tests on a development machine
and to integrate the tests in a CI system.
This commit
From: Isabella Basso
This adds tests to the bit encoding format verification functions on the
file. They're meant to be simpler so as to provide a proof of concept on
testing DML code.
Change since v4:
- Use DRM_AMD_DC_FP guard for FPU tests
Signed-off-by: Isabella Basso
Signed-off-by: Maíra
From: Tales Aparecida
The fixed31_32 library performs a lot of the mathematical operations
involving fixed-point arithmetic and the conversion of integers to
fixed-point representation.
This unit tests intend to assure the proper functioning of the basic
mathematical operations of fixed-point
In 2022, we got a great patchset from a GSoC project introducing unit
tests to the amdgpu display. Since version 3, this effort was put on
hold, and now I'm attempting to revive it. I'll add part of the original
cover letter at the bottom of this cover letter, but you can read all
the original
On 2024-02-21 21:01, Lang Yu wrote:
This is useful to prevent copy-on-write semantics
from changing the physical location of a page if
the parent writes to it after a fork().
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
Reviewed-by: Roman Li
> -Original Message-
> From: SHANMUGAM, SRINIVASAN
> Sent: Wednesday, February 21, 2024 11:37 PM
> To: Siqueira, Rodrigo ; Pillai, Aurabindo
> ; Chung, ChiaHsuan (Tom)
> ; Li, Roman
> Cc: amd-gfx@lists.freedesktop.org; SHANMUGAM, SRINIVASAN
> ; Zhuo, Lillian
>
>
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abort cases on the Raven series.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 45
Hi Christian,
On 2/21/2024 7:58 PM, Christian König wrote:
Am 21.02.24 um 13:18 schrieb Arunpravin Paneer Selvam:
Add a function to support defragmentation.
Thinking more about it maybe you want to call this function differently.
Essentially we are force merging pages even if their cleared
[AMD Official Use Only - General]
Series is Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Thursday, February 22, 2024 3:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kuehling, Felix ; Joshi,
Mukul ;
Le 16/02/2024 à 17:24, Ville Syrjälä a écrit :
On Fri, Feb 16, 2024 at 04:09:55PM +0100, Pierre-Eric Pelloux-Prayer wrote:
With this and the dma_fence_used_as_dependency event, a tool can draw the
relationship between the compositing draw, the atomic commit, and vblank.
An example on a 2
If fatal error is detected, packet submission won't go through. Return
error in such cases. Also, avoid waiting for fence when fatal error is
detected.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
For a RAS error that needs a full reset to recover, set the fatal error
status. Clear the status once the device is reset.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 32 ++
Am 20.02.24 um 15:37 schrieb Lazar, Lijo:
On 2/20/2024 7:52 PM, Christian König wrote:
Am 20.02.24 um 07:32 schrieb Lazar, Lijo:
On 2/16/2024 8:43 PM, Alex Deucher wrote:
Use the new reset critical section accessors for debugfs, sysfs,
and the INFO IOCTL to provide proper mutual exclusivity
Am 21.02.24 um 19:01 schrieb Rodrigo Siqueira Jordao:
[SNIP]
diff --git
a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource_helpers.c
index 87760600e154..e179dea148e7 100644
---
So that's what its about. Somehow I knew it all along. Not long ago, I
posted this on reddit:
https://www.reddit.com/r/Amd/comments/183gye7/rx_6700xt_from_230w_to_capped_115w_at_only_10/
That was 3 months ago. Now suddenly AMD *require*("..hardware engineers
have explicitly pointed out that
Hi Vitaly,
Thank you for looking into this issue!
We have reproduced this issue with a Radeon RX 580 (Polaris 20)
passthrough-ed to a QEMU (4.0.0) VM by VFIO.
All bugs were reproducible on the recent 6.8-rc4 Linux kernel (
https://github.com/torvalds/linux/tree/v6.8-rc4), which I double checked
[+Linus, as we seem to have reached the point in the discussion about
this regression where that is likely for the best.
And just for the record: I'm *not* doing that because I'm disappointed,
angry, or something. I can relate to the point that was made in the mail
I'm replying to. It's just that
On 21.02.24 16:39, Alex Deucher wrote:
> On Wed, Feb 21, 2024 at 1:06 AM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>>
>> On 20.02.24 21:18, Alex Deucher wrote:
>>> On Tue, Feb 20, 2024 at 2:41 PM Romano wrote:
If the increased low range is allowed via boot option, like in
He is my proposal:
On boot, read chip values into min_cap, default_cap, max_cap and set
them, satisfying AMD's requirement.
Do not introduce any new boot flags, keeping things simple.
Keep def_cap and max_cap readonly to protect HW.
Make min_cap readwrite: "echo 1234 > /sys/...min_cap".
No
35 matches
Mail list logo
