== Series Details ==
Series: series starting with [1/3] drm/edid: Allow looking for ext blocks
starting from a specified index (rev2)
URL : https://patchwork.freedesktop.org/series/77699/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8708 -> Patchwork_18081
==
== Series Details ==
Series: series starting with [1/3] drm/edid: Allow looking for ext blocks
starting from a specified index (rev2)
URL : https://patchwork.freedesktop.org/series/77699/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ffc23f2b930d drm/edid: Allow looking for ex
== Series Details ==
Series: drm/i915: Export ppgtt_bind_vma
URL : https://patchwork.freedesktop.org/series/79086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8707_full -> Patchwork_18079_full
Summary
---
**FAILURE
On 02/07/2020 09:32, Chris Wilson wrote:
We need to make the DMA allocations used for page directories to be
performed up front so that we can include those allocations in our
memory reservation pass. The downside is that we have to assume the
worst case, even before we know the final layout, a
On 02/07/2020 09:32, Chris Wilson wrote:
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and t
On 03/07/2020 10:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-03 10:24:27)
On 03/07/2020 10:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-03 09:44:52)
On 02/07/2020 09:32, Chris Wilson wrote:
The GEM object is grossly overweight for the practicality of tracking
large
On 2020-07-03 at 16:48:27 +0530, Anshuman Gupta wrote:
> On 2020-06-23 at 21:29:07 +0530, Sean Paul wrote:
> > From: Sean Paul
> >
> > Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> > MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> > support is th
== Series Details ==
Series: drm/i915: Use ww locking in execbuf submission.
URL : https://patchwork.freedesktop.org/series/79091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8707 -> Patchwork_18080
Summary
---
**F
Hi Chris,
On Thu, Jul 02, 2020 at 09:32:07AM +0100, Chris Wilson wrote:
> Reuse the ppgtt_bind_vma() for aliasing_ppgtt_bind_vma() so we can
> reduce some code near-duplication. The catch is that we need to then
> pass along the i915_address_space and not rely on vma->vm, as they
> differ with the
== Series Details ==
Series: drm/i915: Use ww locking in execbuf submission.
URL : https://patchwork.freedesktop.org/series/79091/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i
== Series Details ==
Series: drm/i915: Use ww locking in execbuf submission.
URL : https://patchwork.freedesktop.org/series/79091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96ffbd309edc Revert "drm/i915/gem: Async GPU relocations only"
-:113: WARNING:MEMORY_BARRIER: memory
== Series Details ==
Series: drm/i915: Export ppgtt_bind_vma
URL : https://patchwork.freedesktop.org/series/79086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8707 -> Patchwork_18079
Summary
---
**SUCCESS**
No r
On 03/07/2020 13:22, Maarten Lankhorst wrote:
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
On 03/07/2020 13:22, Maarten Lankhorst wrote:
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
On 03/07/2020 13:22, Maarten Lankhorst wrote:
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i91
On 03/07/2020 13:22, Maarten Lankhorst wrote:
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
f
On 03/07/2020 13:22, Maarten Lankhorst wrote:
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.
On Wed, 01 Jul 2020, Lucas De Marchi wrote:
> On Tue, Jun 30, 2020 at 06:55:38PM +0300, Jani Nikula wrote:
>>On Wed, 24 Jun 2020, Lucas De Marchi wrote:
>>> We are not checking for specific SKUs and feedback from HW team is that
>>> it may not work since it was supposed to be fixed by the same ti
On Mon, 22 Jun 2020, Lucas De Marchi wrote:
> On Wed, Jan 1, 2020 at 11:19 PM Lucas De Marchi
> wrote:
>>
>> On Tue, Dec 31, 2019 at 1:58 AM Jani Nikula
>> wrote:
>> >
>> > On Mon, 23 Dec 2019, Lucas De Marchi wrote:
>> > > For the latest platforms we can share the logic to initialize the the
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Breaks the execbuf ww locking series.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 314 --
.../i915/gem/se
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
for a single execbuf").
This breaks ww mutex -EDEADLK handling, and we can deal with relocations
fine without it. The ww mutexes protect concur
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..548ed9fb427d 100644
Change the locking hierarchy to put request inside ww, and fix selftests to
hopefully pass now.
Maarten Lankhorst (23):
Revert "drm/i915/gem: Async GPU relocations only"
drm/i915: Revert relocation chaining commits.
Revert "drm/i915/gem: Drop relocation slowpath".
drm/i915: Add an impleme
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
[mlankhorst: Adjusted for reloc_gpu_flush() changes]
Cc: Chris Wilson
Cc: Matthew
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/ge
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
On 2020-06-23 at 21:28:58 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Add an out label and un-indent hdcp disable in preparation for
> hdcp_mutex. No functional changes
LGTM
Reviewed-by: Anshuman Gupta
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/2020
On Thu, Jul 02, 2020 at 11:02:05PM +, Souza, Jose wrote:
> On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The MSG_FBC_REND_STATE register only exists on snb+. For older
> > platforms (would also work for snb+) we can simply rewite DSPSURF
> > to trigge
On Thu, Jul 02, 2020 at 11:24:04PM +, Souza, Jose wrote:
> On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Consult the actual plane stride instead of the fb stride. The two
> > will disagree when we remap the gtt. The plane stride is what the
> > hw wil
On 2020-06-23 at 21:29:07 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> support is the same as the DP case, so we'll re-use those callbacks
>
> Cc: Jus
On Wed, Jun 24, 2020 at 05:29:05PM -0700, José Roberto de Souza wrote:
> Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> supported motherboards to use a special voltage swing table for eDP
> panels that uses less power.
>
> So here if supported by HW, OEM will set it in VB
> -Original Message-
> From: Intel-gfx On Behalf Of José
> Roberto de Souza
> Sent: Thursday, June 25, 2020 5:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3 1/3] drm/i915/bios: Parse HOBL parameter
>
> HOBL means hours of battery life, it is a power-saving
On Thu, Jul 02, 2020 at 12:27:42PM -0700, Manasi Navare wrote:
> On Thu, Jul 02, 2020 at 09:24:50PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we claim to use TPS7 when using TPS4. That is just
> > confusing, so let's fix the debug print.
> >
> > And while we're touchi
On Thu, 02 Jul 2020, Manasi Navare wrote:
> On Thu, Jul 02, 2020 at 12:15:26PM +0300, Stanislav Lisovskiy wrote:
>> We still need "Bump up CDCLK" workaround otherwise getting
>> underruns - however currently it blocks 8K as CDCLK = Pixel rate,
>> in 8K case would require CDCLK to be around 1 Ghz w
Op 02-07-2020 om 16:51 schreef Tvrtko Ursulin:
> On 02/07/2020 14:26, Maarten Lankhorst wrote:
>> Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>>> On 24/06/2020 12:05, Maarten Lankhorst wrote:
Killing context before taking ctx->mutex fixes a hang in
gem_ctx_persistence.close-replace-rac
On 2020-06-23 at 21:29:03 +0530, Sean Paul wrote:
> From: Sean Paul
>
> This patch plumbs port through hdcp init instead of relying on
> intel_attached_encoder() to return a non-NULL encoder which won't work
> for MST connectors.
Looks good to me,
Reviewed-by: Anshuman Gupta
>
> Cc: Ville Syrjä
Reuse the ppgtt_bind_vma() for aliasing_ppgtt_bind_vma() so we can
reduce some code near-duplication. The catch is that we need to then
pass along the i915_address_space and not rely on vma->vm, as they
differ with the aliasing-ppgtt.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
.../
On 2020-06-23 at 21:29:04 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Currently we derive the connector from digital port in check_link(). For
> MST, this isn't sufficient since the digital port passed into the
> function can have multiple connectors downstream. This patch adds
> connector to t
> -Original Message-
> From: Intel-gfx On Behalf Of José
> Roberto de Souza
> Sent: Tuesday, June 30, 2020 1:36 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/ehl: Add new PCI ids
>
> Two new PCI ids added to ehl.
>
> BSpec: 29153
> Signed-off-by: José
Quoting Tvrtko Ursulin (2020-07-03 10:24:27)
>
> On 03/07/2020 10:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-07-03 09:44:52)
> >>
> >> On 02/07/2020 09:32, Chris Wilson wrote:
> >>> The GEM object is grossly overweight for the practicality of tracking
> >>> large numbers of individua
On 03/07/2020 10:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-03 09:44:52)
On 02/07/2020 09:32, Chris Wilson wrote:
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA al
Quoting Tvrtko Ursulin (2020-07-03 09:59:01)
>
> On 02/07/2020 09:32, Chris Wilson wrote:
> > Remove the stub i915_vma_pin() used for incrementally pining objects for
> > execbuf (under the severe restriction that they must not wait on a
> > resource as we may have already pinned it) and replace i
Quoting Tvrtko Ursulin (2020-07-03 09:44:52)
>
> On 02/07/2020 09:32, Chris Wilson wrote:
> > The GEM object is grossly overweight for the practicality of tracking
> > large numbers of individual pages, yet it is currently our only
> > abstraction for tracking DMA allocations. Since those allocati
On 02/07/2020 09:32, Chris Wilson wrote:
Remove the stub i915_vma_pin() used for incrementally pining objects for
execbuf (under the severe restriction that they must not wait on a
resource as we may have already pinned it) and replace it with a
i915_vma_pin_inplace() that is only allowed to re
On 02/07/2020 09:32, Chris Wilson wrote:
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and t
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
URL : https://patchwork.freedesktop.org/series/79064/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8702_full -> Patchwork_18078_full
==
63 matches
Mail list logo
