Re: [PATCH] drm/radeon: avoid page fault during gpu reset

Am 25.01.2020 19:47 schrieb Andreas Messer : When backing up a ring, validate pointer to avoid page fault. When the drivers attempts to handle a gpu lockup, a page fault might occur during call of radeon_ring_backup() since (*ring->next_rptr_cpu_addr) could have invalid content: [

[PATCH 1/3] drm/amdgpu/navi: fix index for OD MCLK

You can only adjust the max mclk, not the min. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c

[PATCH 2/3] drm/amdgpu/navi10: add OD_RANGE for navi overclocking

So users can see the range of valid values. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 59 ++ 1 file changed, 59 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c

[PATCH 3/3] drm/amdgpu/navi10: add OD support for restoring default table

Was missing before. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c

[PATCH] drm/radeon: avoid page fault during gpu reset

When backing up a ring, validate pointer to avoid page fault. When the drivers attempts to handle a gpu lockup, a page fault might occur during call of radeon_ring_backup() since (*ring->next_rptr_cpu_addr) could have invalid content: [ 3790.348267] radeon :01:00.0: ring 0 stalled for more

[PATCH] drm/amdgpu/navi10: add mclk to navi10_get_clock_by_type_with_latency

Doesn't seem to be used, but add it just in case. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c index

Re: [PATCH] drm/amd/display: do not allocate display_mode_lib unnecessarily

On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote: > > On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote: > > > > This allocation isn't required and can fail when resuming from suspend. > > > > Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009 > > Signed-off-by: Dor Askayo > > --- > >

Re: [PATCH] amdgpu: use dma-resv API instead of manual kmalloc

And of course I forgot this is an internal API, so this doesn't work without some of other stuff which isn't ready. Please ignore... Regards, Stephen Le 25/01/2020 12:46, Stephen Kitt a écrit : Instead of hand-coding the dma_resv_list allocation, use dma_resv_list_alloc, which masks the

[PATCH] amdgpu: use dma-resv API instead of manual kmalloc

Instead of hand-coding the dma_resv_list allocation, use dma_resv_list_alloc, which masks the shared_max handling. While we're at it, since we only need shared_count fences, allocate shared_count fences rather than shared_max. (This is the only place in the kernel, outside of dma-resv.c, which