Fixes: 4990f957c845 ("drm/amdgpu/gfx10: fix mqd backup/restore for gfx rings")
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index
This patch fixes 2nd baco reset failure with gfxoff enabled on navi1x.
clear state buffer (resides in vram) is corrupted after 1st baco reset,
upon gfxoff exit, CPF gets garbage header in CSIB and hangs.
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 43
BR,
Aaron Liu
> -Original Message-
> From: Tuikov, Luben
> Sent: Wednesday, November 20, 2019 7:52 AM
> To: Liu, Aaron ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Ray
> ; Koenig, Christian
> Subject: Re: [PATCH 5/5] drm/amdgpu: enable TMZ bit in FRAME_CONTROL
>
BR,
Aaron Liu
> -Original Message-
> From: Tuikov, Luben
> Sent: Wednesday, November 20, 2019 7:12 AM
> To: Liu, Aaron ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Ray
> ; Koenig, Christian
> Subject: Re: [PATCH 1/5] drm/amdgpu: expand sdma copy_buffer interface
>
On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov wrote:
> On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> > From: Huang Rui
> >
> > To align the kernel uapi change from Alex:
> >
> > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers
> with
> > this flag set will be created with
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> This patch is to add add device handle as input param for exec_cs_helper
> and write_linear_helper.
>
> Because they are needed in security tests.
>
> v2: fix typo that basic tests should be un-secure.
> v3: refine the function
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> This patch expand write linear helper for security to submit the command
> with secure context.
>
> v2: refine the function implementation.
> v3: remove amdgpu_cs_ctx_create3.
>
> Signed-off-by: Huang Rui
> Signed-off-by: Aaron
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is
Hi Iago,
Thank you for finding and reporting this potential double lock.
Yes indeed, I see it--it can indeed happen.
Now, since the primitives used--macros using "amdgpu_mm_(r|w)reg\(.*\)"--in
"amdgpu_device_vram_access()" do use their own register-access spinlocks,
it maybe wise to remove the
On 2019-11-18 12:18 a.m., Aaron Liu wrote:
> This patch enables TMZ bit in FRAME_CONTROL for gfx10.
>
> Signed-off-by: Aaron Liu
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>
I wonder if we really do need yet another function argument,
thus increasing the argument list, or if the "tmz" boolean
can/is already a property of the job/command/ib/etc., and
if it can indeed be had from the latter entity...?
Regards,
Luben
On 2019-11-18 12:18 a.m., Aaron Liu wrote:
> This
On 19/11/2019 16:09, Mikita Lipski wrote:
On 19/11/2019 12:11, Ville Syrjälä wrote:
On Tue, Nov 19, 2019 at 04:59:40PM +, Cornij, Nikola wrote:
If you're going to make all of them the same, then u64, please.
This is because I'm not sure if calculations require 64-bit at some
stage.
On 19/11/2019 12:11, Ville Syrjälä wrote:
On Tue, Nov 19, 2019 at 04:59:40PM +, Cornij, Nikola wrote:
If you're going to make all of them the same, then u64, please.
This is because I'm not sure if calculations require 64-bit at some stage.
If it does then it's already broken. Someone
dm_pp_get_clock_levels_by_type needs to add the default clocks
to the powerplay case as well. This was accidently dropped.
Fixes: b3ea88fef321de ("drm/amd/powerplay: add get_clock_by_type interface for
display")
Bug: https://gitlab.freedesktop.org/drm/amd/issues/906
Signed-off-by: Alex Deucher
Am 19.11.19 um 17:45 schrieb Felix Kuehling:
On 2019-11-19 11:37, Alex Sierra wrote:
Only for the debugger use case.
[why]
Avoid endless translation retries, after an invalid address access has
been issued to the GPU. Instead, the trap handler is forced to enter by
generating a no-retry-fault.
I test v3 and it works fine.
Regards,
Philip
On 2019-11-12 3:22 p.m., Jason Gunthorpe wrote:
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry
On Tue, Nov 19, 2019 at 04:59:40PM +, Cornij, Nikola wrote:
> If you're going to make all of them the same, then u64, please.
>
> This is because I'm not sure if calculations require 64-bit at some stage.
If it does then it's already broken. Someone should probably figure out
what's actally
If you're going to make all of them the same, then u64, please.
This is because I'm not sure if calculations require 64-bit at some stage.
-Original Message-
From: Lipski, Mikita
Sent: November 19, 2019 10:08 AM
To: Ville Syrjälä ; Lipski, Mikita
Cc: amd-gfx@lists.freedesktop.org;
On 2019-11-19 11:37, Alex Sierra wrote:
Only for the debugger use case.
[why]
Avoid endless translation retries, after an invalid address access has
been issued to the GPU. Instead, the trap handler is forced to enter by
generating a no-retry-fault.
A s_trap instruction is inserted in the
Flag added to indicate if the amdgpu vm context is used for compute or
graphics.
Change-Id: Ia813037fda2ec2947d73f5c7328388078fbeebe5
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
2 files changed, 5 insertions(+)
Only for the debugger use case.
[why]
Avoid endless translation retries, after an invalid address access has
been issued to the GPU. Instead, the trap handler is forced to enter by
generating a no-retry-fault.
A s_trap instruction is inserted in the debugger case to let the wave to
enter trap
On 19/11/2019 09:56, Ville Syrjälä wrote:
On Tue, Nov 19, 2019 at 09:45:26AM -0500, mikita.lip...@amd.com wrote:
From: Mikita Lipski
We shouldn't compare int with unsigned long to find the max value
and since we are not expecting negative value returned from
compute_offset we should make
On Tue, Nov 19, 2019 at 09:45:26AM -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> We shouldn't compare int with unsigned long to find the max value
> and since we are not expecting negative value returned from
> compute_offset we should make this function return unsigned long
> so
From: Mikita Lipski
We shouldn't compare int with unsigned long to find the max value
and since we are not expecting negative value returned from
compute_offset we should make this function return unsigned long
so we can compare the values when computing rc parameters.
Cc: Nikola Cornij
Cc:
Am 19.11.19 um 10:13 schrieb Changfeng.Zhu:
From: changzhu
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in gmc9/gmc10 invalidation, add semaphore acquire
before invalidation and semaphore release after invalidation.
After adding semaphore
Am 19.11.19 um 10:12 schrieb Changfeng.Zhu:
From: changzhu
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in virt invalidation, add semaphore acquire
before invalidation and semaphore release after invalidation.
Change-Id:
Am 19.11.19 um 10:11 schrieb Changfeng.Zhu:
From: changzhu
SW must acquire/release one of the vm_invalidate_eng*_sem around the
invalidation req/ack. Through this way,it can avoid losing invalidate
acknowledge state across power-gating off cycle.
To use vm_invalidate_eng*_sem, it needs to
From: changzhu
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in gmc9/gmc10 invalidation, add semaphore acquire
before invalidation and semaphore release after invalidation.
After adding semaphore acquire before invalidation, the semaphore
From: changzhu
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in virt invalidation, add semaphore acquire
before invalidation and semaphore release after invalidation.
Change-Id: Ie98304e475166b53eed033462d76423b6b0fc25b
Signed-off-by: changzhu
From: changzhu
SW must acquire/release one of the vm_invalidate_eng*_sem around the
invalidation req/ack. Through this way,it can avoid losing invalidate
acknowledge state across power-gating off cycle.
To use vm_invalidate_eng*_sem, it needs to initialize
vm_invalidate_eng*_sem firstly.
Tested-by: Emily Deng
>-Original Message-
>From: Andrey Grodzovsky
>Sent: Tuesday, November 19, 2019 1:52 AM
>Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; Grodzovsky, Andrey
>
>Subject: [PATCH v2] drm/scheduler: Avoid accessing
Hi,
Alex Deucher wrote on 11/18/19 11:42 AM:
On Mon, Nov 18, 2019 at 3:37 AM Frederick Lawler wrote:
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2
32 matches
Mail list logo
