The series is Reviewed-by: Felix Kuehling
On 2019-03-25 8:22 a.m., Christian König wrote:
> Clean that up further and also fix another case where the BO
> wasn't kmapped for CPU based updates.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31
Hi
Yes. I finally found it upstream in 4.20 .
Thank you for following up.
JD.
On March 25, 2019, at 5:36 PM, "Kuehling, Felix" wrote:
On 2019-03-22 12:58 p.m., John Donnelly wrote:
> Hello ,
>
> I am investigating a issue reported by a test group concerning this driver.
> Their test
On 2019-03-22 12:58 p.m., John Donnelly wrote:
> Hello ,
>
> I am investigating a issue reported by a test group concerning this driver.
> Their test loads and unloads every kernel module included in the 4.14.35
> kernel release . You don’t even need a AMD platform . It occurs on any Intel,
>
I don't see any check for the memory type. As far as I can tell you'll
power up XGMI even for system memory mappings. See inline.
On 2019-03-22 3:28 p.m., Liu, Shaoyun wrote:
> Driver vote low to high pstate switch whenever there is an outstanding
> XGMI mapping request. Driver vote high to low
On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> amdgpu_ttm_tt_get_user_pages() uses provided user
In case alloc_workqueue fails, the fix frees memory and
returns -ENOMEM to avoid potential NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
v2: use radeon_crtc_destroy to properly clean up resources as
suggested by Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_display.c | 15
On 2019-03-25 7:38 a.m., Christian König wrote:
> Am 20.03.19 um 12:57 schrieb Kuehling, Felix:
>> As far as I can tell, the whole series is a small cleanup and big
>> refactor to enable CPU clearing of PTs without a lot of ugliness or code
>> duplication.
>
> It's a bit more than that. Key point
According to HW engineer, they prefer the TMR address be "naturally aligned",
e.g. the start address
must be an integer divide of TME size.
Change-Id: Ie01b3d41e564fc8f416048e001d75edb64c045e3
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 +++---
1 file changed, 3
The extra ; in the macro definition creates an empty statement
preventing any variable declarations from occuring after
any use of to_dm_plane_state(...).
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Thanks for that confirmation Evan. I will drop this patch.
Kent
KENT RUSSELL
Sr. Software Engineer | Linux Compute Kernel
1 Commerce Valley Drive East
Markham, ON L3T 7X6
O +(1) 289-695-2122 | Ext 72122
From: Quan, Evan
Sent: Monday, March 25, 2019 10:26:54 AM
I set CUSTOM to a weird value like "1 2 3 4 5 6" , then switched to VR profile,
then switched back to CUSTOM (just with "echo 6 > profile), and it kept my
custom values. Before this patch, it throws EINVAL but still switches it to
CUSTOM with the saved values, on both vega10 and vega20.
Kent
As I know, BOOTUP profile is only available for Vega10 and later ASICs.
The BOOTUP profile for SMU7 has only some dummy settings and is not expected to
switch to such mode.
The default power profile for SMU7 is FULLSCREEN3D(different with Vega10 and
later ASICs).
hwmgr->workload_mask = 1
How can you tell whether it was already applied before or 1st time to switch to
compute mode?
For the latter case, other settings/parameters do need.
Regards,
Evan
> -Original Message-
> From: amd-gfx On Behalf Of
> Russell, Kent
> Sent: 2019年3月25日 20:42
> To:
On 22/03/2019 12:04, Catalin Marinas wrote:
On Wed, Mar 20, 2019 at 03:51:23PM +0100, Andrey Konovalov wrote:
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
On 22/03/2019 16:07, Catalin Marinas wrote:
On Wed, Mar 20, 2019 at 03:51:31PM +0100, Andrey Konovalov wrote:
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
On 22/03/2019 15:59, Catalin Marinas wrote:
On Wed, Mar 20, 2019 at 03:51:28PM +0100, Andrey Konovalov wrote:
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
With SMU7 using case statements, against vega10/20 only checking for the
CUSTOM profile, SMU7 can't set the power profile back to the
BOOTUP_DEFAULT, while newer HWMGRs can. Add the case statement in to
align functionality with other ASICs
Change-Id: Ibc7df3b94b1a9dabcb88934e534c91209fc75967
Allow changing to the CUSTOM profile without requiring the
parameters being passed in each time. Store the values in
the smu7_profiling table since it's defined here anyways
Change-Id: I6c5e3a1487e12410a6a7670a5cf1a6599253344d
Signed-off-by: Kent Russell
---
Don't return an error after switching to the CUSTOM profile,
if there aren't any CUSTOM values passed in. The CUSTOM profile
is already applied, so if no other arguments are passed, just
return instead of throwing -EINVAL when successful
Change-Id: I114cc9783226ee9ebb146863897e951527a85e20
It is redundant with the job pointer.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 24 +++--
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git
Clean that up further and also fix another case where the BO
wasn't kmapped for CPU based updates.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
Hi Monk,
well it would certainly work, but for the error handling it's just not
the best idea to do the mapping so late.
E.g. we should do the kmap for CPU based updates as well as the GTT map
for SDMA based updates much more earlier to avoid rolling back all work
again when we are
Am 22.03.19 um 20:28 schrieb Liu, Shaoyun:
Driver vote low to high pstate switch whenever there is an outstanding
XGMI mapping request. Driver vote high to low pstate when all the
outstanding XGMI mapping is terminated.
Change-Id: I197501f853c47f844055c0e28c0ac00a1ff06607
Signed-off-by:
Am 20.03.19 um 12:57 schrieb Kuehling, Felix:
As far as I can tell, the whole series is a small cleanup and big
refactor to enable CPU clearing of PTs without a lot of ugliness or code
duplication.
It's a bit more than that. Key point is that I can now easily add a
parameter for direct
Hi Kangjie,
thanks for your patch.
On 2019-03-23 3:29 a.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 5 +
> 1 file
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
v4: remove v3 change and add checking to prevent out-of-order
v5: unify binary and timeline
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a0732088640..4d8db87048d3 100644
---
From: Christian König
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace
Signed-off-by: Christian König
Cc: Lionel
we need to import/export timeline point.
v2: unify to one transfer ioctl
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 74 ++
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence
Signed-off-by: Christian König
Cc: Lionel Landwerlin
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for
Hello Samson Tam,
This is a semi-automatic email about new static checker warnings.
The patch 66acd4418d7d: "drm/amd/display: Link train only when link
is DP and backend is enabled" from Mar 4, 2019, leads to the
following Smatch complaint:
TA accept some options like address is in sram or vram. Most default
options are enough to use. But allow user to setup them.
reuse inject.value to place these options.
At the same time, we need translate the address to a physical/gpu
address which the pages are mapped at.
V2: add a helper to
inject need a real valid address.
Signed-off-by: xinhui pan
---
tests/amdgpu/ras_tests.c | 53 +++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/ras_tests.c b/tests/amdgpu/ras_tests.c
index 612ad1d7..d3f1750d 100644
---
Hello David Francis,
The patch c6ade4ee7375: "drm/amd/display: On DCN1, Wait for vupdate
on cursor updates" from Feb 21, 2019, leads to the following static
checker warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:216
delay_cursor_until_vupdate()
error:
38 matches
Mail list logo
