On Tue, May 05, 2020 at 11:37:23PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 05, 2020 at 02:01:16PM +0300, Ville Syrjälä wrote:
> > On Tue, May 05, 2020 at 01:42:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 05, 2020 at 01:22:43PM +0300, Stanislav Lisovskiy wrote:
> > > > Introduce plat
Quoting Chris Wilson (2020-05-05 22:52:09)
> +bool i915_sched_node_verify_dag(struct i915_sched_node *waiter,
> + struct i915_sched_node *signaler)
> +{
> + struct i915_dependency *dep, *p;
> + struct i915_dependency stack;
> + bool result = false;
>
On Tue, May 05, 2020 at 01:42:46PM +0300, Ville Syrjälä wrote:
> On Tue, May 05, 2020 at 01:22:43PM +0300, Stanislav Lisovskiy wrote:
> > Introduce platform dependent SAGV checking in
> > combination with bandwidth state pipe SAGV mask.
> >
> > v2, v3, v4, v5, v6: Fix rebase conflict
> >
> > Sign
On Wed, May 06, 2020 at 10:55:44AM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 05, 2020 at 01:42:46PM +0300, Ville Syrjälä wrote:
> > On Tue, May 05, 2020 at 01:22:43PM +0300, Stanislav Lisovskiy wrote:
> > > Introduce platform dependent SAGV checking in
> > > combination with bandwidth state
On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > Starting from TGL we need to have a separate wm0
> > values for SAGV and non-SAGV which affects
> > how calculations are done.
> >
> > v2: Remove long lines
> >
On Wed, May 06, 2020 at 11:08:34AM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 10:55:44AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 05, 2020 at 01:42:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 05, 2020 at 01:22:43PM +0300, Stanislav Lisovskiy wrote:
> > > > Introduce plat
On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > Starting from TGL we need to have a separate wm0
> > > values for SAGV and non-SAGV w
On Wed, May 06, 2020 at 11:43:30AM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 06, 2020 at 11:08:34AM +0300, Ville Syrjälä wrote:
> > On Wed, May 06, 2020 at 10:55:44AM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 05, 2020 at 01:42:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 0
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 15/22] drm/i915/rkl: Add DDC pin mapping
>
> The pin mapping for the final two outputs varies according to which
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 18/22] drm/i915/rkl: Handle comp master/slave
> relationships for PHYs
>
> Certain combo P
== Series Details ==
Series: series starting with [01/14] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/76973/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17586_full
===
From: Ville Syrjälä
IBX supports vswing level 3 and pre-emphasis level 3. Don't
limit it to level 2 for those.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.
From: Ville Syrjälä
Final pieces for plumbing the crtc state all the way down to the guts of
the link trainign code. Allows us to eliminate a bunch of adhoc state
from intel_dp, and nukes some of the remaining crtc->config usages.
I'm also fixing the DP spec violations around the vswing/pre-emph
From: Ville Syrjälä
cpt/ppt support pre-emphasis level 3. Let's actually declare
support for it, instead of clamping things to level 2.
Also tweak the if-ladder in intel_dp_voltage_max() to match
intel_dp_pre_emphasis_max() to make it easier to compare them.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Use max() instead of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm
From: Ville Syrjälä
According to the DP spec supporting vswing 1 + preemph 2 is
mandatory. We don't have the hw settings for that though. In
order to pretend to follow the DP spec let's just select
vswing 0 + preemph 2 in this case (the DP spec says to use
the requested preemph in preference to t
From: Ville Syrjälä
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp d
From: Ville Syrjälä
Different platforms have different max vswing/preemph settings.
Turn that into a pair vfuncs so we can decouple intel_dp.c and
intel_ddi.c further.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++
drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
th
From: Ville Syrjälä
The DP spec says:
"The transmitter shall support at least three levels of voltage
swing (Levels 0, 1, and 2).
If only three levels of voltage swing are supported (VOLTAGE
SWING SET field (bits 1:0) are programmed to 10 (Level 2)),
this bit shall be set to 1, and cleared i
From: Ville Syrjälä
The DP spec says:
"When the combination of the requested pre-emphasis level and
voltage swing exceeds the capability of a DPTX, the DPTX shall
set the pre-emphasis level according to the request and use the
highest voltage swing it can output with the given pre-emphasis lev
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code
URL : https://patchwork.freedesktop.org/series/76993/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 02/22] x86/gpu: add RKL stolen memory support
>
> RKL re-uses the same stolen memory regi
On 04/05/2020 14:23, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-05-04 12:12:49)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
th
On 06/05/2020 15:04, Lionel Landwerlin wrote:
On 04/05/2020 14:23, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-05-04 12:12:49)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers usi
Quoting Lionel Landwerlin (2020-05-06 13:04:57)
> On 04/05/2020 14:23, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-05-04 12:12:49)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> >>
> >> This can
On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > > Starting from
On 2020-05-05 at 19:09:54 +0300, Imre Deak wrote:
> On Tue, May 05, 2020 at 07:39:04AM -0700, Matt Roper wrote:
> > On Tue, May 05, 2020 at 10:20:58AM +0530, Anshuman Gupta wrote:
> > > On 2020-05-04 at 15:52:13 -0700, Matt Roper wrote:
> > > > RKL power wells are similar to TGL power wells, but ha
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17588
Summary
--
On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 0
On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK wants the +1 adjustement for the "blocks per line" value
> for x-tile/y-tile, just like cnl+.
>
> Also the x-tile and linear cases are almost identical. The only
> difference is this +1 which is always d
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No change is dsb write/commit functions.
Now dsb get/put function is refactored and currently used only for
reference counting. Below dsb api added to do respective job
On Wed, May 06, 2020 at 04:17:20PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > GLK wants the +1 adjustement for the "blocks per line" value
> > for x-tile/y-tile, just like cnl+.
> >
> > Also the x-tile and l
Op 01-05-2020 om 01:09 schreef Manasi Navare:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, which is
> not supported yet.
>
> eDP does not support bigjoiner, so do not expose bigjoiner only
> m
On Wed, May 06, 2020 at 04:16:36PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 0
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17588_full
Summ
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for
> PHY's A and B
>
> Since the number of platforms with this restr
On 2020-04-29 at 15:54:47 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch fixes a few bugs:
>
> 1- We weren't taking into account sha_leftovers when adding multiple
>ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
>the beginning of ksv[j]
>
> 2- In the sha_
On 2020-04-29 at 15:54:48 -0400, Sean Paul wrote:
> From: Sean Paul
>
> On HDCP disable, clear the repeater bit. This ensures if we connect a
> non-repeater sink after a repeater, the bit is in the state we expect.
>
> Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
> Cc
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17589
Summa
On 2020-04-29 at 15:54:50 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
> aux messages and add the aksv flag in the aux transfer hook.
>
> IIRC, this was the original implementation and folks wanted this hack to
> be isolat
On 2020-04-29 at 15:54:49 -0400, Sean Paul wrote:
> From: Sean Paul
>
> HDCP signalling should not be left on, WARN if it is
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Reviewed-by: Ramalingam C
Just reconfirming the R-b.
-Ram
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesk
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_fence.c | 124
1 file changed, 124 insertions(+)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
index 4b0d87e4d..a75188c9c 100644
--- a/tests/i915/gem_exec_fence.c
+++ b/tests/i915/ge
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 107 +
1 file changed, 107 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 7274ffbf3..a1523277b 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/test
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
Hey,
I've been testing on re-tgl1-display, but series fails.
The 8k mode is rejected because of htotal exceeding limits.
When testing 5120x3200@120 Hz, I get:
[18352.624231] i915 :00:02.0: [drm:intel_crtc_compute_min_cdclk [i915]]
required cdclk (1056740 kHz) exceeds max (652800 kHz)
Latt
Quoting Chris Wilson (2020-05-06 15:36:16)
> Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
> timeslicing, as we do not treat it as a preemption request but as a soft
> ordering hint. If we apply the hint, then when we recompute the ordering
> after unwinding for the timeslice, we
On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> As with the realisation for soft-rc6, we respond to idling the engines
> within microseconds, far faster than the response times for HW RC6 and
> RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> running for many des
Flush TDL,L3 and EUs
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 78f879ed4aa7..e1235d504837 100644
--- a/drivers/gpu/drm/i915/gt/intel_l
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael ANtognolli
Signed-off-by: Mik
This reverts commit 62037229b7d94f1db5ef8d2e2ec819832ef3.
L3 ro cache invalidation is part of the dword0 of pipe
control. Also it is not relevant to this gen.
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 -
drivers/gpu/drm/i915
HDC pipeline flush is bit on the first dword of
the PIPE_CONTROL, not the second. Make it so.
v2: function naming (Chris)
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 34
drivers/gpu/drm/i915/gt/intel_gpu_command
Quoting Mika Kuoppala (2020-05-06 15:47:34)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
This sounds like it should have a sunset clause. Do we anticipate
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17589_full
=
On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the platform if ladders in
> intel_digital_port_connected() and make it a vfunc. Now the if
> ladders are at the encoder initialization which makes them a bit
> less convoluted.
>
> v2: Add
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-05-06 15:47:34)
>> Aux table invalidation can fail on update. So
>> next access may cause memory access to be into stale entry.
>>
>> Proposed workaround is to invalidate entries between
>> all batchbuffers.
>
> This sounds like it should have a
Quoting Mika Kuoppala (2020-05-06 16:20:22)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-05-06 15:47:34)
> >> Aux table invalidation can fail on update. So
> >> next access may cause memory access to be into stale entry.
> >>
> >> Proposed workaround is to invalidate entries between
On 05/05/2020 22:52, Chris Wilson wrote:
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> > As with the realisation for soft-rc6, we respond to idling the engines
> > within microseconds, far faster than the response times for HW RC6 and
> > RPS. Furthermore, our fast parking upo
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc:
On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of constnantly having to figure out which hpd status bit
> array to use let's store them under dev_priv.
>
> Should perhaps take this further and stash even more stuff to
> make the hpd handling more
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 4 +++-
1 fil
On Wed, Mar 11, 2020 at 05:54:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of several platform specific variants of
> intel_digital_port_connected() and just use the ISR bits we've
> stashed away.
>
> v2: Duplicate stuff to avoid exposing platform specific
> functions a
Quoting Mika Kuoppala (2020-05-06 16:58:55)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
>
> v2: correct register address (Yang)
>
> References bspec#4390
On Wed, May 06, 2020 at 06:49:06AM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message- From: Intel-gfx
> > On Behalf Of Matt Roper
> > Sent: Tuesday, May 5, 2020 4:22 AM To:
> > intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2
> > 10/22] drm/i915/rkl: RKL only uses PH
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
v3: respect the order (Chris)
References bspec#43904, hsdes#1809175790
Cc: Chris Wi
== Series Details ==
Series: series starting with [1/2] drm/i915: Mark concurrent submissions with a
weak-dependency
URL : https://patchwork.freedesktop.org/series/76999/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17590
===
Quoting Chris Wilson (2020-05-06 16:55:07)
> Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> > Btw, there are other patches on the list of failed cherry-picks:
> >
> > 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> > unbind")
>
> We need that to fix a deadlock.
>
> > c
Quoting Mika Kuoppala (2020-05-06 15:47:33)
> Flush TDL,L3 and EUs
>
> Signed-off-by: Mika Kuoppala
I bow to your interpretation of the docs,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fre
== Series Details ==
Series: drm/i915: Propagate error from completed fences
URL : https://patchwork.freedesktop.org/series/77003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17591
Summary
---
**S
== Series Details ==
Series: series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3
to invalidate" (rev3)
URL : https://patchwork.freedesktop.org/series/77000/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8437 -> Patchwork_17592
=
== Series Details ==
Series: drm/i915: Propagate error from completed fences
URL : https://patchwork.freedesktop.org/series/77003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8434_full -> Patchwork_17591_full
Summary
On Mon, May 04, 2020 at 03:52:21PM -0700, Matt Roper wrote:
> There are a couple places in our driver that loop over transcoders A..D
> for gen11+; since RKL only has three pipes/transcoders, this can lead to
> unclaimed register reads/writes. We should add checks for transcoder
> existence where
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
The downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the req
These were used to set various timeouts for the reset procedure
(deciding when the engine was dead, and even if the reset itself was not
making forward progress). No longer used.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --g
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
We allow exported sync_file fences to be used as submit fences, but they
are not the only source of user fences. We also accept an array of
syncobj, and as with sync_file these are dma_fences underneath and so
feature the same set of controls. The submit-fence allows for a request
to be scheduled a
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
Just tidy up the return handling for completed dma-fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 7daf81
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Link: https://gitlab.freed
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
While this does not appear to fix any issues, the backend itself knows
when it wants to emit a breadcrumb, so let it make the final call.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 3 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 3 +--
2 files changed, 2
This timeout is only used in one place, to provide a tiny bit of grace
for slow igt to cleanup after themselves. If we are a bit stricter and
opt to kill outstanding requsts rather than wait, we can speed up igt by
not waiting for 200ms after a hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
dri
As a means for a small code consolidation, but primarily to start
thinking more carefully about internal-vs-external linkage, pull the
pair of i915_sw_fence_await_dma_fence() calls into a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 ++--
1
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signe
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wro
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wro
Some Cc to try to get it reviewed.
Lucas De Marchi
On Fri, Mar 6, 2020 at 5:26 PM Lucas De Marchi wrote:
>
> This avoids the annoying message
> "Failed to get panel details from OpRegion (-19)" while initializing.
> On DGFX there is no access to OpRegion, so just avoid any calls related
> to it.
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a
weak-dependency
URL : https://patchwork.freedesktop.org/series/77007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17593
===
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e532b66dff06 drm/i915: Mark concurrent submissions with a
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17594
=
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
992fe0e5bf6f drm/i915/rkl: Add RKL platform info and PCI ids
-:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - pos
1 - 100 of 117 matches
Mail list logo
