The Wa number for this fix is Wa_1607087056 the BSpec bug id is
1607087056, just updating to match BSpec.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/
This issue workaround in Wa_1607063988 has the same fix as
Wa_1607138336, so just adding a note in the code.
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drive
From: Anusha Srivatsa
According to BSpec. Wa_1606931601 applies for all TGL steppings.
This patch moves the WA implementation out of A0 only block of
rcs_engine_wa_init().
The WA is has also been referred to by an alternate name
Wa_1607090982.
Bspec: 46045, 52890
Fixes: 3873fd1a43c7 ("drm/i915
From: Matt Atwood
Disable Push Constant buffer addition for TGL.
v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.
Bspec: 52890
Cc: Rafael Antognolli
Cc: Matt Roper
Reviewed-by: Matt Roper
Signed-off-by: Matt Atwood
Signed-off
This workaround is only fixed in C0 stepping to extend it to B0 too.
BSpec: 52890
Cc: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/d
Add note about the confliting information in BSpec about this WA.
BSpec: 52890
Acked-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_w
This will fix a memory coherence issue.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 20 +++-
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gp
Just to make easier to check that the Wa was implemetend when
comparing to the number in BSpec.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/dri
It is fixed in B0 stepping.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6d9ec124db8..9df150f877b1 100644
--- a/drivers/gp
This workaround the CS not done issue on PIPE_CONTROL.
v2:
- replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits
- shortened the name of the new bit
BSpec: 52890
BSpec: 46218
Cc: Matt Roper
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_
Different issues with the same fix, so justing adding
Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793,
Wa_1409178076 and 1408979724 to the comment so other devs can check if
this Was were implemetend with a simple grep.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/
This will whitelist the HIZ_CHICKEN register so mesa can disable the
optimizations and avoid hang when using D16_UNORM.
v2: moved to the right place and used the right function() (Chris)
Cc: Matt Roper
Cc: Rafael Antognolli
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gp
Spliting GT and display revisions id to correctly apply workarounds
because we have some issues that were fixed in display B0 but no
hardware was made with B0 stepping, so to keep consistent with BSpec
splitting it from GT and adding this adittional handling.
BSpec: 52890
BSpec: 44455
Cc: Matt Rop
This Wa will also be needed by B0 stepping.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/disp
== Series Details ==
Series: 3 display pipes combination system support (rev4)
URL : https://patchwork.freedesktop.org/series/72468/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7998_full -> Patchwork_16687_full
Summary
--
On Sat, Feb 22, 2020 at 10:00:07AM +0100, Mauro Carvalho Chehab wrote:
> Fix two warnings due to file rename:
>
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> csr support for dmc ./drivers/gpu/drm/i915/intel_csr.c' failed with return
> code 1
> WARNING: k
Still the same in rc3
Hopefully patch will land in rc4...
---
Srdačan pozdrav/Best regards/Freundliche Grüße/Cordialement,
Siniša Bandin
On 21.02.2020 03:23, Souza, Jose wrote:
We have a fix for this issue, still going through review.
https://gitlab.freedesktop.org/drm/intel/issues/1151
On
On Fri, Feb 21, 2020 at 10:04 PM Daniel Vetter wrote:
>
> It's (almost, there's some iommu stuff without significance) right
> above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensur
== Series Details ==
Series: drm/i915: split intel_modeset_init() to pre/post irq install
URL : https://patchwork.freedesktop.org/series/73849/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7997_full -> Patchwork_16686_full
On 25.02.2020 08:49, Ye, Tony wrote:
>
>
> On 2/21/2020 11:32 PM, Michal Wajdeczko wrote:
>> From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
>> in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
>> to indicate lack of HuC hardware and we started to use this err
On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
wrote:
> OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
That's impressive :D
> Unfortunately it found a lot of strange stuff:
I will answer for the weirdness I caused.
I have long suspected that a whole bunch of the "simple
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/sel
On 2020-02-24 13:33:12, Jani Nikula wrote:
> We no longer need or use it as we subclass struct drm_device in our
> struct drm_i915_private, and can always use to_i915() to get at
> i915. Stop assigning the pointer to catch anyone trying to add new users
> for ->dev_private.
>
> Cc: Chris Wilson
>
On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> > On 25.02.2020 12:21, Ville Syrjälä wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2020 21:35, Ville Syrjala wrote:
> > >>>
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Link: https://github.com/intel/compute-runtime/pull/261
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Steve Carbonari
Reviewed-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/Makefi
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 42 ++
Quoting Tvrtko Ursulin (2020-02-25 19:07:43)
>
> On 24/02/2020 09:59, Chris Wilson wrote:
> > -int i915_active_wait(struct i915_active *ref)
> > +static int flush_barrier(struct active_node *it)
> > {
> > - struct active_node *it, *n;
> > - int err = 0;
> > + struct intel_engine_cs *
On 24/02/2020 09:59, Chris Wilson wrote:
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
---
drivers/gpu/drm/i915/i915_active.c | 42 +++
Update DRIVER_DATE to 20200225 (2020-02-25 10:41:22 -0800)
- A backmerge of drm-next solving conflicts on i915/gt/intel_lrc.c
- Clean up shadow batch after I915_EXEC_SECURE
- Drop assertion that activ
Quoting Tvrtko Ursulin (2020-02-25 18:18:12)
>
> On 25/02/2020 18:11, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-02-25 18:08:14)
> >>
> >> On 24/02/2020 21:56, Chris Wilson wrote:
> >>> Check that if we have to remove a hostile request from a non-persistent
> >>> context, we do so withou
On 25/02/2020 18:11, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-25 18:08:14)
On 24/02/2020 21:56, Chris Wilson wrote:
Check that if we have to remove a hostile request from a non-persistent
context, we do so without harming any other concurrent users.
Signed-off-by: Chris Wilson
-
Quoting Tvrtko Ursulin (2020-02-25 18:08:14)
>
> On 24/02/2020 21:56, Chris Wilson wrote:
> > Check that if we have to remove a hostile request from a non-persistent
> > context, we do so without harming any other concurrent users.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > + /* All oth
On 24/02/2020 21:56, Chris Wilson wrote:
Check that if we have to remove a hostile request from a non-persistent
context, we do so without harming any other concurrent users.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_persistence.c | 63
1 file chan
On Tue, 25 Feb 2020 at 08:22, Chris Wilson wrote:
>
> Check that we can recover if the LRC is totally corrupted.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesk
== Series Details ==
Series: drm/i915: stop assigning drm->dev_private pointer
URL : https://patchwork.freedesktop.org/series/73848/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7996_full -> Patchwork_16685_full
Summary
--
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure the dbuf slice mask for any individual pipe has no
> holes between the slices.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 9 +
> 1 file
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a global state to track the dbuf slices. Gets rid of all the
> nasty
> coupling between state->modeset and dbuf recomputation. Also we can
> now
> totally nuke state->active_pipe_changes.
>
> dev_priv->wm.distr
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe
> on
> icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's
> active or
> not). Let's make the behaviour consistent and always return 0
On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote:
> Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware):
> > On 2/23/20 4:45 PM, Christian König wrote:
> > > Am 21.02.20 um 18:12 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > Yeah the Great Plan (tm) is to fully rely on ww_mutex sl
From: Ville Syrjälä
skl_ddb_get_pipe_allocation_limits() doesn't care how the weights
for distributing the ddb are caclculated for each pipe. Put that
calculation into a separate function so that such mundane details
are hidden from view.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Switch to the preferred 'crtc' name for our crtc variables.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.
From: Ville Syrjälä
Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe on
icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's active or
not). Let's make the behaviour consistent and always return 0 for any
inactive pipe.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville
From: Ville Syrjälä
Readout the dbuf related stuff during driver init/resume and
stick it into our dbuf state.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 --
drivers/gpu/drm/i915/intel_pm.c | 48 +++-
From: Ville Syrjälä
The low level dbuf slice code is rather inconsitent with its
functiona naming and organization. Make it more consistent.
Also share the enable/disable functions between all platforms
since the same code works just fine for all of them.
Cc: Stanislav Lisovskiy
Signed-off-by:
From: Ville Syrjälä
Make sure the dbuf slice mask for any individual pipe has no
holes between the slices.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/dr
From: Ville Syrjälä
More complete version of intel_dbuf_state. We finally get rid of
distrust_bios_wm and all the uglyness surrounding it. And we no
longer have to know ahead of time whether the duf allocation
might change or not, and thus don't need to pull in all crtcs
into the state up front.
From: Ville Syrjälä
Put the code into a function with a descriptive name. Also relocate
the code a bit help future work.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 34 +++--
1 file changed, 20 insertions(+), 14 deleti
From: Ville Syrjälä
Encapsulate the dbuf state more by moving the pre/post
plane functions out from intel_display.c. We stick them
into intel_pm.c since that's where the rest of the code
lives for now.
Eventually we should add a new file for this stuff at which
point we also need to decide if it
From: Ville Syrjälä
Add a global state to track the dbuf slices. Gets rid of all the nasty
coupling between state->modeset and dbuf recomputation. Also we can now
totally nuke state->active_pipe_changes.
dev_priv->wm.distrust_bios_wm still remains, but that too will get
nuked soon.
Cc: Stanisla
From: Ville Syrjälä
Polish some of the dbuf code to give more meaningful debug
messages and whatnot. Also we can switch over to the per-device
debugs/warns at the same time.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power.c| 40 +--
From: Ville Syrjälä
skl_ddb_get_hw_state() is redundant and kinda called in thw wrong
spot anyway. Just kill it.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
drivers/gpu/drm/i915/intel_pm.h | 1 -
2 files changed, 8 deletions(-)
diff -
From: Ville Syrjälä
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by now requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute
From: Ville Syrjälä
Make life a bit simpler by sticking a sentinel at the end of
the dbuf slice arrays. This way we don't need to pass in the
size. Also unify the types (u8 vs. u32) for active_pipes.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 34
From: Ville Syrjälä
skl_compute_dbuf_slices() has no use for the crtc state, so
just pass the crtc itself.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/driv
From: Ville Syrjälä
The preferred style is to sprinkle commas after each array and
structure initialization, whether or not it happens to be the
last element/member (only exception being sentinel entries which
never have anything after them). This leads to much prettier
diffs if/when new elements
From: Ville Syrjälä
Extract the code to calculate the weights used to chunk up the dbuf
between pipes. There's still extra stuff in there that shouldn't be
there and must be moved out, but that requires a bit more state to
be tracked in the dbuf state.
Cc: Stanislav Lisovskiy
Signed-off-by: Vil
From: Ville Syrjälä
The dbuf state will be where we collect all the inter-pipe dbuf
allocation stuff. Start by moving the actual per-pipe ddb entries
there.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++
.../drm
From: Ville Syrjälä
Combine the two per-pipe dbuf debugs into one, and use the canonical
[CRTC:%d:%s] style to identify the crtc. Also use the same style as
the plane code uses for the ddb start/end, and prefix bitmask properly
with 0x to make it clear they are in fact bitmasks.
The "how many to
From: Ville Syrjälä
Generalize icl_get_first_dbuf_slice_offset() into something that
just gives us the start+end of the dbuf chunk covered by the
specified slices as a standard ddb entry. Initial idea was to use
it during readout as well, but we shall see.
Cc: Stanislav Lisovskiy
Signed-off-by:
From: Ville Syrjälä
These things can never happen, and probably we'd have oopsed long ago
if they did. Just get rid of this pointless noise in the code.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 11 ---
1 file changed, 11 deletions(-)
As we measure how long it takes for each heartbeat when idling the
system, we have a reasonable expectation for the baseline latency when
idling. We can use this baseline to estimate how long we expect it
should take to idle, and so provide a more precise upper bound for
declaring a problem.
Refer
Quoting Janusz Krzysztofik (2020-02-25 15:41:28)
> Hi Chris,
>
> On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > > + /* create userptr object */
> > > + igt_assert_eq(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE),
> > > 0);
>
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Get rid of mode->vrefresh and just calc
Hi Chris,
On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to set up a
> > mmap-offset (or mmap-gtt) mapping to
On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other
== Series Details ==
Series: drm/i915/perf: Mark up the racy use of perf->exclusive_stream
URL : https://patchwork.freedesktop.org/series/73905/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8004 -> Patchwork_16703
Summary
On 25.02.2020 12:21, Ville Syrjälä wrote:
> On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
>> On 19.02.2020 21:35, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> Get rid of mode->vrefresh and just calculate it on demand. Saves
>>> a bit of space and avoids the cached value ge
On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
On Mon, Feb 24, 2020 at 06:10:01PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> - Simp
Quoting Gustavo A. R. Silva (2020-02-25 14:03:47)
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
I remember
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
>
> Hi Daniel,
>
>
> The patchset looks interesting.
>
>
> On 21.02.2020 22:02, Daniel Vetter wrote:
> > We have lots of these. And the cleanup code tends to be of dubious
> > quality. The biggest wrong pattern is that developers use devm_, whi
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with ad
The reasoning behind this is such that current dependencies
in the code are rather implicit in a sense, we have to constantly
check a bunch of different bits like state->modeset,
state->active_pipe_changes, which sometimes can indicate counter
intuitive changes.
By introducing more fine grained st
== Series Details ==
Series: drm/i915/perf: Mark up the racy use of perf->exclusive_stream
URL : https://patchwork.freedesktop.org/series/73905/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0dd2fa185616 drm/i915/perf: Mark up the racy use of perf->exclusive_stream
-:11: WARNIN
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this hap
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 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
== Series Details ==
Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
URL : https://patchwork.freedesktop.org/series/45968/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8004 -> Patchwork_16701
Su
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
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
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_
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_request.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..2a6052d609d9 100644
--- a
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 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 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/
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
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
---
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
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
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
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
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
We want to get rid of struct mutex, but vma reservation was entangled
with vma lookup. Make vma lookup and validation a preparation step,
and vma pinning a repeatable step. This allows us to keep all the looked
up information when dropping all locks, which saves an extra lookup during
relocation sl
From: Chris Wilson
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_n
From: Chris Wilson
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as
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
1 - 100 of 164 matches
Mail list logo
