In amdgpu_vmid_grab_idle, fences is being leaked in one execution path.
The missing kfree was added.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
On 9/20/19 9:36 AM, Mark Brown wrote:
> Hi all,
>
> News: There will likely be no more -next builds until Stephen returns on
> the 30th, I *may* do some next week but it's more likely that I won't
> and it certainly won't be every day.
>
> Changes since 20190919:
>
on x86_64:
(1) where is
On 2019-09-20 4:18 p.m., Alex Deucher wrote:
> Use proper helper for 32 bit.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c| 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
Use proper helper for 32 bit.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c| 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c
The index is stored in scratch register 4 after asic init. Use
that index. No functional change since all asics in a family
use the same type of vram (G5, G6, HBM) and that is all we use
at the monent, but if we ever need to query other info, we will
now have the proper index.
Signed-off-by:
On 9/20/19 9:36 AM, Mark Brown wrote:
> Hi all,
>
> News: There will likely be no more -next builds until Stephen returns on
> the 30th, I *may* do some next week but it's more likely that I won't
> and it certainly won't be every day.
>
> Changes since 20190919:
>
on i386:
ld:
On Fri, Sep 20, 2019 at 1:01 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> Avoids a crash described in
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/43#note_223718
>
> (Ported from amdgpu commit 5b8bc9fc505c551dcd9b0ed5ab835a49fa4f9fda)
>
> Signed-off-by:
On Tue, Dec 12, 2017 at 10:34 AM Roger He wrote:
>
> on_alloc_stage: is this operation on allocation stage
> resv: reservation bo used of this operation
>
> Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
> Signed-off-by: Roger He
Real commit message (the later patches using this are even
From: Michel Dänzer
Avoids a crash described in
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/43#note_223718
(Ported from amdgpu commit 5b8bc9fc505c551dcd9b0ed5ab835a49fa4f9fda)
Signed-off-by: Michel Dänzer
---
src/radeon_kms.c | 10 +-
1 file changed, 9
From: Michel Dänzer
FindClientResourcesByType finds pixmaps from all screens, but trying to
process ones from other screens here makes no sense and likely results
in a crash or memory corruption.
Signed-off-by: Michel Dänzer
---
src/radeon_kms.c | 27 +--
1 file
On 2019-09-19 4:56 a.m., Ma, Le wrote:
> Thanks Alex.
BTW, merge requests (MRs) are enabled now for the drm repository, so
it's probably best to use MRs from now on.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
Hello Alex,
after release of 5.3 my devel system was migrated to compressed firmware
files.
So current 'amd-staging-drm-next' can't boot any longer and I can't test
anything on it for you (AMD) ;-)
Greetings,
Dieter
PS I'm NOT on amd-gfx.
___
Am 20.09.19 um 08:57 schrieb Jesse Zhang:
When compute fence did not signal, compute ring cannot detect hardware hang
because its timeout value is set to be infinite by default.
In SR-IOV and passthrough mode, if user does not declare custome timeout
value for compute ring, then use gfx ring
Am 20.09.19 um 04:15 schrieb Marek Olšák:
From: Marek Olšák
Never used.
Signed-off-by: Marek Olšák
Acked-by: Christian König
Nice cleanup,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 41 -
Am 19.09.19 um 23:45 schrieb Alex Deucher:
Missing parameters, wrong comment type, etc.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
When compute fence did not signal, compute ring cannot detect hardware hang
because its timeout value is set to be infinite by default.
In SR-IOV and passthrough mode, if user does not declare custome timeout
value for compute ring, then use gfx ring timeout value as default. So
that when there
These registers are used in GFX9 NGG and the addresses are managed by KMD;
GFX10 has changed the design; UMD does not need to care about these values any
more.
I can confirm UMD does not read these values from KMD.
Alex
-Original Message-
From: Zhou, David(ChunMing)
Sent: Friday,
17 matches
Mail list logo