From: wentalou
[ Upstream commit 14d20ec7f31ef96a2e7dcf7880b13dde1d473b56 ]
psp_ring_destroy inside psp_load_fw cause psp->km_ring.ring_mem NULL.
Call Trace occurred when psp_cmd_submit.
should be psp_ring_stop instead.
Reviewed-by: Xiangliang Yu
Signed-off-by: Wentao Lou
Signed-off-by: Alex
Patches 1-3 are Reviewed-by: Felix Kuehling
About the direct mode, that removes a bunch of synchronization, so it
must make some assumptions about the state of the page tables. What
makes that safe? Is it safe to use direct-mode on a
per-page-table-update basis? Or do all page table updates ha
Fixes
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
on 32 bit platforms.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/dr
We don't hold a reference to the old fence, so it can go away
any time we are waiting for it to signal.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 24 ---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/am
Op 29-03-2019 om 10:20 schreef Daniel Vetter:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of 0x.
>
> Cc: Um
On 3/29/19 10:20 AM, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of 0x.
>
> Cc: Um
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
On 29/03/2019 09:20, Daniel Vetter wrote:
Interpreting it as a 0.16 fixed point means we can't accurately
represent 1.0. Which is one of the values we really should be able to
represent.
Since most (all?) luts have lower precision this will only affect
rounding of 0x.
Cc: Uma Shankar
Cc: V
Only vega and newer have the concept of profiles in the SMU. Vegas has a set
of profiles that the SMU tracks directly. SMU7 parts don't really have
profiles per se; there just one "state" and the driver loads all the params
into that state when you request a profile (custom or hardcoded).
Ale
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
On Fri, Mar 29, 2019 at 08:32:41PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> t
Am 29.03.19 um 15:23 schrieb Alex Deucher:
On Fri, Mar 29, 2019 at 6:45 AM Christian König
wrote:
We are going to need that for recoverable page faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
2 files c
On Fri, Mar 29, 2019 at 6:45 AM Christian König
wrote:
>
> We are going to need that for recoverable page faults.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff -
On 3/29/19 8:00 AM, Mario Kleiner wrote:
> During VRR mode we can not allow vblank irq dis-/enable
> transitions, as an enable after a disable can happen at
> an arbitrary time during the video refresh cycle, e.g.,
> with a high likelyhood inside vblank front-porch. An
> enable during front-porch w
On 3/29/19 8:00 AM, Mario Kleiner wrote:
> We need the VRR active/inactive state info earlier in
> the commit sequence, so VRR related setup functions like
> amdgpu_dm_handle_vrr_transition() know the final VRR state
> when they need to do their hw setup work.
>
> Split update_freesync_state_on_st
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consisten
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mod
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no lo
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations wh
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must
The hopefully final patch series, with feedback applied and
r-b / acked-by tags added. Rebased to current agd5f/drm-5.2-wip
branch.
Numbering has slightly changed. Patches 3-5 are identical to last
series. Patch 2/5 v3 (the former 1/4 v2) trivially rebased on top of
the new 1/5.
Patch 1/5 is new
We need the VRR active/inactive state info earlier in
the commit sequence, so VRR related setup functions like
amdgpu_dm_handle_vrr_transition() know the final VRR state
when they need to do their hw setup work.
Split update_freesync_state_on_stream() into an early part,
that can run at the beginn
On Fri, Mar 29, 2019 at 08:32:41PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> t
Sorry for all of the questions, Evan. I see that we store the CUSTOM profile
for Vega10/Fiji, but is that a limitation of the HW not being able to store it
via the SMU? It seems like a lot of extra work to store a local copy, when we
can just get the copy from the GPU itself, especially if we do
Am 28.03.19 um 21:39 schrieb Kuehling, Felix:
On 2019-03-28 4:38 p.m., Liu, Shaoyun wrote:
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
peer device
Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
Signed-off-by: shaoyunl
This patch is Reviewed-by: Felix K
Am 28.03.19 um 18:55 schrieb Liu, Shaoyun:
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
peer device
Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 13 +
drivers/gpu/drm/a
We are going to need that for recoverable page faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgp
For handling PDE updates directly in the fault handler.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_
Otherwise we don't correctly use translate further.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 3
Next step towards HMM support. For now just silence the retry fault and
optionally redirect the request to the dummy page.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 59 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +
drivers/gpu/drm/amd
For handling PD/PT clears directly in the fault handler.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm
This way we get retry faults for missing PDs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
inde
This allows us to update page tables directly while in a page fault.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c | 4 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 29 +
3 files cha
For handling PTE updates directly in the fault handler.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm
Interpreting it as a 0.16 fixed point means we can't accurately
represent 1.0. Which is one of the values we really should be able to
represent.
Since most (all?) luts have lower precision this will only affect
rounding of 0x.
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Shashank Sharma
Cc: "Kuma
36 matches
Mail list logo
