From: pding
Move kfd probe prior to device init. Release exclusive mode
after hw_init if kfd is not enabled.
v2:
- pass pdev param
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amd
From: Philip Cox
Signed-off-by: Philip Cox
Signed-off-by: shaoyun liu
Signed-off-by: Yong Zhao
Signed-off-by: Jay Cornwall
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 85 ---
drivers/gpu/drm/amd/amdgpu/vid.h | 2
Fix the SDMA load and unload sequence as suggested by HW document.
Signed-off-by: shaoyun liu
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 ---
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amd
Save wptr in hqd_sdma_destroy, restore it in hqd_sdma_load. Also
read updated wptr from user mode when resuming an SDMA queue.
Signed-off-by: Jay Cornwall
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 30 +++
Signed-off-by: shaoyun liu
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 13 +
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 5 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 2 --
3 files changed, 10 insertions(+), 10 deletions
From: Philip Cox
Signed-off-by: Philip Cox
Signed-off-by: shaoyun liu
Signed-off-by: Jay Cornwall
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 103 +++-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/a
This patch series fixes SDMA user mode queue support for GFX7 and adds
support for GFX8.
Felix Kuehling (5):
drm/amdgpu: Correct SDMA load/unload sequence on HWS disabled mode
drm/amdkfd: Fix SDMA oversubsription handling
drm/amd: Update kgd_kfd interface for resuming SDMA queues
drm/amdgp
Add wptr and mm parameters to hqd_sdma_load and pass these parameters
from device_queue_manager through the mqd_manager.
SDMA doesn't support polling while the engine believes it's idle. The
driver must update the wptr. The new parameters will be used for looking
up the updated value from the spec
SDMA only supports a fixed number of queues. HWS cannot handle
oversubscription.
Signed-off-by: shaoyun liu
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd
From: shaoyunl
ffs function return the position of the first bit set on 1 based.
(bit zero returns 1).
Signed-off-by: shaoyun liu
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
Am 30.10.2017 um 19:52 schrieb Harry Wentland:
On 2017-10-30 02:00 PM, Christian König wrote:
Am 30.10.2017 um 18:41 schrieb Harry Wentland:
VM support is only available for CZ and newer APUs. Trying to
enable it for dGPU will blow up in DC.
Signed-off-by: Harry Wentland
Suggested-by: Alex De
On 2017-10-30 02:00 PM, Christian König wrote:
> Am 30.10.2017 um 18:41 schrieb Harry Wentland:
>> VM support is only available for CZ and newer APUs. Trying to
>> enable it for dGPU will blow up in DC.
>>
>> Signed-off-by: Harry Wentland
>> Suggested-by: Alex Deucher
>> CC: Christian Koenig
>
Am 30.10.2017 um 18:41 schrieb Harry Wentland:
VM support is only available for CZ and newer APUs. Trying to
enable it for dGPU will blow up in DC.
Signed-off-by: Harry Wentland
Suggested-by: Alex Deucher
CC: Christian Koenig
Ok, with me. But I think it would be cleaner if the backend can j
VM support is only available for CZ and newer APUs. Trying to
enable it for dGPU will blow up in DC.
Signed-off-by: Harry Wentland
Suggested-by: Alex Deucher
CC: Christian Koenig
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drive
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Harry Wentland
> Sent: Monday, October 30, 2017 11:02 AM
> To: Christian König; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/display: revert "enable GPU VM support"
>
> On 201
On 10/30/2017 01:14 PM, Leo wrote:
On 2017-10-30 12:36 PM, Leo wrote:
On 2017-10-26 11:06 PM, Andrey Grodzovsky wrote:
On 2017-10-26 02:34 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
Abandon new_crtcs array and use for_each_new iterator to acquire new
crtcs.
Signed-off-by: Le
On 10/30/2017 12:36 PM, Leo wrote:
On 2017-10-26 11:06 PM, Andrey Grodzovsky wrote:
On 2017-10-26 02:34 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
Abandon new_crtcs array and use for_each_new iterator to acquire new
crtcs.
Signed-off-by: Leo (Sunpeng) Li
Reviewed-by: Harry Wen
On 2017-10-30 12:36 PM, Leo wrote:
On 2017-10-26 11:06 PM, Andrey Grodzovsky wrote:
On 2017-10-26 02:34 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
Abandon new_crtcs array and use for_each_new iterator to acquire new
crtcs.
Signed-off-by: Leo (Sunpeng) Li
Reviewed-by: Harry Wen
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Monday, October 30, 2017 10:00 AM
> To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/ttm: once more fix ttm_buffer_object_trans
On 2017-10-26 11:06 PM, Andrey Grodzovsky wrote:
On 2017-10-26 02:34 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
Abandon new_crtcs array and use for_each_new iterator to acquire new
crtcs.
Signed-off-by: Leo (Sunpeng) Li
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/amd/displ
On 2017-10-28 10:44 AM, Christian König wrote:
> Am 28.10.2017 um 01:35 schrieb Felix Kuehling:
>> The kfd_process doesn't own a reference to the mm_struct, so it can
>> disappear without warning even while the kfd_process still exists.
>>
>> Therefore, avoid dereferencing the kfd_process.mm pointe
Reviewed-by: Andrey Grodzovsky
On 10/30/2017 11:10 AM, Harry Wentland wrote:
We need to avoid calling reset after detection because the next
commit adds freesync properties on the atomic_state which are set
during detection. Calling reset after this clears them.
The easiest way to accomplish
We need to avoid calling reset after detection because the next
commit adds freesync properties on the atomic_state which are set
during detection. Calling reset after this clears them.
The easiest way to accomplish this right now is to call ->reset on
the connector right after creation but before
On 2017-10-30 10:55 AM, Christian König wrote:
> From: Christian König
>
> This reverts commit aa7187c5c640559ebc02caa0191c0db46b55b4a6.
>
> Disable GPU VM support again for now until it doesn't cause a warning on
> hardware which doesn't support it.
>
> Signed-off-by: Christian König
Reviewe
From: Christian König
The amdgpu issue to also need signaled fences in the reservation objects should
be fixed by now.
Optimize the handling by replacing a signaled fence when adding a new
shared one.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 18 +++---
1
From: Christian König
The amdgpu issue to also need signaled fences in the reservation objects
should be fixed by now.
Optimize the list by keeping only the not signaled yet fences around.
v2: temporary put the signaled fences at the end of the new container
Signed-off-by: Christian König
---
From: Christian König
This reverts commit aa7187c5c640559ebc02caa0191c0db46b55b4a6.
Disable GPU VM support again for now until it doesn't cause a warning on
hardware which doesn't support it.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
1 file c
On 30/10/17 03:51 PM, Christian König wrote:
> Well I've found a minor bug in TTM (false positive warning), but was
> never able to reproduce this issue.
I've been reproducing it fairly regularly since I reported it.
> What hardware generation did you use for testing?
Tonga.
--
Earthling Mic
Well I've found a minor bug in TTM (false positive warning), but was
never able to reproduce this issue.
What hardware generation did you use for testing?
Christian.
Am 25.10.2017 um 17:54 schrieb Michel Dänzer:
On 25/10/17 05:51 PM, Christian König wrote:
Going to take a look tomorrow.
Th
Hi Dieter, Tom,
I'm not sure I'll be able to send a DC commit to fix this today. We should
probably revert the offending commit for now.
Harry
On 2017-10-30 10:16 AM, Christian König wrote:
> Hi Dieter,
>
> yes Tom is right that the display team is going to take care of it.
>
> If Harry hasn'
Hi Dieter,
yes Tom is right that the display team is going to take care of it.
If Harry hasn't come up with a patch by the evening we should probably
revert the offending commit for now.
The problem the ttm patch is about is really hard to trigger and only
occurs very occasionally.
Regards
Hi Dieter,
This is due to:
commit aa7187c5c640559ebc02caa0191c0db46b55b4a6
Author: Christian König
Date: Thu Oct 26 12:00:36 2017 +0200
drm/amd/display: enable GPU VM support
Just set the bit so that DC does the hardware programming.
Signed-off-by: Christian König
Reviewed
Hello Christian,
is this for these warnings flooding my dmesg-log or do I have to open a
new ticket:
Current amd-staging-drm-next commit #7781a8c68a6a from you ;-)
[ 6588.429302] WARNING: CPU: 5 PID: 2957 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x
From: Christian König
When the mutex is locked just in the moment we copy it we end up with a
warning that we release a locked mutex.
Fix this by properly reinitializing the mutex.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
1 file changed, 1 insertion(+)
diff
The function for byteswapping the data send to/from atombios was buggy for
num_bytes not divisible by four. The function must be aware of the fact
that after byte-swapping the u32 units, valid bytes might end up after the
num_bytes boundary.
This patch was tested on kernel 3.12 and allowed us to s
From: Christian König
To quote Felix: "For testing KV with current user mode stack, please use
amdgpu. I don't expect this to work with radeon and I'm not planning to spend
any effort on making radeon work with a current user mode stack."
Only compile tested, but should be straight forward.
Sig
Am 30.10.2017 um 05:15 schrieb Monk Liu:
for SR-IOV when doing gpu reset this routine shouldn't do
resource allocating otherwise memory leak
Change-Id: I25da3a5b475196c75c7e639adc40751754625968
Signed-off-by: Monk Liu
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
Am 30.10.2017 um 05:15 schrieb Monk Liu:
Signed-off-by: Monk Liu
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
b/drivers/gpu/drm/amd/amdgpu/mxg
Am 30.10.2017 um 05:15 schrieb Monk Liu:
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
Si
Am 30.10.2017 um 05:15 schrieb Monk Liu:
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
Reviewed-by:
Yeah, my typo, thanks !
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: 2017年10月30日 18:00
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/6] amd/scheduler:imple job skip feature(v3)
Am 30.10.2017 um 05:15 schrieb Monk Liu:
> jo
Am 30.10.2017 um 05:15 schrieb Monk Liu:
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 asic reset
part is implemented differently
3,gpu_recover will increase hang job karma and mark its enti
Am 30.10.2017 um 05:15 schrieb Monk Liu:
jobs are skipped under two cases
1)when the entity behind this job marked guilty, the job
poped from this entity's queue will be dropped in sched_main loop.
2)in job_recovery(), skip the scheduling job if its karma detected
above limit, and also skipped a
Am 30.10.2017 um 04:25 schrieb Chunming Zhou:
On 2017年10月27日 22:43, Christian König wrote:
From: Christian König
Just allocate the GART space and fill it.
This prevents forcing the BO to be idle.
v2: don't unbind/bind at all, just fill the allocated GART space
Could you explain what 'unbin
The only thing that is not pushed through the scheduler are the ring and
IB tests and those only because we want to use them directly in the GPU
reset code to check if the hardware now works properly again.
The VM updates have a separate queue for each VM, but the initial clear
goes through th
Another option is adding a function with the same logics as top half probe to
determine if KFD is enabled or not, like amdgpu_amdkfd_enabled().
I think it’s okay to pass pdev separately. The KFD probe implementation also
has pdev parameter, it doesn’t retrieve that from adev, while the middle la
Except from pdev, kfd doesn't access any other fields in adev, so
passing pdev as a different parameter seems fine.
The problem with that approach is we need to remember for the future
not to access other adev fields, and that seems risky and not correct
On Mon, Oct 30, 2017 at 10:30 AM, Ding,
Get your point. I don’t know why the test is passed however will revise later.
I definitely want the know if KFD is enabled before device init. Any
suggestion? Or do you mind if the pdev is passed to probe in other way?
—
Sincerely Yours,
Pixel
On 30/10/2017, 4:20 PM, "Oded Gabbay" wro
On Mon, Oct 30, 2017 at 9:57 AM, Pixel Ding wrote:
> From: pding
>
> Move kfd probe prior to device init. Release exclusive mode
> after hw_init if kfd is not enabled.
>
> Signed-off-by: pding
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
From: pding
Move kfd probe prior to device init. Release exclusive mode
after hw_init if kfd is not enabled.
Signed-off-by: pding
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff
> That is not correct. All VM activity goes through the GPU scheduler as well.
> So we are certainly going to re-schedule everything.
I'll check on that, if all go through scheduler that will be fine, that way
just don't increase the karma of the job from kernel RQ is enough
To prevent VM jobs b
I can't see any difference between the handling of existing VMs and new created
ones.
I know, for existing VMs we still have similar problems, I'm not saying this
patch can save existing VM problem ...
My eldest patch series actually use a way can 100% avoid such problem: use RW
mlock on drm_
52 matches
Mail list logo
