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,
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
> ---
>
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
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:
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
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,
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
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.
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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 +-
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
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:
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
---
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
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 ++
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
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
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
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
---
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
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
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
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
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
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
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
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
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: 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
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
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
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
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
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
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).
>>
51 matches
Mail list logo
