Reviewed-by: Felix Kuehling
Thanks,
Felix
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, December 13, 2018 9:59:30 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix; Quan, Evan
Subject: [PATCH] drm/amdgpu: update the vm invalidation engi
Addressed this in the new patch which was just sent out.
Thanks,
Evan
> -Original Message-
> From: Kuehling, Felix
> Sent: 2018年12月14日 1:09
> To: amd-gfx@lists.freedesktop.org; Quan, Evan ;
> Deucher, Alexander ; Zeng, Oak
> ; Koenig, Christian
> Subject: Re: [PATCH 2/4] drm/amdgpu: updat
We need new invalidation engine layout due to new SDMA page
queues added.
V2: fix coding style and add correct return value
Change-Id: I2f3861689bffb9828c9eae744a7a0de4963ac2b6
Signed-off-by: Evan Quan
Reviewed-by: Christian König
Reviewed-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
incl
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
* branch device was unplugged. This should be fixed by tracking
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is al
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/dri
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks a
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/disp
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
There should be no functional changes here
Signed-off-by: Lyude Paul
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topo
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
---
drivers/gpu/drm/i915/intel_connector.c | 4
drivers/gpu/drm/i915/intel_dp
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
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, but ports which need their payloads released due
to being removed wi
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
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git a/dri
This is a WIP version of the series I've been working on for a while now
to get all of the atomic DRM drivers in the tree to use the atomic MST
helpers, and to make the atomic MST helpers actually idempotent. Turns
out it's a lot more difficult to do that without also fixing how port
and branch dev
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 could be simplified.
To the best of my understanding, the current s
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 a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
in
I thought to change the filename to amdgpu_hmm.c/h, then change the data
structure,
variables, function name from amdgpu_mn_* to amdgpu_hmm_*, seems too
many changes,
so I gave up that change.
Philip
On 2018-12-07 7:00 a.m., Zhou, David(ChunMing) wrote:
> Even you should rename amdgpu_mn.c/h to
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 upda
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 updates from drm helpers go through the full
atomic cod
On 2018-12-10 7:12 p.m., Kuehling, Felix wrote:
> This is a nice improvement from the last version. I still see some
> potential problems. See inline ...
>
> I'm skipping over the CS and GEM parts. I hope Christian can review
> those parts.
>
> On 2018-12-06 4:02 p.m., Yang, Philip wrote:
>> Use HM
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 updates from drm helpers go through the full
>>> atomic codepath. A high volume of cursor updates through this slow
Am 13.12.18 um 18:26 schrieb Daniel Vetter:
>>> Code sharing just because the code looks similar is imo a really
>>> bad idea, when the semantics are entirely different (that was also the
>>> reason behind not reusing all the cpu event stuff for dma_fence, they're
>>> not normal cpu events).
>> Ok,
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(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu
On Thu, Dec 13, 2018 at 5:47 PM Koenig, Christian
wrote:
>
> Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> > On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> >> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 u
Some nit-picks inline.
On 2018-12-12 11:09 p.m., Evan Quan wrote:
> We need new invalidation engine layout due to new SDMA page
> queues added.
>
> Change-Id: I2f3861689bffb9828c9eae744a7a0de4963ac2b6
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 47 ++---
Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
>> Am 13.12.18 um 13:21 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2018-12-13 12:11:10)
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11
Reviewed-by: Oak Zeng
Regards,
Oak
-Original Message-
From: Evan Quan
Sent: Wednesday, December 12, 2018 11:10 PM
To: amd-gfx@lists.freedesktop.org
Cc: Koenig, Christian ; Zeng, Oak ;
Deucher, Alexander ; Quan, Evan
Subject: [PATCH 2/4] drm/amdgpu: update the vm invalidation engine l
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Michel
Dänzer
Sent: Thursday, December 13, 2018 11:06:35 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: WARN once if amdgpu_bo_unpin is called for an
unpinned BO
From: Michel Dänzer
It
Reviewed-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Wednesday, December 12, 2018 11:10 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zeng, Oak
; Quan, Evan ; Koenig, Christian
Subject: [PATCH 1/4] drm/amdgpu: increase the M
From: Michel Dänzer
It indicates a pin/unpin imbalance bug somewhere. While the bug isn't
necessarily in the call chain hitting this, it's at least one part
involved.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2018-12-13 12:11:10)
> >> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> >>> Quoting Chunming Zhou (2018-12-11 10:34:45)
> From: Christian König
>
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 updates from drm helpers go through the full
>> atomic codepath. A high volume of cursor updates through this slow
>> code path can cause subsequent page-flips to skip vb
On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Legacy cursor plane updates from drm helpers go through the full
> atomic codepath. A high volume of cursor updates through this slow
> code path can cause subsequent page-flips to skip vblank intervals
> since each individual update is
Quoting Chris Wilson (2018-12-13 15:36:43)
> Quoting Antonio Argenziano (2018-12-13 15:28:00)
> >
> >
> > On 13/12/18 03:57, Chris Wilson wrote:
> > > amdgpu has started to report out of space after creating a few contexts.
> > > This is not the scope of this test as here we just verifying that f
On Thu, Dec 13, 2018 at 6:57 AM Chris Wilson wrote:
>
> amdgpu has started to report out of space after creating a few contexts.
> This is not the scope of this test as here we just verifying that fences
> created in amd can be imported and used for synchronisation by i915 and
> for that we just n
Quoting Antonio Argenziano (2018-12-13 15:28:00)
>
>
> On 13/12/18 03:57, Chris Wilson wrote:
> > amdgpu has started to report out of space after creating a few contexts.
> > This is not the scope of this test as here we just verifying that fences
> > created in amd can be imported and used for s
On 13/12/18 03:57, Chris Wilson wrote:
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one con
From: Huaisheng Ye
There are compiler warnings within functions 'dcn10_log_hubbub_state’
and 'dcn10_get_hubbub_state’. This patch avoids the compiler reports
the following warning when building amdgpu.ko.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_lo
On Wed, Dec 12, 2018 at 7:08 PM Dave Airlie wrote:
>
> On Thu, 13 Dec 2018 at 07:13, Alex Deucher wrote:
> >
> > Hi Dave,
> >
> > Updates for 4.21:
> > - Powerplay updates for newer polaris variants
> > - Add cursor plane update fast path
> > - Enable gpu reset by default on CI parts
> > - Fix co
Acked-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, December 13, 2018 1:14:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amdgpu: unify Vega20 PSP SOS firmwares for A0 and A1
The new PSP SOS firmware can sup
Am 13.12.18 um 13:21 schrieb Chris Wilson:
> Quoting Koenig, Christian (2018-12-13 12:11:10)
>> Am 13.12.18 um 12:37 schrieb Chris Wilson:
>>> Quoting Chunming Zhou (2018-12-11 10:34:45)
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> > Quoting Chunming Zhou (2018-12-11 10:34:45)
> >> From: Christian König
> >>
> >> Implement finding the right timeline point in drm_syncobj_find_fence.
> >>
> >> v2: return -EINVAL when the point is not
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11 10:34:45)
>> 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 h
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one context created!
References: https://bugs.fre
Quoting Chunming Zhou (2018-12-11 10:34:45)
> 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
>
> Signed-off-by: Christian Kön
Quoting Chunming Zhou (2018-12-11 10:34:40)
> 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,
>
Am 13.12.18 um 05:09 schrieb Evan Quan:
> As two more SDMA page queue rings are added on Vega20.
>
> Change-Id: I8a3d8fbc924f7c24aaebf17b3f329a4a38fe5a56
> Signed-off-by: Evan Quan
Reviewed-by: Christian König for this one.
And Acked-by: Christian König for patch #3
and #4.
Regards,
Christia
Am 13.12.18 um 05:09 schrieb Evan Quan:
> We need new invalidation engine layout due to new SDMA page
> queues added.
>
> Change-Id: I2f3861689bffb9828c9eae744a7a0de4963ac2b6
> Signed-off-by: Evan Quan
Wow, that looks really nice. Patch is Reviewed-by: Christian König
> ---
> drivers/gpu/drm
51 matches
Mail list logo