[Intel-gfx] [PATCH 1/1] drm/i915/perf: Map OA buffer to user space
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach based on
triggered reports within oa buffer. In order to enable above feature
two changes are required:
1. Whitelist update:
- enable triggered reports within oa buffer
- reading oa buffer head/tail/status information
- reading gpu ticks counter.
2. Map oa buffer at umd driver level to solve below constraints related
to time based sampling interface:
- longer time to access reports collected by oa buffer
- slow oa reports browsing since oa buffer size is large
- missing oa report index, so query cannot browse report directly
- with direct access to oa buffer, query can extract other useful
reports like context switch information needed to calculate correct
performance counters values.
Signed-off-by: Piotr Maciejewski
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 54
drivers/gpu/drm/i915/i915_perf.c| 130 +++-
drivers/gpu/drm/i915/i915_perf_types.h | 13 ++
drivers/gpu/drm/i915/i915_reg.h | 14 +++
include/uapi/drm/i915_drm.h | 19 +++
5 files changed, 227 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 5726cd0a37e0..cf89928fc3a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1365,6 +1365,48 @@ whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
}
+static void gen9_whitelist_build_performance_counters(struct i915_wa_list *w)
+{
+ /* OA buffer trigger report 2/6 used by performance query */
+ whitelist_reg(w, OAREPORTTRIG2);
+ whitelist_reg(w, OAREPORTTRIG6);
+
+ /* Performance counters A18-20 used by tbs marker query */
+ whitelist_reg_ext(w, OA_PERF_COUNTER_A18,
+ RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_16);
+
+ /* Read access to gpu ticks */
+ whitelist_reg_ext(w, GEN8_GPU_TICKS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+ /* Read access to: oa status, head, tail, buffer settings */
+ whitelist_reg_ext(w, GEN8_OASTATUS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4);
+}
+
+static void gen12_whitelist_build_performance_counters(struct i915_wa_list *w)
+{
+ /* OA buffer trigger report 2/6 used by performance query */
+ whitelist_reg(w, GEN12_OAG_OAREPORTTRIG2);
+ whitelist_reg(w, GEN12_OAG_OAREPORTTRIG6);
+
+ /* Performance counters A18-20 used by tbs marker query */
+ whitelist_reg_ext(w, GEN12_OAG_PERF_COUNTER_A18,
+ RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_16);
+
+ /* Read access to gpu ticks */
+ whitelist_reg_ext(w, GEN12_OAG_GPU_TICKS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+ /* Read access to: oa status, head, tail, buffer settings */
+ whitelist_reg_ext(w, GEN12_OAG_OASTATUS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4);
+}
+
static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
@@ -1378,6 +1420,9 @@ static void gen9_whitelist_build(struct i915_wa_list *w)
/* WaSendPushConstantsFromMMIO:skl,bxt */
whitelist_reg(w, COMMON_SLICE_CHICKEN2);
+
+ /* Performance counters support */
+ gen9_whitelist_build_performance_counters(w);
}
static void skl_whitelist_build(struct intel_engine_cs *engine)
@@ -1471,6 +1516,9 @@ static void cnl_whitelist_build(struct intel_engine_cs
*engine)
/* WaEnablePreemptionGranularityControlByUMD:cnl */
whitelist_reg(w, GEN8_CS_CHICKEN1);
+
+ /* Performance counters support */
+ gen9_whitelist_build_performance_counters(w);
}
static void icl_whitelist_build(struct intel_engine_cs *engine)
@@ -1500,6 +1548,9 @@ static void icl_whitelist_build(struct intel_engine_cs
*engine)
whitelist_reg_ext(w, PS_INVOCATION_COUNT,
RING_FORCE_TO_NONPRIV_ACCESS_RD |
RING_FORCE_TO_NONPRIV_RANGE_4);
+
+ /* Performance counters support */
+ gen9_whitelist_build_performance_counters(w);
break;
case VIDEO_DECODE_CLASS:
@@ -1550,6 +1601,9 @@ static void tgl_whitelist_build(struct intel_engine_cs
*engine)
/* Wa_1806527549:tgl */
whitelist_reg(w, HI
[Intel-gfx] [PATCH 0/1] Allow privileged user to map the OA buffer
This cover letter is included to trigger "Test-with" an IGT patch. Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200714071334.69883-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (1): drm/i915/perf: Map OA buffer to user space drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 drivers/gpu/drm/i915/i915_perf.c| 130 +++- drivers/gpu/drm/i915/i915_perf_types.h | 13 ++ drivers/gpu/drm/i915/i915_reg.h | 14 +++ include/uapi/drm/i915_drm.h | 19 +++ 5 files changed, 227 insertions(+), 3 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915/perf: Map OA buffer to user space
On Tue, Jul 14, 2020 at 12:22:39AM -0700, Umesh Nerlige Ramappa wrote:
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach based on
triggered reports within oa buffer. In order to enable above feature
two changes are required:
1. Whitelist update:
- enable triggered reports within oa buffer
- reading oa buffer head/tail/status information
- reading gpu ticks counter.
2. Map oa buffer at umd driver level to solve below constraints related
to time based sampling interface:
- longer time to access reports collected by oa buffer
- slow oa reports browsing since oa buffer size is large
- missing oa report index, so query cannot browse report directly
- with direct access to oa buffer, query can extract other useful
reports like context switch information needed to calculate correct
performance counters values.
Signed-off-by: Piotr Maciejewski
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 54
drivers/gpu/drm/i915/i915_perf.c| 130 +++-
drivers/gpu/drm/i915/i915_perf_types.h | 13 ++
drivers/gpu/drm/i915/i915_reg.h | 14 +++
include/uapi/drm/i915_drm.h | 19 +++
5 files changed, 227 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 5726cd0a37e0..cf89928fc3a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1365,6 +1365,48 @@ whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
}
+static void gen9_whitelist_build_performance_counters(struct i915_wa_list *w)
+{
+ /* OA buffer trigger report 2/6 used by performance query */
+ whitelist_reg(w, OAREPORTTRIG2);
+ whitelist_reg(w, OAREPORTTRIG6);
+
+ /* Performance counters A18-20 used by tbs marker query */
+ whitelist_reg_ext(w, OA_PERF_COUNTER_A18,
+ RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_16);
the above whitelist should be broken into
whitelist_reg_ext(w, OA_PERF_COUNTER_A18,
RING_FORCE_TO_NONPRIV_ACCESS_RW |
RING_FORCE_TO_NONPRIV_RANGE_4);
whitelist_reg(w, OA_PERF_COUNTER_A20);
whitelist_reg(w, OA_PERF_COUNTER_A20_UPPER);
+
+ /* Read access to gpu ticks */
+ whitelist_reg_ext(w, GEN8_GPU_TICKS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+ /* Read access to: oa status, head, tail, buffer settings */
+ whitelist_reg_ext(w, GEN8_OASTATUS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4);
+}
+
+static void gen12_whitelist_build_performance_counters(struct i915_wa_list *w)
+{
+ /* OA buffer trigger report 2/6 used by performance query */
+ whitelist_reg(w, GEN12_OAG_OAREPORTTRIG2);
+ whitelist_reg(w, GEN12_OAG_OAREPORTTRIG6);
+
+ /* Performance counters A18-20 used by tbs marker query */
+ whitelist_reg_ext(w, GEN12_OAG_PERF_COUNTER_A18,
+ RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_16);
same as the above comment
+
+ /* Read access to gpu ticks */
+ whitelist_reg_ext(w, GEN12_OAG_GPU_TICKS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+ /* Read access to: oa status, head, tail, buffer settings */
+ whitelist_reg_ext(w, GEN12_OAG_OASTATUS,
+ RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4);
+}
+
static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
@@ -1378,6 +1420,9 @@ static void gen9_whitelist_build(struct i915_wa_list *w)
/* WaSendPushConstantsFromMMIO:skl,bxt */
whitelist_reg(w, COMMON_SLICE_CHICKEN2);
+
+ /* Performance counters support */
+ gen9_whitelist_build_performance_counters(w);
}
static void skl_whitelist_build(struct intel_engine_cs *engine)
@@ -1471,6 +1516,9 @@ static void cnl_whitelist_build(struct intel_engine_cs
*engine)
/* WaEnablePreemptionGranularityControlByUMD:cnl */
whitelist_reg(w, GEN8_CS_CHICKEN1);
+
+ /* Performance counters support */
+ gen9_whitelist_build_performance_counters(w);
}
static void icl_whitelist_build(struct intel_engine_cs *engine)
@@ -1500,6 +1548,9 @@ static void icl_whitelist_build(struct intel_engine_cs
*engine)
whitelist_reg_ext(w, PS_INVOCATION_COUNT,
RING_FORCE_TO_NONPRIV_ACCESS_RD |
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Allow privileged user to map the OA buffer
== Series Details ==
Series: Allow privileged user to map the OA buffer
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
69208bf02940 drm/i915/perf: Map OA buffer to user space
-:214: ERROR:SPACING: space required before the open parenthesis '('
#214: FILE: drivers/gpu/drm/i915/i915_perf.c:1625:
+ if(stream->oa_buffer.cpu_address != 0)
-:280: CHECK:SPACING: No space is necessary after a cast
#280: FILE: drivers/gpu/drm/i915/i915_perf.c:3292:
+ void __user *output = (void __user *) arg;
total: 1 errors, 0 warnings, 1 checks, 393 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/tilcdc: Use standard drm_atomic_helper_commit
On Fri, Jul 10, 2020 at 02:16:50PM +0300, Jyri Sarha wrote:
> Thank you Daniel,
> Now this works perfectly, all while I was on vacation.
>
> On 08/07/2020 17:20, Daniel Vetter wrote:
> > Gives us proper nonblocking support for free, and a pile of other
> > things. The tilcdc code is simply old enough that it was never
> > converted over, but was stuck forever with the copypasta from when it
> > was initially merged.
> >
> > The riskiest thing with this conversion is maybe that there's an issue
> > with the vblank handling or vblank event handling, which will upset
> > the modern commit support in atomic helpers. But from a cursory review
> > drm_crtc_vblank_on/off is called in the right places, and the event
> > handling also seems to exist (albeit with much hand-rolling and
> > probably some races, could perhaps be converted over to
> > drm_crtc_arm_vblank_event without any real loss).
> >
> > Motivated by me not having to hand-roll the dma-fence annotations for
> > this.
> >
> > v2: Clear out crtc_state->event when we're handling the event, to
> > avoid upsetting the helpers (reported by Jyri).
> >
> > v3: Also send out even whent the crtc is getting disabled. Tilcdc looks a
> > bit like conversion to simple display helpers would work out really
> > nice.
> >
>
> Probably. Should take a closer looks some day when I have time.
>
> > Signed-off-by: Daniel Vetter
> > Cc: Jyri Sarha
> > Cc: Tomi Valkeinen
>
> Tested-by: Jyri Sarha
> Reviewed-by: Jyri Sarha
Thanks for testing and reviewing, patch pushed to drm-misc-next.
-Daniel
>
> > --
> > From logs looks like we're not stuck when disabling the display, so I
> > hacked in a bit of code for that too. Like mentioned above, tilcdc
> > looks like a perfect candidate for simple display helpers, I think
> > that would simplify a _lot_ of code here.
> > -Daniel
> > ---
> > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 13
> > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +--
> > drivers/gpu/drm/tilcdc/tilcdc_plane.c | 8 +++--
> > 3 files changed, 19 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > index e9dd5e5cb4e7..1856962411c7 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > @@ -537,6 +537,18 @@ static void tilcdc_crtc_atomic_disable(struct drm_crtc
> > *crtc,
> > tilcdc_crtc_disable(crtc);
> > }
> >
> > +static void tilcdc_crtc_atomic_flush(struct drm_crtc *crtc,
> > +struct drm_crtc_state *old_state)
> > +{
> > + if (!crtc->state->event)
> > + return;
> > +
> > + spin_lock_irq(&crtc->dev->event_lock);
> > + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> > + crtc->state->event = NULL;
> > + spin_unlock_irq(&crtc->dev->event_lock);
> > +}
> > +
> > void tilcdc_crtc_shutdown(struct drm_crtc *crtc)
> > {
> > tilcdc_crtc_off(crtc, true);
> > @@ -822,6 +834,7 @@ static const struct drm_crtc_helper_funcs
> > tilcdc_crtc_helper_funcs = {
> > .atomic_check = tilcdc_crtc_atomic_check,
> > .atomic_enable = tilcdc_crtc_atomic_enable,
> > .atomic_disable = tilcdc_crtc_atomic_disable,
> > + .atomic_flush = tilcdc_crtc_atomic_flush,
> > };
> >
> > void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > index 0d74a6443263..4f5fc3e87383 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > @@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
> > return ret;
> > }
> >
> > -static int tilcdc_commit(struct drm_device *dev,
> > - struct drm_atomic_state *state,
> > - bool async)
> > -{
> > - int ret;
> > -
> > - ret = drm_atomic_helper_prepare_planes(dev, state);
> > - if (ret)
> > - return ret;
> > -
> > - ret = drm_atomic_helper_swap_state(state, true);
> > - if (ret) {
> > - drm_atomic_helper_cleanup_planes(dev, state);
> > - return ret;
> > - }
> > -
> > - /*
> > -* Everything below can be run asynchronously without the need to grab
> > -* any modeset locks at all under one condition: It must be guaranteed
> > -* that the asynchronous work has either been cancelled (if the driver
> > -* supports it, which at least requires that the framebuffers get
> > -* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
> > -* before the new state gets committed on the software side with
> > -* drm_atomic_helper_swap_state().
> > -*
> > -* This scheme allows new atomic state updates to be prepared and
> > -* checked in parallel to the asynchronous completion of the previous
> > -* update. Which is important since compositors need to figure out the
> > -* composition of the next frame right after having sub
Re: [Intel-gfx] [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path
On Wed, Jul 08, 2020 at 01:17:39PM +0800, james qian wang (Arm Technology
China) wrote:
> On Tue, Jul 07, 2020 at 10:12:11PM +0200, Daniel Vetter wrote:
> > Like the helpers, nothing special. Well except not, because we the
> > critical section extends until after hw_done(), since that's the last
> > thing which could hold up a subsequent atomic commit. That means the
> > wait_for_flip_done is included, but that's not a problem, we're
> > allowed to call dma_fence_wait() from signalling critical sections.
> > Even on our own fence (which this does), it's just a bit confusing.
> > But in a way those last 2 function calls are already part of the fence
> > signalling critical section for the next atomic commit.
> >
> > Reading this I'm wondering why komeda waits for flip_done() before
> > calling hw_done(), which is a bit backwards (but hey hw can be
> > special). Might be good to throw a comment in there that explains why,
> > because the original commit that added this just doesn't.
>
> Hi Daniel:
>
> It's a typo, thank you for pointing this out, and I'll give a fix after
> this series have been merged.
>
> for this patch
>
> Reviewed-by: James Qian Wang
Hi James,
Thanks for revieweing. Note that the "wrong" order doesn't have to be a
real problem, there's other drivers which need this one too. But they
explain why in a comment. So if you change that, make sure you test it all
well to avoid surprises.
Testing (with lockdep enabled) would be really good here, can you try to
do that too?
Also, next patch is for drm/malidp, can you pls review that patch too?
Thanks, Daniel
>
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Mihail Atanassov
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 1f6682032ca4..cc5b5915bc5e 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -73,6 +73,7 @@ static struct drm_driver komeda_kms_driver = {
> > static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
> > {
> > struct drm_device *dev = old_state->dev;
> > + bool fence_cookie = dma_fence_begin_signalling();
> >
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >
> > @@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct
> > drm_atomic_state *old_state)
> >
> > drm_atomic_helper_commit_hw_done(old_state);
> >
> > + dma_fence_end_signalling(fence_cookie);
> > +
> > drm_atomic_helper_cleanup_planes(dev, old_state);
> > }
> >
> > --
> > 2.27.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path
On Wed, Jul 08, 2020 at 02:32:40AM +0300, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote: > > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > > nothing fancy going on here. > > Just looking at this patch and the commit message, I have no idea what > this does, and why. It would be nice to expand the commit message to > give some more context, and especially explain why ending signalling > right after drm_atomic_helper_commit_hw_done() is the right option. > > I suppose I'll have to check the whole series in the meantime :-) Yes first three patches. They should land in the next few days. The explanation is a few pages long, not sure that makes much sense to copypaste into every driver patch here. Also patch 16 has some more explanation specific for display. > > Signed-off-by: Daniel Vetter > > Cc: Laurent Pinchart > > Cc: Kieran Bingham > > Cc: linux-renesas-...@vger.kernel.org > > --- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > index 482329102f19..42c5dc588435 100644 > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct > > drm_atomic_state *old_state) > > struct drm_crtc_state *crtc_state; > > struct drm_crtc *crtc; > > unsigned int i; > > + bool fence_cookie = dma_fence_begin_signalling(); > > Can this be moved right before the > drm_atomic_helper_commit_modeset_disables() call ? The critical section starts even before this function starts, but for composability each part is individually annotated. That's why I've put it as the very first thing in every patch. Currently there's nothing between the funciton start and drm_atomic_helper_commit_modeset_disables which could break dma-fence rules, but the entire point of annotations is to not have to manually prove stuff like this. Wrapping it all is the point here. Does that make sense? Also, what I'm realling looking for is testing with lockdep enabled. Neither me nor you is going to catch issues with review here :-) -Daniel > > > > > /* > > * Store RGB routing to DPAD0 and DPAD1, the hardware will be configured > > @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct > > drm_atomic_state *old_state) > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > > > drm_atomic_helper_commit_hw_done(old_state); > > + dma_fence_end_signalling(fence_cookie); > > drm_atomic_helper_wait_for_flip_done(dev, old_state); > > > > drm_atomic_helper_cleanup_planes(dev, old_state); > > -- > Regards, > > Laurent Pinchart -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/79460/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8741 -> Patchwork_18154 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18154 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18154, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18154: ### IGT changes ### Possible regressions * igt@i915_selftest@live@workarounds: - fi-tgl-u2: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-tgl-u2/igt@i915_selftest@l...@workarounds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-tgl-u2/igt@i915_selftest@l...@workarounds.html - fi-skl-6700k2: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-skl-6700k2/igt@i915_selftest@l...@workarounds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-skl-6700k2/igt@i915_selftest@l...@workarounds.html - fi-cml-s: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-cml-s/igt@i915_selftest@l...@workarounds.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-cml-s/igt@i915_selftest@l...@workarounds.html - fi-icl-y: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-icl-y/igt@i915_selftest@l...@workarounds.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-icl-y/igt@i915_selftest@l...@workarounds.html - fi-kbl-x1275: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-kbl-x1275/igt@i915_selftest@l...@workarounds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-kbl-x1275/igt@i915_selftest@l...@workarounds.html - fi-cfl-guc: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-cfl-guc/igt@i915_selftest@l...@workarounds.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-cfl-guc/igt@i915_selftest@l...@workarounds.html - fi-tgl-y: [PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-tgl-y/igt@i915_selftest@l...@workarounds.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-tgl-y/igt@i915_selftest@l...@workarounds.html - fi-skl-guc: [PASS][15] -> [DMESG-FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-skl-guc/igt@i915_selftest@l...@workarounds.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-skl-guc/igt@i915_selftest@l...@workarounds.html - fi-kbl-8809g: [PASS][17] -> [DMESG-FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-kbl-8809g/igt@i915_selftest@l...@workarounds.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-kbl-8809g/igt@i915_selftest@l...@workarounds.html - fi-cfl-8700k: [PASS][19] -> [DMESG-FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-cfl-8700k/igt@i915_selftest@l...@workarounds.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-cfl-8700k/igt@i915_selftest@l...@workarounds.html - fi-kbl-r: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-kbl-r/igt@i915_selftest@l...@workarounds.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-kbl-r/igt@i915_selftest@l...@workarounds.html - fi-icl-u2: [PASS][23] -> [DMESG-FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-icl-u2/igt@i915_selftest@l...@workarounds.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-icl-u2/igt@i915_selftest@l...@workarounds.html - fi-cfl-8109u: [PASS][25] -> [DMESG-FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-cfl-8109u/igt@i915_selftest@l...@workarounds.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-cfl-8109u/igt@i915_selftest@l...@workarounds.html - fi-skl-lmem:[PASS][27] -> [DMESG-FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8741/fi-skl-lmem/igt@i915_selftest@l...@workarounds.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18154/fi-skl-lmem/igt@i915_selftest@l...@workarounds.html - fi-kbl-7500u: [PASS][29
Re: [Intel-gfx] [PATCH 12/20] drm/i915/gem: Asynchronous GTT unbinding
On 06/07/2020 07:19, Chris Wilson wrote:
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can queue up a job that waits on the signal for the old
nodes to complete and upon those signals, remove the old nodes replacing
them with the new ones for the batch. This is still CPU driven, but in
theory we can do the GTT patching from the GPU. The job itself has a
completion signal allowing the execbuf to wait upon the rebinding, and
also other observers to coordinate with the common VM activity.
Letting userspace queue up more work, lets it do more stuff without
blocking other clients. In turn, we take care not to let it too much
concurrent work, creating a small number of queues for each context to
limit the number of concurrent tasks.
This is a monster patch.. what is the end result here? If there are a
few conflicts they can go async, but if more than "concurrency width"
need evict then it will be synchronous?
Could you do without this patch for the first implementation? Or come up
with ideas to split it up and so make understanding and review manageable?
The implementation relies on only scheduling one unbind operation per
vma as we use the unbound vma->node location to track the stale PTE.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1402
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 917 --
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 7 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
drivers/gpu/drm/i915/i915_vma.c | 71 +-
drivers/gpu/drm/i915/i915_vma.h | 4 +
8 files changed, 883 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4d8ac89c56fc..6a406e8798ef 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -18,6 +18,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_gt_buffer_pool.h"
#include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_requests.h"
#include "gt/intel_ring.h"
#include "i915_drv.h"
@@ -43,6 +44,12 @@ struct eb_vma {
u32 handle;
};
+struct eb_bind_vma {
+ struct eb_vma *ev;
+ struct drm_mm_node hole;
+ unsigned int bind_flags;
+};
+
struct eb_vma_array {
struct kref kref;
struct eb_vma vma[];
@@ -66,11 +73,12 @@ struct eb_vma_array {
I915_EXEC_RESOURCE_STREAMER)
/* Catch emission of unexpected errors for CI! */
+#define __EINVAL__ 22
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
#undef EINVAL
#define EINVAL ({ \
DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
- 22; \
+ __EINVAL__; \
})
#endif
@@ -311,6 +319,12 @@ static struct eb_vma_array *eb_vma_array_create(unsigned int count)
return arr;
}
+static struct eb_vma_array *eb_vma_array_get(struct eb_vma_array *arr)
+{
+ kref_get(&arr->kref);
+ return arr;
+}
+
static inline void eb_unreserve_vma(struct eb_vma *ev)
{
struct i915_vma *vma = ev->vma;
@@ -444,7 +458,10 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ if (test_bit(I915_VMA_ERROR_BIT, __i915_vma_flags(vma)))
+ return true;
+
+ if (vma->node.size < max(vma->size, entry->pad_to_size))
return true;
if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
@@ -469,32 +486,6 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
return false;
}
-static u64 eb_pin_flags(const struct drm_i915_gem_exec_object2 *entry,
- unsigned int exec_flags)
-{
- u64 pin_flags = 0;
-
- if (exec_flags & EXEC_OBJECT_NEEDS_GTT)
- pin_flags |= PIN_GLOBAL;
-
- /*
-* Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset,
-* limit address to the first 4GBs for unflagged objects.
-*/
- if (!(exec_flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS))
- pin_flags |= PIN_ZONE_4G;
-
- if (exec_flags & __EXEC_OBJECT_NEEDS_MAP)
- pin_flags |= PIN_MAPPABLE;
-
- if (exec_flags & EXEC_OBJECT_PINNED)
- pin_flags |= entry->offset | PIN_OFFSET_FIXED;
- else if (exec_flags & __EXEC_OBJECT_NEEDS_BIAS)
- pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
-
-
Re: [Intel-gfx] [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function
On Thu, Jul 09, 2020 at 04:05:31PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
> >
> > This avoids me having to roll out dma-fence critical section
> > annotations to this copy.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: David Airlie
> > Cc: Gerd Hoffmann
> > Cc: virtualizat...@lists.linux-foundation.org
> > ---
> > drivers/gpu/drm/virtio/virtgpu_display.c | 20
> > 1 file changed, 20 deletions(-)
> Very nice catch:
> Reviewed-by: Sam Ravnborg
Patch applied, thanks for reviewing.
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> > b/drivers/gpu/drm/virtio/virtgpu_display.c
> > index f3ce49c5a34c..af55b334be2f 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> > @@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device
> > *dev,
> > return &virtio_gpu_fb->base;
> > }
> >
> > -static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
> > -{
> > - struct drm_device *dev = state->dev;
> > -
> > - drm_atomic_helper_commit_modeset_disables(dev, state);
> > - drm_atomic_helper_commit_modeset_enables(dev, state);
> > - drm_atomic_helper_commit_planes(dev, state, 0);
> > -
> > - drm_atomic_helper_fake_vblank(state);
> > - drm_atomic_helper_commit_hw_done(state);
> > -
> > - drm_atomic_helper_wait_for_vblanks(dev, state);
> > - drm_atomic_helper_cleanup_planes(dev, state);
> > -}
> > -
> > -static const struct drm_mode_config_helper_funcs
> > virtio_mode_config_helpers = {
> > - .atomic_commit_tail = vgdev_atomic_commit_tail,
> > -};
> > -
> > static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
> > .fb_create = virtio_gpu_user_framebuffer_create,
> > .atomic_check = drm_atomic_helper_check,
> > @@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device
> > *vgdev)
> > drm_mode_config_init(vgdev->ddev);
> > vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
> > vgdev->ddev->mode_config.funcs = &virtio_gpu_mode_funcs;
> > - vgdev->ddev->mode_config.helper_private = &virtio_mode_config_helpers;
> >
> > /* modes will be validated against the framebuffer size */
> > vgdev->ddev->mode_config.min_width = XRES_MIN;
> > --
> > 2.27.0
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock within request submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 100 +++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ---
drivers/gpu/drm/i915/i915_request.c | 25 ++---
3 files changed, 60 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 91786310c114..87fd06d3eb3f 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,17 +220,17 @@ static void signal_irq_work(struct irq_work *work)
}
}
-static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
lockdep_assert_held(&b->irq_lock);
if (b->irq_armed)
- return true;
+ return;
if (!intel_gt_pm_get_if_awake(engine->gt))
- return false;
+ return;
/*
* The breadcrumb irq will be disarmed on the interrupt after the
@@ -250,8 +250,6 @@ static bool __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
if (!b->irq_enabled++)
irq_enable(engine);
-
- return true;
}
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine)
@@ -310,57 +308,69 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
}
-bool i915_request_enable_breadcrumb(struct i915_request *rq)
+static void insert_breadcrumb(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
{
- lockdep_assert_held(&rq->lock);
+ struct intel_context *ce = rq->context;
+ struct list_head *pos;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
- return true;
+ if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
+ return;
- if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
- struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
- struct intel_context *ce = rq->context;
- struct list_head *pos;
+ __intel_breadcrumbs_arm_irq(b);
- spin_lock(&b->irq_lock);
+ /*
+* We keep the seqno in retirement order, so we can break
+* inside intel_engine_signal_breadcrumbs as soon as we've
+* passed the last completed request (or seen a request that
+* hasn't event started). We could walk the timeline->requests,
+* but keeping a separate signalers_list has the advantage of
+* hopefully being much smaller than the full list and so
+* provides faster iteration and detection when there are no
+* more interrupts required for this context.
+*
+* We typically expect to add new signalers in order, so we
+* start looking for our insertion point from the tail of
+* the list.
+*/
+ list_for_each_prev(pos, &ce->signals) {
+ struct i915_request *it =
+ list_entry(pos, typeof(*it), signal_link);
+
+ if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
+ break;
+ }
+ list_add(&rq->signal_link, pos);
+ if (pos == &ce->signals) /* catch transitions from empty list */
+ list_move_tail(&ce->signal_link, &b->signalers);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
- if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
- goto unlock;
+ set_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+}
- if (!__intel_breadcrumbs_arm_irq(b))
- goto unlock;
+bool i915_request_enable_breadcrumb(struct i915_request *rq)
+{
+ struct intel_breadcrumbs *b;
- /*
-* We keep the seqno in retirement order, so we can break
-* inside intel_engine_signal_breadcrumbs as soon as we've
-* passed the last completed request (or seen a request that
-* hasn't event started). We could walk the timeline->requests,
-* but keeping a separate signalers_list has the advantage of
-* hopefully being much smaller than the full list and so
-* provides faster iteration and detection when there are no
-* more interrupts required for this context.
-*
-* We typically expect to add new signalers in order, so we
-* start looking for our
[Intel-gfx] [PATCH 1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 38 +++--
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0b2fe55e6194..c59315def07d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -190,13 +190,11 @@ static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
- lockdep_assert_held(&rq->lock);
-
- GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(&rq->execute_cb))
return;
- llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(&rq->execute_cb), work.llnode)
irq_work_queue(&cb->work);
/*
@@ -209,7 +207,6 @@ static void __notify_execute_cb(struct i915_request *rq)
* preempt-to-idle cycle on the target engine, all the while the
* master execute_cb may refire.
*/
- init_llist_head(&rq->execute_cb);
}
static inline void
@@ -276,6 +273,7 @@ static void remove_from_engine(struct i915_request *rq)
list_del_init(&rq->sched.link);
clear_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
clear_bit(I915_FENCE_FLAG_HOLD, &rq->fence.flags);
+ set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
spin_unlock_irq(&locked->active.lock);
}
@@ -323,12 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(&rq->engine->gt->rps.num_waiters));
atomic_dec(&rq->engine->gt->rps.num_waiters);
}
- if (!test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
- set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
- __notify_execute_cb(rq);
- }
- GEM_BUG_ON(!llist_empty(&rq->execute_cb));
spin_unlock_irq(&rq->lock);
+ __notify_execute_cb(rq);
remove_from_client(rq);
__list_del_entry(&rq->link); /* poison neither prev/next (RCU walks) */
@@ -357,12 +351,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
}
-static void __llist_add(struct llist_node *node, struct llist_head *head)
-{
- node->next = head->first;
- head->first = node;
-}
-
static struct i915_request * const *
__engine_active(struct intel_engine_cs *engine)
{
@@ -439,18 +427,11 @@ __await_execution(struct i915_request *rq,
cb->work.func = irq_execute_cb_hook;
}
- spin_lock_irq(&signal->lock);
- if (i915_request_is_active(signal) || __request_in_flight(signal)) {
- if (hook) {
- hook(rq, &signal->fence);
- i915_request_put(signal);
- }
- i915_sw_fence_complete(cb->fence);
- kmem_cache_free(global.slab_execute_cbs, cb);
- } else {
- __llist_add(&cb->work.llnode, &signal->execute_cb);
+ if (llist_add(&cb->work.llnode, &signal->execute_cb)) {
+ if (i915_request_is_active(signal) ||
+ __request_in_flight(signal))
+ __notify_execute_cb(signal);
}
- spin_unlock_irq(&signal->lock);
return 0;
}
@@ -565,19 +546,18 @@ bool __i915_request_submit(struct i915_request *request)
list_move_tail(&request->sched.link, &engine->active.requests);
clear_bit(I915_FENCE_FLAG_PQUEUE, &request->fence.flags);
}
+ __notify_execute_cb(request);
/* We may be recursing from the signal callback of another i915 fence */
if (!i915_request_signaled(request)) {
spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
- __notify_execute_cb(request);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
&request->fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_signal_breadcrumbs(engine);
spin_unlock(&request->lock);
- GEM_BUG_ON(!llist_empty(&request->execute_cb));
}
return result;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atmel: Use drm_atomic_helper_commit
Hi Daniel.
On Tue, Jul 07, 2020 at 11:31:37PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could also perhaps use the drm_mode_config_helper_suspend/resume
> stuff, for another few lines deleted. But I'm not looking at that
> stuff, I'm just going through all the atomic commit functions and make
> sure they have properly annotated dma-fence critical sections
> everywhere.
>
> v2:
> - Also delete the workqueue (Sam)
> - drop the @commit kerneldoc, I missed that one.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-arm-ker...@lists.infradead.org
I did succeed getttign my board operational.
But based on reading the code:
Reviewed-by: Sam Ravnborg
I assume you will apply it.
Sam
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 7 --
> 2 files changed, 2 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 871293d1aeeb..03984932d174 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -struct atmel_hlcdc_dc_commit {
> - struct work_struct work;
> - struct drm_device *dev;
> - struct drm_atomic_state *state;
> -};
> -
> -static void
> -atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
> -{
> - struct drm_device *dev = commit->dev;
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct drm_atomic_state *old_state = commit->state;
> -
> - /* Apply the atomic update. */
> - drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> -
> - drm_atomic_helper_cleanup_planes(dev, old_state);
> -
> - drm_atomic_state_put(old_state);
> -
> - /* Complete the commit, wake up any waiter. */
> - spin_lock(&dc->commit.wait.lock);
> - dc->commit.pending = false;
> - wake_up_all_locked(&dc->commit.wait);
> - spin_unlock(&dc->commit.wait.lock);
> -
> - kfree(commit);
> -}
> -
> -static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
> -{
> - struct atmel_hlcdc_dc_commit *commit =
> - container_of(work, struct atmel_hlcdc_dc_commit, work);
> -
> - atmel_hlcdc_dc_atomic_complete(commit);
> -}
> -
> -static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
> - struct drm_atomic_state *state,
> - bool async)
> -{
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct atmel_hlcdc_dc_commit *commit;
> - int ret;
> -
> - ret = drm_atomic_helper_prepare_planes(dev, state);
> - if (ret)
> - return ret;
> -
> - /* Allocate the commit object. */
> - commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> - if (!commit) {
> - ret = -ENOMEM;
> - goto error;
> - }
> -
> - INIT_WORK(&commit->work, atmel_hlcdc_dc_atomic_work);
> - commit->dev = dev;
> - commit->state = state;
> -
> - spin_lock(&dc->commit.wait.lock);
> - ret = wait_event_interruptible_locked(dc->commit.wait,
> - !dc->commit.pending);
> - if (ret == 0)
> - dc->commit.pending = true;
> - spin_unlock(&dc->commit.wait.lock);
> -
> - if (ret)
> - goto err_free;
> -
> - /* We have our own synchronization through the commit lock. */
> - BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
> -
> - /* Swap state succeeded, this is the point of no return. */
> - drm_atomic_state_get(state);
> - if (async)
> - queue_work(dc->wq, &commit->work);
> - else
> - atmel_hlcdc_dc_atomic_complete(commit);
> -
> - return 0;
> -
> -err_free:
> - kfree(commit);
> -error:
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> -}
> -
> static const struct drm_mode_config_funcs mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> .atomic_check = drm_atomic_helper_check,
> - .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
> };
>
> static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
> @@ -712,11 +619,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
> if (!dc)
> return -ENOME
Re: [Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
On 07/12, Rodrigo Siqueira wrote:
> Hi,
>
> Everything looks fine to me, I just noticed that the amdgpu patches did
> not apply smoothly, however it was trivial to fix the issues.
>
> Reviewed-by: Rodrigo Siqueira
>
> Melissa,
> Since you are using vkms regularly, could you test this patch and review
> it? Remember to add your Tested-by when you finish.
>
Hi,
I've applied the patch series, ran some tests on vkms, and found no
issues. I mean, things have remained stable.
Tested-by: Melissa Wen
> Thanks
>
> On 07/07, Daniel Vetter wrote:
> > This is needed to signal the fences from page flips, annotate it
> > accordingly. We need to annotate entire timer callback since if we get
> > stuck anywhere in there, then the timer stops, and hence fences stop.
> > Just annotating the top part that does the vblank handling isn't
> > enough.
> >
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-...@lists.freedesktop.org
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson
> > Cc: Maarten Lankhorst
> > Cc: Christian König
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..a53a40848a72 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -1,5 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0+
> >
> > +#include
> > +
> > #include
> > #include
> > #include
> > @@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > struct drm_crtc *crtc = &output->crtc;
> > struct vkms_crtc_state *state;
> > u64 ret_overrun;
> > - bool ret;
> > + bool ret, fence_cookie;
> > +
> > + fence_cookie = dma_fence_begin_signalling();
> >
> > ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> > output->period_ns);
> > @@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > DRM_DEBUG_DRIVER("Composer worker already queued\n");
> > }
> >
> > + dma_fence_end_signalling(fence_cookie);
> > +
> > return HRTIMER_RESTART;
> > }
> >
> > --
> > 2.27.0
> >
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
>
> On 07/12, Rodrigo Siqueira wrote:
> > Hi,
> >
> > Everything looks fine to me, I just noticed that the amdgpu patches did
> > not apply smoothly, however it was trivial to fix the issues.
> >
> > Reviewed-by: Rodrigo Siqueira
> >
> > Melissa,
> > Since you are using vkms regularly, could you test this patch and review
> > it? Remember to add your Tested-by when you finish.
> >
> Hi,
>
> I've applied the patch series, ran some tests on vkms, and found no
> issues. I mean, things have remained stable.
>
> Tested-by: Melissa Wen
Did you test with CONFIG_PROVE_LOCKING enabled in the kernel .config?
Without that enabled, there's not really any change here, but with
that enabled there might be some lockdep splats in dmesg indicating a
problem.
Thanks, Daniel
>
> > Thanks
> >
> > On 07/07, Daniel Vetter wrote:
> > > This is needed to signal the fences from page flips, annotate it
> > > accordingly. We need to annotate entire timer callback since if we get
> > > stuck anywhere in there, then the timer stops, and hence fences stop.
> > > Just annotating the top part that does the vblank handling isn't
> > > enough.
> > >
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: amd-...@lists.freedesktop.org
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson
> > > Cc: Maarten Lankhorst
> > > Cc: Christian König
> > > Signed-off-by: Daniel Vetter
> > > Cc: Rodrigo Siqueira
> > > Cc: Haneen Mohammed
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > index ac85e17428f8..a53a40848a72 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -1,5 +1,7 @@
> > > // SPDX-License-Identifier: GPL-2.0+
> > >
> > > +#include
> > > +
> > > #include
> > > #include
> > > #include
> > > @@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > > hrtimer *timer)
> > > struct drm_crtc *crtc = &output->crtc;
> > > struct vkms_crtc_state *state;
> > > u64 ret_overrun;
> > > - bool ret;
> > > + bool ret, fence_cookie;
> > > +
> > > + fence_cookie = dma_fence_begin_signalling();
> > >
> > > ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> > > output->period_ns);
> > > @@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > > hrtimer *timer)
> > > DRM_DEBUG_DRIVER("Composer worker already queued\n");
> > > }
> > >
> > > + dma_fence_end_signalling(fence_cookie);
> > > +
> > > return HRTIMER_RESTART;
> > > }
> > >
> > > --
> > > 2.27.0
> > >
> >
> > --
> > Rodrigo Siqueira
> > https://siqueira.tech
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag
On Mon, Jul 13, 2020 at 09:51:30PM +, Patchwork wrote: == Series Details == Series: series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag URL : https://patchwork.freedesktop.org/series/79420/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8739_full -> Patchwork_18150_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18150_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18150_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18150_full: ### Piglit changes ### Possible regressions * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 s=d=z24_s8 (NEW): - pig-snb-2600: NOTRUN -> [FAIL][1] +1 similar issue [1]: None Unrelated. Pushed, Lucas De Marchi New tests - New tests have been introduced between CI_DRM_8739_full and Patchwork_18150_full: ### New Piglit tests (1) ### * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 s=d=z24_s8: - Statuses : 1 fail(s) - Exec time: [4.59] s Known issues Here are the changes found in Patchwork_18150_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([i915#69]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-skl2/igt@gem_...@in-flight-suspend.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-skl7/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2079]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-kbl7/igt@gem_exec_balan...@bonded-early.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-kbl7/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_balancer@hang: - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#1635] / [i915#95]) +11 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-apl3/igt@gem_exec_balan...@hang.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-apl4/igt@gem_exec_balan...@hang.html * igt@gem_exec_whisper@basic-fds: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#118] / [i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-glk2/igt@gem_exec_whis...@basic-fds.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-glk9/igt@gem_exec_whis...@basic-fds.html * igt@i915_pm_dc@dc5-psr: - shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#198]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-skl3/igt@i915_pm...@dc5-psr.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-skl10/igt@i915_pm...@dc5-psr.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-tglb: [PASS][12] -> [DMESG-WARN][13] ([i915#402]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-tglb3/igt@i915_pm_...@system-suspend-execbuf.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-tglb7/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][14] -> [DMESG-FAIL][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-glk4/igt@kms_big...@y-tiled-64bpp-rotate-180.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-onscreen: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#93] / [i915#95]) +4 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#1635] / [i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-apl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-apl8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8739/shard-glk5/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18150/shard-glk
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove i915_request.lock
requirement for execution callbacks
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8742 -> Patchwork_18155
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/index.html
Known issues
Here are the changes found in Patchwork_18155 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-bsw-n3050/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-bsw-n3050/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [PASS][5] -> [DMESG-FAIL][6] ([i915#1233])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-y/igt@vgem_ba...@setversion.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/fi-kbl-x1275/igt@kms_cursor
Re: [Intel-gfx] [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote: > My dma-fence lockdep annotations caught an inversion because we > allocate memory where we really shouldn't: > > kmem_cache_alloc+0x2b/0x6d0 > amdgpu_fence_emit+0x30/0x330 [amdgpu] > amdgpu_ib_schedule+0x306/0x550 [amdgpu] > amdgpu_job_run+0x10f/0x260 [amdgpu] > drm_sched_main+0x1b9/0x490 [gpu_sched] > kthread+0x12e/0x150 > > Trouble right now is that lockdep only validates against GFP_FS, which > would be good enough for shrinkers. But for mmu_notifiers we actually > need !GFP_ATOMIC, since they can be called from any page laundering, > even if GFP_NOFS or GFP_NOIO are set. > > I guess we should improve the lockdep annotations for > fs_reclaim_acquire/release. > > Ofc real fix is to properly preallocate this fence and stuff it into > the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of > the way. > > v2: Two more allocations in scheduler paths. > > Frist one: > > __kmalloc+0x58/0x720 > amdgpu_vmid_grab+0x100/0xca0 [amdgpu] > amdgpu_job_dependency+0xf9/0x120 [amdgpu] > drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] > drm_sched_main+0xf9/0x490 [gpu_sched] > > Second one: > > kmem_cache_alloc+0x2b/0x6d0 > amdgpu_sync_fence+0x7e/0x110 [amdgpu] > amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] > amdgpu_job_dependency+0xf9/0x120 [amdgpu] > drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] > drm_sched_main+0xf9/0x490 [gpu_sched] > > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter Has anyone from amd side started looking into how to fix this properly? I looked a bit into fixing this with mempool, and the big guarantee we need is that - there's a hard upper limit on how many allocations we minimally need to guarantee forward progress. And the entire vmid allocation and amdgpu_sync_fence stuff kinda makes me question that's a valid assumption. - mempool_free must be called without any locks in the way which are held while we call mempool_alloc. Otherwise we again have a nice deadlock with no forward progress. I tried auditing that, but got lost in amdgpu and scheduler code. Some lockdep annotations for mempool.c might help, but they're not going to catch everything. Plus it would be again manual annotations because this is yet another cross-release issue. So not sure that helps at all. iow, not sure what to do here. Ideas? Cheers, Daniel > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > index 8d84975885cd..a089a827fdfe 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct > dma_fence **f, > uint32_t seq; > int r; > > - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); > + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); > if (fence == NULL) > return -ENOMEM; > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > index 267fa45ddb66..a333ca2d4ddd 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, > if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) > return amdgpu_sync_fence(sync, ring->vmid_wait); > > - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); > + fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC); > if (!fences) > return -ENOMEM; > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c > index 8ea6c49529e7..af22b526cec9 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c > @@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct > dma_fence *f) > if (amdgpu_sync_add_later(sync, f)) > return 0; > > - e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL); > + e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC); > if (!e) > return -ENOMEM; > > -- > 2.27.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gf
Re: [Intel-gfx] [PATCH v8 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability
On Mon, Jul 13, 2020 at 03:51:52PM -0300, Arnaldo Carvalho de Melo wrote: > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > > index 856d98c36f56..a2397f724c10 100644 > > > --- a/kernel/events/core.c > > > +++ b/kernel/events/core.c > > > @@ -11595,7 +11595,7 @@ SYSCALL_DEFINE5(perf_event_open, > > >* perf_event_exit_task() that could imply). > > >*/ > > > err = -EACCES; > > > - if (!ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS)) > > > + if (!perfmon_capable() && !ptrace_may_access(task, > > > PTRACE_MODE_READ_REALCREDS)) > > > goto err_cred; > > > } > > > > > >> makes monitoring simpler and even more secure to use since Perf tool need > > >> not to start/stop/single-step and read/write registers and memory and so > > >> on > > >> like a debugger or strace-like tool. What do you think? > > > > > > I tend to agree, Peter? So this basically says that if CAP_PERFMON, we don't care about the ptrace() permissions? Just like how CAP_SYS_PTRACE would always allow the ptrace checks? I suppose that makes sense. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations
On Wed, Jul 08, 2020 at 05:37:19PM +0200, Daniel Vetter wrote: > On Wed, Jul 8, 2020 at 5:19 PM Alex Deucher wrote: > > > > On Wed, Jul 8, 2020 at 11:13 AM Daniel Vetter > > wrote: > > > > > > On Wed, Jul 8, 2020 at 4:57 PM Christian König > > > wrote: > > > > > > > > Could we merge this controlled by a separate config option? > > > > > > > > This way we could have the checks upstream without having to fix all the > > > > stuff before we do this? > > > > > > Since it's fully opt-in annotations nothing blows up if we don't merge > > > any annotations. So we could start merging the first 3 patches. After > > > that the fun starts ... > > > > > > My rough idea was that first I'd try to tackle display, thus far > > > there's 2 actual issues in drivers: > > > - amdgpu has some dma_resv_lock in commit_tail, plus a kmalloc. I > > > think those should be fairly easy to fix (I'd try a stab at them even) > > > - vmwgfx has a full on locking inversion with dma_resv_lock in > > > commit_tail, and that one is functional. Not just reading something > > > which we can safely assume to be invariant anyway (like the tmz flag > > > for amdgpu, or whatever it was). > > > > > > I've done a pile more annotations patches for other atomic drivers > > > now, so hopefully that flushes out any remaining offenders here. Since > > > some of the annotations are in helper code worst case we might need a > > > dev->mode_config.broken_atomic_commit flag to disable them. At least > > > for now I have 0 plans to merge any of these while there's known > > > unsolved issues. Maybe if some drivers take forever to get fixed we > > > can then apply some duct-tape for the atomic helper annotation patch. > > > Instead of a flag we can also copypasta the atomic_commit_tail hook, > > > leaving the annotations out and adding a huge warning about that. > > > > > > Next big chunk is the drm/scheduler annotations: > > > - amdgpu needs a full rework of display reset (but apparently in the > > > works) > > > > I think the display deadlock issues should be fixed in: > > https://cgit.freedesktop.org/drm/drm/commit/?id=cdaae8371aa9d4ea1648a299b1a75946b9556944 Oh btw you have some more memory allocations in that commit, so you just traded one deadlock for another one :-) -Daniel > > That's the reset/tdr inversion, there's two more: > - kmalloc, see > https://cgit.freedesktop.org/~danvet/drm/commit/?id=d9353cc3bf6111430a24188b92412dc49e7ead79 > - ttm_bo_reserve in the wrong place > https://cgit.freedesktop.org/~danvet/drm/commit/?id=a6c03176152625a2f9cf1e499aceb8b2217dc2a2 > - console_lock in the wrong spot > https://cgit.freedesktop.org/~danvet/drm/commit/?id=a6c03176152625a2f9cf1e499aceb8b2217dc2a2 > > Especially the last one I have no idea how to address really. > -Daniel > > > > > > Alex > > > > > - I read all the drivers, they all have the fairly cosmetic issue of > > > doing small allocations in their callbacks. > > > > > > I might end up typing the mempool we need for the latter issue, but > > > first still hoping for some actual test feedback from other drivers > > > using drm/scheduler. Again no intentions of merging these annotations > > > without the drivers being fixed first, or at least some duct-atpe > > > applied. > > > > > > Another option I've been thinking about, if there's cases where fixing > > > things properly is a lot of effort: We could do annotations for broken > > > sections (just the broken part, so we still catch bugs everywhere > > > else). They'd simply drop&reacquire the lock. We could then e.g. use > > > that in the amdgpu display reset code, and so still make sure that > > > everything else in reset doesn't get worse. But I think adding that > > > shouldn't be our first option. > > > > > > I'm not personally a big fan of the Kconfig or runtime option, only > > > upsets people since it breaks lockdep for them. Or they ignore it, and > > > we don't catch bugs, making it fairly pointless to merge. > > > > > > Cheers, Daniel > > > > > > > > > > > > > > Thanks, > > > > Christian. > > > > > > > > Am 07.07.20 um 22:12 schrieb Daniel Vetter: > > > > > Design is similar to the lockdep annotations for workers, but with > > > > > some twists: > > > > > > > > > > - We use a read-lock for the execution/worker/completion side, so that > > > > >this explicit annotation can be more liberally sprinkled around. > > > > >With read locks lockdep isn't going to complain if the read-side > > > > >isn't nested the same way under all circumstances, so ABBA > > > > > deadlocks > > > > >are ok. Which they are, since this is an annotation only. > > > > > > > > > > - We're using non-recursive lockdep read lock mode, since in recursive > > > > >read lock mode lockdep does not catch read side hazards. And we > > > > >_very_ much want read side hazards to be caught. For full details > > > > > of > > > > >this limitation see > > > > > > > > > >commit e91498589746065e3ae95d9a00b068e525eec34f > > > > >Author:
Re: [Intel-gfx] [PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't
On Tue, Jul 07, 2020 at 10:12:24PM +0200, Daniel Vetter wrote:
> Not going to bother with a complete&pretty commit message, just
> offending backtrace:
>
> kvmalloc_node+0x47/0x80
> dc_create_state+0x1f/0x60 [amdgpu]
> dc_commit_state+0xcb/0x9b0 [amdgpu]
> amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
> commit_tail+0xa4/0x140 [drm_kms_helper]
> drm_atomic_helper_commit+0x152/0x180 [drm_kms_helper]
> drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
> drm_client_modeset_commit_locked+0x55/0x190 [drm]
> drm_client_modeset_commit+0x24/0x40 [drm]
>
> v2: Found more in DC code, I'm just going to pile them all up.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
> Signed-off-by: Daniel Vetter
Anyone from amdgpu DC team started to look into this and the subsequent
patches in DC? Note that the last one isn't needed anymore because it's
now fix in upstream with
commit cdaae8371aa9d4ea1648a299b1a75946b9556944
Author: Bhawanpreet Lakha
Date: Mon May 11 14:21:17 2020 -0400
drm/amd/display: Handle GPU reset for DC block
But that patch has a ton of memory allocations in the reset path now, so
you just replaced one deadlock with another one ...
Note that since amdgpu has it's private atomic_commit_tail implemenation
this won't hold up the generic atomic annotations, but I think it will
hold up the tdr annotations at least. Plus would be nice to fix this
somehow.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +++-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 4cfc786699c7..1b0c674fab25 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -1226,7 +1226,7 @@ static int amdgpu_atom_execute_table_locked(struct
> atom_context *ctx, int index,
> ectx.abort = false;
> ectx.last_jump = 0;
> if (ws)
> - ectx.ws = kcalloc(4, ws, GFP_KERNEL);
> + ectx.ws = kcalloc(4, ws, GFP_ATOMIC);
> else
> ectx.ws = NULL;
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 6afcc33ff846..3d41eddc7908 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6872,7 +6872,7 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> struct dc_stream_update stream_update;
> } *bundle;
>
> - bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
> + bundle = kzalloc(sizeof(*bundle), GFP_ATOMIC);
>
> if (!bundle) {
> dm_error("Failed to allocate update bundle\n");
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 942ceb0f6383..f9a58509efb2 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1475,8 +1475,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
>
> struct dc_state *dc_create_state(struct dc *dc)
> {
> + /* No you really cant allocate random crap here this late in
> + * atomic_commit_tail. */
> struct dc_state *context = kvzalloc(sizeof(struct dc_state),
> - GFP_KERNEL);
> + GFP_ATOMIC);
>
> if (!context)
> return NULL;
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915/perf: Map OA buffer to user space
Quoting Umesh Nerlige Ramappa (2020-07-14 08:22:39)
> From: Piotr Maciejewski
>
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implementation for query, but Gen12+ requires a new approach based on
> triggered reports within oa buffer. In order to enable above feature
> two changes are required:
>
> 1. Whitelist update:
> - enable triggered reports within oa buffer
> - reading oa buffer head/tail/status information
> - reading gpu ticks counter.
>
> 2. Map oa buffer at umd driver level to solve below constraints related
>to time based sampling interface:
> - longer time to access reports collected by oa buffer
If you aren't talking about a few 10us, then something else is wrong.
> - slow oa reports browsing since oa buffer size is large
Nothing changes on the surface. That does not sound like inherent
inefficiencies. Since the same number of events will be generated and
need to be processed. You may argue that they are easier to process in
situ, and that the number of events dwarf L1 cache. An mmap interface
could eliminate one copy (and certainly a copy-to-user).
> - missing oa report index, so query cannot browse report directly
There's more to it than that otherwise you would have proposed an
extension to the event format.
> - with direct access to oa buffer, query can extract other useful
> reports like context switch information needed to calculate correct
> performance counters values.
Why would you not start with an unprivileged mediated mmapped buffer?
If the goal is to reduce sample latency by replacing read ioctls with a
mmap, that would seem to be an orthogonal step to exposing the raw OA
buffer. The inference would be that you do want to extract extra details
from the OA that are not being catered for. That's perfectly fine, our
goal is to _safely_ expose HW and not get in the way of userspace. But
if that was the intent, it should not appear to be an afterthought.
[i.e. that mmap should be inherently faster for accessing a large ring
of data is much less important than discussing the safety concerns of
letting userspace have direct control/access of OA.]
> Signed-off-by: Piotr Maciejewski
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 54
> drivers/gpu/drm/i915/i915_perf.c| 130 +++-
> drivers/gpu/drm/i915/i915_perf_types.h | 13 ++
> drivers/gpu/drm/i915/i915_reg.h | 14 +++
> include/uapi/drm/i915_drm.h | 19 +++
> 5 files changed, 227 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 5726cd0a37e0..cf89928fc3a5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1365,6 +1365,48 @@ whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
> whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
> }
>
> +static void gen9_whitelist_build_performance_counters(struct i915_wa_list *w)
> +{
> + /* OA buffer trigger report 2/6 used by performance query */
> + whitelist_reg(w, OAREPORTTRIG2);
> + whitelist_reg(w, OAREPORTTRIG6);
> +
> + /* Performance counters A18-20 used by tbs marker query */
> + whitelist_reg_ext(w, OA_PERF_COUNTER_A18,
> + RING_FORCE_TO_NONPRIV_ACCESS_RW |
> + RING_FORCE_TO_NONPRIV_RANGE_16);
> +
> + /* Read access to gpu ticks */
> + whitelist_reg_ext(w, GEN8_GPU_TICKS,
> + RING_FORCE_TO_NONPRIV_ACCESS_RD);
> +
> + /* Read access to: oa status, head, tail, buffer settings */
> + whitelist_reg_ext(w, GEN8_OASTATUS,
> + RING_FORCE_TO_NONPRIV_ACCESS_RD |
> + RING_FORCE_TO_NONPRIV_RANGE_4);
> +}
> +
> +static void gen12_whitelist_build_performance_counters(struct i915_wa_list
> *w)
> +{
> + /* OA buffer trigger report 2/6 used by performance query */
> + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG2);
> + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG6);
> +
> + /* Performance counters A18-20 used by tbs marker query */
> + whitelist_reg_ext(w, GEN12_OAG_PERF_COUNTER_A18,
> + RING_FORCE_TO_NONPRIV_ACCESS_RW |
> + RING_FORCE_TO_NONPRIV_RANGE_16);
> +
> + /* Read access to gpu ticks */
> + whitelist_reg_ext(w, GEN12_OAG_GPU_TICKS,
> + RING_FORCE_TO_NONPRIV_ACCESS_RD);
> +
> + /* Read access to: oa status, head, tail, buffer settings */
> + whitelist_reg_ext(w, GEN12_OAG_OASTATUS,
> + RING_FORCE_TO_NONPRIV_ACCESS_RD |
> + RING_FORCE_TO_NONPRIV_RANGE_4);
> +}
> +
> static void gen9_whitelist_build(struct i915_
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
== Series Details == Series: series starting with [1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks URL : https://patchwork.freedesktop.org/series/79467/ State : success == Summary == CI Bug Log - changes from CI_DRM_8742_full -> Patchwork_18155_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18155_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#1436] / [i915#1635] / [i915#716]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-apl8/igt@gen9_exec_pa...@allowed-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-apl4/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-hsw: [PASS][3] -> [WARN][4] ([i915#1519]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-idle.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-tglb2/igt@i915_pm_...@system-suspend-execbuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-tglb5/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-skl9/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-skl6/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-glk3/igt@kms_big...@x-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-onscreen: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-kbl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-wf_vblank-interruptible@a-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-kbl4/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-kbl6/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / [i915#95]) +18 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-apl7/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-apl2/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-skl3/igt@kms_...@bpc-switch-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18155/shard-skl6/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_cursor@pipe-a-viewport-size-128: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +11 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8742/shard-skl9/igt@kms_plane_cur...@pipe-a-viewport-size-128.html [24]: https
Re: [Intel-gfx] [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
Am 14.07.20 um 12:49 schrieb Daniel Vetter: On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote: My dma-fence lockdep annotations caught an inversion because we allocate memory where we really shouldn't: kmem_cache_alloc+0x2b/0x6d0 amdgpu_fence_emit+0x30/0x330 [amdgpu] amdgpu_ib_schedule+0x306/0x550 [amdgpu] amdgpu_job_run+0x10f/0x260 [amdgpu] drm_sched_main+0x1b9/0x490 [gpu_sched] kthread+0x12e/0x150 Trouble right now is that lockdep only validates against GFP_FS, which would be good enough for shrinkers. But for mmu_notifiers we actually need !GFP_ATOMIC, since they can be called from any page laundering, even if GFP_NOFS or GFP_NOIO are set. I guess we should improve the lockdep annotations for fs_reclaim_acquire/release. Ofc real fix is to properly preallocate this fence and stuff it into the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of the way. v2: Two more allocations in scheduler paths. Frist one: __kmalloc+0x58/0x720 amdgpu_vmid_grab+0x100/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Second one: kmem_cache_alloc+0x2b/0x6d0 amdgpu_sync_fence+0x7e/0x110 [amdgpu] amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter Has anyone from amd side started looking into how to fix this properly? Yeah I checked both and neither are any real problem. I looked a bit into fixing this with mempool, and the big guarantee we need is that - there's a hard upper limit on how many allocations we minimally need to guarantee forward progress. And the entire vmid allocation and amdgpu_sync_fence stuff kinda makes me question that's a valid assumption. We do have hard upper limits for those. The VMID allocation could as well just return the fence instead of putting it into the sync object IIRC. So that just needs some cleanup and can avoid the allocation entirely. The hardware fence is limited by the number of submissions we can have concurrently on the ring buffers, so also not a problem at all. Regards, Christian. - mempool_free must be called without any locks in the way which are held while we call mempool_alloc. Otherwise we again have a nice deadlock with no forward progress. I tried auditing that, but got lost in amdgpu and scheduler code. Some lockdep annotations for mempool.c might help, but they're not going to catch everything. Plus it would be again manual annotations because this is yet another cross-release issue. So not sure that helps at all. iow, not sure what to do here. Ideas? Cheers, Daniel --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index 8d84975885cd..a089a827fdfe 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, uint32_t seq; int r; - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); if (fence == NULL) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index 267fa45ddb66..a333ca2d4ddd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC); if (!fences) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index 8ea6c49529e7..af22b526cec9 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c @@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f) if (amdgpu_sync_add_later(sync, f)) return 0; - e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL); +
[Intel-gfx] [PATCH] drm/i915/gt: Assert the kernel context is using the HWSP
We need to ensure that the kernel context is using the permanently pinned HWSP so that we can always submit a pm request from any context. By construction, the engine->kernel_context should only be using the engine->status_page.vma so let's assert that is still true when we have to submit a request for parking the engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c index d0a1078ef632..8ec3eecf3e39 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c @@ -142,6 +142,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine) return true; GEM_BUG_ON(!intel_context_is_barrier(ce)); + GEM_BUG_ON(ce->timeline->hwsp_ggtt != engine->status_page.vma); /* Already inside the kernel context, safe to power down. */ if (engine->wakeref_serial == engine->serial) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/23] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
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_ctx and obj order in locking functions (Jonas Lahtinen)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../i915/gem/selftests/i915_gem_coherency.c | 10 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 4 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
.../drm/i915/gem/selftests/i915_gem_phys.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 52 +--
drivers/gpu/drm/i915/i915_gem.h | 11
drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
22 files changed, 170 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 729ec6e0d43a..62121289dc75 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2310,7 +2310,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
{
- i915_gem_object_lock(vma->obj);
+ i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
i915_gem_object_unpin_from_display_plane(vma);
@@ -17139,7 +17139,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
tiling = i915_gem_object_get_tiling(obj);
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 278664f831e7..f4bf7bacb2c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -287,7 +287,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
err = i915_sw_fence_await_reservation(&work->wait,
obj->base.resv, NULL, true, 0,
I915_FENCE_GFP);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 2679380159fc..27fddc22a7c6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -128,7 +128,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
if (err)
return err;
- err = i915_gem_object_lock_interruptible(obj);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
@@ -149,7 +149,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
if (err)
return err;
- err = i915_gem_object_lock_interruptible(obj);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 7f76fc68f498..c0acfc97fae3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -32,7 +32,7 @@ void i915_gem_object_flush_if_display(struct
drm_i915_gem_object *obj)
if (!i915_gem_object_is_framebuffer(obj))
return;
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
__i915_gem_object_flush_for_display(obj);
i915_gem_object_unlock(obj);
}
@@ -197,7 +197,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
[Intel-gfx] [PATCH 22/23] drm/i915: Add ww locking to vm_fault_gtt
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
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -283,37 +283,46 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
struct intel_runtime_pm *rpm = &i915->runtime_pm;
struct i915_ggtt *ggtt = &i915->ggtt;
bool write = area->vm_flags & VM_WRITE;
+ struct i915_gem_ww_ctx ww;
intel_wakeref_t wakeref;
struct i915_vma *vma;
pgoff_t page_offset;
int srcu;
int ret;
- /* Sanity check that we allow writing into this object */
- if (i915_gem_object_is_readonly(obj) && write)
- return VM_FAULT_SIGBUS;
-
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
trace_i915_gem_object_fault(obj, page_offset, true, write);
- ret = i915_gem_object_pin_pages(obj);
+ wakeref = intel_runtime_pm_get(rpm);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
if (ret)
- goto err;
+ goto err_rpm;
- wakeref = intel_runtime_pm_get(rpm);
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write) {
+ ret = -EFAULT;
+ goto err_rpm;
+ }
- ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err_rpm;
+ ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ if (ret)
+ goto err_pages;
+
/* Now pin it into the GTT as needed */
- vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
- PIN_MAPPABLE |
- PIN_NONBLOCK /* NOWARN */ |
- PIN_NOEVICT);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, NULL, 0, 0,
+ PIN_MAPPABLE |
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
@@ -328,11 +337,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
* all hope that the hardware is able to track future writes.
*/
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 0, flags);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
0, flags);
}
/* The entire mappable GGTT is pinned? Unexpected! */
@@ -389,10 +398,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
__i915_vma_unpin(vma);
err_reset:
intel_gt_reset_unlock(ggtt->vm.gt, srcu);
+err_pages:
+ i915_gem_object_unpin_pages(obj);
err_rpm:
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_runtime_pm_put(rpm, wakeref);
- i915_gem_object_unpin_pages(obj);
-err:
return i915_error_to_vmf_fault(ret);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/23] drm/i915: Revert relocation chaining commits.
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 concurrent access to the BO's.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 171 --
.../i915/gem/selftests/i915_gem_execbuffer.c | 8 +-
2 files changed, 35 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 446e76e95c38..8e2ae8317c5c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -268,9 +268,7 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
- struct i915_vma *target;
struct i915_request *rq;
- struct i915_vma *rq_vma;
u32 *rq_cmd;
unsigned int rq_size;
} reloc_cache;
@@ -962,7 +960,7 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
cache->rq = NULL;
- cache->target = NULL;
+ cache->rq_size = 0;
}
static inline void *unmask_page(unsigned long p)
@@ -984,122 +982,29 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
reloc_cache *cache)
return &i915->ggtt;
}
-#define RELOC_TAIL 4
-
-static int reloc_gpu_chain(struct reloc_cache *cache)
+static void reloc_gpu_flush(struct reloc_cache *cache)
{
- struct intel_gt_buffer_pool_node *pool;
- struct i915_request *rq = cache->rq;
- struct i915_vma *batch;
- u32 *cmd;
- int err;
-
- pool = intel_gt_get_buffer_pool(rq->engine->gt, PAGE_SIZE);
- if (IS_ERR(pool))
- return PTR_ERR(pool);
-
- batch = i915_vma_instance(pool->obj, rq->context->vm, NULL);
- if (IS_ERR(batch)) {
- err = PTR_ERR(batch);
- goto out_pool;
- }
-
- err = i915_vma_pin(batch, 0, 0, PIN_USER | PIN_NONBLOCK);
- if (err)
- goto out_pool;
-
- GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32));
- cmd = cache->rq_cmd + cache->rq_size;
- *cmd++ = MI_ARB_CHECK;
- if (cache->gen >= 8)
- *cmd++ = MI_BATCH_BUFFER_START_GEN8;
- else if (cache->gen >= 6)
- *cmd++ = MI_BATCH_BUFFER_START;
- else
- *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT;
- *cmd++ = lower_32_bits(batch->node.start);
- *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */
- i915_gem_object_flush_map(cache->rq_vma->obj);
- i915_gem_object_unpin_map(cache->rq_vma->obj);
- cache->rq_vma = NULL;
-
- err = intel_gt_buffer_pool_mark_active(pool, rq);
- if (err == 0) {
- i915_vma_lock(batch);
- err = i915_request_await_object(rq, batch->obj, false);
- if (err == 0)
- err = i915_vma_move_to_active(batch, rq, 0);
- i915_vma_unlock(batch);
- }
- i915_vma_unpin(batch);
- if (err)
- goto out_pool;
+ struct drm_i915_gem_object *obj = cache->rq->batch->obj;
- cmd = i915_gem_object_pin_map(batch->obj,
- cache->has_llc ?
- I915_MAP_FORCE_WB :
- I915_MAP_FORCE_WC);
- if (IS_ERR(cmd)) {
- err = PTR_ERR(cmd);
- goto out_pool;
- }
+ GEM_BUG_ON(cache->rq_size >= obj->base.size / sizeof(u32));
+ cache->rq_cmd[cache->rq_size] = MI_BATCH_BUFFER_END;
- /* Return with batch mapping (cmd) still pinned */
- cache->rq_cmd = cmd;
- cache->rq_size = 0;
- cache->rq_vma = batch;
+ __i915_gem_object_flush_map(obj, 0, sizeof(u32) * (cache->rq_size + 1));
+ i915_gem_object_unpin_map(obj);
-out_pool:
- intel_gt_buffer_pool_put(pool);
- return err;
-}
+ intel_gt_chipset_flush(cache->rq->engine->gt);
-static unsigned int reloc_bb_flags(const struct reloc_cache *cache)
-{
- return cache->gen > 5 ? 0 : I915_DISPATCH_SECURE;
-}
-
-static int reloc_gpu_flush(struct reloc_cache *cache)
-{
- struct i915_request *rq;
- int err;
-
- rq = fetch_and_zero(&cache->rq);
- if (!rq)
- return 0;
-
- if (cache->rq_vma) {
- struct drm_i915_gem_object *obj = cache->rq_vma->obj;
-
- GEM_BUG_ON(cache->rq_size >= obj->base.size / sizeof(u32));
- cache->rq_cmd[cache->rq_size++] = MI_BATCH_BUFFER_END;
-
- __i915_gem_object_flush_map(obj,
-
[Intel-gfx] [PATCH 11/23] drm/i915: Nuke arguments to eb_pin_engine
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 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 900ccd122c4a..e9afa50ec4de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2610,11 +2610,10 @@ static void eb_unpin_engine(struct i915_execbuffer *eb)
}
static unsigned int
-eb_select_legacy_ring(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_select_legacy_ring(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
+ struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
if (user_ring_id != I915_EXEC_BSD &&
@@ -2629,7 +2628,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -2654,18 +2653,16 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
}
static int
-eb_pin_engine(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_pin_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce;
unsigned int idx;
int err;
if (i915_gem_context_user_engines(eb->gem_context))
- idx = args->flags & I915_EXEC_RING_MASK;
+ idx = eb->args->flags & I915_EXEC_RING_MASK;
else
- idx = eb_select_legacy_ring(eb, file, args);
+ idx = eb_select_legacy_ring(eb);
ce = i915_gem_context_get_engine(eb->gem_context, idx);
if (IS_ERR(ce))
@@ -2931,7 +2928,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_destroy;
- err = eb_pin_engine(&eb, file, args);
+ err = eb_pin_engine(&eb);
if (unlikely(err))
goto err_context;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/23] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v2.
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/gem/selftests/i915_gem_context.c | 9 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/gpu/drm/i915/gt/selftest_rps.c| 30 --
drivers/gpu/drm/i915/selftests/i915_request.c | 18 +---
5 files changed, 80 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index dcdfc396f2f8..7049a6bbc03d 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -201,25 +201,25 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
- i915_gem_object_unlock(ctx->obj);
if (err)
- return err;
+ goto out_unlock;
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unlock;
+ }
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto out_unpin;
}
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
- i915_request_add(rq);
- i915_vma_unpin(vma);
- return PTR_ERR(cs);
+ err = PTR_ERR(cs);
+ goto out_rq;
}
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -240,14 +240,16 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
}
intel_ring_advance(rq, cs);
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- i915_vma_unpin(vma);
+out_rq:
i915_request_add(rq);
+out_unpin:
+ i915_vma_unpin(vma);
+out_unlock:
+ i915_gem_object_unlock(ctx->obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b93fd16a539d..29ff33ce3f44 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -958,13 +958,12 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
i915_gem_object_lock(obj, NULL);
err = i915_gem_object_set_to_gtt_domain(obj, false);
- i915_gem_object_unlock(obj);
if (err)
- return err;
+ goto out;
err = i915_vma_pin(vma, 0, 0, PIN_USER);
if (err)
- return err;
+ goto out;
batch = rpcs_query_batch(vma);
if (IS_ERR(batch)) {
@@ -1013,7 +1012,7 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
i915_request_add(rq);
- return 0;
+ goto out;
skip_request:
i915_request_set_error_once(rq, err);
@@ -1023,6 +1022,8 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
err_vma:
i915_vma_unpin(vma);
+out:
+ i915_gem_object_unlock(obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 9fb95a45bcad..d27d87a678c8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -528,31 +528,42 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(obj, &ww);
+ if (!err)
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
if (err)
- return err;
+ goto err;
rq = intel_engine_create_kernel_request(engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ g
[Intel-gfx] [PATCH 08/23] drm/i915: Use per object locking in execbuf, v12.
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 finally allows us to do parallel submission, but because not
all of the pinning code uses the ww ctx yet, we cannot completely
drop struct_mutex yet.
Changes since v1:
- Keep struct_mutex for now. :(
Changes since v2:
- Make sure we always lock the ww context in slowpath.
Changes since v3:
- Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
done on normal unlock path.
- Unconditionally release vmas and context.
Changes since v4:
- Rebased on top of struct_mutex reduction.
Changes since v5:
- Remove training wheels.
Changes since v6:
- Fix accidentally broken -ENOSPC handling.
Changes since v7:
- Handle gt buffer pool better.
Changes since v8:
- Properly clear variables, to make -EDEADLK handling not BUG.
Change since v9:
- Fix unpinning fence on pnv and below.
Changes since v10:
- Make relocation gpu chaining working again.
Changes since v11:
- Remove relocation chaining, pain to make it work.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 364 +++---
.../i915/gem/selftests/i915_gem_execbuffer.c | 62 +--
drivers/gpu/drm/i915/i915_gem.c | 6 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
4 files changed, 262 insertions(+), 171 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 06a5b086fc78..900ccd122c4a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -249,6 +249,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct i915_gem_ww_ctx ww;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -267,14 +269,18 @@ struct i915_execbuffer {
struct i915_request *rq;
u32 *rq_cmd;
unsigned int rq_size;
+ struct intel_gt_buffer_pool_node *pool;
} reloc_cache;
+ struct intel_gt_buffer_pool_node *reloc_pool; /** relocation pool for
-EDEADLK handling */
+
u64 invalid_flags; /** Set of execobj.flags that are invalid */
u32 context_flags; /** Set of execobj.flags to insert from the ctx */
u32 batch_start_offset; /** Location within object of batch */
u32 batch_len; /** Length of batch within object */
u32 batch_flags; /** Flags composed for emit_bb_start() */
+ struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch
buffer */
/**
* Indicate either the size of the hastable used to resolve
@@ -441,23 +447,16 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
- GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
- if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- __i915_vma_unpin(vma);
-}
-
static inline void
eb_unreserve_vma(struct eb_vma *ev)
{
if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
return;
- __eb_unreserve_vma(ev->vma, ev->flags);
+ if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(ev->vma);
+
+ __i915_vma_unpin(ev->vma);
ev->flags &= ~__EXEC_OBJECT_RESERVED;
}
@@ -552,16 +551,6 @@ eb_add_vma(struct i915_execbuffer *eb,
eb->batch = ev;
}
-
- if (eb_pin_vma(eb, entry, ev)) {
- if (entry->offset != vma->node.start) {
- entry->offset = vma->node.start | UPDATE;
- eb->args->flags |= __EXEC_HAS_RELOC;
- }
- } else {
- eb_unreserve_vma(ev);
- list_add_tail(&ev->bind_link, &eb->unbound);
- }
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -646,10 +635,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
* This avoid unnecessary unbinding of later objects in order to make
* room for the earlier objects *unless* we need to defragment.
*/
-
- if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
- return -EINTR;
-
pass = 0;
do {
list_for_each_entry(ev, &eb->unbound, bind_link) {
@@ -658,7 +643,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
break;
}
if (err != -ENOSPC)
- break;
+ return err;
[Intel-gfx] [PATCH 07/23] Revert "drm/i915/gem: Split eb_vma into its own allocation"
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/i915_gem_execbuffer.c| 124 +++---
1 file changed, 51 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e8221b6d0a53..06a5b086fc78 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -40,11 +40,6 @@ struct eb_vma {
u32 handle;
};
-struct eb_vma_array {
- struct kref kref;
- struct eb_vma vma[];
-};
-
enum {
FORCE_CPU_RELOC = 1,
FORCE_GTT_RELOC,
@@ -57,6 +52,7 @@ enum {
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -287,7 +283,6 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
- struct eb_vma_array *array;
};
static int eb_parse(struct i915_execbuffer *eb);
@@ -299,62 +294,8 @@ static inline bool eb_use_cmdparser(const struct
i915_execbuffer *eb)
eb->args->batch_len);
}
-static struct eb_vma_array *eb_vma_array_create(unsigned int count)
-{
- struct eb_vma_array *arr;
-
- arr = kvmalloc(struct_size(arr, vma, count), GFP_KERNEL | __GFP_NOWARN);
- if (!arr)
- return NULL;
-
- kref_init(&arr->kref);
- arr->vma[0].vma = NULL;
-
- return arr;
-}
-
-static inline void eb_unreserve_vma(struct eb_vma *ev)
-{
- struct i915_vma *vma = ev->vma;
-
- if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- if (ev->flags & __EXEC_OBJECT_HAS_PIN)
- __i915_vma_unpin(vma);
-
- ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
- __EXEC_OBJECT_HAS_FENCE);
-}
-
-static void eb_vma_array_destroy(struct kref *kref)
-{
- struct eb_vma_array *arr = container_of(kref, typeof(*arr), kref);
- struct eb_vma *ev = arr->vma;
-
- while (ev->vma) {
- eb_unreserve_vma(ev);
- i915_vma_put(ev->vma);
- ev++;
- }
-
- kvfree(arr);
-}
-
-static void eb_vma_array_put(struct eb_vma_array *arr)
-{
- kref_put(&arr->kref, eb_vma_array_destroy);
-}
-
static int eb_create(struct i915_execbuffer *eb)
{
- /* Allocate an extra slot for use by the command parser + sentinel */
- eb->array = eb_vma_array_create(eb->buffer_count + 2);
- if (!eb->array)
- return -ENOMEM;
-
- eb->vma = eb->array->vma;
-
if (!(eb->args->flags & I915_EXEC_HANDLE_LUT)) {
unsigned int size = 1 + ilog2(eb->buffer_count);
@@ -388,10 +329,8 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!size)) {
- eb_vma_array_put(eb->array);
+ if (unlikely(!size))
return -ENOMEM;
- }
eb->lut_size = size;
} else {
@@ -502,6 +441,26 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
+static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
+{
+ GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
+
+ if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(vma);
+
+ __i915_vma_unpin(vma);
+}
+
+static inline void
+eb_unreserve_vma(struct eb_vma *ev)
+{
+ if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
+ return;
+
+ __eb_unreserve_vma(ev->vma, ev->flags);
+ ev->flags &= ~__EXEC_OBJECT_RESERVED;
+}
+
static int
eb_validate_vma(struct i915_execbuffer *eb,
struct drm_i915_gem_exec_object2 *entry,
@@ -944,13 +903,31 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
long handle)
}
}
+static void eb_release_vmas(const struct i915_execbuffer *eb)
+{
+ const unsigned int count = eb->buffer_count;
+ unsigned int i;
+
+ for (i = 0; i < count; i++) {
+ struct eb_vma *ev = &eb->vma[i];
+ struct i915_vma *vma = ev->vma;
+
+ if (!vma)
+ break;
+
+ eb->vma[i].vma = NULL;
+
+ if (ev->flags & __EXEC_OBJECT_HAS_PIN)
+ __eb_unreserve_vma(vma, ev->flags);
+
+ i915_vma_put(vma);
+ }
+}
+
static v
[Intel-gfx] [PATCH 16/23] drm/i915: Kill last user of intel_context_create_request outside of selftests
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 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 5726cd0a37e0..80f3d97df57b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2045,6 +2045,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
const struct i915_wa *wa;
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
unsigned int i;
u32 *results;
int err;
@@ -2057,29 +2058,34 @@ static int engine_wa_list_verify(struct intel_context
*ce,
return PTR_ERR(vma);
intel_engine_pm_get(ce->engine);
- rq = intel_context_create_request(ce);
- intel_engine_pm_put(ce->engine);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err == 0)
+ err = intel_context_pin_ww(ce, &ww);
+ if (err)
+ goto err_pm;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_vma;
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- if (err) {
- i915_request_add(rq);
- goto err_vma;
- }
-
- err = wa_list_srm(rq, wal, vma);
- if (err)
- goto err_vma;
+ if (err == 0)
+ err = wa_list_srm(rq, wal, vma);
i915_request_get(rq);
+ if (err)
+ i915_request_set_error_once(rq, err);
i915_request_add(rq);
+
+ if (err)
+ goto err_rq;
+
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_rq;
@@ -2104,7 +2110,16 @@ static int engine_wa_list_verify(struct intel_context
*ce,
err_rq:
i915_request_put(rq);
-err_vma:
+err_unpin:
+ intel_context_unpin(ce);
+err_pm:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ intel_engine_pm_put(ce->engine);
i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/23] drm/i915: Remove locking from i915_gem_object_prepare_read/write
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
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 -
.../i915/gem/selftests/i915_gem_coherency.c | 14 +
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 20 +--
8 files changed, 59 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index c0acfc97fae3..8ebceebd11b0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -576,19 +576,17 @@ int i915_gem_object_prepare_read(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -616,8 +614,6 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object
*obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
@@ -630,20 +626,18 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_ALL,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -680,7 +674,5 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2cd217495207..ad7e92316375 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1003,11 +1003,14 @@ static void reloc_cache_reset(struct reloc_cache *cache)
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP) {
+ struct drm_i915_gem_object *obj =
+ (struct drm_i915_gem_object *)cache->node.mm;
if (cache->vaddr & CLFLUSH_AFTER)
mb();
kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
+ i915_gem_object_finish_access(obj);
+ i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
@@ -1043,10 +1046,16 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_prepare_write(obj, &flushes);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
return ERR_PTR(err);
+ err = i915_gem_object_prepare_write(obj, &flushes);
+ if (err) {
+ i915_gem_object_unlock(obj);
+ return ERR_PTR(err);
+ }
+
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 488459143366..45d79d75e73a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++
[Intel-gfx] [PATCH 03/23] Revert "drm/i915/gem: Drop relocation slowpath".
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 Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 274 +-
1 file changed, 261 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8e2ae8317c5c..c0aef4928d77 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -696,7 +696,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
if (err)
break;
}
- if (!(err == -ENOSPC || err == -EAGAIN))
+ if (err != -ENOSPC)
break;
/* Resort *all* the objects into priority order */
@@ -727,13 +727,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
}
list_splice_tail(&last, &eb->unbound);
- if (err == -EAGAIN) {
- mutex_unlock(&eb->i915->drm.struct_mutex);
- flush_workqueue(eb->i915->mm.userptr_wq);
- mutex_lock(&eb->i915->drm.struct_mutex);
- continue;
- }
-
switch (pass++) {
case 0:
break;
@@ -1039,9 +1032,10 @@ static void reloc_cache_reset(struct reloc_cache *cache)
static void *reloc_kmap(struct drm_i915_gem_object *obj,
struct reloc_cache *cache,
- unsigned long page)
+ unsigned long pageno)
{
void *vaddr;
+ struct page *page;
if (cache->vaddr) {
kunmap_atomic(unmask_page(cache->vaddr));
@@ -1062,9 +1056,13 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
mb();
}
- vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
+ page = i915_gem_object_get_page(obj, pageno);
+ if (!obj->mm.dirty)
+ set_page_dirty(page);
+
+ vaddr = kmap_atomic(page);
cache->vaddr = unmask_flags(cache->vaddr) | (unsigned long)vaddr;
- cache->page = page;
+ cache->page = pageno;
return vaddr;
}
@@ -1610,7 +1608,9 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct eb_vma *ev)
* we would try to acquire the struct mutex again. Obviously
* this is bad and so lockdep complains vehemently.
*/
- copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+ pagefault_disable();
+ copied = __copy_from_user_inatomic(r, urelocs, count *
sizeof(r[0]));
+ pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
@@ -1658,6 +1658,251 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct eb_vma *ev)
return remain;
}
+static int
+eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+ const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+ struct drm_i915_gem_relocation_entry *relocs =
+ u64_to_ptr(typeof(*relocs), entry->relocs_ptr);
+ unsigned int i;
+ int err;
+
+ for (i = 0; i < entry->relocation_count; i++) {
+ u64 offset = eb_relocate_entry(eb, ev, &relocs[i]);
+
+ if ((s64)offset < 0) {
+ err = (int)offset;
+ goto err;
+ }
+ }
+ err = 0;
+err:
+ reloc_cache_reset(&eb->reloc_cache);
+ return err;
+}
+
+static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+{
+ const char __user *addr, *end;
+ unsigned long size;
+ char __maybe_unused c;
+
+ size = entry->relocation_count;
+ if (size == 0)
+ return 0;
+
+ if (size > N_RELOC(ULONG_MAX))
+ return -EINVAL;
+
+ addr = u64_to_user_ptr(entry->relocs_ptr);
+ size *= sizeof(struct drm_i915_gem_relocation_entry);
+ if (!access_ok(addr, size))
+ return -EFAULT;
+
+ end = addr + size;
+ for (; addr < end; addr += PAGE_SIZE) {
+ int err = __get_user(c, addr);
+ if (err)
+ return err;
+ }
+ return __get_user(c, end - 1);
+}
+
+static int eb_copy_relocations(const struct i915_execbuffer *eb)
+{
+ struct drm_i915_gem_relocation_entry *relocs;
+ const unsigned int count = eb->buffer_count;
+ unsigned int i;
+ int err;
+
+ for (i = 0; i < count; i++) {
+ const unsigne
[Intel-gfx] [PATCH 10/23] drm/i915: Add ww context handling to context_barrier_task
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(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0bdb6d447ed..bc1a90abbdbe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1094,6 +1094,7 @@ I915_SELFTEST_DECLARE(static intel_engine_mask_t
context_barrier_inject_fault);
static int context_barrier_task(struct i915_gem_context *ctx,
intel_engine_mask_t engines,
bool (*skip)(struct intel_context *ce, void
*data),
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
int (*emit)(struct i915_request *rq, void
*data),
void (*task)(void *data),
void *data)
@@ -1101,6 +1102,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
+ struct i915_gem_ww_ctx ww;
struct intel_context *ce;
int err = 0;
@@ -1138,10 +1140,21 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (skip && skip(ce, data))
continue;
- rq = intel_context_create_request(ce);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ if (pin)
+ err = pin(ce, &ww, data);
+ if (err)
+ goto err_unpin;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- break;
+ goto err_unpin;
}
err = 0;
@@ -1151,6 +1164,16 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
err = i915_active_add_request(&cb->base, rq);
i915_request_add(rq);
+err_unpin:
+ intel_context_unpin(ce);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
if (err)
break;
}
@@ -1206,6 +1229,17 @@ static void set_ppgtt_barrier(void *data)
i915_vm_close(old);
}
+static int pin_ppgtt_update(struct intel_context *ce, struct i915_gem_ww_ctx
*ww, void *data)
+{
+ struct i915_address_space *vm = ce->vm;
+
+ if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
+ /* ppGTT is not part of the legacy context image */
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+
+ return 0;
+}
+
static int emit_ppgtt_update(struct i915_request *rq, void *data)
{
struct i915_address_space *vm = rq->context->vm;
@@ -1262,20 +1296,10 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
static bool skip_ppgtt_update(struct intel_context *ce, void *data)
{
- if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
- return true;
-
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
- return false;
-
- if (!atomic_read(&ce->pin_count))
- return true;
-
- /* ppGTT is not part of the legacy context image */
- if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
- return true;
-
- return false;
+ return !ce->state;
+ else
+ return !atomic_read(&ce->pin_count);
}
static int set_ppgtt(struct drm_i915_file_private *file_priv,
@@ -1326,6 +1350,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
*/
err = context_barrier_task(ctx, ALL_ENGINES,
skip_ppgtt_update,
+ pin_ppgtt_update,
emit_ppgtt_update,
set_ppgtt_barrier,
old);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index bf50c4abd0b6..b93fd16a539d 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1920,8 +1920,8 @@ static int mock_context_barrier(void *arg)
return -ENOMEM;
counter = 0;
- err = context_barrier_task(ctx, 0,
-
[Intel-gfx] [PATCH 20/23] drm/i915: Use ww pinning for intel_context_create_request()
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.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 671081b0e4d6..61b05cd4c47a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -449,15 +449,25 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce)
{
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
int err;
- err = intel_context_pin(ce);
- if (unlikely(err))
- return ERR_PTR(err);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin_ww(ce, &ww);
+ if (!err) {
+ rq = i915_request_create(ce);
+ intel_context_unpin(ce);
+ } else if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ } else {
+ rq = ERR_PTR(err);
+ }
- rq = i915_request_create(ce);
- intel_context_unpin(ce);
+ i915_gem_ww_ctx_fini(&ww);
if (IS_ERR(rq))
return rq;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/23] drm/i915: Pin engine before pinning all objects, v5.
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 the fastpath, if not we will take the slowpath and wait for
the throttle request while unlocked.
The engine has to be pinned as first step, otherwise gpu relocations
won't work.
Changes since v1:
- Only need to get a throttled request in the fastpath, no need for
a global flag any more.
- Always free the waited request correctly.
Changes since v2:
- Use intel_engine_pm_get()/put() to keeep engine pool alive during
EDEADLK handling.
Changes since v3:
- Fix small rq leak.
Changes since v4:
- Use a single reloc_context, for intel_context_pin_ww().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 214 --
.../i915/gem/selftests/i915_gem_execbuffer.c | 3 +
2 files changed, 152 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9afa50ec4de..d3699408faca 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -55,7 +55,8 @@ enum {
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
-#define __EXEC_INTERNAL_FLAGS (~0u << 31)
+#define __EXEC_ENGINE_PINNED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -273,6 +274,7 @@ struct i915_execbuffer {
} reloc_cache;
struct intel_gt_buffer_pool_node *reloc_pool; /** relocation pool for
-EDEADLK handling */
+ struct intel_context *reloc_context;
u64 invalid_flags; /** Set of execobj.flags that are invalid */
u32 context_flags; /** Set of execobj.flags to insert from the ctx */
@@ -292,6 +294,9 @@ struct i915_execbuffer {
};
static int eb_parse(struct i915_execbuffer *eb);
+static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
+ bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
@@ -924,7 +929,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb, bool final)
+static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
{
const unsigned int count = eb->buffer_count;
unsigned int i;
@@ -941,6 +946,8 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb, bool final)
if (final)
i915_vma_put(vma);
}
+
+ eb_unpin_engine(eb);
}
static void eb_destroy(const struct i915_execbuffer *eb)
@@ -1281,19 +1288,26 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
if (engine == eb->context->engine) {
rq = i915_request_create(eb->context);
} else {
- struct intel_context *ce;
+ struct intel_context *ce = eb->reloc_context;
- ce = intel_context_create(engine);
- if (IS_ERR(ce)) {
- err = PTR_ERR(ce);
- goto err_unpin;
+ if (!ce) {
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ goto err_unpin;
+ }
+
+ i915_vm_put(ce->vm);
+ ce->vm = i915_vm_get(eb->context->vm);
+ eb->reloc_context = ce;
}
- i915_vm_put(ce->vm);
- ce->vm = i915_vm_get(eb->context->vm);
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_unpin;
- rq = intel_context_create_request(ce);
- intel_context_put(ce);
+ rq = i915_request_create(ce);
+ intel_context_unpin(ce);
}
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
@@ -1860,7 +1874,8 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb,
+ struct i915_request *rq)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1876,6 +1891,21 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
eb_release_vmas(eb, false);
i915_gem_ww_ctx_fini(&eb->ww);
+ if (rq) {
+ /* nonblocking is
[Intel-gfx] [PATCH 09/23] drm/i915: Use ww locking in intel_renderstate.
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 Lankhorst
---
drivers/gpu/drm/i915/gt/intel_gt.c | 21 +++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 73 +++--
drivers/gpu/drm/i915/gt/intel_renderstate.h | 9 ++-
3 files changed, 71 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e0755f1a904b..8694ddbdac4c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
- err = intel_renderstate_init(&so, engine);
- if (err)
- goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
- rq = intel_context_create_request(ce);
+ err = intel_renderstate_init(&so, ce);
+ if (err)
+ goto err;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- intel_context_put(ce);
- goto out;
+ goto err_fini;
}
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
- intel_renderstate_fini(&so);
- if (err)
+err_fini:
+ intel_renderstate_fini(&so, ce);
+err:
+ if (err) {
+ intel_context_put(ce);
goto out;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index 1bfad589c63b..5164de04049d 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "intel_renderstate.h"
+#include "gt/intel_context.h"
#include "intel_ring.h"
static const struct intel_renderstate_rodata *
@@ -157,33 +158,47 @@ static int render_state_setup(struct intel_renderstate
*so,
#undef OUT_BATCH
int intel_renderstate_init(struct intel_renderstate *so,
- struct intel_engine_cs *engine)
+ struct intel_context *ce)
{
- struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *engine = ce->engine;
+ struct drm_i915_gem_object *obj = NULL;
int err;
memset(so, 0, sizeof(*so));
so->rodata = render_state_get_rodata(engine);
- if (!so->rodata)
- return 0;
+ if (so->rodata) {
+ if (so->rodata->batch_items * 4 > PAGE_SIZE)
+ return -EINVAL;
+
+ obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
+ if (IS_ERR(so->vma)) {
+ err = PTR_ERR(so->vma);
+ goto err_obj;
+ }
+ }
- if (so->rodata->batch_items * 4 > PAGE_SIZE)
- return -EINVAL;
+ i915_gem_ww_ctx_init(&so->ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_fini;
- obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ /* return early if there's nothing to setup */
+ if (!err && !so->rodata)
+ return 0;
- so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
- if (IS_ERR(so->vma)) {
- err = PTR_ERR(so->vma);
- goto err_obj;
- }
+ err = i915_gem_object_lock(so->vma->obj, &so->ww);
+ if (err)
+ goto err_context;
err = i915_vma_pin(so->vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
- goto err_obj;
+ goto err_context;
err = render_state_setup(so, engine->i915);
if (err)
@@ -193,8 +208,18 @@ int intel_renderstate_init(struct intel_renderstate *so,
err_unpin:
i915_vma_unpin(so->vma);
+err_context:
+ intel_context_unpin(ce);
+err_fini:
+ if (err == -EDEADL
[Intel-gfx] [PATCH 06/23] drm/i915: Parse command buffer earlier in eb_relocate(slow)
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 called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 68 ++-
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ad7e92316375..e8221b6d0a53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -290,6 +290,8 @@ struct i915_execbuffer {
struct eb_vma_array *array;
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -873,6 +875,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
+ struct drm_i915_private *i915 = eb->i915;
unsigned int batch = eb_batch_index(eb);
unsigned int i;
int err = 0;
@@ -886,18 +889,37 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
vma = eb_lookup_vma(eb, eb->exec[i].handle);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
- break;
+ goto err;
}
err = eb_validate_vma(eb, &eb->exec[i], vma);
if (unlikely(err)) {
i915_vma_put(vma);
- break;
+ goto err;
}
eb_add_vma(eb, i, batch, vma);
}
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(&i915->drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
+ return 0;
+
+err:
eb->vma[i].vma = NULL;
return err;
}
@@ -1814,7 +1836,7 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1880,6 +1902,11 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
if (err)
goto err;
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1912,7 +1939,7 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1937,10 +1964,10 @@ static int eb_relocate(struct i915_execbuffer *eb)
}
if (err)
- return eb_relocate_slow(eb);
+ return eb_relocate_parse_slow(eb);
}
- return 0;
+ return eb_parse(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2877,7 +2904,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = eb_relocate(&eb);
+ err = eb_relocate_parse(&eb);
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2890,33 +2917,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(&i915->drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (eb.batch_len == 0)
- eb.batch_len = eb
[Intel-gfx] [PATCH 23/23] drm/i915: Add ww locking to pin_to_display_plane
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/i915_gem_domain.c
index 8ebceebd11b0..c0d153284984 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -37,6 +37,12 @@ void i915_gem_object_flush_if_display(struct
drm_i915_gem_object *obj)
i915_gem_object_unlock(obj);
}
+void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj)
+{
+ if (i915_gem_object_is_framebuffer(obj))
+ __i915_gem_object_flush_for_display(obj);
+}
+
/**
* Moves a single object to the WC read, and possibly write domain.
* @obj: object to act on
@@ -197,18 +203,12 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
if (ret)
return ret;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
-
/* Always invalidate stale cachelines */
if (obj->cache_level != cache_level) {
i915_gem_object_set_cache_coherency(obj, cache_level);
obj->cache_dirty = true;
}
- i915_gem_object_unlock(obj);
-
/* The cache-level will be applied when each vma is rebound. */
return i915_gem_object_unbind(obj,
I915_GEM_OBJECT_UNBIND_ACTIVE |
@@ -255,6 +255,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_caching *args = data;
struct drm_i915_gem_object *obj;
enum i915_cache_level level;
+ struct i915_gem_ww_ctx ww;
int ret = 0;
switch (args->caching) {
@@ -293,7 +294,18 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev,
void *data,
goto out;
}
- ret = i915_gem_object_set_cache_level(obj, level);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (!ret)
+ ret = i915_gem_object_set_cache_level(obj, level);
+
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
out:
i915_gem_object_put(obj);
@@ -313,6 +325,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
unsigned int flags)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
int ret;
@@ -320,6 +333,11 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (ret)
+ goto err;
/*
* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
@@ -334,7 +352,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
HAS_WT(i915) ?
I915_CACHE_WT : I915_CACHE_NONE);
if (ret)
- return ERR_PTR(ret);
+ goto err;
/*
* As the user may map the buffer once pinned in the display plane
@@ -347,18 +365,31 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
vma = ERR_PTR(-ENOSPC);
if ((flags & PIN_MAPPABLE) == 0 &&
(!view || view->type == I915_GGTT_VIEW_NORMAL))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
- flags |
- PIN_MAPPABLE |
- PIN_NONBLOCK);
- if (IS_ERR(vma))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
- if (IS_ERR(vma))
- return vma;
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0, alignment,
+ flags | PIN_MAPPABLE |
+ PIN_NONBLOCK);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK))
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0,
+ alignment, flags);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err;
+ }
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
- i915_gem_object_flush_if_display(obj);
+ i915_gem_object_flush_if_display_loc
[Intel-gfx] [PATCH 13/23] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex
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 to take pin refcounts correctly
all the time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 232 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 ++-
.../gpu/drm/i915/gt/intel_ring_submission.c | 13 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 13 +-
5 files changed, 190 insertions(+), 106 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..efe9a7a89ede 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -93,79 +93,6 @@ static void intel_context_active_release(struct
intel_context *ce)
i915_active_release(&ce->active);
}
-int __intel_context_do_pin(struct intel_context *ce)
-{
- int err;
-
- if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
- err = intel_context_alloc_state(ce);
- if (err)
- return err;
- }
-
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
-
- if (mutex_lock_interruptible(&ce->pin_mutex)) {
- err = -EINTR;
- goto out_release;
- }
-
- if (unlikely(intel_context_is_closed(ce))) {
- err = -ENOENT;
- goto out_unlock;
- }
-
- if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
- err = intel_context_active_acquire(ce);
- if (unlikely(err))
- goto out_unlock;
-
- err = ce->ops->pin(ce);
- if (unlikely(err))
- goto err_active;
-
- CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
-ce->ring->head, ce->ring->tail);
-
- smp_mb__before_atomic(); /* flush pin before it is visible */
- atomic_inc(&ce->pin_count);
- }
-
- GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
- GEM_BUG_ON(i915_active_is_idle(&ce->active));
- goto out_unlock;
-
-err_active:
- intel_context_active_release(ce);
-out_unlock:
- mutex_unlock(&ce->pin_mutex);
-out_release:
- i915_active_release(&ce->active);
- return err;
-}
-
-void intel_context_unpin(struct intel_context *ce)
-{
- if (!atomic_dec_and_test(&ce->pin_count))
- return;
-
- CE_TRACE(ce, "unpin\n");
- ce->ops->unpin(ce);
-
- /*
-* Once released, we may asynchronously drop the active reference.
-* As that may be the only reference keeping the context alive,
-* take an extra now so that it is not freed before we finish
-* dereferencing it.
-*/
- intel_context_get(ce);
- intel_context_active_release(ce);
- intel_context_put(ce);
-}
-
static int __context_pin_state(struct i915_vma *vma)
{
unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
@@ -225,6 +152,138 @@ static void __ring_retire(struct intel_ring *ring)
intel_ring_unpin(ring);
}
+static int intel_context_pre_pin(struct intel_context *ce)
+{
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ err = __ring_active(ce->ring);
+ if (err)
+ return err;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+ return err;
+}
+
+static void intel_context_post_unpin(struct intel_context *ce)
+{
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+}
+
+int __intel_context_do_pin(struct intel_context *ce)
+{
+ bool handoff = false;
+ void *vaddr;
+ int err = 0;
+
+ if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
+ err = intel_context_alloc_state(ce);
+ if (err)
+ return err;
+ }
+
+ /*
+* We always pin the context/ring/timeline here, to ensure a pin
+* refcount for __intel_context_active(), which prevent a lock
+* inversion of ce->pin_mutex vs dma_resv_lock().
+*/
+ err = intel_context_pre_pin(ce);
+ if (err)
+ return err;
+
+ err = i915_
[Intel-gfx] [PATCH 01/23] Revert "drm/i915/gem: Async GPU relocations only"
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/selftests/i915_gem_execbuffer.c | 21 +-
2 files changed, 308 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6b4ec66cb558..446e76e95c38 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -45,6 +45,13 @@ struct eb_vma_array {
struct eb_vma vma[];
};
+enum {
+ FORCE_CPU_RELOC = 1,
+ FORCE_GTT_RELOC,
+ FORCE_GPU_RELOC,
+#define DBG_FORCE_RELOC 0 /* choose one of the above! */
+};
+
#define __EXEC_OBJECT_HAS_PIN BIT(31)
#define __EXEC_OBJECT_HAS_FENCEBIT(30)
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
@@ -253,6 +260,8 @@ struct i915_execbuffer {
*/
struct reloc_cache {
struct drm_mm_node node; /** temporary GTT binding */
+ unsigned long vaddr; /** Current kmap address */
+ unsigned long page; /** Currently mapped page index */
unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
bool has_llc : 1;
@@ -596,6 +605,23 @@ eb_add_vma(struct i915_execbuffer *eb,
}
}
+static inline int use_cpu_reloc(const struct reloc_cache *cache,
+ const struct drm_i915_gem_object *obj)
+{
+ if (!i915_gem_object_has_struct_page(obj))
+ return false;
+
+ if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
+ return true;
+
+ if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
+ return false;
+
+ return (cache->has_llc ||
+ obj->cache_dirty ||
+ obj->cache_level != I915_CACHE_NONE);
+}
+
static int eb_reserve_vma(const struct i915_execbuffer *eb,
struct eb_vma *ev,
u64 pin_flags)
@@ -926,6 +952,8 @@ relocation_target(const struct
drm_i915_gem_relocation_entry *reloc,
static void reloc_cache_init(struct reloc_cache *cache,
struct drm_i915_private *i915)
{
+ cache->page = -1;
+ cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
@@ -937,6 +965,25 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->target = NULL;
}
+static inline void *unmask_page(unsigned long p)
+{
+ return (void *)(uintptr_t)(p & PAGE_MASK);
+}
+
+static inline unsigned int unmask_flags(unsigned long p)
+{
+ return p & ~PAGE_MASK;
+}
+
+#define KMAP 0x4 /* after CLFLUSH_FLAGS */
+
+static inline struct i915_ggtt *cache_to_ggtt(struct reloc_cache *cache)
+{
+ struct drm_i915_private *i915 =
+ container_of(cache, struct i915_execbuffer, reloc_cache)->i915;
+ return &i915->ggtt;
+}
+
#define RELOC_TAIL 4
static int reloc_gpu_chain(struct reloc_cache *cache)
@@ -1049,6 +1096,181 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
return err;
}
+static void reloc_cache_reset(struct reloc_cache *cache)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ vaddr = unmask_page(cache->vaddr);
+ if (cache->vaddr & KMAP) {
+ if (cache->vaddr & CLFLUSH_AFTER)
+ mb();
+
+ kunmap_atomic(vaddr);
+ i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
+ } else {
+ struct i915_ggtt *ggtt = cache_to_ggtt(cache);
+
+ intel_gt_flush_ggtt_writes(ggtt->vm.gt);
+ io_mapping_unmap_atomic((void __iomem *)vaddr);
+
+ if (drm_mm_node_allocated(&cache->node)) {
+ ggtt->vm.clear_range(&ggtt->vm,
+cache->node.start,
+cache->node.size);
+ mutex_lock(&ggtt->vm.mutex);
+ drm_mm_remove_node(&cache->node);
+ mutex_unlock(&ggtt->vm.mutex);
+ } else {
+ i915_vma_unpin((struct i915_vma *)cache->node.mm);
+ }
+ }
+
+ cache->vaddr = 0;
+ cache->page = -1;
+}
+
+static void *reloc_kmap(struct drm_i915_gem_object *obj,
+ struct reloc_cache *cache,
+ unsigned long page)
+{
+ void *vaddr;
+
+ if (cache->vaddr) {
+ kunmap_atomic(unmask_page(cache->vaddr));
+ } else {
+ unsigned int flushes;
+ int err;
+
+ err = i915_gem_
[Intel-gfx] [PATCH 15/23] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.
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/put() calls to fix use-after-free when using
intel_engine_get_pool().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 78 +++--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 152 --
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 3 +
3 files changed, 163 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index f4bf7bacb2c3..cc74b31e3669 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -157,6 +157,7 @@ static void clear_pages_worker(struct work_struct *work)
struct clear_pages_work *w = container_of(work, typeof(*w), work);
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -172,17 +173,20 @@ static void clear_pages_worker(struct work_struct *work)
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (unlikely(err))
+ i915_gem_ww_ctx_init(&ww, false);
+ intel_engine_pm_get(w->ce->engine);
+retry:
+ err = intel_context_pin_ww(w->ce, &ww);
+ if (err)
goto out_signal;
- batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
+ batch = intel_emit_vma_fill_blt(w->ce, vma, &ww, w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
- goto out_unpin;
+ goto out_ctx;
}
- rq = intel_context_create_request(w->ce);
+ rq = i915_request_create(w->ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_batch;
@@ -224,9 +228,19 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
- i915_vma_unpin(vma);
+out_ctx:
+ intel_context_unpin(w->ce);
out_signal:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ i915_vma_unpin(w->sleeve->vma);
+ intel_engine_pm_put(w->ce->engine);
+
if (unlikely(err)) {
dma_fence_set_error(&w->dma, err);
dma_fence_signal(&w->dma);
@@ -234,6 +248,44 @@ static void clear_pages_worker(struct work_struct *work)
}
}
+static int pin_wait_clear_pages_work(struct clear_pages_work *w,
+struct intel_context *ce)
+{
+ struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err)
+ goto out;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto out;
+
+ err = i915_sw_fence_await_reservation(&w->wait,
+ vma->obj->base.resv, NULL,
+ true, 0, I915_FENCE_GFP);
+ if (err)
+ goto err_unpin_vma;
+
+ dma_resv_add_excl_fence(vma->obj->base.resv, &w->dma);
+
+err_unpin_vma:
+ if (err)
+ i915_vma_unpin(vma);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ return err;
+}
+
static int __i915_sw_fence_call
clear_pages_work_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
@@ -287,17 +339,9 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj, NULL);
- err = i915_sw_fence_await_reservation(&work->wait,
- obj->base.resv, NULL, true, 0,
- I915_FENCE_GFP);
- if (err < 0) {
+ err = pin_wait_clear_pages_work(work, ce);
+ if (err < 0)
dma_fence_set_error(&work->dma, err);
- } else {
- dma_resv_add_excl_fence(obj->base.resv, &work->dma);
- err = 0;
- }
- i915_gem_object_unlock(obj);
dma_f
[Intel-gfx] [PATCH 18/23] drm/i915: Dirty hack to fix selftests locking inversion
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/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index c05ef213bdc2..671081b0e4d6 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -459,6 +459,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* +* timeline->mutex should be the inner lock, but is used as outer lock. +* Hack around this to shut up lockdep in selftests.. +*/ + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); + return rq; } -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/23] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.
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 ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 140 ++
.../i915/gem/selftests/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 4 +-
drivers/gpu/drm/i915/gt/intel_context.c | 65 +---
drivers/gpu/drm/i915/gt/intel_context.h | 13 ++
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ring.h | 3 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 15 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 12 +-
drivers/gpu/drm/i915/gt/intel_timeline.h | 3 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 13 +-
drivers/gpu/drm/i915/i915_gem.c | 11 +-
drivers/gpu/drm/i915/i915_vma.c | 13 +-
drivers/gpu/drm/i915/i915_vma.h | 13 +-
26 files changed, 217 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 62121289dc75..62db736e0f95 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3450,7 +3450,7 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
- if (i915_ggtt_pin(vma, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
+ if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
goto err_obj;
if (i915_gem_object_is_tiled(obj) &&
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index bc1a90abbdbe..0cc985a63d6c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1142,7 +1142,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
i915_gem_ww_ctx_init(&ww, true);
retry:
- err = intel_context_pin(ce);
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err;
@@ -1235,7 +1235,7 @@ static int pin_ppgtt_update(struct intel_context *ce,
struct i915_gem_ww_ctx *ww
if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
/* ppGTT is not part of the legacy context image */
- return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm), ww);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3699408faca..da570b27f9f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -425,16 +425,17 @@ eb_pin_vma(struct i915_execbuffer *eb,
pin_flags |= PIN_GLOBAL;
/* Attempt to reuse the current location if available */
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
+ /* TODO: Add -EDEADLK handling here */
+ if (unlikely(i915_vma_pin_ww(vma, &eb->ww, 0, 0, pin_flags))) {
if (entry->flags & EXEC_OBJECT_PINNED)
return false;
/* Failing that pick any _free_ space if suitable */
- if (unlikely(i915_vma_pin(vma,
- entry->pad_to_size,
- entry->alignment,
- eb_pin_flags(entry, ev->flags) |
- PIN_USER | PIN_NOEVICT)))
+ if (unlikely(i915_vma_pin_ww(vma, &eb->ww,
+entry->pad_to_size,
+entry->alignment,
+eb_pin_flags(entry, ev->flags) |
+PIN_USER | PIN_NOEVICT)))
return false;
}
@@ -575,7 +576,7 @@ static inline int use_cpu_reloc(const struct reloc_c
[Intel-gfx] [PATCH 19/23] drm/i915/selftests: Fix locking inversion in lrc selftest.
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 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index df6fd472cb78..b05df2a0964c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -4997,6 +4997,7 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
{
struct intel_context *ce;
struct i915_request *rq;
+ struct i915_gem_ww_ctx ww;
enum {
RING_START_IDX = 0,
RING_TAIL_IDX,
@@ -5011,7 +5012,11 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
if (IS_ERR(ce))
return PTR_ERR(ce);
- err = intel_context_pin(ce);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(scratch->obj, &ww);
+ if (!err)
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err_put;
@@ -5040,11 +5045,9 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
*cs++ = i915_ggtt_offset(scratch) + RING_TAIL_IDX * sizeof(u32);
*cs++ = 0;
- i915_vma_lock(scratch);
err = i915_request_await_object(rq, scratch->obj, true);
if (!err)
err = i915_vma_move_to_active(scratch, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(scratch);
i915_request_get(rq);
i915_request_add(rq);
@@ -5081,6 +5084,12 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
err_unpin:
intel_context_unpin(ce);
err_put:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_context_put(ce);
return err;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/23] drm/i915: Convert i915_perf to ww locking as well
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: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_perf.c | 57 +++-
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c6f6370283cf..e94976976571 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1195,24 +1195,39 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
struct i915_gem_engines_iter it;
struct i915_gem_context *ctx = stream->ctx;
struct intel_context *ce;
- int err;
+ struct i915_gem_ww_ctx ww;
+ int err = -ENODEV;
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
if (ce->engine != stream->engine) /* first match! */
continue;
- /*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*/
- err = intel_context_pin(ce);
- if (err == 0) {
- stream->pinned_ctx = ce;
- break;
- }
+ err = 0;
+ break;
}
i915_gem_context_unlock_engines(ctx);
+ if (err)
+ return ERR_PTR(err);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*/
+ err = intel_context_pin_ww(ce, &ww);
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ if (err)
+ return ERR_PTR(err);
+
+ stream->pinned_ctx = ce;
return stream->pinned_ctx;
}
@@ -1923,15 +1938,22 @@ emit_oa_config(struct i915_perf_stream *stream,
{
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = get_oa_vma(stream, oa_config);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err)
+ goto err;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
- goto err_vma_put;
+ goto err;
intel_engine_pm_get(ce->engine);
rq = i915_request_create(ce);
@@ -1953,11 +1975,9 @@ emit_oa_config(struct i915_perf_stream *stream,
goto err_add_request;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
if (!err)
err = i915_vma_move_to_active(vma, rq, 0);
- i915_vma_unlock(vma);
if (err)
goto err_add_request;
@@ -1971,7 +1991,14 @@ emit_oa_config(struct i915_perf_stream *stream,
i915_request_add(rq);
err_vma_unpin:
i915_vma_unpin(vma);
-err_vma_put:
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+
+ i915_gem_ww_ctx_fini(&ww);
i915_vma_put(vma);
return err;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/20] drm/i915/gem: Bind the fence async for execbuf
On 06/07/2020 07:19, Chris Wilson wrote:
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 137 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 5 +
3 files changed, 151 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6a406e8798ef..c14c3b7e0dfd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1056,15 +1056,6 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_bind_vma *bind)
return err;
pin:
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
- err = __i915_vma_pin_fence(vma); /* XXX no waiting */
- if (unlikely(err))
- return err;
-
- if (vma->fence)
- bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
- }
-
bind_flags &= ~atomic_read(&vma->flags);
if (bind_flags) {
err = set_bind_fence(vma, work);
@@ -1095,6 +1086,15 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_bind_vma *bind)
bind->ev->flags |= __EXEC_OBJECT_HAS_PIN;
GEM_BUG_ON(eb_vma_misplaced(entry, vma, bind->ev->flags));
+ if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ err = __i915_vma_pin_fence_async(vma, &work->base);
+ if (unlikely(err))
+ return err;
+
+ if (vma->fence)
+ bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+ }
+
return 0;
}
@@ -1160,6 +1160,9 @@ static void __eb_bind_vma(struct eb_vm_work *work)
struct eb_bind_vma *bind = &work->bind[n];
struct i915_vma *vma = bind->ev->vma;
+ if (bind->ev->flags & __EXEC_OBJECT_HAS_FENCE)
+ __i915_vma_apply_fence_async(vma);
+
if (!bind->bind_flags)
goto put;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 7fb36b12fe7a..734b6aa61809 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -21,10 +21,13 @@
* IN THE SOFTWARE.
*/
+#include "i915_active.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
+#include "i915_sw_fence_work.h"
#include "i915_pvinfo.h"
#include "i915_vgpu.h"
+#include "i915_vma.h"
/**
* DOC: fence register handling
@@ -340,19 +343,37 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt
*ggtt)
return ERR_PTR(-EDEADLK);
}
+static int fence_wait_bind(struct i915_fence_reg *reg)
+{
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = i915_active_fence_get(®->active.excl);
+ if (fence) {
+ err = dma_fence_wait(fence, true);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
int __i915_vma_pin_fence(struct i915_vma *vma)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
- struct i915_fence_reg *fence;
+ struct i915_fence_reg *fence = vma->fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
int err;
lockdep_assert_held(&vma->vm->mutex);
/* Just update our place in the LRU if our fence is getting reused. */
- if (vma->fence) {
- fence = vma->fence;
+ if (fence) {
GEM_BUG_ON(fence->vma != vma);
+
+ err = fence_wait_bind(fence);
+ if (err)
+ return err;
+
atomic_inc(&fence->pin_count);
if (!fence->dirty) {
list_move_tail(&fence->link, &ggtt->fence_list);
@@ -384,6 +405,116 @@ int __i915_vma_pin_fence(struct i915_vma *vma)
return err;
}
+static int set_bind_fence(struct i915_fence_reg *fence,
+ struct dma_fence_work *work)
+{
+ struct dma_fence *prev;
+ int err;
+
+ if (rcu_access_pointer(fence->active.excl.fence) == &work->dma)
+ return 0;
What is this checking for?
+
+ err = i915_sw_fence_await_active(&work->chain,
+&fence->active,
+I915_ACTIVE_AWAIT_ACTIVE);
+ if (err)
+ return err;
+
+ if (i915_active_acquire(&fence->active))
+ return -ENOENT;
+
+ prev = i915_active_set_exclusive(&fence->active, &work->dma);
+ if (unlikely(prev)) {
+ err = i915
[Intel-gfx] [PATCH i-g-t] gem_wsim: Use CTX_TIMESTAMP for timed spinners
From: Tvrtko Ursulin
Use MI_MATH and MI_COND_BBE we can construct a loop that runs for a
precise number of clock cycles, as measured by the CTX_TIMESTAMP. We use
the CTX_TIMESTAMP (as opposed to the CS_TIMESTAMP) so that the elapsed
time is measured local to the context, and the length of the batch is
unaffected by preemption. Since the clock ticks at a known frequency, we
can directly translate the batch durations into cycles and so remove the
requirement for nop calibration, and the often excessively large nop
batches.
The downside to this is that we need to use engine local registers, and
before gen11 there is no support in the CS for relative mmio and so this
technique does not support transparent load balancing on a virtual
engine before Icelake.
Signed-off-by: Chris Wilson
---
benchmarks/gem_wsim.c | 512 ++
1 file changed, 170 insertions(+), 342 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index dbb46b9aa..b6e2f8adb 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -176,10 +176,9 @@ struct w_step
struct drm_i915_gem_execbuffer2 eb;
struct drm_i915_gem_exec_object2 *obj;
- struct drm_i915_gem_relocation_entry reloc[1];
- unsigned long bb_sz;
+ struct drm_i915_gem_relocation_entry reloc[3];
uint32_t bb_handle;
- uint32_t *recursive_bb_start;
+ uint32_t *bb_duration;
};
struct ctx {
@@ -227,9 +226,7 @@ struct workload
unsigned int nrequest[NUM_ENGINES];
};
-static const unsigned int nop_calibration_us = 1000;
-static bool has_nop_calibration = false;
-static bool sequential = true;
+static int ts_frequency;
static unsigned int master_prng;
@@ -253,59 +250,58 @@ static const char *ring_str_map[NUM_ENGINES] = {
[VECS] = "VECS",
};
-/* stores calibrations for particular engines */
-static unsigned long engine_calib_map[NUM_ENGINES];
-
-static enum intel_engine_id
-ci_to_engine_id(int class, int instance)
-{
- static const struct {
- int class;
- int instance;
- unsigned int id;
- } map[] = {
- { I915_ENGINE_CLASS_RENDER, 0, RCS },
- { I915_ENGINE_CLASS_COPY, 0, BCS },
- { I915_ENGINE_CLASS_VIDEO, 0, VCS1 },
- { I915_ENGINE_CLASS_VIDEO, 1, VCS2 },
- { I915_ENGINE_CLASS_VIDEO, 2, VCS2 }, /* FIXME/ICL */
- { I915_ENGINE_CLASS_VIDEO_ENHANCE, 0, VECS },
+static int read_timestamp_frequency(int i915)
+{
+ int value = 0;
+ drm_i915_getparam_t gp = {
+ .value = &value,
+ .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
};
-
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(map); i++) {
- if (class == map[i].class && instance == map[i].instance)
- return map[i].id;
- }
- return -1;
+ ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+ return value;
}
-static void
-apply_unset_calibrations(unsigned long raw_number)
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
{
- for (int i = 0; i < NUM_ENGINES; i++)
- engine_calib_map[i] += engine_calib_map[i] ? 0 : raw_number;
+ return (x + y - 1) / y;
}
-static void
-print_engine_calibrations(void)
+static uint64_t ns_to_ticks(uint64_t ns)
{
- bool first_entry = true;
+ return div64_u64_round_up(ns * ts_frequency, 10);
+}
- printf("Nop calibration for %uus delay is: ", nop_calibration_us);
- for (int i = 0; i < NUM_ENGINES; i++) {
- /* skip engines not present and DEFAULT and VCS */
- if (i != DEFAULT && i != VCS && engine_calib_map[i]) {
- if (first_entry) {
- printf("%s=%lu", ring_str_map[i],
engine_calib_map[i]);
- first_entry = false;
- } else {
- printf(",%s=%lu", ring_str_map[i],
engine_calib_map[i]);
- }
- }
- }
- printf("\n");
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x) MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define MI_MATH_NOOP MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define MI_MATH_ADD MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define MI_MATH_SUB MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define MI_MATH_AND MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define MI_MATH_ORMI_MATH_
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Assert the kernel context is using the HWSP
== Series Details == Series: drm/i915/gt: Assert the kernel context is using the HWSP URL : https://patchwork.freedesktop.org/series/79469/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18156 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/index.html Known issues Here are the changes found in Patchwork_18156 that come from known issues: ### IGT changes ### Issues hit * igt@prime_vgem@basic-write: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@prime_v...@basic-write.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-tgl-y/igt@prime_v...@basic-write.html Possible fixes * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][3] ([i915#402]) -> [PASS][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_module_load@reload: - fi-tgl-u2: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_backlight@basic-brightness: - fi-whl-u: [DMESG-WARN][7] ([i915#95]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][9] ([i915#579]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][16] ([i915#62] / [i915#92]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (46 -> 39) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8744 -> Patchwork_18156 CI-20190529: 20190529 CI_DRM_8744: beb1c0b42c5368a48e782e5556be95c8332d28c6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_573
Re: [Intel-gfx] [PATCH 14/20] drm/i915/gem: Include cmdparser in common execbuf pinning
On 06/07/2020 07:19, Chris Wilson wrote:
Pull the cmdparser allocations in to the reservation phase, and then
they are included in the common vma pinning pass.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 348 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 10 +
drivers/gpu/drm/i915/i915_cmd_parser.c| 21 +-
3 files changed, 218 insertions(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c14c3b7e0dfd..8e4681427ce3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -25,6 +25,7 @@
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
#include "i915_gem_ioctls.h"
+#include "i915_memcpy.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
@@ -52,6 +53,7 @@ struct eb_bind_vma {
struct eb_vma_array {
struct kref kref;
+ struct list_head aux_list;
Why is the aux_list needed (code comment would do).
struct eb_vma vma[];
};
@@ -246,7 +248,6 @@ struct i915_execbuffer {
struct i915_request *request; /** our request to build */
struct eb_vma *batch; /** identity of the batch obj/vma */
- struct i915_vma *trampoline; /** trampoline used for chaining */
/** actual size of execobj[] as we may extend it for the cmdparser */
unsigned int buffer_count;
@@ -281,6 +282,11 @@ struct i915_execbuffer {
unsigned int rq_size;
} reloc_cache;
+ struct eb_cmdparser {
+ struct eb_vma *shadow;
+ struct eb_vma *trampoline;
+ } parser;
+
u64 invalid_flags; /** Set of execobj.flags that are invalid */
u32 context_flags; /** Set of execobj.flags to insert from the ctx */
@@ -298,6 +304,10 @@ struct i915_execbuffer {
struct eb_vma_array *array;
};
+static struct drm_i915_gem_exec_object2 no_entry = {
+ .offset = -1ull
Is the -1 ever used or just the unique element address is enough?
+};
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -314,6 +324,7 @@ static struct eb_vma_array *eb_vma_array_create(unsigned
int count)
return NULL;
kref_init(&arr->kref);
+ INIT_LIST_HEAD(&arr->aux_list);
arr->vma[0].vma = NULL;
return arr;
@@ -339,16 +350,31 @@ static inline void eb_unreserve_vma(struct eb_vma *ev)
__EXEC_OBJECT_HAS_FENCE);
}
+static void eb_vma_destroy(struct eb_vma *ev)
+{
+ eb_unreserve_vma(ev);
+ i915_vma_put(ev->vma);
+}
+
+static void eb_destroy_aux(struct eb_vma_array *arr)
+{
+ struct eb_vma *ev, *en;
+
+ list_for_each_entry_safe(ev, en, &arr->aux_list, reloc_link) {
+ eb_vma_destroy(ev);
+ kfree(ev);
+ }
+}
+
static void eb_vma_array_destroy(struct kref *kref)
{
struct eb_vma_array *arr = container_of(kref, typeof(*arr), kref);
- struct eb_vma *ev = arr->vma;
+ struct eb_vma *ev;
- while (ev->vma) {
- eb_unreserve_vma(ev);
- i915_vma_put(ev->vma);
- ev++;
- }
+ eb_destroy_aux(arr);
+
+ for (ev = arr->vma; ev->vma; ev++)
+ eb_vma_destroy(ev);
kvfree(arr);
}
@@ -396,8 +422,8 @@ eb_lock_vma(struct i915_execbuffer *eb, struct
ww_acquire_ctx *acquire)
static int eb_create(struct i915_execbuffer *eb)
{
- /* Allocate an extra slot for use by the command parser + sentinel */
- eb->array = eb_vma_array_create(eb->buffer_count + 2);
+ /* Allocate an extra slot for use by the sentinel */
+ eb->array = eb_vma_array_create(eb->buffer_count + 1);
if (!eb->array)
return -ENOMEM;
@@ -1078,7 +1104,7 @@ static int eb_reserve_vma(struct eb_vm_work *work, struct eb_bind_vma *bind)
GEM_BUG_ON(!(drm_mm_node_allocated(&vma->node) ^
drm_mm_node_allocated(&bind->hole)));
- if (entry->offset != vma->node.start) {
+ if (entry != &no_entry && entry->offset != vma->node.start) {
entry->offset = vma->node.start | UPDATE;
*work->p_flags |= __EXEC_HAS_RELOC;
}
@@ -1374,7 +1400,8 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
struct i915_vma *vma = ev->vma;
if (eb_pin_vma_inplace(eb, entry, ev)) {
- if (entry->offset != vma->node.start) {
+ if (entry != &no_entry &&
+ entry->offset != vma->node.start) {
entry->offset = vma->node.start | UPDATE;
eb->args->flags |= __EXEC_HAS_RELOC;
}
@@ -1514,6 +1541,113 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
} while (1);
}
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only"
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only"
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
78aced2defcc Revert "drm/i915/gem: Async GPU relocations only"
-:113: WARNING:MEMORY_BARRIER: memory barrier without comment
#113: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1109:
+ mb();
-:161: WARNING:MEMORY_BARRIER: memory barrier without comment
#161: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1157:
+ mb();
-:181: CHECK:SPACING: No space is necessary after a cast
#181: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1177:
+ io_mapping_unmap_atomic((void __force __iomem *)
unmask_page(cache->vaddr));
-:260: WARNING:MEMORY_BARRIER: memory barrier without comment
#260: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1256:
+ mb();
-:274: CHECK:BRACES: Unbalanced braces around else statement
#274: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1270:
+ } else
total: 0 errors, 3 warnings, 2 checks, 455 lines checked
b24ea956a0cd drm/i915: Revert relocation chaining commits.
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
-:221: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#221: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1313:
+ if (cache->rq_size > PAGE_SIZE/sizeof(u32) - (len + 1))
^
total: 0 errors, 1 warnings, 1 checks, 281 lines checked
2e2d495d2636 Revert "drm/i915/gem: Drop relocation slowpath".
-:131: WARNING:LINE_SPACING: Missing a blank line after declarations
#131: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1705:
+ int err = __get_user(c, addr);
+ if (err)
total: 0 errors, 1 warnings, 0 checks, 320 lines checked
02b119c2f553 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:445: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#445: FILE: drivers/gpu/drm/i915/i915_gem.c:1359:
+ while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 441 lines checked
501006da4f38 drm/i915: Remove locking from i915_gem_object_prepare_read/write
d9c6f39414a8 drm/i915: Parse command buffer earlier in eb_relocate(slow)
2ce51010178d Revert "drm/i915/gem: Split eb_vma into its own allocation"
66c795743a3b drm/i915: Use per object locking in execbuf, v12.
-:457: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#457: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1410:
+static int __reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:477: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#477: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1483:
+static int reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:489: ERROR:TRAILING_WHITESPACE: trailing whitespace
#489: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1508:
+^I$
-:759: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#759: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2878:
+ eb.reloc_pool = eb.batch_pool = NULL;
total: 1 errors, 0 warnings, 3 checks, 865 lines checked
984da9ade426 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 190 lines checked
a6bff076144d drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1097:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
9770bed119fc drm/i915: Nuke arguments to eb_pin_engine
8e93a20010bc drm/i915: Pin engine before pinning all objects, v5.
a2068d12cab5 drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:338: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#338: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3483:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 434 lines checked
28d1811b0e5f drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only"
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" URL : https://patchwork.freedesktop.org/series/79470/ 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/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only"
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" URL : https://patchwork.freedesktop.org/series/79470/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18157 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18157 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18157, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18157: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html - fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html Known issues Here are the changes found in Patchwork_18157 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@double-flink: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@double-flink.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-tgl-y/igt@gem_flink_ba...@double-flink.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-kbl-x1275/igt@kms_busy@ba...@flip.html Possible fixes * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][11] ([i915#579]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-kbl-soraka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html - fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18157/fi-kbl-x1275/igt@g
[Intel-gfx] [PATCH] drm/i915/gt: Trace placement of timeline HWSP
Track the position of the HWSP for each timeline.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_timeline.c| 7 +++
drivers/gpu/drm/i915/gt/selftest_timeline.c | 13 -
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 4546284fede1..46d20f5f3ddc 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -73,6 +73,8 @@ hwsp_alloc(struct intel_timeline *timeline, unsigned int
*cacheline)
return vma;
}
+ GT_TRACE(timeline->gt, "new HWSP allocated\n");
+
vma->private = hwsp;
hwsp->gt = timeline->gt;
hwsp->vma = vma;
@@ -327,6 +329,8 @@ int intel_timeline_pin(struct intel_timeline *tl)
tl->hwsp_offset =
i915_ggtt_offset(tl->hwsp_ggtt) +
offset_in_page(tl->hwsp_offset);
+ GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n",
+tl->fence_context, tl->hwsp_offset);
cacheline_acquire(tl->hwsp_cacheline);
if (atomic_fetch_inc(&tl->pin_count)) {
@@ -434,6 +438,7 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
int err;
might_lock(&tl->gt->ggtt->vm.mutex);
+ GT_TRACE(tl->gt, "timeline:%llx wrapped\n", tl->fence_context);
/*
* If there is an outstanding GPU reference to this cacheline,
@@ -497,6 +502,8 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
memset(vaddr + tl->hwsp_offset, 0, CACHELINE_BYTES);
tl->hwsp_offset += i915_ggtt_offset(vma);
+ GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n",
+tl->fence_context, tl->hwsp_offset);
cacheline_acquire(cl);
tl->hwsp_cacheline = cl;
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index fcdee951579b..fb5b7d3498a6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -562,8 +562,9 @@ static int live_hwsp_engine(void *arg)
struct intel_timeline *tl = timelines[n];
if (!err && *tl->hwsp_seqno != n) {
- pr_err("Invalid seqno stored in timeline %lu, found
0x%x\n",
- n, *tl->hwsp_seqno);
+ pr_err("Invalid seqno stored in timeline %lu @ %x,
found 0x%x\n",
+ n, tl->hwsp_offset, *tl->hwsp_seqno);
+ GEM_TRACE_DUMP();
err = -EINVAL;
}
intel_timeline_put(tl);
@@ -633,8 +634,9 @@ static int live_hwsp_alternate(void *arg)
struct intel_timeline *tl = timelines[n];
if (!err && *tl->hwsp_seqno != n) {
- pr_err("Invalid seqno stored in timeline %lu, found
0x%x\n",
- n, *tl->hwsp_seqno);
+ pr_err("Invalid seqno stored in timeline %lu @ %x,
found 0x%x\n",
+ n, tl->hwsp_offset, *tl->hwsp_seqno);
+ GEM_TRACE_DUMP();
err = -EINVAL;
}
intel_timeline_put(tl);
@@ -965,8 +967,9 @@ static int live_hwsp_recycle(void *arg)
}
if (*tl->hwsp_seqno != count) {
- pr_err("Invalid seqno stored in timeline %lu,
found 0x%x\n",
+ pr_err("Invalid seqno stored in timeline %lu @
tl->hwsp_offset, found 0x%x\n",
count, *tl->hwsp_seqno);
+ GEM_TRACE_DUMP();
err = -EINVAL;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/20] drm/i915/gem: Assign context id for async work
Quoting Tvrtko Ursulin (2020-07-13 13:22:19) > > On 09/07/2020 13:07, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-07-09 12:59:51) > >> > >> On 09/07/2020 12:07, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2020-07-09 12:01:29) > > On 08/07/2020 16:36, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-07-08 15:24:20) > >> And what is the effective behaviour you get with N contexts - emit N > >> concurrent operations and for N + 1 block in execbuf? > > > > Each context defines a timeline. A task is not ready to run until the > > task before it in its timeline is completed. So we don't block in > > execbuf, the scheduler waits until the request is ready before putting > > it into the HW queues -- i.e. the number chain of fences with everything > > that entails about ensuring it runs to completion [whether successfully > > or not, if not we then rely on the error propagation to limit the damage > > and report it back to the user if they kept a fence around to inspect]. > > Okay but what is the benefit of N contexts in this series, before the > work is actually spread over ctx async width CPUs? Is there any? If not > I would prefer this patch is delayed until the time some actual > parallelism is ready to be added. > >>> > >>> We currently submit an unbounded amount of work. This patch is added > >>> along with its user to restrict the amount of work allowed to run in > >>> parallel, and also is used to [crudely] serialise the multiple threads > >>> attempting to allocate space in the vm when we completely exhaust that > >>> address space. We need at least one fence-context id for each user, this > >>> took the opportunity to generalise that to N ids for each user. > >> > >> Right, this is what I asked at the beginning - restricting amount of > >> work run in parallel - does mean there is some "blocking"/serialisation > >> during execbuf? Or it is all async but then what is restricted? > > > > It's all* async, so the number of workqueues we utilise is restricted, > > and so limits the number of CPUs we allow the one context to spread > > across with multiple execbufs. > > > > *fsvo all. > > Okay. > > Related topic - have we ever thought about what happens when fence > context id wraps? I know it's 64-bit, and even with this patch giving > out num_cpus blocks, it still feels impossible that it would wrap in > normal use. But I wonder if malicious client could create/destroy > contexts to cause a wrap and then how well we handle it. I am probably > just underestimating today how big 64-bit is and how many ioctls that > would require.. I've had cold sweats. We will get silent glitches. I *don't* think we will corrupt kernel data and oops, but we will corrupt user data. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/20] drm/i915/gem: Separate the ww_mutex walker into its own list
Quoting Tvrtko Ursulin (2020-07-13 15:53:56) > > On 06/07/2020 07:19, Chris Wilson wrote: > Just a temporary stage... are we reviewing those? Best if they can be > avoided. Yes, I am not chuffed in having it. But with the transition from using an array of execobj[] to having a list that includes the supplementary objects, the inplace swap() now breaks the lists. We would have to do a bunch of list_replace() to preserve them. At the moment, I think this is the lessor of evils, although it is quite hideous. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftest: Fix an error code in live_noa_gpr()
The error code is not set on this error path. It's either zero or
uninitialized at this point.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index deb6dec1b5ab..7aa73bb03381 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -329,6 +329,7 @@ static int live_noa_gpr(void *arg)
cs = intel_ring_begin(rq, 2 * 32 + 2);
if (IS_ERR(cs)) {
i915_request_add(rq);
+ err = PTR_ERR(cs);
goto out_rq;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftest: Fix an error code in live_noa_gpr()
On 14/07/2020 17:12, Dan Carpenter wrote:
The error code is not set on this error path. It's either zero or
uninitialized at this point.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index deb6dec1b5ab..7aa73bb03381 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -329,6 +329,7 @@ static int live_noa_gpr(void *arg)
cs = intel_ring_begin(rq, 2 * 32 + 2);
if (IS_ERR(cs)) {
i915_request_add(rq);
+ err = PTR_ERR(cs);
goto out_rq;
}
Looks like there is another below :
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
i915_request_add(rq);
goto out_rq;
}
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Trace placement of timeline HWSP
== Series Details ==
Series: drm/i915/gt: Trace placement of timeline HWSP
URL : https://patchwork.freedesktop.org/series/79477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18158
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/index.html
Known issues
Here are the changes found in Patchwork_18158 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [FAIL][7] ([i915#579]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-cml-s: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
- fi-tgl-u2: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@vgem_basic@unload:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@vgem_ba...@unload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-tgl-y/igt@vgem_ba...@unload.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2175]: https://gitlab.freedesktop.org/drm/intel/issues/2175
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#579]: https://gitlab.freedeskt
Re: [Intel-gfx] [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote: > Am 14.07.20 um 12:49 schrieb Daniel Vetter: > > On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote: > > > My dma-fence lockdep annotations caught an inversion because we > > > allocate memory where we really shouldn't: > > > > > > kmem_cache_alloc+0x2b/0x6d0 > > > amdgpu_fence_emit+0x30/0x330 [amdgpu] > > > amdgpu_ib_schedule+0x306/0x550 [amdgpu] > > > amdgpu_job_run+0x10f/0x260 [amdgpu] > > > drm_sched_main+0x1b9/0x490 [gpu_sched] > > > kthread+0x12e/0x150 > > > > > > Trouble right now is that lockdep only validates against GFP_FS, which > > > would be good enough for shrinkers. But for mmu_notifiers we actually > > > need !GFP_ATOMIC, since they can be called from any page laundering, > > > even if GFP_NOFS or GFP_NOIO are set. > > > > > > I guess we should improve the lockdep annotations for > > > fs_reclaim_acquire/release. > > > > > > Ofc real fix is to properly preallocate this fence and stuff it into > > > the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of > > > the way. > > > > > > v2: Two more allocations in scheduler paths. > > > > > > Frist one: > > > > > > __kmalloc+0x58/0x720 > > > amdgpu_vmid_grab+0x100/0xca0 [amdgpu] > > > amdgpu_job_dependency+0xf9/0x120 [amdgpu] > > > drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] > > > drm_sched_main+0xf9/0x490 [gpu_sched] > > > > > > Second one: > > > > > > kmem_cache_alloc+0x2b/0x6d0 > > > amdgpu_sync_fence+0x7e/0x110 [amdgpu] > > > amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] > > > amdgpu_job_dependency+0xf9/0x120 [amdgpu] > > > drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] > > > drm_sched_main+0xf9/0x490 [gpu_sched] > > > > > > Cc: linux-me...@vger.kernel.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Cc: linux-r...@vger.kernel.org > > > Cc: amd-...@lists.freedesktop.org > > > Cc: intel-gfx@lists.freedesktop.org > > > Cc: Chris Wilson > > > Cc: Maarten Lankhorst > > > Cc: Christian König > > > Signed-off-by: Daniel Vetter > > Has anyone from amd side started looking into how to fix this properly? > > Yeah I checked both and neither are any real problem. I'm confused ... do you mean "no real problem fixing them" or "not actually a real problem"? > > I looked a bit into fixing this with mempool, and the big guarantee we > > need is that > > - there's a hard upper limit on how many allocations we minimally need to > >guarantee forward progress. And the entire vmid allocation and > >amdgpu_sync_fence stuff kinda makes me question that's a valid > >assumption. > > We do have hard upper limits for those. > > The VMID allocation could as well just return the fence instead of putting > it into the sync object IIRC. So that just needs some cleanup and can avoid > the allocation entirely. Yeah embedding should be simplest solution of all. > The hardware fence is limited by the number of submissions we can have > concurrently on the ring buffers, so also not a problem at all. Ok that sounds good. Wrt releasing the memory again, is that also done without any of the allocation-side locks held? I've seen some vmid manager somewhere ... -Daniel > > Regards, > Christian. > > > > > - mempool_free must be called without any locks in the way which are held > >while we call mempool_alloc. Otherwise we again have a nice deadlock > >with no forward progress. I tried auditing that, but got lost in amdgpu > >and scheduler code. Some lockdep annotations for mempool.c might help, > >but they're not going to catch everything. Plus it would be again manual > >annotations because this is yet another cross-release issue. So not sure > >that helps at all. > > > > iow, not sure what to do here. Ideas? > > > > Cheers, Daniel > > > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- > > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > > index 8d84975885cd..a089a827fdfe 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c > > > @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, > > > struct dma_fence **f, > > > uint32_t seq; > > > int r; > > > - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); > > > + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); > > > if (fence == NULL) > > > return -ENOMEM; > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > > > index 267fa45ddb66..a333ca2d4ddd 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > > > @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_
Re: [Intel-gfx] [PATCH] drm/i915/selftest: Fix an error code in live_noa_gpr()
On Tue, Jul 14, 2020 at 05:16:33PM +0300, Lionel Landwerlin wrote:
> On 14/07/2020 17:12, Dan Carpenter wrote:
> > The error code is not set on this error path. It's either zero or
> > uninitialized at this point.
> >
> > Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
> > noa_wait")
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
> > b/drivers/gpu/drm/i915/selftests/i915_perf.c
> > index deb6dec1b5ab..7aa73bb03381 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
> > @@ -329,6 +329,7 @@ static int live_noa_gpr(void *arg)
> > cs = intel_ring_begin(rq, 2 * 32 + 2);
> > if (IS_ERR(cs)) {
> > i915_request_add(rq);
> > + err = PTR_ERR(cs);
> > goto out_rq;
> > }
>
> Looks like there is another below :
>
> cs = intel_ring_begin(rq, 4);
> if (IS_ERR(cs)) {
> i915_request_add(rq);
> goto out_rq;
> }
Oh... Hm... I'm looking at linux-next now and you're right. Also
Colin already fixed the return that I fixed. I'll resend.
regards,
dan carpenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 33/60] drm/i915/lmem: support pwrite
On 13/07/2020 06:09, Dave Airlie wrote: On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote: We need to add support for pwrite'ing an LMEM object. why? DG1 is a discrete GPU, these interfaces we already gross and overly hacky for integrated, I'd prefer not to drag them across into discrete land. same goes for pread. You have no legacy userspace here, userspace needs change to support LMEM, it can be fixed to avoid legacy ioctls paths. Ok, there have also been similar discussions internally in the past. I think one of the reasons was around IGT, and how keeping the pread/pwrite interface meant slightly less pain, also it's not much effort to implement for LMEM. If this is a NACK, then I guess the other idea was to somehow fallback to mmap and update IGT accordingly. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftest: Fix an error code in live_noa_gpr()
The error code needs to be set on this path. It currently returns
success.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Reported-by: Lionel Landwerlin
Signed-off-by: Dan Carpenter
---
v2: Fix a different bug instead. :P Colin fixed mine already.
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index 0aa151501fb3..c232194c60a2 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -358,6 +358,7 @@ static int live_noa_gpr(void *arg)
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
i915_request_add(rq);
+ err = PTR_ERR(cs);
goto out_rq;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/selftest: Fix an error code in live_noa_gpr()
On 14/07/2020 17:36, Dan Carpenter wrote:
The error code needs to be set on this path. It currently returns
success.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Reported-by: Lionel Landwerlin
Signed-off-by: Dan Carpenter
---
v2: Fix a different bug instead. :P Colin fixed mine already.
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index 0aa151501fb3..c232194c60a2 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -358,6 +358,7 @@ static int live_noa_gpr(void *arg)
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
i915_request_add(rq);
+ err = PTR_ERR(cs);
goto out_rq;
}
Reviewed-by: Lionel Landwerlin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v2.
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/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/gpu/drm/i915/gt/selftest_rps.c| 30 --
drivers/gpu/drm/i915/selftests/i915_request.c | 18 +---
4 files changed, 75 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index dcdfc396f2f8..7049a6bbc03d 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -201,25 +201,25 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
- i915_gem_object_unlock(ctx->obj);
if (err)
- return err;
+ goto out_unlock;
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unlock;
+ }
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto out_unpin;
}
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
- i915_request_add(rq);
- i915_vma_unpin(vma);
- return PTR_ERR(cs);
+ err = PTR_ERR(cs);
+ goto out_rq;
}
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -240,14 +240,16 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
}
intel_ring_advance(rq, cs);
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- i915_vma_unpin(vma);
+out_rq:
i915_request_add(rq);
+out_unpin:
+ i915_vma_unpin(vma);
+out_unlock:
+ i915_gem_object_unlock(ctx->obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 9fb95a45bcad..d27d87a678c8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -528,31 +528,42 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(obj, &ww);
+ if (!err)
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
if (err)
- return err;
+ goto err;
rq = intel_engine_create_kernel_request(engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq,
EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
i915_request_add(rq);
+err_unpin:
i915_vma_unpin(vma);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
if (err)
return err;
}
@@ -1123,6 +1134,7 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
vma = i915_vma_instance(obj, engine->kernel_context->vm, NULL);
if (IS_ERR(vma)) {
@@ -1130,9 +1142,13 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest: Fix an error code in live_noa_gpr()
== Series Details == Series: drm/i915/selftest: Fix an error code in live_noa_gpr() URL : https://patchwork.freedesktop.org/series/79478/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18159 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/index.html Known issues Here are the changes found in Patchwork_18159 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-byt-j1900/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-byt-j1900/igt@i915_module_l...@reload.html * igt@vgem_basic@debugfs: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@vgem_ba...@debugfs.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-tgl-y/igt@vgem_ba...@debugfs.html Possible fixes * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][11] ([i915#579]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html - fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18159/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][26] ([i915#62] / [i915#92]) +2 similar issues [25]: ht
Re: [Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
Hi,
On 07/14, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
> >
> > On 07/12, Rodrigo Siqueira wrote:
> > > Hi,
> > >
> > > Everything looks fine to me, I just noticed that the amdgpu patches did
> > > not apply smoothly, however it was trivial to fix the issues.
> > >
> > > Reviewed-by: Rodrigo Siqueira
> > >
> > > Melissa,
> > > Since you are using vkms regularly, could you test this patch and review
> > > it? Remember to add your Tested-by when you finish.
> > >
> > Hi,
> >
> > I've applied the patch series, ran some tests on vkms, and found no
> > issues. I mean, things have remained stable.
> >
> > Tested-by: Melissa Wen
>
> Did you test with CONFIG_PROVE_LOCKING enabled in the kernel .config?
> Without that enabled, there's not really any change here, but with
> that enabled there might be some lockdep splats in dmesg indicating a
> problem.
>
Even with the lock debugging config enabled, no new issue arose in dmesg
during my tests using vkms.
Melissa
> Thanks, Daniel
> >
> > > Thanks
> > >
> > > On 07/07, Daniel Vetter wrote:
> > > > This is needed to signal the fences from page flips, annotate it
> > > > accordingly. We need to annotate entire timer callback since if we get
> > > > stuck anywhere in there, then the timer stops, and hence fences stop.
> > > > Just annotating the top part that does the vblank handling isn't
> > > > enough.
> > > >
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: linaro-mm-...@lists.linaro.org
> > > > Cc: linux-r...@vger.kernel.org
> > > > Cc: amd-...@lists.freedesktop.org
> > > > Cc: intel-gfx@lists.freedesktop.org
> > > > Cc: Chris Wilson
> > > > Cc: Maarten Lankhorst
> > > > Cc: Christian König
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Rodrigo Siqueira
> > > > Cc: Haneen Mohammed
> > > > Cc: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > index ac85e17428f8..a53a40848a72 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > @@ -1,5 +1,7 @@
> > > > // SPDX-License-Identifier: GPL-2.0+
> > > >
> > > > +#include
> > > > +
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -14,7 +16,9 @@ static enum hrtimer_restart
> > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > struct drm_crtc *crtc = &output->crtc;
> > > > struct vkms_crtc_state *state;
> > > > u64 ret_overrun;
> > > > - bool ret;
> > > > + bool ret, fence_cookie;
> > > > +
> > > > + fence_cookie = dma_fence_begin_signalling();
> > > >
> > > > ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> > > > output->period_ns);
> > > > @@ -49,6 +53,8 @@ static enum hrtimer_restart
> > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > DRM_DEBUG_DRIVER("Composer worker already
> > > > queued\n");
> > > > }
> > > >
> > > > + dma_fence_end_signalling(fence_cookie);
> > > > +
> > > > return HRTIMER_RESTART;
> > > > }
> > > >
> > > > --
> > > > 2.27.0
> > > >
> > >
> > > --
> > > Rodrigo Siqueira
> > > https://siqueira.tech
> >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
On Thu, Jul 9, 2020 at 8:48 AM Hans de Goede wrote:
>
> Hi,
>
> On 7/8/20 11:25 PM, Alex Deucher wrote:
> > On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
> >>
> >> Hi All,
> >>
> >> Here is the privacy-screen related code which we discussed a while ago.
> >> This series consists of a number of different parts:
> >>
> >> 1. A new version of Rajat's privacy-screen connector properties patch,
> >> this adds new userspace API in the form of new properties
> >>
> >> 2. Since on most devices the privacy screen is actually controlled by
> >> some vendor specific ACPI/WMI interface which has a driver under
> >> drivers/platform/x86, we need some "glue" code to make this functionality
> >> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
> >> this, which allows non KMS drivers (and possibly KMS drivers too) to
> >> register a privacy-screen device and also adds an interface for KMS drivers
> >> to get access to the privacy-screen associated with a specific connector.
> >> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> >> kernel, including separate includes for consumers and providers(drivers).
> >>
> >> 3. Some drm_connector helper functions to keep the actual changes needed
> >> for this in individual KMS drivers as small as possible (patch 6).
> >>
> >> 4. Make the thinkpad_acpi code register a privacy-screen device on
> >> ThinkPads with a privacy-screen (patches 7-8)
> >>
> >> 5. Make the i915 driver export the privacy-screen functionality through
> >> the connector properties on the eDP connector.
> >
> > Care to create a patch 10 for amdgpu? Lenovo sells AMD thinkpads with
> > a privacy screen as well, presumably it works
> > the same way.
>
> Yes the AMD based Thinkpads should work the same way.
>
> We will need similar changes for amdgpu and very likely also for
> nouveau. The problem is I don't really have hw to test this.
>
> Do you have access to a recent thinkpad with amdgpu ? It does not need
> to have a privacy screen, as long as it is new enough that the ACPI
> tables have the GSSS and methods you can test by ignoring
> the presence bit for the privacy-screen, I use this little change for
> that:
Thanks for the hints Hans. If I can find some time, I will give it a try.
Alex
>
> From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
> From: Hans de Goede
> Date: Wed, 27 May 2020 14:38:42 +0200
> Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
> on devices without a privacy-screen
>
> Hack to allow testing on devices without a privacy-screen.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/drm_privacy_screen_x86.c | 4
> drivers/platform/x86/thinkpad_acpi.c | 4 ++--
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
> b/drivers/gpu/drm/drm_privacy_screen_x86.c
> index f486d9087819..87725766a90d 100644
> --- a/drivers/gpu/drm/drm_privacy_screen_x86.c
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
> if (ACPI_FAILURE(status))
> return false;
>
> +#if 1
> + return true;
> +#else
> return (output & 0x1) ? true : false;
> +#endif
> }
>
> static const struct arch_init_data arch_init_data[] __initconst = {
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index 1583c18f7f77..92aad746d1f8 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct
> *iibm)
> if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
> return -EIO;
>
> - if (!(output & 0x1))
> - return 0;
> +// if (!(output & 0x1))
> +// return 0;
>
> lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
> &lcdshadow_ops);
> --
> 2.26.2
>
>
> So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
> then you should be able to implement this yourself. You can read/write the new
> props under X11 with xrandr. And you monitor if the changes make it to the
> hardware by doing:
>
> cat /proc/acpi/ibm/lcdshadow
>
> And you can simulate external changes (like through a hotkey handled by the
> embedded-controller) by doing:
>
> echo 0 > /proc/acpi/ibm/lcdshadow
> echo 1 > /proc/acpi/ibm/lcdshadow
>
> When you do this you should see udev change events for the properties, you
> can test for those by doing:
>
> sudo udevadm monitor -u -p
>
> ###
>
> With all that said, I can take a shot at blindly implementing this for amdgpu
> but I would greatly prefer an actually tested patch, even if it is tested in
> the way described above. When the patch is ready you can just send it to me
> and I'll add my s-o-b and add it as patch
Re: [Intel-gfx] [RFC 53/60] drm/i915: Create stolen memory region from local memory
On 13/07/2020 05:48, Dave Airlie wrote: On Fri, 10 Jul 2020 at 22:01, Matthew Auld wrote: From: CQ Tang Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. The memory region is marked with "is_devmem=true". So is stolen fake on LMEM devices? The concept of stolen doesn't seem to make much sense with VRAM, so please enlighten me. CQ, do we actually need an explicit stolen LMEM region? The idea of having a DSM like stolen region for LMEM does sound strange(outside of the usual reserved portions which are for HW use etc), since the driver has complete control over LMEM. Is it just a convenience thing to keep things working as-is for fbc, initial fb, etc. or is there more to it? There is buddy_alloc_range() for LMEM which we could potentially use to wrap an object around for things like the initial fb or similar. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Assert the kernel context is using the HWSP
== Series Details == Series: drm/i915/gt: Assert the kernel context is using the HWSP URL : https://patchwork.freedesktop.org/series/79469/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744_full -> Patchwork_18156_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_18156_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18156_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18156_full: ### IGT changes ### Warnings * igt@i915_selftest@mock@requests: - shard-kbl: [INCOMPLETE][1] ([i915#2110]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-kbl3/igt@i915_selftest@m...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-kbl6/igt@i915_selftest@m...@requests.html - shard-tglb: [INCOMPLETE][3] ([i915#2110]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-tglb6/igt@i915_selftest@m...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-tglb3/igt@i915_selftest@m...@requests.html - shard-iclb: [INCOMPLETE][5] ([i915#2110]) -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-iclb7/igt@i915_selftest@m...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-iclb5/igt@i915_selftest@m...@requests.html - shard-hsw: [INCOMPLETE][7] ([i915#2110]) -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-hsw4/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-hsw4/igt@i915_selftest@m...@requests.html Known issues Here are the changes found in Patchwork_18156_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2079]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-kbl1/igt@gem_exec_balan...@bonded-early.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-kbl2/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_whisper@basic-contexts: - shard-iclb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-iclb1/igt@gem_exec_whis...@basic-contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-iclb2/igt@gem_exec_whis...@basic-contexts.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk1/igt@gem_exec_whis...@basic-queues-priority.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-glk6/igt@gem_exec_whis...@basic-queues-priority.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-hsw: [PASS][15] -> [WARN][16] ([i915#1519]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-hsw7/igt@i915_pm_rc6_reside...@rc6-idle.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_selftest@mock@requests: - shard-glk: [PASS][17] -> [INCOMPLETE][18] ([i915#58] / [k.org#198133]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk3/igt@i915_selftest@m...@requests.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-glk3/igt@i915_selftest@m...@requests.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#198]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-skl9/igt@i915_selftest@m...@requests.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-skl5/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][21] -> [DMESG-FAIL][22] ([i915#118] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk4/igt@kms_big...@linear-64bpp-rotate-0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +12 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18156/shard-skl2/igt@kms_co...@pipe-b-ctm-negative.html * ig
Re: [Intel-gfx] [PATCH 12/20] drm/i915/gem: Asynchronous GTT unbinding
Quoting Tvrtko Ursulin (2020-07-14 10:02:35)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> > It is reasonably common for userspace (even modern drivers like iris) to
> > reuse an active address for a new buffer. This would cause the
> > application to stall under its mutex (originally struct_mutex) until the
> > old batches were idle and it could synchronously remove the stale PTE.
> > However, we can queue up a job that waits on the signal for the old
> > nodes to complete and upon those signals, remove the old nodes replacing
> > them with the new ones for the batch. This is still CPU driven, but in
> > theory we can do the GTT patching from the GPU. The job itself has a
> > completion signal allowing the execbuf to wait upon the rebinding, and
> > also other observers to coordinate with the common VM activity.
> >
> > Letting userspace queue up more work, lets it do more stuff without
> > blocking other clients. In turn, we take care not to let it too much
> > concurrent work, creating a small number of queues for each context to
> > limit the number of concurrent tasks.
>
> This is a monster patch.. what is the end result here? If there are a
> few conflicts they can go async, but if more than "concurrency width"
> need evict then it will be synchronous?
No, if userspace gets far ahead of the binder, the tasks join the queue,
and userspace continues on to complete the submission [without blocking,
for as much as is possible, the waits I have not yet killed should only
be hit if userspace exhausts the entire GTT for itself]. The throttling
for userspace is indeeded to be on acquiring the timeline->mutex and
checking for sufficient ring space, so right at the very start where we
have the O_NONBLOCK check.
> Could you do without this patch for the first implementation? Or come up
> with ideas to split it up and so make understanding and review manageable?
Challenging. The task is to hold vm->mutex for all the i915_vma_pin(),
which entails breaking i915_vma_pin() into its steps [those before /
during / after vm->mutex]
The intention is really to use the lessons learnt here to generalise it
again.
> > +static int best_hole(struct drm_mm *mm, struct drm_mm_node *node,
> > + u64 start, u64 end, u64 align)
> > +{
> > + struct drm_mm_node *hole;
> > + u64 size = node->size;
> > +
> > + do {
> > + hole = __best_hole(mm, size);
> > + if (!hole)
> > + return -ENOSPC;
> > +
> > + node->start = round_up(max(start,
> > drm_mm_hole_node_start(hole)),
> > +align);
> > + if (min(drm_mm_hole_node_end(hole), end) >=
> > + node->start + node->size)
> > + return drm_mm_reserve_node(mm, node);
> > +
> > + /*
> > + * Too expensive to search for every single hole every time,
> > + * so just look for the next bigger hole, introducing enough
> > + * space for alignments. Finding the smallest hole with ideal
> > + * alignment scales very poorly, so we choose to waste space
> > + * if an alignment is forced. On the other hand, simply
> > + * randomly selecting an offset in 48b space will cause us
> > + * to use the majority of that space and exhaust all memory
> > + * in storing the page directories. Compromise is required.
> > + */
> > + size = hole->hole_size + align;
> > + } while (1);
> > +}
>
> evict_for_* and all above, feels like it is too much for
> i915_gem_execbuffer.c. How about that goes to i915_gem_evict.c? Apart
> from it depending on eb_vm_work..
Right. It's also a question of whether this should work as a part of the
vm (gt/intel_gtt*) or as part of the user rules above that (gem/foo*)
At the moment, execbuf should be the *only* place that cares about
multiple PIN_USER and the risk of eviction interlocks.
> Best hole at least operates solely on drm_mm so should go out,
> presumably in preparation for moving into drm core.
Yikes. The algorithm is very wasteful and doesn't do a good job of
picking a good candidate, I wouldn't suggest this is suitable for wide
use. It's just less bad than randomly picking (and so spreading evenly)
over 48b. There was an attempt to do a fast drm_mm alignment search, but
has not yet yielded something we can use. So for the time being a hack
to avoid the O(N^2).
> Hm, i915_gem_eb_vm.c for most of the rest?
It's currently 25% of i915_gem_execbuffer.c, ~1000 / 3750 lines, for the
entire chunk of eb_reserve_vm. About 500 for the search/evict/bind code
itself. A sizeable chunk, just not sure where it really belongs. I do
agree that it doesn't really belong here, in one huge file.
> > +static void eb_vma_work_release(struct dma_fence_work *base)
> > +{
> > + struct eb_vm_work *work = container_of(base, typeof(*work), base);
> > +
> > + __eb_bind_vma(work
Re: [Intel-gfx] [PATCH v4 1/5] drm/i915: Add enable/disable flip done and flip done handler
Hi Karthik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next v5.8-rc5 next-20200713]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Karthik-B-S/Asynchronous-flip-implementation-for-i915/20200714-095304
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a002-20200714 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_irq.c:700:5: error: no previous prototype for
>> 'g4x_get_flip_counter' [-Werror=missing-prototypes]
700 | u32 g4x_get_flip_counter(struct drm_crtc *crtc)
| ^~~~
cc1: all warnings being treated as errors
vim +/g4x_get_flip_counter +700 drivers/gpu/drm/i915/i915_irq.c
699
> 700 u32 g4x_get_flip_counter(struct drm_crtc *crtc)
701 {
702 struct drm_i915_private *dev_priv = to_i915(crtc->dev);
703 enum pipe pipe = to_intel_crtc(crtc)->pipe;
704
705 return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
706 }
707
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest: Fix an error code in live_noa_gpr() (rev2)
== Series Details == Series: drm/i915/selftest: Fix an error code in live_noa_gpr() (rev2) URL : https://patchwork.freedesktop.org/series/79478/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18160 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/index.html Known issues Here are the changes found in Patchwork_18160 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_ctx_cre...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-tgl-y/igt@gem_ctx_cre...@basic.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html Possible fixes * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-whl-u: [DMESG-WARN][7] ([i915#95]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][11] ([i915#579]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html - fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18160/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +3
Re: [Intel-gfx] [PATCH 13/20] drm/i915/gem: Bind the fence async for execbuf
Quoting Tvrtko Ursulin (2020-07-14 13:19:22)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> > It is illegal to wait on an another vma while holding the vm->mutex, as
> > that easily leads to ABBA deadlocks (we wait on a second vma that waits
> > on us to release the vm->mutex). So while the vm->mutex exists, move the
> > waiting outside of the lock into the async binding pipeline.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 137 +-
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 5 +
> > 3 files changed, 151 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 6a406e8798ef..c14c3b7e0dfd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -1056,15 +1056,6 @@ static int eb_reserve_vma(struct eb_vm_work *work,
> > struct eb_bind_vma *bind)
> > return err;
> >
> > pin:
> > - if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
> > - err = __i915_vma_pin_fence(vma); /* XXX no waiting */
> > - if (unlikely(err))
> > - return err;
> > -
> > - if (vma->fence)
> > - bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
> > - }
> > -
> > bind_flags &= ~atomic_read(&vma->flags);
> > if (bind_flags) {
> > err = set_bind_fence(vma, work);
> > @@ -1095,6 +1086,15 @@ static int eb_reserve_vma(struct eb_vm_work *work,
> > struct eb_bind_vma *bind)
> > bind->ev->flags |= __EXEC_OBJECT_HAS_PIN;
> > GEM_BUG_ON(eb_vma_misplaced(entry, vma, bind->ev->flags));
> >
> > + if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
> > + err = __i915_vma_pin_fence_async(vma, &work->base);
> > + if (unlikely(err))
> > + return err;
> > +
> > + if (vma->fence)
> > + bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
> > + }
> > +
> > return 0;
> > }
> >
> > @@ -1160,6 +1160,9 @@ static void __eb_bind_vma(struct eb_vm_work *work)
> > struct eb_bind_vma *bind = &work->bind[n];
> > struct i915_vma *vma = bind->ev->vma;
> >
> > + if (bind->ev->flags & __EXEC_OBJECT_HAS_FENCE)
> > + __i915_vma_apply_fence_async(vma);
> > +
> > if (!bind->bind_flags)
> > goto put;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > index 7fb36b12fe7a..734b6aa61809 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > @@ -21,10 +21,13 @@
> >* IN THE SOFTWARE.
> >*/
> >
> > +#include "i915_active.h"
> > #include "i915_drv.h"
> > #include "i915_scatterlist.h"
> > +#include "i915_sw_fence_work.h"
> > #include "i915_pvinfo.h"
> > #include "i915_vgpu.h"
> > +#include "i915_vma.h"
> >
> > /**
> >* DOC: fence register handling
> > @@ -340,19 +343,37 @@ static struct i915_fence_reg *fence_find(struct
> > i915_ggtt *ggtt)
> > return ERR_PTR(-EDEADLK);
> > }
> >
> > +static int fence_wait_bind(struct i915_fence_reg *reg)
> > +{
> > + struct dma_fence *fence;
> > + int err = 0;
> > +
> > + fence = i915_active_fence_get(®->active.excl);
> > + if (fence) {
> > + err = dma_fence_wait(fence, true);
> > + dma_fence_put(fence);
> > + }
> > +
> > + return err;
> > +}
> > +
> > int __i915_vma_pin_fence(struct i915_vma *vma)
> > {
> > struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
> > - struct i915_fence_reg *fence;
> > + struct i915_fence_reg *fence = vma->fence;
> > struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma :
> > NULL;
> > int err;
> >
> > lockdep_assert_held(&vma->vm->mutex);
> >
> > /* Just update our place in the LRU if our fence is getting reused. */
> > - if (vma->fence) {
> > - fence = vma->fence;
> > + if (fence) {
> > GEM_BUG_ON(fence->vma != vma);
> > +
> > + err = fence_wait_bind(fence);
> > + if (err)
> > + return err;
> > +
> > atomic_inc(&fence->pin_count);
> > if (!fence->dirty) {
> > list_move_tail(&fence->link, &ggtt->fence_list);
> > @@ -384,6 +405,116 @@ int __i915_vma_pin_fence(struct i915_vma *vma)
> > return err;
> > }
> >
> > +static int set_bind_fence(struct i915_fence_reg *fence,
> > + struct dma_fence_work *work)
> > +{
> > + struct dma_fence *prev;
> > + int err;
> > +
> > + if (rcu_access_pointer(fence->active.excl.fence) == &work->dma)
> > +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev2)
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev2)
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6a326d9f8985 Revert "drm/i915/gem: Async GPU relocations only"
-:113: WARNING:MEMORY_BARRIER: memory barrier without comment
#113: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1109:
+ mb();
-:161: WARNING:MEMORY_BARRIER: memory barrier without comment
#161: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1157:
+ mb();
-:181: CHECK:SPACING: No space is necessary after a cast
#181: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1177:
+ io_mapping_unmap_atomic((void __force __iomem *)
unmask_page(cache->vaddr));
-:260: WARNING:MEMORY_BARRIER: memory barrier without comment
#260: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1256:
+ mb();
-:274: CHECK:BRACES: Unbalanced braces around else statement
#274: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1270:
+ } else
total: 0 errors, 3 warnings, 2 checks, 455 lines checked
05d012e20b45 drm/i915: Revert relocation chaining commits.
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
-:221: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#221: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1313:
+ if (cache->rq_size > PAGE_SIZE/sizeof(u32) - (len + 1))
^
total: 0 errors, 1 warnings, 1 checks, 281 lines checked
a780c63bddfb Revert "drm/i915/gem: Drop relocation slowpath".
-:131: WARNING:LINE_SPACING: Missing a blank line after declarations
#131: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1705:
+ int err = __get_user(c, addr);
+ if (err)
total: 0 errors, 1 warnings, 0 checks, 320 lines checked
48113ee8a844 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:445: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#445: FILE: drivers/gpu/drm/i915/i915_gem.c:1359:
+ while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 441 lines checked
4aaec1db237b drm/i915: Remove locking from i915_gem_object_prepare_read/write
21fd5642515c drm/i915: Parse command buffer earlier in eb_relocate(slow)
cfdfd2191f9e Revert "drm/i915/gem: Split eb_vma into its own allocation"
a3f2b79bd1ce drm/i915: Use per object locking in execbuf, v12.
-:457: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#457: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1410:
+static int __reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:477: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#477: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1483:
+static int reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:489: ERROR:TRAILING_WHITESPACE: trailing whitespace
#489: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1508:
+^I$
-:759: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#759: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2878:
+ eb.reloc_pool = eb.batch_pool = NULL;
total: 1 errors, 0 warnings, 3 checks, 865 lines checked
d4369286d54d drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 190 lines checked
5eda6dc5378e drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1097:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
ad64baa191f1 drm/i915: Nuke arguments to eb_pin_engine
402f556b79e3 drm/i915: Pin engine before pinning all objects, v5.
60c31ab26acd drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:338: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#338: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3483:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 434 lines checked
af579dfca323 drm/i915: Make sure execbuffer always passes ww state to
i915_vma
Re: [Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
On Tue, Jul 14, 2020 at 4:56 PM Melissa Wen wrote:
>
> Hi,
>
> On 07/14, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
> > >
> > > On 07/12, Rodrigo Siqueira wrote:
> > > > Hi,
> > > >
> > > > Everything looks fine to me, I just noticed that the amdgpu patches did
> > > > not apply smoothly, however it was trivial to fix the issues.
> > > >
> > > > Reviewed-by: Rodrigo Siqueira
> > > >
> > > > Melissa,
> > > > Since you are using vkms regularly, could you test this patch and review
> > > > it? Remember to add your Tested-by when you finish.
> > > >
> > > Hi,
> > >
> > > I've applied the patch series, ran some tests on vkms, and found no
> > > issues. I mean, things have remained stable.
> > >
> > > Tested-by: Melissa Wen
> >
> > Did you test with CONFIG_PROVE_LOCKING enabled in the kernel .config?
> > Without that enabled, there's not really any change here, but with
> > that enabled there might be some lockdep splats in dmesg indicating a
> > problem.
> >
>
> Even with the lock debugging config enabled, no new issue arose in dmesg
> during my tests using vkms.
Excellent, thanks a lot for confirming this.
-Daniel
>
> Melissa
>
> > Thanks, Daniel
> > >
> > > > Thanks
> > > >
> > > > On 07/07, Daniel Vetter wrote:
> > > > > This is needed to signal the fences from page flips, annotate it
> > > > > accordingly. We need to annotate entire timer callback since if we get
> > > > > stuck anywhere in there, then the timer stops, and hence fences stop.
> > > > > Just annotating the top part that does the vblank handling isn't
> > > > > enough.
> > > > >
> > > > > Cc: linux-me...@vger.kernel.org
> > > > > Cc: linaro-mm-...@lists.linaro.org
> > > > > Cc: linux-r...@vger.kernel.org
> > > > > Cc: amd-...@lists.freedesktop.org
> > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > Cc: Chris Wilson
> > > > > Cc: Maarten Lankhorst
> > > > > Cc: Christian König
> > > > > Signed-off-by: Daniel Vetter
> > > > > Cc: Rodrigo Siqueira
> > > > > Cc: Haneen Mohammed
> > > > > Cc: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> > > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > index ac85e17428f8..a53a40848a72 100644
> > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > @@ -1,5 +1,7 @@
> > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > >
> > > > > +#include
> > > > > +
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -14,7 +16,9 @@ static enum hrtimer_restart
> > > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > > struct drm_crtc *crtc = &output->crtc;
> > > > > struct vkms_crtc_state *state;
> > > > > u64 ret_overrun;
> > > > > - bool ret;
> > > > > + bool ret, fence_cookie;
> > > > > +
> > > > > + fence_cookie = dma_fence_begin_signalling();
> > > > >
> > > > > ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> > > > > output->period_ns);
> > > > > @@ -49,6 +53,8 @@ static enum hrtimer_restart
> > > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > > DRM_DEBUG_DRIVER("Composer worker already
> > > > > queued\n");
> > > > > }
> > > > >
> > > > > + dma_fence_end_signalling(fence_cookie);
> > > > > +
> > > > > return HRTIMER_RESTART;
> > > > > }
> > > > >
> > > > > --
> > > > > 2.27.0
> > > > >
> > > >
> > > > --
> > > > Rodrigo Siqueira
> > > > https://siqueira.tech
> > >
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev2)
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev2) URL : https://patchwork.freedesktop.org/series/79470/ 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/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Fix some whitespace
From: Ville Syrjälä Some spaces have snuck in where we want tabs. Fix it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index bb91dace304a..72095ef14426 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -2677,7 +2677,7 @@ void intel_update_cdclk(struct drm_i915_private *dev_priv) */ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) intel_de_write(dev_priv, GMBUSFREQ_VLV, - DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000)); + DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000)); } static int cnp_rawclk(struct drm_i915_private *dev_priv) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Pack struct intel_cdclk_vals
From: Ville Syrjälä
There's a pointless hole in struct intel_cdclk_vals, get rid of it.
Fortunately we already use named initializers so the order does not
matter.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index 5731806e4cee..6b31fde4be16 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -17,8 +17,8 @@ struct intel_atomic_state;
struct intel_crtc_state;
struct intel_cdclk_vals {
- u16 refclk;
u32 cdclk;
+ u16 refclk;
u8 divider; /* CD2X divider * 2 */
u8 ratio;
};
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Nuke force_min_cdclk_changed
From: Ville Syrjälä
Since we now have proper old and new cdclk state we no longer
need to keep this flag to indicate that the force min cdclk has
changed. Instead just check if the old vs. new value are different.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_audio.c | 5 -
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
drivers/gpu/drm/i915/display/intel_cdclk.h | 1 -
drivers/gpu/drm/i915/display/intel_display.c | 7 +--
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index ad4aa66fd676..f7de55707746 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -958,13 +958,8 @@ static int glk_force_audio_cdclk_commit(struct
intel_atomic_state *state,
if (IS_ERR(cdclk_state))
return PTR_ERR(cdclk_state);
- cdclk_state->force_min_cdclk_changed = true;
cdclk_state->force_min_cdclk = enable ? 2 * 96000 : 0;
- ret = intel_atomic_lock_global_state(&cdclk_state->base);
- if (ret)
- return ret;
-
return drm_atomic_commit(&state->base);
}
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 9d6cacbdb691..268a7211dd6c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2426,7 +2426,6 @@ static struct intel_global_state
*intel_cdclk_duplicate_state(struct intel_globa
if (!cdclk_state)
return NULL;
- cdclk_state->force_min_cdclk_changed = false;
cdclk_state->pipe = INVALID_PIPE;
return &cdclk_state->base;
@@ -2501,6 +2500,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
if (ret)
return ret;
} else if (old_cdclk_state->active_pipes !=
new_cdclk_state->active_pipes ||
+ old_cdclk_state->force_min_cdclk !=
new_cdclk_state->force_min_cdclk ||
intel_cdclk_changed(&old_cdclk_state->logical,
&new_cdclk_state->logical)) {
ret = intel_atomic_lock_global_state(&new_cdclk_state->base);
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index 6b31fde4be16..b34eb00fb327 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -49,7 +49,6 @@ struct intel_cdclk_state {
/* forced minimum cdclk for glk+ audio w/a */
int force_min_cdclk;
- bool force_min_cdclk_changed;
/* bitmask of active pipes */
u8 active_pipes;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 729ec6e0d43a..f571ded3cba8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14736,7 +14736,8 @@ static int intel_atomic_check_cdclk(struct
intel_atomic_state *state,
bool *need_cdclk_calc)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct intel_cdclk_state *new_cdclk_state;
+ const struct intel_cdclk_state *old_cdclk_state;
+ const struct intel_cdclk_state *new_cdclk_state;
struct intel_plane_state *plane_state;
struct intel_bw_state *new_bw_state;
struct intel_plane *plane;
@@ -14755,9 +14756,11 @@ static int intel_atomic_check_cdclk(struct
intel_atomic_state *state,
return ret;
}
+ old_cdclk_state = intel_atomic_get_old_cdclk_state(state);
new_cdclk_state = intel_atomic_get_new_cdclk_state(state);
- if (new_cdclk_state && new_cdclk_state->force_min_cdclk_changed)
+ if (new_cdclk_state &&
+ old_cdclk_state->force_min_cdclk !=
new_cdclk_state->force_min_cdclk)
*need_cdclk_calc = true;
ret = dev_priv->display.bw_calc_min_cdclk(state);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Make i830 .get_cdclk() assignment less confusing
From: Ville Syrjälä
Explicitly check for i830 when assigning the .get_cdclk() vfunc,
and then deal with the case of not having assigned the vfunc
separately. Less confusing, and gets rid of the checkpatch complaint
about using {} on one branch but not the others.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 72095ef14426..9d6cacbdb691 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2903,9 +2903,10 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.get_cdclk = i85x_get_cdclk;
else if (IS_I845G(dev_priv))
dev_priv->display.get_cdclk = fixed_200mhz_get_cdclk;
- else { /* 830 */
- drm_WARN(&dev_priv->drm, !IS_I830(dev_priv),
-"Unknown platform. Assuming 133 MHz CDCLK\n");
+ else if (IS_I830(dev_priv))
+ dev_priv->display.get_cdclk = fixed_133mhz_get_cdclk;
+
+ if (drm_WARN(&dev_priv->drm, !dev_priv->display.get_cdclk,
+"Unknown platform. Assuming 133 MHz CDCLK\n"))
dev_priv->display.get_cdclk = fixed_133mhz_get_cdclk;
- }
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/ddi: Don't frob the DP link scramble disabling flag
According to BSpec this flag should not be changed while the DDI
function is enabled. On BDW+ the DP_TP_CTL register spec also states it
explicitly that the HW takes care of enabling/disabling the scrambling
for training patterns (and it must stay enabled for normal pixel
output). Assume that this HW automatic handling of scrambling is also
true for HSW.
BSpec: 8013, 7557, 50484
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2c484b55bcdf..c467f18d5e1b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4037,8 +4037,7 @@ static void intel_ddi_prepare_link_retrain(struct
intel_dp *intel_dp)
intel_wait_ddi_buf_idle(dev_priv, port);
}
- dp_tp_ctl = DP_TP_CTL_ENABLE |
- DP_TP_CTL_LINK_TRAIN_PAT1 | DP_TP_CTL_SCRAMBLE_DISABLE;
+ dp_tp_ctl = DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_PAT1;
if (intel_dp->link_mst)
dp_tp_ctl |= DP_TP_CTL_MODE_MST;
else {
@@ -4066,11 +4065,6 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
- if (dp_train_pat & DP_LINK_SCRAMBLING_DISABLE)
- temp |= DP_TP_CTL_SCRAMBLE_DISABLE;
- else
- temp &= ~DP_TP_CTL_SCRAMBLE_DISABLE;
-
temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
switch (dp_train_pat & train_pat_mask) {
case DP_TRAINING_PATTERN_DISABLE:
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training
The driver enables the DDI function in the DDI_BUF_CTL register before
starting the link training and disables it when disabling the output. It
also gets disabled/re-enabled during link re-trainining.
Except of the above the value we program to the register (intel_dp->DP)
doesn't change, so no need to reprogram the register when changing the
link training patterns.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c467f18d5e1b..424d59671561 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4060,7 +4060,6 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
- enum port port = dp_to_dig_port(intel_dp)->base.port;
u32 temp;
temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
@@ -4085,9 +4084,6 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
}
intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, temp);
-
- intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
- intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
}
static void intel_ddi_set_idle_link_train(struct intel_dp *intel_dp)
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev2)
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev2)
URL : https://patchwork.freedesktop.org/series/79470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18161
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18161 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18161, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18161:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {fi-kbl-7560u}: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
Known issues
Here are the changes found in Patchwork_18161 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][7] -> [FAIL][8] ([i915#1888])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-s: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@vgem_ba...@setversion.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_flink_basic@basic:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [FAIL][17] ([i915#579]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18161/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-tgl-dsi
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ddi: Don't frob the DP link scramble disabling flag
On Tue, Jul 14, 2020 at 06:31:40PM +0300, Imre Deak wrote:
> According to BSpec this flag should not be changed while the DDI
> function is enabled. On BDW+ the DP_TP_CTL register spec also states it
> explicitly that the HW takes care of enabling/disabling the scrambling
> for training patterns (and it must stay enabled for normal pixel
> output). Assume that this HW automatic handling of scrambling is also
> true for HSW.
It is at least marked as debug only for hsw.
Reviewed-by: Ville Syrjälä
>
> BSpec: 8013, 7557, 50484
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2c484b55bcdf..c467f18d5e1b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4037,8 +4037,7 @@ static void intel_ddi_prepare_link_retrain(struct
> intel_dp *intel_dp)
> intel_wait_ddi_buf_idle(dev_priv, port);
> }
>
> - dp_tp_ctl = DP_TP_CTL_ENABLE |
> - DP_TP_CTL_LINK_TRAIN_PAT1 | DP_TP_CTL_SCRAMBLE_DISABLE;
> + dp_tp_ctl = DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_PAT1;
> if (intel_dp->link_mst)
> dp_tp_ctl |= DP_TP_CTL_MODE_MST;
> else {
> @@ -4066,11 +4065,6 @@ static void intel_ddi_set_link_train(struct intel_dp
> *intel_dp,
>
> temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
>
> - if (dp_train_pat & DP_LINK_SCRAMBLING_DISABLE)
> - temp |= DP_TP_CTL_SCRAMBLE_DISABLE;
> - else
> - temp &= ~DP_TP_CTL_SCRAMBLE_DISABLE;
> -
> temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> switch (dp_train_pat & train_pat_mask) {
> case DP_TRAINING_PATTERN_DISABLE:
> --
> 2.23.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Avoid modeset when content protection changes
From: Sean Paul
Instead of doing a full modeset to enable/disable content protection,
simply go through the update_pipe flow which was introduced in the
related patch below. This avoids flashing the screen every time the user
starts viewing protected content.
Related: 634852d1f468 ("drm/i915: HDCP state handling in ddi_update_pipe")
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 89a4d294822d..839ce1715253 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2191,7 +2191,7 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
return;
}
- crtc_state->mode_changed = true;
+ to_intel_crtc_state(crtc_state)->update_pipe = true;
}
/* Handles the CP_IRQ raised from the DP HDCP sink */
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Pack struct intel_cdclk_vals
== Series Details == Series: series starting with [1/4] drm/i915: Pack struct intel_cdclk_vals URL : https://patchwork.freedesktop.org/series/79480/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18162 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/index.html Known issues Here are the changes found in Patchwork_18162 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-bsw-n3050/igt@i915_pm_...@module-reload.html * igt@kms_force_connector_basic@force-connector-state: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_force_connector_ba...@force-connector-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-tgl-y/igt@kms_force_connector_ba...@force-connector-state.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-tgl-y/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@gem_flink_ba...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][9] ([i915#579]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_busy@ba...@flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html - fi-tgl-u2: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22] ([i915#62]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18162/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275:
Re: [Intel-gfx] [PATCH 2/2] drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training
On Tue, Jul 14, 2020 at 06:31:41PM +0300, Imre Deak wrote:
> The driver enables the DDI function in the DDI_BUF_CTL register before
> starting the link training and disables it when disabling the output. It
> also gets disabled/re-enabled during link re-trainining.
>
> Except of the above the value we program to the register (intel_dp->DP)
> doesn't change, so no need to reprogram the register when changing the
> link training patterns.
>
> Signed-off-by: Imre Deak
The only concern I had was the buf trans stuff for hsw/bdw/skl,
but looks like hsw_set_signal_levels() does everything we need.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index c467f18d5e1b..424d59671561 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4060,7 +4060,6 @@ static void intel_ddi_set_link_train(struct intel_dp
> *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> - enum port port = dp_to_dig_port(intel_dp)->base.port;
> u32 temp;
>
> temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
> @@ -4085,9 +4084,6 @@ static void intel_ddi_set_link_train(struct intel_dp
> *intel_dp,
> }
>
> intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, temp);
> -
> - intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
> - intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
> }
>
> static void intel_ddi_set_idle_link_train(struct intel_dp *intel_dp)
> --
> 2.23.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Trace placement of timeline HWSP
== Series Details == Series: drm/i915/gt: Trace placement of timeline HWSP URL : https://patchwork.freedesktop.org/series/79477/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744_full -> Patchwork_18158_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18158_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +12 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-skl9/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-skl8/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_addfb_basic@addfb25-modifier-no-flag: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / [i915#95]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-apl7/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-apl6/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk4/igt@kms_big...@linear-64bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-onscreen: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([i915#155]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][11] -> [FAIL][12] ([IGT#5]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk9/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-glk3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html * igt@kms_flip@modeset-vs-vblank-race-interruptible@b-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#407]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-glk8/igt@kms_flip@modeset-vs-vblank-race-interrupti...@b-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-glk3/igt@kms_flip@modeset-vs-vblank-race-interrupti...@b-hdmi-a2.html * igt@kms_flip@plain-flip-fb-recreate@b-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-skl8/igt@kms_flip@plain-flip-fb-recre...@b-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-skl5/igt@kms_flip@plain-flip-fb-recre...@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-kbl3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_psr@psr2_dpms: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#402]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-tglb8/igt@kms_psr@psr2_dpms.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18158/shard-tglb3/igt@kms_psr@psr2_dpms.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Pa
Re: [Intel-gfx] [PATCH 2/2] drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training
On Tue, Jul 14, 2020 at 07:08:33PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 14, 2020 at 06:31:41PM +0300, Imre Deak wrote:
> > The driver enables the DDI function in the DDI_BUF_CTL register before
> > starting the link training and disables it when disabling the output. It
> > also gets disabled/re-enabled during link re-trainining.
> >
> > Except of the above the value we program to the register (intel_dp->DP)
> > doesn't change, so no need to reprogram the register when changing the
> > link training patterns.
> >
> > Signed-off-by: Imre Deak
>
> The only concern I had was the buf trans stuff for hsw/bdw/skl,
> but looks like hsw_set_signal_levels() does everything we need.
Ok, I missed this part, will fix the commit message.
>
> Reviewed-by: Ville Syrjälä
>
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index c467f18d5e1b..424d59671561 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4060,7 +4060,6 @@ static void intel_ddi_set_link_train(struct intel_dp
> > *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> > - enum port port = dp_to_dig_port(intel_dp)->base.port;
> > u32 temp;
> >
> > temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
> > @@ -4085,9 +4084,6 @@ static void intel_ddi_set_link_train(struct intel_dp
> > *intel_dp,
> > }
> >
> > intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, temp);
> > -
> > - intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
> > - intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
> > }
> >
> > static void intel_ddi_set_idle_link_train(struct intel_dp *intel_dp)
> > --
> > 2.23.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl+: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock
Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a
problem where the PLL output frequency is slightly off with the current
PLL fractional divider value.
I haven't seen an actual case where this causes a problem, but let's
follow the spec. It's also needed on some EHL platforms, but for that we
also need a way to distinguish the affected EHL SKUs, so I leave that
for a follow-up.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 54 +--
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index aeb6ee395cce..aee9101f5e7c 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -2887,7 +2887,7 @@ static const struct icl_combo_pll_params
icl_dp_combo_pll_24MHz_values[] = {
};
-/* Also used for 38.4 MHz values. */
+/* On ICL also used for 38.4 MHz values. */
static const struct icl_combo_pll_params icl_dp_combo_pll_19_2MHz_values[] = {
{ 54,
{ .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [0]:
5.4 */
@@ -2915,6 +2915,37 @@ static const struct icl_combo_pll_params
icl_dp_combo_pll_19_2MHz_values[] = {
.pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
};
+/*
+ * Display WA #22010492432: tgl
+ * Divide the nominal .dco_fraction value by 2.
+ */
+static const struct icl_combo_pll_params tgl_dp_combo_pll_38_4MHz_values[] = {
+ { 54,
+ { .dco_integer = 0x1A5, .dco_fraction = 0x3800, /* [0]:
5.4 */
+ .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 27,
+ { .dco_integer = 0x1A5, .dco_fraction = 0x3800, /* [1]:
2.7 */
+ .pdiv = 0x2 /* 3 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 162000,
+ { .dco_integer = 0x1A5, .dco_fraction = 0x3800, /* [2]:
1.62 */
+ .pdiv = 0x4 /* 5 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 324000,
+ { .dco_integer = 0x1A5, .dco_fraction = 0x3800, /* [3]:
3.24 */
+ .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 216000,
+ { .dco_integer = 0x1C2, .dco_fraction = 0x, /* [4]:
2.16 */
+ .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 1, .qdiv_ratio = 2, },
},
+ { 432000,
+ { .dco_integer = 0x1C2, .dco_fraction = 0x, /* [5]:
4.32 */
+ .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 648000,
+ { .dco_integer = 0x1FA, .dco_fraction = 0x1000, /* [6]:
6.48 */
+ .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+ { 81,
+ { .dco_integer = 0x1A5, .dco_fraction = 0x3800, /* [7]:
8.1 */
+ .pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0, },
},
+};
+
static const struct skl_wrpll_params icl_tbt_pll_24MHz_values = {
.dco_integer = 0x151, .dco_fraction = 0x4000,
.pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0,
@@ -2950,13 +2981,26 @@ static bool icl_calc_dp_combo_pll(struct
intel_crtc_state *crtc_state,
struct skl_wrpll_params *pll_params)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
- const struct icl_combo_pll_params *params =
- dev_priv->dpll.ref_clks.nssc == 24000 ?
- icl_dp_combo_pll_24MHz_values :
- icl_dp_combo_pll_19_2MHz_values;
+ const struct icl_combo_pll_params *params;
int clock = crtc_state->port_clock;
int i;
+ switch (dev_priv->dpll.ref_clks.nssc) {
+ case 19200:
+ params = icl_dp_combo_pll_19_2MHz_values;
+ break;
+ case 24000:
+ params = icl_dp_combo_pll_24MHz_values;
+ break;
+ case 38400:
+ /* TODO: Apply WA #22010492432 on EHL too. */
+ if (IS_TIGERLAKE(dev_priv))
+ params = tgl_dp_combo_pll_38_4MHz_values;
+ else
+ params = icl_dp_combo_pll_19_2MHz_values;
+ break;
+ }
+
for (i = 0; i < ARRAY_SIZE(icl_dp_combo_pll_24MHz_values); i++) {
if (clock == params[i].clock) {
*pll_params = params[i].wrpll;
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ddi: Don't frob the DP link scramble disabling flag
== Series Details == Series: series starting with [1/2] drm/i915/ddi: Don't frob the DP link scramble disabling flag URL : https://patchwork.freedesktop.org/series/79481/ State : success == Summary == CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18163 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/index.html Known issues Here are the changes found in Patchwork_18163 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@vgem_basic@debugfs: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@vgem_ba...@debugfs.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-tgl-y/igt@vgem_ba...@debugfs.html Possible fixes * igt@i915_module_load@reload: - fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-u2/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][9] ([i915#579]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-guc/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-bsw-n3050: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-cml-s: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-cml-s/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@vgem_basic@unload: - fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-tgl-y/igt@vgem_ba...@unload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-tgl-y/igt@vgem_ba...@unload.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8744/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18163/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/display: Implement HOBL
On Mon, Jul 13, 2020 at 04:53:33PM -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 VBT and i915 will try
> to train link with HOBL vswing table if link training fails it fall
> back to the original table.
>
> intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
> instead of do something like is done in intel_ddi_dp_voltage_max()
> because it is only called after the first entry of the voltage swing
> table was loaded so the HOBL flag is valid at that point.
>
> v3:
> - removed a few parameters of icl_ddi_combo_vswing_program() that
> can be taken from encoder
>
> v4:
> - using the HOBL vswing table until training fails completely (Ville)
>
> v5:
> - not reducing lane or link rate when link training fails with HOBL
> active
> - duplicated the HOBL voltage swing entry to match DP spec requirement
>
> BSpec: 49291
> BSpec: 49399
> Cc: Ville Syrjälä
> Cc: Animesh Manna
> Cc: Manasi Navare
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 42 +++
> .../drm/i915/display/intel_display_types.h| 2 +
> .../drm/i915/display/intel_dp_link_training.c | 19 ++---
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> 4 files changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2c484b55bcdf..92ae036440fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -706,6 +706,29 @@ static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_dp_hbr2[] =
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +/*
> + * Cloned the HOBL entry to comply with the voltage and pre-emphasis entries
> + * that DisplayPort specification requires
> + */
> +static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> + /* VS pre-emp */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 00 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 01 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 02 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 03 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 10 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 11 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 12 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 20 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 21 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 30 */
We could skip the last entry since that's still legal. Dunno which is
better though.
> +};
> +
> +static bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
> +{
> + return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> +}
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> @@ -1050,6 +1073,16 @@ static const struct cnl_ddi_buf_trans *
> tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> {
> + if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (!intel_dp->hobl_failed && rate <= 54) {
> + /* Same table applies to TGL, RKL and DG1 */
> + *n_entries =
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> + }
> + }
> +
> if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
> return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
> } else if (rate > 27) {
> @@ -2392,6 +2425,15 @@ static void icl_ddi_combo_vswing_program(struct
> intel_encoder *encoder,
> level = n_entries - 1;
> }
>
> + if (type == INTEL_OUTPUT_EDP) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + val = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> + intel_dp->hobl_active = is_hobl_buf_trans(ddi_translations);
Still don't understand why we have these two booleans and this table
comparison. Why not just set the intel_dp->hobl=true intiailly
based on vbt, and clear it if and when link training fails?
> + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), val,
> + intel_dp->hobl_active ? val : 0);
> + }
> +
> /* Set PORT_TX_DW5 */
> val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
> val &= ~(SCALING_MODE_SEL
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Pack struct intel_cdclk_vals
Quoting Ville Syrjala (2020-07-14 16:26:23)
> From: Ville Syrjälä
>
> There's a pointless hole in struct intel_cdclk_vals, get rid of it.
> Fortunately we already use named initializers so the order does not
> matter.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 5731806e4cee..6b31fde4be16 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -17,8 +17,8 @@ struct intel_atomic_state;
> struct intel_crtc_state;
>
> struct intel_cdclk_vals {
> - u16 refclk;
> u32 cdclk;
> + u16 refclk;
> u8 divider; /* CD2X divider * 2 */
> u8 ratio;
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make i830 .get_cdclk() assignment less confusing
Quoting Ville Syrjala (2020-07-14 16:26:25)
> From: Ville Syrjälä
>
> Explicitly check for i830 when assigning the .get_cdclk() vfunc,
> and then deal with the case of not having assigned the vfunc
> separately. Less confusing, and gets rid of the checkpatch complaint
> about using {} on one branch but not the others.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix some whitespace
Quoting Ville Syrjala (2020-07-14 16:26:24) > From: Ville Syrjälä > > Some spaces have snuck in where we want tabs. Fix it. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c > b/drivers/gpu/drm/i915/display/intel_cdclk.c > index bb91dace304a..72095ef14426 100644 > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c > @@ -2677,7 +2677,7 @@ void intel_update_cdclk(struct drm_i915_private > *dev_priv) > */ > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) > intel_de_write(dev_priv, GMBUSFREQ_VLV, > - DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000)); > + DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000)); I appear to have a silly mua. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 53/60] drm/i915: Create stolen memory region from local memory
> -Original Message- > From: Auld, Matthew > Sent: Tuesday, July 14, 2020 8:02 AM > To: Dave Airlie > Cc: Intel Graphics Development ; Tang, CQ > ; Joonas Lahtinen ; > Abdiel Janulgue ; Wilson, Chris P > ; Balestrieri, Francesco > ; Vishwanathapura, Niranjana > ; Dhanalakota, Venkata S > ; Neel Desai ; > Brost, Matthew ; Dutt, Sudeep > ; De Marchi, Lucas > Subject: Re: [RFC 53/60] drm/i915: Create stolen memory region from local > memory > > On 13/07/2020 05:48, Dave Airlie wrote: > > On Fri, 10 Jul 2020 at 22:01, Matthew Auld > wrote: > >> > >> From: CQ Tang > >> > >> Add "REGION_STOLEN" device info to dg1, create stolen memory region > >> from upper portion of local device memory, starting from DSMBASE. > >> > >> The memory region is marked with "is_devmem=true". > > > > So is stolen fake on LMEM devices? The concept of stolen doesn't seem > > to make much sense with VRAM, so please enlighten me. > > CQ, do we actually need an explicit stolen LMEM region? The idea of having a > DSM like stolen region for LMEM does sound strange(outside of the usual > reserved portions which are for HW use etc), since the driver has complete > control over LMEM. Is it just a convenience thing to keep things working as-is > for fbc, initial fb, etc. or is there more to it? > There is buddy_alloc_range() for LMEM which we could potentially use to > wrap an object around for things like the initial fb or similar. This is a natural extension from IGT stolen memory region into DGT, we want to allocate objects from stolen area. In DGT, we have one stolen area per tile so we create one region in each of these area. Using memory region is easier to manage objects allocation and free. Other than fbc and rc6, we have gt/ring allocate stolen memory objects when without LMEM, so only apply to IGT case: display/intel_display.c:obj = i915_gem_object_create_stolen_for_preallocated(dev_priv, display/intel_fbdev.c: obj = i915_gem_object_create_stolen(dev_priv, size); display/intel_overlay.c:obj = i915_gem_object_create_stolen(i915, PAGE_SIZE); intel_rc6.c:pctx = i915_gem_object_create_stolen_for_preallocated(i915, intel_rc6.c:pctx = i915_gem_object_create_stolen(i915, pctx_size); intel_ring.c: obj = intel_gt_object_create_stolen(ggtt->vm.gt, size); intel_gt.c: obj = intel_gt_object_create_stolen(gt, size); For some reason, we don't use buddy allocator to manage the stolen memory, instead, we use drm_mm_node allocator directly, we have one-to-one mapping between drm_mm address space to dma address of the stolen memory. We also use contiguous allocation where an object always get a single contiguous block of pages. So fundamentally, we want to use the same code to work on both IGT stolen memory and DGT stolen memory. --CQ > > > > > Dave. > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid modeset when content protection changes
== Series Details ==
Series: drm/i915: Avoid modeset when content protection changes
URL : https://patchwork.freedesktop.org/series/79484/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4a5730a3aea6 drm/i915: Avoid modeset when content protection changes
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 634852d1f468 ("drm/i915: HDCP
state handling in ddi_update_pipe")'
#11:
Related: 634852d1f468 ("drm/i915: HDCP state handling in ddi_update_pipe")
total: 1 errors, 0 warnings, 0 checks, 8 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
