On Sun, Aug 25, 2024 at 2:12 AM Mikhail Gavrilov
wrote:
>
> Hi,
> Is anyone trying to look into it?
> I continue to reproduce this issue on fresh kernel builds 6.11-rc4+.
> In addition to the RenPy engine, the problem also reproduces on games
> from Ubisoft, such as Far Cry 4.
> A very important n
On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote:
> From: Tobias Jakobi
>
> dc_state_destruct() nulls the resource context of the DC state. The pipe
> context passed to dcn10_set_drr() is a member of this resource context.
>
> If dc_state_destruct() is called parallel to the IRQ processing (which
On 30/08/2024 10:40, Thomas Zimmermann wrote:
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The mediatek driver specifies a preferred color mode of 32. As this
is the
Applied amdgpu patches. Thanks!
On Fri, Aug 30, 2024 at 10:19 AM Christian König
wrote:
>
> Am 30.08.24 um 03:22 schrieb Li Zetao:
> > When it needs to get a value within a certain interval, using clamp()
> > makes the code easier to understand than min(max()).
> >
> > Signed-off-by: Li Zetao
>
Applied. Thanks!
On Fri, Aug 30, 2024 at 3:27 AM Lu Yao wrote:
>
> From: Peng Liu
>
> Enabling gfxoff quirk results in perfectly usable
> graphical user interface on HP 705G4 DM with R5 2400G.
>
> Without the quirk, X server is completely unusable as
> every few seconds there is gpu reset due t
Applied. Thanks!
On Fri, Aug 30, 2024 at 3:26 AM Lu Yao wrote:
>
> From: Peng Liu
>
> Fix screen corruption with openkylin.
>
> Link: https://bbs.openkylin.top/t/topic/171497
> Signed-off-by: Peng Liu
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>
Applied. Thanks!
On Wed, Aug 28, 2024 at 5:43 AM Colin Ian King wrote:
>
> There is a spelling mistake in a DRM_DEBUG_DRIVER message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
From: Tobias Jakobi
dc_state_destruct() nulls the resource context of the DC state. The pipe
context passed to dcn10_set_drr() is a member of this resource context.
If dc_state_destruct() is called parallel to the IRQ processing (which
calls dcn10_set_drr() at some point), we can end up using al
> From: Tobias Jakobi
>
> dc_state_destruct() nulls the resource context of the DC state. The
> pipe
> context passed to dcn10_set_drr() is a member of this resource
> context.
>
> If dc_state_destruct() is called parallel to the IRQ processing
> (which
> calls dcn10_set_drr() at some point), we c
From: Tobias Jakobi
dc_state_destruct() nulls the resource context of the DC state. The pipe
context passed to dcn35_set_drr() is a member of this resource context.
If dc_state_destruct() is called parallel to the IRQ processing (which
calls dcn35_set_drr() at some point), we can end up using al
From: Tobias Jakobi
Hello,
this fixes a nasty race condition in the set_drr() callbacks for DCN10
and DCN35 that has existed now since quite some time, see this GitLab
issue for reference.
https://gitlab.freedesktop.org/drm/amd/-/issues/3142
The report just focuses von DCN10, but the same prob
> From: Tobias Jakobi
>
> dc_state_destruct() nulls the resource context of the DC state. The
> pipe
> context passed to dcn10_set_drr() is a member of this resource
> context.
>
> If dc_state_destruct() is called parallel to the IRQ processing
> (which
> calls dcn10_set_drr() at some point), we c
On Mon, 2024-09-02 at 11:40 +0200, tjak...@math.uni-bielefeld.de wrote:
> From: Tobias Jakobi
>
> dc_state_destruct() nulls the resource context of the DC state. The
> pipe
> context passed to dcn10_set_drr() is a member of this resource
> context.
>
> If dc_state_destruct() is called parallel t
Am 02.09.24 um 05:03 schrieb Lang Yu:
Fixes: 5a1c27951966 ("drm/amdgpu: implement TLB flush fence")
Signed-off-by: Lang Yu
Ah yes, that explains why CPU based updates doesn't work reliable any more.
You need to add some explanation to the commit message, e.g. something
like "CPU based updat
August 30, 2024 at 11:40 AM, "Thomas Zimmermann" mailto:tzimmerm...@suse.de?to=%22Thomas%20Zimmermann%22%20%3Ctzimmermann%40suse.de%3E
> wrote:
>
> Call drm_client_setup_with_color_mode() to run the kernel's default
> client setup for DRM. Set fbdev_probe in struct drm_driver, so that
> the clie
There're some other suspend abort cases which can call the noirq
suspend except for executing _S3 method. In those cases need to
process as incomplete suspendsion.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
A reset on initialization will be needed if a new PSP TOS needs to be
loaded than the one currently active on the system. This is possible
only on SOCs which support a full device reset which results in unload
of active PSP TOS.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/soc15.c |
Add XGMI reset on init support to aldebaran and SOCs with GC v9.4.3.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/aldebaran.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/aldebaran.c
b/drivers/gpu/drm/amd/amdgpu/aldebaran.c
index b0f95a7649bf..119ac
Add interface to check if a different TOS needs to be loaded than the
one which is which is already active on the SOC. Presently the interface
is restricted to specific variants of PSPv13.0.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 13 +
drivers/gpu/drm
Drop delayed reset work handler as it is no longer used.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 --
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 80 -
2 files changed, 84 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/dr
In some cases, device needs to be reset before first use. Add handlers
for doing device reset during driver init sequence.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 148 ++
drivers/gpu/drm/amd/
Use XGMI hive information to rely on resetting XGMI devices on
initialization rather than using mgpu structure. mgpu structure may have
other devices as well.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 6 --
dr
Move the reinitialization part after a reset to another function. No
functional changes.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 150 -
2 files changed, 89 insertions(+), 63 deletions(-)
d
Add a separate function to read badpage data during initialization.
Reading bad pages will need hardware access and cannot be done during
reset. Hence in cases where device needs a full reset during
init itself, attempting to read will cause a deadlock.
Signed-off-by: Lijo Lazar
---
drivers/gpu/
Drop pending_reset flag in gmc block. Instead use init level to
determine which type of init is preferred - in this case MINIMAL.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 33 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gp
Add init levels to define the level to which device needs to be
initialized.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 54 ++
2 files changed, 68 insertions(+)
diff --git a/drivers/gpu/d
There are case where a device needs to be reset first before it is fully
initialized. An example case is a driver reinstallation with a different version
of PSP TOS. In such a case, if a device supports reset in which PSP TOS is
unloaded, then driver needs to reset device first and then load the ne
27 matches
Mail list logo
