Am 24.10.2017 um 03:41 schrieb Chunming Zhou:
On 2017年10月23日 22:26, Christian König wrote:
Why I prefer to keep is_bound for naming is we only can get gpu
offset after gtt is bound not check if node is allocated.
No, it is just the other way around.
When the TTM is bound it doesn't mean we c
From: Shirish S
The addReq attribute sent to fill_plane_attributes_from_fb() is always false,
hence fb_location is never set properly causing issues in rendereing on
underlay.
This patch cleans up the addReq attribute and hence fixes the issue.
Signed-off-by: Shirish S
Reviewed-by: Alex Deuc
From: Shirish S
Currently the high part of the address structure is not populated in case of
luma and chroma.
This patch adds this calculation.
Signed-off-by: Shirish S
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++--
1 file changed, 7 insertions
retire gpu_reset and sriov_gpu_reset and use new implemented
amdgpu_gpu_recover
Change-Id: Ib1de998eaffe7ed2bdd398a4f1b4ca62f9abf2a6
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 307 +
dr
this query will give flag bits to indicate what happend
on the given context
Change-Id: I638efef736de77519388199d000ca8f62b4dc89a
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 37 +
include/uapi/drm/amdgpu_drm.h | 8 +++
2 fi
1,no sriov check since gpu recover is unified
2,need CPU_ACCESS_REQUIRED flag for VRAM if SRIOV
because otherwise after following PIN the first allocated
VRAM bo is wasted due to some TTM mgr reason.
Change-Id: I4d029f2da8bb463942c7861d3e52f309bdba9576
Signed-off-by: Monk Liu
---
drivers/gpu/drm
since now gpu reset is unified with gpu_recover
for both bare-metal and SR-IOV:
1)rename in_sriov_reset to in_gpu_reset
2)move lock_reset from adev->virt to adev
Change-Id: I9f4dbab9a4c916fbc156f669824d15ddcd0f2322
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 ++-
reset_counter marks the reset counter number once the context
is created, shouldn't be changed due to query.
To keep U/K interface on the ctx_query and keep ctx's reset_counter
logic compatible with GPU RESET feature, now use another var named
"reset_counter_query" to replace the original checked
1,new imple names amdgpu_gpu_recover which gives more hint
on what it does compared with gpu_reset
2,gpu_recover unify bare-metal and SR-IOV, only the reset part
is implemented differently
3,gpu_recover will increase hang job karma and its context guilty
if exceeds limit, which will be canceled i
From: Yong Zhao
Remove empty initialize function.
Rename register_process to update_qpd to avoid confusion with the
non-ASIC-specific register_process.
Shorten ops_asic_specific to asic_ops.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_m
Another pass through a diff between our internal branch and upstream
yielded a few more fixes and cleanups that were previously missed.
Ben Goz (1):
drm/amdkfd: Register/Deregister process on qpd resolution
Felix Kuehling (1):
drm/amdkfd: Minor cleanups
Jay Cornwall (1):
drm/amdkfd: Disabl
From: Yong Zhao
A list of per-process queues is maintained in the
kfd_process_queue_manager, so the queues array in kfd_process is
redundant and in fact unused.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 6 --
drivers/gpu/drm/amd
From: Yong Zhao
When kfd suspending on APU, we do not need to call
amd_iommu_unbind_pasid(), because pasid will be unbound automatically
when power goes off.
On the other hand, calling amd_iommu_unbind_pasid() will trigger
kfd_process_iommu_unbind_callback() if the process is not terminating.
By
These were missed previously when rebasing changes for upstreaming.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 ++
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +-
3 file
From: Ben Goz
Process registration needs to happen on each device. So use per-device
queue lists to determine when to register/deregister the process.
Signed-off-by: Ben Goz
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 9 ++---
1 file changed,
From: Jay Cornwall
The MQD represents an inactive context and should not have ring or
doorbell enable bits set. Doing so interferes with HWS which streams
the MQD onto the HQD. If enable bits are set this activates the ring
or doorbell before the HQD is fully configured.
Signed-off-by: Jay Cornw
From: Yair Shachar
Take the dbgmgr lock and unregister before destroying the debug manager.
Do this before destroying the queues.
Signed-off-by: Yair Shachar
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 37 +++-
1 file changed, 27 in
Can you try call pci_disable_device once you found init failed, and make sure
it is called before re-init
-Original Message-
From: Ding, Pixel
Sent: 2017年10月24日 9:31
To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Xiao, Jack
Cc: Sun, Gary ; Li, Bingley
Subject: Re: [PATCH 5/7] drm/am
Okay, I missed that part,
Free to add my RB
-Original Message-
From: Ding, Pixel
Sent: 2017年10月24日 9:33
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Cc: Sun, Gary ; Li, Bingley
Subject: Re: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops
This is for retry init.
If the driver fa
Sorry for the misunderstanding. Will test with similar fix instead of 5248e3d9
directly later.
—
Sincerely Yours,
Pixel
On 24/10/2017, 9:31 AM, "Ding, Pixel" wrote:
>Tested with 5248e3d9, however issue is still reproduced in reinit case.
>
>+Jack,
>To bypass MSI enable/disable for reinit
It works with current MMIO blocking policy, while all pages are blocked expect
the one containing mailbox registers. But actually it’s not a good approach, as
commented we should add interaction between host and guest for MMIO blocking
check in future.
By now I can add more comments here, is it
On 2017年10月23日 22:26, Christian König wrote:
Why I prefer to keep is_bound for naming is we only can get gpu
offset after gtt is bound not check if node is allocated.
No, it is just the other way around.
When the TTM is bound it doesn't mean we can get the GPU offset
because it can be that t
This is for retry init.
If the driver fails before late_init, the IRQ handler is not registered then.
We need to know if the FLR is done at this point. I think maybe we also can
leverage this interface to handle some special cases in future. Any concern
about it?
—
Sincerely Yours,
Pixel
Tested with 5248e3d9, however issue is still reproduced in reinit case.
+Jack,
To bypass MSI enable/disable for reinit, any comment?
—
Sincerely Yours,
Pixel
On 23/10/2017, 6:57 PM, "Liu, Monk" wrote:
>Please check commit "5248e3d9", your issue should already be fixed by that
>patch, pl
Deucher, Alexander wrote:
> Sorry, been swamped lately. Haven't had a chance to look.
Cool. I know what that's like.
Um, but, can you please look, just a little? :)
I do not mean "resolve the bug now kthx !!111", but perhaps judge
complexity/difficulty, or see if there is some key information o
Reviewed-by: Leo Liu
On 10/23/2017 01:34 PM, Alex Deucher wrote:
On Mon, Oct 23, 2017 at 1:03 PM, Tom St Denis wrote:
On APUs the uvd6 driver was skipping proper suspend/resume routines resulting
in a broken state upon resume.
Signed-off-by: Tom St Denis
Acked-by: Alex Deucher
---
dr
On Mon, Oct 23, 2017 at 1:03 PM, Tom St Denis wrote:
> On APUs the uvd6 driver was skipping proper suspend/resume routines resulting
> in a broken state upon resume.
>
> Signed-off-by: Tom St Denis
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 16 +---
> 1
On APUs the uvd6 driver was skipping proper suspend/resume routines resulting
in a broken state upon resume.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_
On 10/23/2017 12:06 PM, Tom St Denis wrote:
This diff:
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
index 71299c67c517..d4a6b97d20e7 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
@@ -566,7 +566,7 @
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Monday, October 23, 2017 10:46 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu/psp: Use %p for printing pointers
>
> From: Michel Dänzer
>
> The c
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, October 23, 2017 6:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
> Subject: [PATCH 2/7] drm/amdgpu: add init_log param to contr
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, October 23, 2017 6:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
> Subject: [PATCH 4/7] drm/amdgpu/virt: add function to check
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, October 23, 2017 6:04 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
> Subject: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt op
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, October 23, 2017 6:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
> Subject: [PATCH 1/7] drm/amdgpu: release VF exclusive access
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, October 23, 2017 6:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Gary; Ding, Pixel; Li, Bingley
> Subject: [PATCH 3/7] drm/amdgpu: avoid soft lockup when wa
This diff:
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
index 71299c67c517..d4a6b97d20e7 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
@@ -566,7 +566,7 @@ static int uvd_v6_0_suspend(void *handle)
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Monday, October 23, 2017 3:06 AM
> To: Liu, Monk; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/ttm:fix memory leak due to individualize
>
> Am 23.10.2017 u
On 2017-10-23 06:03 AM, Pixel Ding wrote:
From: pding
The exclusive mode has real-time limitation in reality, such like being
done in 300ms. It's easy observed if running many VF/VMs in single host
with heavy CPU workload.
If we find the init fails due to exclusive mode timeout, try it again
Am 23.10.2017 um 16:45 schrieb Michel Dänzer:
From: Michel Dänzer
The compiler was warning:
In file included from drivers/gpu/drm//amd/amdgpu/amdgpu.h:45:0,
from drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27:
drivers/gpu/drm//amd/amdgpu/psp_v10_0.c: In function ‘psp_v10_0_cmd_su
From: Michel Dänzer
The compiler was warning:
In file included from drivers/gpu/drm//amd/amdgpu/amdgpu.h:45:0,
from drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27:
drivers/gpu/drm//amd/amdgpu/psp_v10_0.c: In function ‘psp_v10_0_cmd_submit’:
drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27
Why I prefer to keep is_bound for naming is we only can get gpu offset
after gtt is bound not check if node is allocated.
No, it is just the other way around.
When the TTM is bound it doesn't mean we can get the GPU offset because
it can be that there wasn't any GART space assigned.
But if th
On 23/10/17 09:27 AM, Tom St Denis wrote:
Doing a suspend during playback results in the uvd not resuming when
waking up with drm-next as the kernel.
Trying with cg_mask=pg_mask=0 It hangs on decode start. I've attached
the readout of the ring which looks normal.
Initially I thought maybe i
Doing a suspend during playback results in the uvd not resuming when
waking up with drm-next as the kernel.
Tom
[0.00] Linux version 4.13.0-rc5+ (root@carrizo) (gcc version 6.3.1
20161221 (Red Hat 6.3.1-1) (GCC)) #37 SMP Thu Oct 12 07:12:29 EDT 2017
[0.00] Command line: BOOT_IMA
Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky:
Switch from kfifo to SPSC queue.
Bug:
Kfifo is limited at size, during GPU reset it would fill up to limit
and the pushing thread (producer) would wait for the scheduler worker to
consume the items in the fifo while holding reservation lock
on a
Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky:
It is intended to sabstitute the bounded fifo we are currently
using.
Signed-off-by: Andrey Grodzovsky
Two style nit picks below, with those fixed the patch is Reviewed-by:
Christian König
---
drivers/gpu/drm/amd/scheduler/spsc_queue.h
Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky:
Bug: amdgpu_job_free_cb was accessing s_job->s_entity when the allocated
amdgpu_ctx (and the entity inside it) were already deallocated from
amdgpu_cs_parser_fini.
Fix: Save job's priority on it's creation instead of accessing it from
s_entity la
Am 23.10.2017 um 07:46 schrieb Monk Liu:
merge the setting guilty on context into this function
to avoid implement extra routine.
v2:
go through entity list and compare the fence_ctx
before operate on the entity, otherwise the entity
may be just a wild pointer
Change-Id: I7a0063464fdc85d5ac9080
Both patches:
Reviewed-by: Nicolai Hähnle
On 20.10.2017 16:57, Andres Rodriguez wrote:
Generated using make headers_install from:
airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ...
Signed-off-by: Andres Rodriguez
---
include/drm/amdgpu_drm.h | 31 ++
I don't see this is a necessary patch, driver already have the implement to
check if VF FLR is completed or not, see "xgpu_ai/vi_mailbox_flr_work()"
Driver won't do gpu reset until this function received the NOTIFICATION_CMPL
message
Do you have any particular reason to add this wait_reset ? if
Please check commit "5248e3d9", your issue should already be fixed by that
patch, please verify
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Pixel
Ding
Sent: 2017年10月23日 18:04
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Gary ; Ding, Pixel ;
On 2017-10-23 12:06 AM, Liu, Monk wrote:
If the deadlock issue could be solved I don't see why we give up kfifo and
switch to SPSC ..
The deadlock is solved because we don't block anymore waiting for
consumer to dequeue items from the queue - which can only be
achieved with not bounded
From: pding
The exclusive mode has real-time limitation in reality, such like being
done in 300ms. It's easy observed if running many VF/VMs in single host
with heavy CPU workload.
If we find the init fails due to exclusive mode timeout, try it again.
Signed-off-by: pding
---
drivers/gpu/drm/
From: pding
Normally all waiting get timeout if there's one.
Release the lock and return immediately when timeout happens.
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 6 ++
2 files changed, 12 insertions(+)
diff --git
From: pding
Driver can use this interface to check if there's a function level
reset done in hypervisor.
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 2 ++
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c| 1 +
d
From: pding
After calling pci_disable_msi() and pci_enable_msi(), VF can't
receive interrupt anymore. This may introduce problems in module
reloading or retrying init.
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
d
From: pding
MMIO space can be blocked on virtualised device. Add this function
to check if MMIO is blocked or not.
Todo: need a reliable method such like communation with hypervisor.
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu
The subsequent operations don't need exclusive accessing hardware.
Signed-off-by: Pixel Ding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 3 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
From: pding
When this VF stays in exclusive mode for long, other VFs will be
impacted.
The redundant messages causes exclusive mode timeout when they're
redirected. That is a normal use case for cloud service to redirect
guest log to virtual serial port.
Introduce init_log param to control logs
This is the second patch series merged or reimplemented from SRIOV
branch. It changes the init time consuming.
Exclusive mode means that a VF occupies hardware and other VFs need
to wait until this VF releases exclusive mode. The timing of exclusive
mode is limited to avoid starvation causing unav
I read the source again, looks like I misunderstand your point, let me clear it
again:
1, the cs_submit deadlock can be resolved by moving eu_fence_buffer()
2, in GEM_VA IOCTL, the reservation lock is hold in the very beginning, and
vm_update_directories() need that lock held till all related JO
Yes, I see the checking in backend_bind:
if (!amdgpu_gtt_mgr_is_allocated(bo_mem))
return 0;
OK, then my only concern is your ’instead‘ assumes
amdgpu_gtt_mgr_is_allocated means gart is bound, how about:
bool amdgpu_gtt_is_bound(struct ttm_tt *ttm)
{
return amdgpu_
The series is Reviewed-by: Chunming Zhou
On 2017年10月23日 13:46, Monk Liu wrote:
merge the setting guilty on context into this function
to avoid implement extra routine.
v2:
go through entity list and compare the fence_ctx
before operate on the entity, otherwise the entity
may be just a wild po
Am 23.10.2017 um 09:33 schrieb Chunming Zhou:
using ttm->state == tt_bound seems make more sense.
That won't work. We set ttm->state = tt_bound even when we haven't
allocated GART space.
That's also a reason why I wanted to remove it, the name is confusing.
Christian.
On 2017年10月20日 17:
Yeah, already did so, please check the amd-gfx
-Original Message-
From: Koenig, Christian
Sent: 2017年10月23日 15:17
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/amdgpu:implement guilty pointer
Am 23.10.2017 um 06:26 schrieb Liu, Monk:
> Don't set this directly
Let's make it clear enough:
> That won't work. All VM updates must be completed while the reservation
> object lock is still held, otherwise you run into possible concurrent VM
> updates.
All VM updates will be represented as fence which will be hook in the sync
object, and after we push job to
using ttm->state == tt_bound seems make more sense.
On 2017年10月20日 17:20, Christian König wrote:
From: Christian König
use amdgpu_gtt_mgr_is_allocated() instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_objec
For VM updates, the situation is same as commands submission, deadlock can also
be solved by moving ttm_eu_fence_buffer_objects() ahead of push_job()
That won't work. All VM updates must be completed while the reservation
object lock is still held, otherwise you run into possible concurrent VM
For VM updates, the situation is same as commands submission, deadlock can also
be solved by moving ttm_eu_fence_buffer_objects() ahead of push_job()
For TTM buffers moves can we pardon gpu_reset routine and wait till the TTM
moves complete ?
-Original Message-
From: Christian König [mai
Am 23.10.2017 um 06:26 schrieb Liu, Monk:
Don't set this directly, make it a parameter of amd_sched_entity_init().
And please split up the patches differently.
First all changes to the scheduler, including the guilty marking.
Then the changes to amdgpu.
[ML] that way the first patch will bre
Am 23.10.2017 um 08:00 schrieb Monk Liu:
no need to manually cleanup job and fence after sched_fence_finish(),
they are auto handled by the callback
Change-Id: I9da26064c9e73c178949663bed1e490539e95e41
Signed-off-by: Monk Liu
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/scheduler
We discussed that as well, problem is that this won't be sufficient.
We push to the kfifo not only during command submission, but also for VM
updates and TTM buffers moves.
So we can still deadlock because of them.
Regards,
Christian.
Am 23.10.2017 um 05:03 schrieb Liu, Monk:
Why not use a
Am 23.10.2017 um 04:31 schrieb Monk Liu:
Change-Id: I6d06b81b8b894775e55e495e96f3c999b83cf2be
Signed-off-by: Monk Liu
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drive
72 matches
Mail list logo