On 12/14/2018 02:17 PM, Kazlauskas, Nicholas wrote:
> On 12/14/18 2:06 PM, Grodzovsky, Andrey wrote:
>> In general I agree with Michel that DRM solution is required to
>> properly address this but since now it's not really obvious what is the
>> proper solution it seems to me OK to go with this
Except for the GEM and CS parts, the series is Reviewed-by: Felix
Kuehling
Regards,
Felix
On 2018-12-14 4:10 p.m., Yang, Philip wrote:
> Use HMM helper function hmm_vma_fault() to get physical pages backing
> userptr and start CPU page table update track of those pages. Then use
>
The series is Reviewed-by: Felix Kuehling
On 2018-12-14 10:22 a.m., Lin, Amber wrote:
> Since amdkfd is merged into amdgpu module and amdgpu can access amdkfd
> directly, move declaration of kgd2kfd functions from kfd_priv.h to
> amdgpu_amdkfd.h
>
> Signed-off-by: Amber Lin
> ---
>
On 2018-12-14 2:31 p.m., Wentland, Harry wrote:
> On 2018-12-07 3:32 p.m., Kuehling, Felix wrote:
>> On 2018-12-07 9:46 a.m., Wentland, Harry wrote:
>>> On 2018-12-07 9:41 a.m., Wentland, Harry wrote:
On 2018-12-07 12:40 a.m., Kuehling, Felix wrote:
> This change seems to be breaking the
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are
Hi Felix,
Thanks, I will submit another patch to fix those KFD part issues.
Philip
On 2018-12-14 2:54 p.m., Kuehling, Felix wrote:
> Looks good for the KFD part. One nit-pick inline. And two more
> suggestions about amdgpu_ttm.c to make our handling of
> get_user_pages_done more robust.
>
>
Looks good for the KFD part. One nit-pick inline. And two more
suggestions about amdgpu_ttm.c to make our handling of
get_user_pages_done more robust.
Christian, would you review the CS and GEM parts? And maybe take a look
you see nothing wrong with the amdgpu_ttm changes either.
On 2018-12-13
On 2018-12-14 12:26 p.m., Nicholas Kazlauskas wrote:
> [Why]
> The behavior of drm_atomic_helper_cleanup_planes differs depending on
> whether the commit was asynchronous or not. When it's called from
> amdgpu_dm_atomic_commit_tail during a typical atomic commit the
> plane state has been swapped
On 2018-12-04 5:18 p.m., Mikhail Gavrilov wrote:
> Hi guys.
> I having troubles when Vega GPU is hang I unable reboot system.
>
> Can somebody help me please.
>
> I tried enter follow commands:
> # init 6
> # reboot
> But no one of them having success.
>
> SysRq-W showing to us this:
>
Looks
4.16 and older kernels work great with the hardware, no performance
drops or glitching/freezing
kernels 4.17 , 4.18 , 4.19 and 4.20 is not working with the hardware,
causing heavy performance drops and system unstability,
commit responsible is:
With this change in latest drm-next and related commit in latest FW i get
[ 148.887374] [drm:psp_hw_init [amdgpu]] *ERROR* PSP firmware loading failed
[ 148.887535] [drm:amdgpu_device_fw_loading [amdgpu]] *ERROR* hw_init of IP
block failed -22
Had to revert to be able to boot.
Andrey
On
On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
>
> Signed-off-by: Chunming Zhou
+igt-dev
I think intel-gfx still works for IGT development but most of the IGT work
happens on igt-...@lists.freedesktop.org now.
Harry
> ---
> include/drm-uapi/drm.h | 33
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Kuehling,
Felix
Sent: Friday, December 14, 2018 2:05:11 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix
Subject: [PATCH 1/1] drm/amdkfd: Fix handling of return code of dma_buf_get
On errors,
On 12/14/18 2:06 PM, Grodzovsky, Andrey wrote:
> In general I agree with Michel that DRM solution is required to
> properly address this but since now it's not really obvious what is the
> proper solution it seems to me OK to go with this fix until it's found.
>
> Reviewed-by: Andrey Grodzovsky
In general I agree with Michel that DRM solution is required to
properly address this but since now it's not really obvious what is the
proper solution it seems to me OK to go with this fix until it's found.
Reviewed-by: Andrey Grodzovsky
Andrey
On 12/14/2018 12:51 PM, Kazlauskas, Nicholas
On errors, dma_buf_get returns a negative error code, rather than NULL.
Reported-by: Dan Carpenter
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
On 12/14/18 12:47 PM, Grodzovsky, Andrey wrote:
>
>
> On 12/14/2018 12:41 PM, Kazlauskas, Nicholas wrote:
>> On 12/14/18 12:34 PM, Grodzovsky, Andrey wrote:
>>>
>>> On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote:
[Why]
The behavior of drm_atomic_helper_cleanup_planes differs
On 12/14/2018 12:41 PM, Kazlauskas, Nicholas wrote:
> On 12/14/18 12:34 PM, Grodzovsky, Andrey wrote:
>>
>> On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote:
>>> [Why]
>>> The behavior of drm_atomic_helper_cleanup_planes differs depending on
>>> whether the commit was asynchronous or not. When
On 12/14/18 12:34 PM, Grodzovsky, Andrey wrote:
>
>
> On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote:
>> [Why]
>> The behavior of drm_atomic_helper_cleanup_planes differs depending on
>> whether the commit was asynchronous or not. When it's called from
>> amdgpu_dm_atomic_commit_tail during a
On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote:
> [Why]
> The behavior of drm_atomic_helper_cleanup_planes differs depending on
> whether the commit was asynchronous or not. When it's called from
> amdgpu_dm_atomic_commit_tail during a typical atomic commit the
> plane state has been swapped
[Why]
The behavior of drm_atomic_helper_cleanup_planes differs depending on
whether the commit was asynchronous or not. When it's called from
amdgpu_dm_atomic_commit_tail during a typical atomic commit the
plane state has been swapped so it calls cleanup_fb on the old plane
state.
However, in the
The series are:
Acked-by: Leo Liu
On 12/13/18 1:08 PM, Zhu, James wrote:
> Remove bit 31 for scratch2 to indicate the Hardware bug work around is active.
>
> Signed-off-by: James Zhu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
On 12/14/18 10:19 AM, Kazlauskas, Nicholas wrote:
> On 12/14/18 10:01 AM, Michel Dänzer wrote:
>> On 2018-12-14 3:48 p.m., Nicholas Kazlauskas wrote:
>>> [Why]
>>> The behavior of dm_plane_helper_cleanup_fb differs depending on
>>> whether the commit was asynchronous or not. When it's called from
On Thu, Dec 13, 2018 at 08:25:42PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>*
Reviewed-by: Alex Deucher
From: Christian König
Sent: Friday, December 14, 2018 9:37:23 AM
To: Deucher, Alexander; alexdeuc...@gmail.com; amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix IH overflow on Vega10
When an ring buffer overflow happens
After amdkfd is merged into amdgpu module, amdgpu can call amdkfd
functions directly.
Signed-off-by: Amber Lin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 26 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 3 +--
kgd2kfd function pointers and global kgd2kfd pointer are no longer in use.
Signed-off-by: Amber Lin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 3 +-
drivers/gpu/drm/amd/amdkfd/kfd_module.c | 29 +-
Since amdkfd is merged into amdgpu module and amdgpu can access amdkfd
directly, move declaration of kgd2kfd functions from kfd_priv.h to
amdgpu_amdkfd.h
Signed-off-by: Amber Lin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 43
On 12/14/18 10:01 AM, Michel Dänzer wrote:
> On 2018-12-14 3:48 p.m., Nicholas Kazlauskas wrote:
>> [Why]
>> The behavior of dm_plane_helper_cleanup_fb differs depending on
>> whether the commit was asynchronous or not. When it's called from
>> amdgpu_dm_atomic_commit_tail during a typical atomic
Just a reminder. Any new comments in light of all the discussion ?
Andrey
On 12/12/2018 08:08 AM, Grodzovsky, Andrey wrote:
> BTW, the problem I pointed out with drm_sched_entity_kill_jobs_cb is not
> an issue with this patch set since it removes the cb from
> s_fence->finished in general so we
On 2018-12-14 3:48 p.m., Nicholas Kazlauskas wrote:
> [Why]
> The behavior of dm_plane_helper_cleanup_fb differs depending on
> whether the commit was asynchronous or not. When it's called from
> amdgpu_dm_atomic_commit_tail during a typical atomic commit the
> plane state has been swapped so it
Hello Felix Kuehling,
The patch 1dde0ea95b78: "drm/amdkfd: Add DMABuf import functionality"
from Nov 20, 2018, leads to the following static checker warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_chardev.c:1643
kfd_ioctl_import_dmabuf()
error: 'dmabuf' dereferencing possible
[Why]
The behavior of dm_plane_helper_cleanup_fb differs depending on
whether the commit was asynchronous or not. When it's called from
amdgpu_dm_atomic_commit_tail during a typical atomic commit the
plane state has been swapped so it calls cleanup_fb on the old plane
state.
However, in the
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the
On 12/14/18 3:46 AM, Michel Dänzer wrote:
> On 2018-12-13 9:59 p.m., Kazlauskas, Nicholas wrote:
>> On 12/13/18 2:21 PM, Kazlauskas, Nicholas wrote:
>>> On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote:
On 12/13/18 10:48 AM, Michel Dänzer wrote:
> On 2018-12-05 8:59 p.m., Nicholas
On Thu, Dec 13, 2018 at 08:25:33PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
>
On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote:
> Up until now, freeing payloads on remote MST hubs that just had ports
> removed has almost never worked because we've been relying on port
> validation in order to stop us from accessing ports that have already
> been freed from memory,
On Thu, Dec 13, 2018 at 08:25:35PM -0500, Lyude Paul wrote:
> So that the ports stay around until we've destroyed the connectors, in
> order to ensure that we don't pass an invalid pointer to any MST helpers
> once we introduce the new MST VCPI helpers.
>
> Signed-off-by: Lyude Paul
> ---
>
On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things
On 2018-12-13 9:59 p.m., Kazlauskas, Nicholas wrote:
> On 12/13/18 2:21 PM, Kazlauskas, Nicholas wrote:
>> On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote:
>>> On 12/13/18 10:48 AM, Michel Dänzer wrote:
On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Legacy cursor plane
On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
> There should be no functional changes here
Would be good to explain what you did refactor here, instead of me trying
to reconstruct it from the patch. Especially pre-coffee that helps :-)
>
> Signed-off-by: Lyude Paul
> Cc: Juston Li
On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
> There's no reason we need this, it's just confusing looking.
>
> Signed-off-by: Lyude Paul
> Cc: Juston Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git
42 matches
Mail list logo
