Re: [Intel-gfx] [PATCH 7/7] drm/i915: Engine queues query
On 19/03/18 18:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As well as exposing active requests on engines via PMU, we can also export
the current raw values (as tracked by i915 command submission) via a
dedicated query.
This is to satisfy customers who have userspace load balancing solutions
implemented on top of their custom kernel patches.
Userspace is now able to include DRM_I915_QUERY_ENGINE_QUEUES in their
query list, pointing to initialized struct drm_i915_query_engine_queues
entry. Fields describing engine class and instance userspace would like to
know about need to be filled in, and i915 will fill in the rest.
Multiple engines can be queried in one go by having multiple queries in
the query list.
Signed-off-by: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
---
drivers/gpu/drm/i915/i915_query.c | 43 +++
include/uapi/drm/i915_drm.h | 26 +++
2 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 3ace929dd90f..b3bc69e8deb7 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -82,9 +82,52 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_queues(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_queues __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_query_engine_queues query;
+ struct intel_engine_cs *engine;
+ const int len = sizeof(query);
+ unsigned int i;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -ENOSPC;
topology returns EINVAL in that case. I think ENOSPC makes more sense,
do we need to change topology?
+
+ if (copy_from_user(&query, query_ptr, len))
+ return -EFAULT;
+
+ for (i = 0; i < ARRAY_SIZE(query.rsvd); i++) {
+ if (query.rsvd[i])
+ return -EINVAL;
+ }
+
+ engine = intel_engine_lookup_user(i915, query.class, query.instance);
+ if (!engine)
+ return -ENOENT;
+
+ query.queued = atomic_read(&engine->request_stats.queued);
+ query.runnable = engine->request_stats.runnable;
+ query.running = intel_engine_last_submit(engine) -
+ intel_engine_get_seqno(engine);
+
+ if (copy_to_user(query_ptr, &query, len))
+ return -EFAULT;
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
+ query_engine_queues,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 9a00c30e4071..064c3d620286 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1637,6 +1637,7 @@ struct drm_i915_perf_oa_config {
struct drm_i915_query_item {
__u64 query_id;
#define DRM_I915_QUERY_TOPOLOGY_INFO1
+#define DRM_I915_QUERY_ENGINE_QUEUES 2
/*
* When set to zero by userspace, this is filled with the size of the
@@ -1734,6 +1735,31 @@ struct drm_i915_query_topology_info {
__u8 data[];
};
+/**
+ * struct drm_i915_query_engine_queues
+ *
+ * Engine queues query enables userspace to query current counts of active
+ * requests in their different states.
+ */
+struct drm_i915_query_engine_queues {
+ /** Engine class as in enum drm_i915_gem_engine_class. */
+ __u16 class;
+
+ /** Engine instance number. */
+ __u16 instance;
+
+ /** Number of requests with unresolved fences and dependencies. */
+ __u32 queued;
+
+ /** Number of ready requests waiting on a slot on GPU. */
+ __u32 runnable;
+
+ /** Number of requests executing on the GPU. */
+ __u32 running;
+
+ __u32 rsvd[5];
+};
+
#if defined(__cplusplus)
}
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP
On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > This was my bad, spec says that the name of this bit is
> > 'Y-coordinate valid' but the values for it is:
> > 0: Include Y-coordinate valid eDP1.4a
> > 1: Do not include Y-coordinate valid eDP 1.4
> > So renaming the bit and not setting it.
> >
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > drivers/gpu/drm/i915/intel_psr.c | 5 ++---
> > 2 files changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 176dca6554f4..19429cb1f3a7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4058,7 +4058,7 @@ enum {
> > #define EDP_PSR2_CTL _MMIO(0x6f900)
> > #define EDP_PSR2_ENABLE (1<<31)
> > #define EDP_SU_TRACK_ENABLE (1<<30)
> > -#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> > +#define EDP_Y_COORDINATE_INVALID (1<<26) /* GLK and CNL+
> > */
>
> INVALID isn't the same as asking the source to not send the y-
> coordinate
> valid bit. Sorry to be pedantic, please leave the definition as it
> is.
I agree with you, if it don't need to send the y-coordinate is
better just not set EDP_Y_COORDINATE_ENABLE but leave the bit
definition name as it is, is prone to others do the same error as I
did.
>
> Reviewed-by: Dhinakaran Pandiyan if
> you
> remove this hunk.
>
> > #define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+
> > */
> > #define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> > #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2d53f7398a6d..f12111438bcf 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > * mesh at all with our frontbuffer tracking. And the hw
> > alone isn't
> > * good enough. */
> > val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > {
> > - val |= EDP_Y_COORDINATE_VALID |
> > EDP_Y_COORDINATE_ENABLE;
> > - }
> > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > + val |= EDP_Y_COORDINATE_ENABLE;
> >
> > val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv-
> > >psr.sink_sync_latency + 1);
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP
On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> This was my bad, spec says that the name of this bit is
> 'Y-coordinate valid' but the values for it is:
> 0: Include Y-coordinate valid eDP1.4a
> 1: Do not include Y-coordinate valid eDP 1.4
> So renaming the bit and not setting it.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_psr.c | 5 ++---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 176dca6554f4..19429cb1f3a7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4058,7 +4058,7 @@ enum {
> #define EDP_PSR2_CTL _MMIO(0x6f900)
> #define EDP_PSR2_ENABLE(1<<31)
> #define EDP_SU_TRACK_ENABLE(1<<30)
> -#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define EDP_Y_COORDINATE_INVALID (1<<26) /* GLK and CNL+ */
INVALID isn't the same as asking the source to not send the y-coordinate
valid bit. Sorry to be pedantic, please leave the definition as it is.
Reviewed-by: Dhinakaran Pandiyan if you
remove this hunk.
> #define EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d53f7398a6d..f12111438bcf 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> - val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> - }
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + val |= EDP_Y_COORDINATE_ENABLE;
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
___
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: Use full serialisation around engine->irq_posted
Quoting Chris Wilson (2018-03-22 07:35:32)
> Using engine->irq_posted for execlists, we are not always serialised by
> the tasklet as we supposed. On the reset paths, the tasklet is disabled
> and ignored. Instead, we manipulate the engine->irq_posted directly to
> account for the reset, but if an interrupt fired before the reset and so
> wrote to engine->irq_posted, that write may not be flushed from the
> local CPU's cacheline until much later as the tasklet is already active
> and so does not generate a mb(). To correctly serialise the interrupt
> with reset, we need serialisation on the set_bit() itself.
>
> And at last Mika can be happy.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_irq.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index fa7310766217..27aee25429b7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1405,10 +1405,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine,
> u32 iir)
> bool tasklet = false;
>
> if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
> - if (READ_ONCE(engine->execlists.active)) {
> - __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> - tasklet = true;
> - }
> + if (READ_ONCE(engine->execlists.active))
> + tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
> + &engine->irq_posted);
This is driving me mad. A very rare missed interrupt unless we
unconditionally kick tasklet:
if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
+ if (READ_ONCE(engine->execlists.active)) {
+ set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ tasklet = true;
+ }
}
I can't see why.
Hmm, I wonder if we are seeing READ_ONCE(execlsts->active) false
negatives.
Getting close to admitting defeat :(
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details == Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/40978/ State : warning == Summary == Series 40978v1 series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function https://patchwork.freedesktop.org/api/1.0/series/40978/revisions/1/mbox/ Possible new issues: Test kms_busy: Subgroup basic-flip-a: pass -> DMESG-WARN (fi-skl-6700k2) pass -> DMESG-WARN (fi-skl-guc) Subgroup basic-flip-c: pass -> DMESG-WARN (fi-kbl-7567u) fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:544s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:295s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:515s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:506s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:517s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:564s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:588s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:418s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:319s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:464s fi-kbl-7567u total:285 pass:264 dwarn:1 dfail:0 fail:0 skip:20 time:457s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:660s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:437s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:477s fi-skl-guc total:285 pass:256 dwarn:1 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:565s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:407s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:505s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC integration manifest 67745738f4d0 drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side 164ed46e42e1 drm/i915/psr: Handle PSR RFB storage error 191d9682d215 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink ac18ae2ade2c drm/i915: Keep IGT PSR and frontbuffer tests functional f42690dc389a drm/i915/dp: Exit PSR before do a aux channel transaction 6d6bc90eccc3 drm/i915/psr: Add intel_psr_activate_block_get()/put() af1fc4a61d32 drm/i915/psr: Export intel_psr_activate/exit() 384712a1fb4a drm/i915/psr: Remove intel_crtc_state parameter from disable() 00837d74661e drm/i915/psr: Share code between disable and exit 5f0bc3f1c19d drm/i915/psr: Move PSR exit specific code to hardware specific function 499cc3f929a4 drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8554/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Print sink PSR status
== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: dmesg-warn -> PASS (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-plflip-blt: pass -> DMESG-FAIL (shard-apl) Subgroup fbc-rgb565-draw-mmap-gtt: pass -> FAIL (shard-apl) Known issues: Test gem_softpin: Subgroup noreloc-s3: incomplete -> PASS (shard-hsw) fdo#103540 Test kms_flip: Subgroup flip-vs-expired-vblank: pass -> FAIL (shard-hsw) fdo#102887 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-msflip-blt: dmesg-fail -> PASS (shard-apl) fdo#104727 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727 shard-apltotal:3495 pass:1829 dwarn:1 dfail:1 fail:8 skip:1655 time:12846s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11486s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:7021s Blacklisted hosts: shard-kbltotal:3495 pass:1959 dwarn:1 dfail:0 fail:7 skip:1528 time:9234s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8553/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details ==
Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON
to HSW+ function
URL : https://patchwork.freedesktop.org/series/40978/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
499cc3f929a4 drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
5f0bc3f1c19d drm/i915/psr: Move PSR exit specific code to hardware specific
function
00837d74661e drm/i915/psr: Share code between disable and exit
384712a1fb4a drm/i915/psr: Remove intel_crtc_state parameter from disable()
af1fc4a61d32 drm/i915/psr: Export intel_psr_activate/exit()
-:177: CHECK:BRACES: braces {} should be used on all arms of this statement
#177: FILE: drivers/gpu/drm/i915/intel_psr.c:1182:
+ if (schedule) {
[...]
+ } else
[...]
-:181: CHECK:BRACES: Unbalanced braces around else statement
#181: FILE: drivers/gpu/drm/i915/intel_psr.c:1186:
+ } else
total: 0 errors, 0 warnings, 2 checks, 153 lines checked
6d6bc90eccc3 drm/i915/psr: Add intel_psr_activate_block_get()/put()
-:88: CHECK:LINE_SPACING: Please don't use multiple blank lines
#88: FILE: drivers/gpu/drm/i915/intel_psr.c:1219:
+
+
total: 0 errors, 0 warnings, 1 checks, 78 lines checked
f42690dc389a drm/i915/dp: Exit PSR before do a aux channel transaction
ac18ae2ade2c drm/i915: Keep IGT PSR and frontbuffer tests functional
191d9682d215 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
164ed46e42e1 drm/i915/psr: Handle PSR RFB storage error
67745738f4d0 drm/i915/psr/bdw+: Enable CRC check in the static frame on the
sink side
-:29: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#29: FILE: drivers/gpu/drm/i915/i915_reg.h:4004:
+#define EDP_PSR_CRC_ENABLE (1<<10) /* BDW+ */
^
total: 0 errors, 0 warnings, 1 checks, 38 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction
When PSR/PSR2 is enabled hardware can do aux ch transactions by it
self.
Spec requires that PSR is inactive before do any aux ch transaction
in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
recommended.
So exiting PSR/PSR2 and waiting the transition to inactive to prevent
any concurrent access between hardware and software in aux ch
registers.
VLV and CHV hardware don't do any aux as software is responsible to
do all the buffer tracking and it sends the wake up aux ch message
to sink.
BSpec: 7530, 799 and 7532
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 38 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_psr.c | 8
3 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..fedee4e7ed24 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp
*intel_dp,
DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
}
+/**
+ * intel_dp_aux_ch_get - Get total control of aux ch registers
+ *
+ * By exiting or disabling any hardware feature that can also use the aux ch
+ * registers at the same time as driver, this function will give total control
+ * of aux ch registers to driver.
+ */
+static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
+{
+ if (!intel_dp->exit_psr_on_aux_ch_xfer)
+ return;
+
+ intel_psr_activate_block_get(intel_dp);
+ intel_psr_exit(intel_dp, true);
+}
+
+/**
+ * intel_dp_aux_ch_put - Release aux ch registers control
+ *
+ * It is the intel_dp_aux_ch_get() counterpart.
+ */
+static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
+{
+ if (!intel_dp->exit_psr_on_aux_ch_xfer)
+ return;
+
+ intel_psr_activate_block_put(intel_dp);
+ /* Usually more than just one aux ch transaction is executed when
+* handling some event, activating PSR right way would cause several
+* msecs of delay waiting PSR to exit for each aux ch transaction, so
+* here asking it to be scheduled.
+*/
+ intel_psr_activate(intel_dp, true);
+}
+
static int
intel_dp_aux_xfer(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
@@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
intel_dp_check_edp(intel_dp);
+ intel_dp_aux_ch_get(intel_dp);
+
/* Try to wait for any previous AUX channel activity */
for (try = 0; try < 3; try++) {
status = I915_READ_NOTRACE(ch_ctl);
@@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
ret = recv_bytes;
out:
+ intel_dp_aux_ch_put(intel_dp);
pm_qos_update_request(&dev_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
if (vdd)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 020b96324135..177478f0b032 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1139,6 +1139,8 @@ struct intel_dp {
/* Displayport compliance testing */
struct intel_dp_compliance compliance;
+
+ bool exit_psr_on_aux_ch_xfer;
};
struct intel_lspcon {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 8702dbafb42d..f88f12246a23 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
}
+ /* From all platforms that supports PSR/PSR2 this 2 is the ones that
+* don't have restrictions about use of the aux ch while PSR/PSR2 is
+* enabled.
+*/
+ if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
+ intel_dp->exit_psr_on_aux_ch_xfer = true;
+
unlock:
mutex_unlock(&dev_priv->psr.lock);
}
@@ -732,6 +739,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
dev_priv->psr.disable_source(intel_dp);
+ intel_dp->exit_psr_on_aux_ch_xfer = false;
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()
intel_psr_activate_block_get() should be called when by some reason
PSR should not be activated for some time, it will increment counter
and it should the decremented by intel_psr_activate_block_put()
when PSR can be activated again.
intel_psr_activate_block_put() will not actually activate PSR, users
of this function should also call intel_psr_activate().
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_psr.c | 54
3 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 99af9169d792..41ebb144594e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -609,6 +609,7 @@ struct i915_psr {
bool has_hw_tracking;
bool psr2_enabled;
u8 sink_sync_latency;
+ unsigned int activate_block_count;
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 70026b772721..020b96324135 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1893,6 +1893,8 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle);
void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
+void intel_psr_activate_block_get(struct intel_dp *intel_dp);
+void intel_psr_activate_block_put(struct intel_dp *intel_dp);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 906a12ea934d..8702dbafb42d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -558,6 +558,8 @@ static void __intel_psr_activate(struct intel_dp *intel_dp)
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(&dev_priv->psr.lock);
+ if (dev_priv->psr.activate_block_count)
+ return;
dev_priv->psr.activate(intel_dp);
dev_priv->psr.active = true;
@@ -1188,3 +1190,55 @@ void intel_psr_activate(struct intel_dp *intel_dp, bool
schedule)
out:
mutex_unlock(&dev_priv->psr.lock);
}
+
+/**
+ * intel_psr_activate_block_get - Block further attempts to activate PSR
+ * @intel_dp: DisplayPort that have PSR enabled
+ *
+ * It have a internal reference count, so each intel_psr_activate_block_get()
+ * should have a intel_psr_activate_block_put() counterpart.
+ */
+void intel_psr_activate_block_get(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (!CAN_PSR(dev_priv))
+ return;
+
+ mutex_lock(&dev_priv->psr.lock);
+ if (dev_priv->psr.enabled != intel_dp)
+ goto out;
+
+ dev_priv->psr.activate_block_count++;
+out:
+ mutex_unlock(&dev_priv->psr.lock);
+}
+
+
+/**
+ * intel_psr_activate_block_put - Unblock further attempts to activate PSR
+ * @intel_dp: DisplayPort that have PSR enabled
+ *
+ * Decrease the reference counter incremented by intel_psr_activate_block_get()
+ * when zero it allows PSR be activate. To actually activate PSR when reference
+ * counter is zero intel_psr_activate() should be called.
+ */
+void intel_psr_activate_block_put(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (!CAN_PSR(dev_priv))
+ return;
+
+ mutex_lock(&dev_priv->psr.lock);
+ if (dev_priv->psr.enabled != intel_dp)
+ goto out;
+
+ dev_priv->psr.activate_block_count--;
+out:
+ mutex_unlock(&dev_priv->psr.lock);
+}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915/psr: Move PSR exit specific code to hardware specific function
To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to
differentiate between VLV/CHV and HSW+ hardware, so here moving each
hardware handling to his own function.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 94 +++-
2 files changed, 56 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..a8d300280a2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -617,6 +617,7 @@ struct i915_psr {
void (*enable_sink)(struct intel_dp *);
void (*activate)(struct intel_dp *);
void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
+ void (*exit)(struct intel_dp *intel_dp);
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index fc7c36efd401..bcaac9e69f8c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -838,53 +838,67 @@ static void intel_psr_work(struct work_struct *work)
mutex_unlock(&dev_priv->psr.lock);
}
-static void intel_psr_exit(struct drm_i915_private *dev_priv)
+static void hsw_psr_exit(struct intel_dp *intel_dp)
{
- struct intel_dp *intel_dp = dev_priv->psr.enabled;
- struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 val;
+
+ if (dev_priv->psr.psr2_enabled) {
+ val = I915_READ(EDP_PSR2_CTL);
+ WARN_ON(!(val & EDP_PSR2_ENABLE));
+ I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
+ } else {
+ val = I915_READ(EDP_PSR_CTL);
+ WARN_ON(!(val & EDP_PSR_ENABLE));
+ I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
+ }
+}
+
+static void vlv_psr_exit(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_crtc *crtc = dig_port->base.base.crtc;
enum pipe pipe = to_intel_crtc(crtc)->pipe;
u32 val;
- if (!dev_priv->psr.active)
- return;
+ val = I915_READ(VLV_PSRCTL(pipe));
- if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.psr2_enabled) {
- val = I915_READ(EDP_PSR2_CTL);
- WARN_ON(!(val & EDP_PSR2_ENABLE));
- I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
- } else {
- val = I915_READ(EDP_PSR_CTL);
- WARN_ON(!(val & EDP_PSR_ENABLE));
- I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
- }
- } else {
- val = I915_READ(VLV_PSRCTL(pipe));
+ /*
+* Here we do the transition drirectly from
+* PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to
+* PSR_state 5 (exit).
+* PSR State 4 (active with single frame update) can be skipped.
+* On PSR_state 5 (exit) Hardware is responsible to transition
+* back to PSR_state 1 (inactive).
+* Now we are at Same state after vlv_psr_enable_source.
+*/
+ val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
+ I915_WRITE(VLV_PSRCTL(pipe), val);
- /*
-* Here we do the transition drirectly from
-* PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to
-* PSR_state 5 (exit).
-* PSR State 4 (active with single frame update) can be skipped.
-* On PSR_state 5 (exit) Hardware is responsible to transition
-* back to PSR_state 1 (inactive).
-* Now we are at Same state after vlv_psr_enable_source.
-*/
- val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
- I915_WRITE(VLV_PSRCTL(pipe), val);
+ /*
+* Send AUX wake up - Spec says after transitioning to PSR
+* active we have to send AUX wake up by writing 01h in DPCD
+* 600h of sink device.
+* XXX: This might slow down the transition, but without this
+* HW doesn't complete the transition to PSR_state 1 and we
+* never get the screen updated.
+*/
+ drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
+ DP_SET_POWER_D0);
+}
- /*
-* Send AUX wake up - Spec says after transitioning to PSR
-* active we have to send AUX wake up by writing 01h in DPCD
-* 600h of sink device.
-* XXX: This might slow down the tran
[Intel-gfx] [PATCH 09/11] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
eDP spec states that sink device will do a short pulse in HPD
line when there is a PSR/PSR2 error that needs to be handled by
source, this is handling the first and most simples error:
DP_PSR_SINK_INTERNAL_ERROR.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 31 +++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c655f6c08a02..fc8b86bc0120 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4518,6 +4518,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
if (intel_dp_needs_link_retrain(intel_dp))
return false;
+ intel_psr_hpd_short_pulse_handle(intel_dp);
+
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
/* Send a Hotplug Uevent to userspace to start modeset */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 177478f0b032..d4c7e1e0fb86 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1897,6 +1897,7 @@ void intel_psr_exit(struct intel_dp *intel_dp, bool
wait_idle);
void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
void intel_psr_activate_block_get(struct intel_dp *intel_dp);
void intel_psr_activate_block_put(struct intel_dp *intel_dp);
+void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f88f12246a23..85d201fce287 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1250,3 +1250,34 @@ void intel_psr_activate_block_put(struct intel_dp
*intel_dp)
out:
mutex_unlock(&dev_priv->psr.lock);
}
+
+void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct i915_psr *psr = &dev_priv->psr;
+ uint8_t val;
+
+ if (!HAS_PSR(dev_priv))
+ return;
+
+ mutex_lock(&psr->lock);
+ if (psr->enabled != intel_dp)
+ goto out;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val) != 1) {
+ DRM_DEBUG_KMS("PSR_STATUS read failed\n");
+ goto dpcd_read_error;
+ }
+
+ if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR)
+ __intel_psr_exit(dev_priv);
+
+ /* TODO: handle other PSR/PSR2 errors */
+dpcd_read_error:
+ if (!dev_priv->psr.busy_frontbuffer_bits)
+ __intel_psr_activate(intel_dp);
+out:
+ mutex_unlock(&psr->lock);
+}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: Keep IGT PSR and frontbuffer tests functional
'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all
IGT PSR and frontbuffer tracking tests to not be userful.
Those tests depend in reading the calculated CRC value of the
frontbuffer in sink and doing a aux transaction now causes the PSR
to exit.
So any bug in software and hardware buffer tracking will be masked by
this forced PSR exit.
This is a dirty workaround that makes those tests functional again
at the risk of causing concurrent access in the aux ch registers
while running_igt_psr_tests is set.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1dba2c451255..519f67598d44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4732,6 +4732,27 @@ static int i915_drrs_ctl_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(i915_drrs_ctl_fops, NULL, i915_drrs_ctl_set, "%llu\n");
+static int i915_running_igt_psr_tests_get(void *data, u64 *val)
+{
+ struct drm_i915_private *dev_priv = data;
+
+ *val = dev_priv->running_igt_psr_tests;
+ return 0;
+}
+
+static int i915_running_igt_psr_tests_set(void *data, u64 val)
+{
+ struct drm_i915_private *dev_priv = data;
+
+ dev_priv->running_igt_psr_tests = !!val;
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_running_igt_psr_tests_fops,
+ i915_running_igt_psr_tests_get,
+ i915_running_igt_psr_tests_set,
+ "%llu\n");
+
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
@@ -4812,7 +4833,8 @@ static const struct i915_debugfs_files {
{"i915_guc_log_relay", &i915_guc_log_relay_fops},
{"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
{"i915_ipc_status", &i915_ipc_status_fops},
- {"i915_drrs_ctl", &i915_drrs_ctl_fops}
+ {"i915_drrs_ctl", &i915_drrs_ctl_fops},
+ {"i915_running_igt_psr_tests", &i915_running_igt_psr_tests_fops}
};
int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 41ebb144594e..9e0a5e29f48e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2110,6 +2110,8 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ bool running_igt_psr_tests;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fedee4e7ed24..c655f6c08a02 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1071,8 +1071,20 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp
*intel_dp,
*/
static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
+ to_i915(intel_dig_port->base.base.dev);
+
if (!intel_dp->exit_psr_on_aux_ch_xfer)
return;
+ /*
+* HACK: This is a workaround to keep IGT PSR and frontbuffer tracking
+* tests functional, otherwise when IGT request the CRC of the
+* frontbuffer to sink it would cause this function to complete execute
+* and exit PSR.
+*/
+ if (dev_priv->running_igt_psr_tests)
+ return;
intel_psr_activate_block_get(intel_dp);
intel_psr_exit(intel_dp, true);
@@ -1085,8 +1097,14 @@ static void intel_dp_aux_ch_get(struct intel_dp
*intel_dp)
*/
static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
+ to_i915(intel_dig_port->base.base.dev);
+
if (!intel_dp->exit_psr_on_aux_ch_xfer)
return;
+ if (dev_priv->running_igt_psr_tests)
+ return;
intel_psr_activate_block_put(intel_dp);
/* Usually more than just one aux ch transaction is executed when
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit
The disable and exit sequence are very similar with a lot common
code between both, so here sharing the code.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_psr.c | 84 ++--
2 files changed, 38 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a8d300280a2c..cb72ee27422f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -617,7 +617,7 @@ struct i915_psr {
void (*enable_sink)(struct intel_dp *);
void (*activate)(struct intel_dp *);
void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
- void (*exit)(struct intel_dp *intel_dp);
+ void (*exit)(struct intel_dp *intel_dp, bool disabling);
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index bcaac9e69f8c..d3451afeb8bb 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -672,23 +672,9 @@ static void vlv_psr_disable(struct intel_dp *intel_dp,
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
- uint32_t val;
if (dev_priv->psr.active) {
- /* Put VLV PSR back to PSR_state 0 (disabled). */
- if (intel_wait_for_register(dev_priv,
- VLV_PSRSTAT(crtc->pipe),
- VLV_EDP_PSR_IN_TRANS,
- 0,
- 1))
- WARN(1, "PSR transition took longer than expected\n");
-
- val = I915_READ(VLV_PSRCTL(crtc->pipe));
- val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
- val &= ~VLV_EDP_PSR_ENABLE;
- val &= ~VLV_EDP_PSR_MODE_MASK;
- I915_WRITE(VLV_PSRCTL(crtc->pipe), val);
-
+ dev_priv->psr.exit(intel_dp, true);
dev_priv->psr.active = false;
} else {
WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe));
@@ -703,31 +689,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = to_i915(dev);
if (dev_priv->psr.active) {
- i915_reg_t psr_status;
- u32 psr_status_mask;
-
- if (dev_priv->psr.psr2_enabled) {
- psr_status = EDP_PSR2_STATUS;
- psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
-
- I915_WRITE(EDP_PSR2_CTL,
- I915_READ(EDP_PSR2_CTL) &
- ~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
-
- } else {
- psr_status = EDP_PSR_STATUS;
- psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
-
- I915_WRITE(EDP_PSR_CTL,
- I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
- }
-
- /* Wait till PSR is idle */
- if (intel_wait_for_register(dev_priv,
- psr_status, psr_status_mask, 0,
- 2000))
- DRM_ERROR("Timed out waiting for PSR Idle State\n");
-
+ dev_priv->psr.exit(intel_dp, true);
dev_priv->psr.active = false;
} else {
if (dev_priv->psr.psr2_enabled)
@@ -838,25 +800,41 @@ static void intel_psr_work(struct work_struct *work)
mutex_unlock(&dev_priv->psr.lock);
}
-static void hsw_psr_exit(struct intel_dp *intel_dp)
+static void hsw_psr_exit(struct intel_dp *intel_dp, bool disabling)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+ i915_reg_t psr_status;
+ u32 psr_status_mask;
u32 val;
if (dev_priv->psr.psr2_enabled) {
+ psr_status = EDP_PSR2_STATUS;
+ psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
+
val = I915_READ(EDP_PSR2_CTL);
- WARN_ON(!(val & EDP_PSR2_ENABLE));
- I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
+ WARN_ON(!disabling && !(val & EDP_PSR2_ENABLE));
+ val &= ~EDP_PSR2_ENABLE;
+ if (disabling)
+ val &= ~EDP_SU_TRACK_ENABLE;
+ I915_WRITE(EDP_PSR2_CTL, val);
} else {
+ psr_status = EDP_PSR_STATUS;
+ psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
+
val = I915_READ(EDP_PSR_CTL);
- WARN_ON(!(val & EDP_PSR_ENABLE));
+
[Intel-gfx] [PATCH 05/11] drm/i915/psr: Export intel_psr_activate/exit()
Export this functions so other modules can activate and exit PSR.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_psr.c | 94 +---
2 files changed, 89 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d1452fd2a58d..70026b772721 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1891,6 +1891,8 @@ void intel_psr_single_frame_update(struct
drm_i915_private *dev_priv,
unsigned frontbuffer_bits);
void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
+void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle);
+void intel_psr_activate(struct intel_dp *intel_dp, bool schedule);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c4720b0152c3..906a12ea934d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,6 +56,8 @@
#include "intel_drv.h"
#include "i915_drv.h"
+#define ACTIVATE_WORK_MSEC_DELAY 100
+
static inline enum intel_display_power_domain
psr_aux_domain(struct intel_dp *intel_dp)
{
@@ -548,7 +550,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
}
-static void intel_psr_activate(struct intel_dp *intel_dp)
+static void __intel_psr_activate(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -645,7 +647,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enabled = intel_dp;
if (INTEL_GEN(dev_priv) >= 9) {
- intel_psr_activate(intel_dp);
+ __intel_psr_activate(intel_dp);
} else {
/*
* FIXME: Activation should happen immediately since this
@@ -794,7 +796,7 @@ static void intel_psr_work(struct work_struct *work)
if (dev_priv->psr.busy_frontbuffer_bits)
goto unlock;
- intel_psr_activate(intel_dp);
+ __intel_psr_activate(intel_dp);
unlock:
mutex_unlock(&dev_priv->psr.lock);
}
@@ -880,7 +882,7 @@ static void vlv_psr_exit(struct intel_dp *intel_dp, bool
disabling)
DP_SET_POWER_D0);
}
-static void intel_psr_exit(struct drm_i915_private *dev_priv)
+static void __intel_psr_exit(struct drm_i915_private *dev_priv)
{
struct intel_dp *intel_dp = dev_priv->psr.enabled;
@@ -977,7 +979,7 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv,
dev_priv->psr.busy_frontbuffer_bits |= frontbuffer_bits;
if (frontbuffer_bits)
- intel_psr_exit(dev_priv);
+ __intel_psr_exit(dev_priv);
mutex_unlock(&dev_priv->psr.lock);
}
@@ -1023,7 +1025,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
if (frontbuffer_bits) {
if (dev_priv->psr.psr2_enabled ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- intel_psr_exit(dev_priv);
+ __intel_psr_exit(dev_priv);
} else {
/*
* Display WA #0884: all
@@ -1041,7 +1043,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
if (!work_busy(&dev_priv->psr.work.work))
schedule_delayed_work(&dev_priv->psr.work,
- msecs_to_jiffies(100));
+
msecs_to_jiffies(ACTIVATE_WORK_MSEC_DELAY));
mutex_unlock(&dev_priv->psr.lock);
}
@@ -1108,3 +1110,81 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
dev_priv->psr.exit = hsw_psr_exit;
}
}
+
+/**
+ * intel_psr_exit - Exit PSR
+ * @intel_dp: DisplayPort that should have PSR exited if active
+ * @wait_idle: if true wait until PSR is inactive otherwise just request it
+ *
+ * This function exit PSR if enabled and active in this DisplayPort.
+ */
+void intel_psr_exit(struct intel_dp *intel_dp, bool wait_idle)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (!CAN_PSR(dev_priv))
+ return;
+
+ mutex_lock(&dev_priv->psr.lock);
+ if (dev_priv->psr.enabled != intel_dp)
+ goto out;
+ if (!dev_priv->psr.active && !wait_idle)
+ goto out;
+
+ if (IS_VALLEYVIEW(dev_priv)
[Intel-gfx] [PATCH 04/11] drm/i915/psr: Remove intel_crtc_state parameter from disable()
It is not necessary as is possible to get the pipe information
from intel_dp.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_psr.c | 13 ++---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb72ee27422f..99af9169d792 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -612,8 +612,7 @@ struct i915_psr {
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
- void (*disable_source)(struct intel_dp *,
- const struct intel_crtc_state *);
+ void (*disable_source)(struct intel_dp *intel_dp);
void (*enable_sink)(struct intel_dp *);
void (*activate)(struct intel_dp *);
void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d3451afeb8bb..c4720b0152c3 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -665,24 +665,23 @@ void intel_psr_enable(struct intel_dp *intel_dp,
mutex_unlock(&dev_priv->psr.lock);
}
-static void vlv_psr_disable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *old_crtc_state)
+static void vlv_psr_disable(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+ struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
if (dev_priv->psr.active) {
dev_priv->psr.exit(intel_dp, true);
dev_priv->psr.active = false;
} else {
- WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe));
+ WARN_ON(vlv_is_psr_active_on_pipe(dev, pipe));
}
}
-static void hsw_psr_disable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *old_crtc_state)
+static void hsw_psr_disable(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -727,7 +726,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
return;
}
- dev_priv->psr.disable_source(intel_dp, old_crtc_state);
+ dev_priv->psr.disable_source(intel_dp);
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915/psr: Handle PSR RFB storage error
Sink will interrupt source when it have any problem saving or reading
the remote frame buffer.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 85d201fce287..d76eece63ebd 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1274,6 +1274,16 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp
*intel_dp)
if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR)
__intel_psr_exit(dev_priv);
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_ERROR_STATUS, &val) != 1) {
+ DRM_DEBUG_KMS("PSR_ERROR_STATUS read failed\n");
+ goto dpcd_read_error;
+ }
+
+ if (val & DP_PSR_RFB_STORAGE_ERROR)
+ __intel_psr_exit(dev_priv);
+ /* clear status register */
+ drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_ERROR_STATUS, val);
+
/* TODO: handle other PSR/PSR2 errors */
dpcd_read_error:
if (!dev_priv->psr.busy_frontbuffer_bits)
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
It was reading some random register in VLV and CHV. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2d53f7398a6d..fc7c36efd401 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -424,6 +424,11 @@ static void hsw_psr_activate(struct intel_dp *intel_dp) struct drm_device *dev = dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); + if (dev_priv->psr.psr2_enabled) + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE); + else + WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE); + /* On HSW+ after we enable PSR on source it will activate it * as soon as it match configure idle_frame count. So * we just actually enable it here on activation time. @@ -549,10 +554,6 @@ static void intel_psr_activate(struct intel_dp *intel_dp) struct drm_device *dev = intel_dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - if (dev_priv->psr.psr2_enabled) - WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE); - else - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE); WARN_ON(dev_priv->psr.active); lockdep_assert_held(&dev_priv->psr.lock); -- 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side
Sink can be configured to calculate the CRC over the static frame and
compare with the CRC calculated and transmited in the VSC SDP by
source, if there is a mismatch sink will do a short pulse in HPD
and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS.
Spec: 7723
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 176dca6554f4..3bd8f5edee87 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4001,6 +4001,7 @@ enum {
#define EDP_PSR_SKIP_AUX_EXIT(1<<12)
#define EDP_PSR_TP1_TP2_SEL (0<<11)
#define EDP_PSR_TP1_TP3_SEL (1<<11)
+#define EDP_PSR_CRC_ENABLE (1<<10) /* BDW+ */
#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d76eece63ebd..1f4bf079dd39 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -292,6 +292,8 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
dpcd_val |= DP_PSR_ENABLE_PSR2;
if (dev_priv->psr.link_standby)
dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
+ if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
+ dpcd_val |= DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val);
drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
@@ -379,6 +381,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
else
val |= EDP_PSR_TP1_TP2_SEL;
+ if (INTEL_GEN(dev_priv) >= 8)
+ val |= EDP_PSR_CRC_ENABLE;
+
val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
I915_WRITE(EDP_PSR_CTL, val);
}
@@ -1279,12 +1284,12 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp
*intel_dp)
goto dpcd_read_error;
}
- if (val & DP_PSR_RFB_STORAGE_ERROR)
+ if (val & (DP_PSR_RFB_STORAGE_ERROR | DP_PSR_LINK_CRC_ERROR))
__intel_psr_exit(dev_priv);
/* clear status register */
drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_ERROR_STATUS, val);
- /* TODO: handle other PSR/PSR2 errors */
+ /* TODO: handle PSR2 errors */
dpcd_read_error:
if (!dev_priv->psr.busy_frontbuffer_bits)
__intel_psr_activate(intel_dp);
--
2.16.3
___
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/debugfs: Print sink PSR status
== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : success == Summary == Series 40977v1 series starting with [1/2] drm/i915/debugfs: Print sink PSR status https://patchwork.freedesktop.org/api/1.0/series/40977/revisions/1/mbox/ fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:541s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:511s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:517s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:558s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:515s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:319s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:665s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:436s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:541s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:490s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:583s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:530s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:483s c46052cde6a50c5459e00791ffc4d5aa1ec58a9e drm-tip: 2018y-03m-30d-18h-56m-26s UTC integration manifest 6d65247b0089 drm/i915/psr/cnl: Set y-coordinate as valid in SDP 9444b2175c0a drm/i915/debugfs: Print sink PSR status == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8553/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/debugfs: Print sink PSR status
== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9444b2175c0a drm/i915/debugfs: Print sink PSR status 6d65247b0089 drm/i915/psr/cnl: Set y-coordinate as valid in SDP -:27: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #27: FILE: drivers/gpu/drm/i915/i915_reg.h:4061: +#define EDP_Y_COORDINATE_INVALID (1<<26) /* GLK and CNL+ */ ^ total: 0 errors, 0 warnings, 1 checks, 19 lines checked ___ 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 [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2) URL : https://patchwork.freedesktop.org/series/40704/ State : failure == Summary == Applying: drm/i915: Enable edp psr error interrupts on hsw Applying: drm/i915: Enable edp psr error interrupts on bdw+ Applying: drm/i915/psr: Control PSR interrupts via debugfs error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs.c M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_psr.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_psr.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_psr.c Auto-merging drivers/gpu/drm/i915/i915_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/i915_debugfs.c Patch failed at 0003 drm/i915/psr: Control PSR interrupts via debugfs The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Control PSR interrupts via debugfs
On Fri, 2018-03-30 at 14:15 -0700, Dhinakaran Pandiyan wrote: > Interrupts other than the one for AUX errors are required only for debug, > so unmask them via debugfs when the user requests debug. > > User can make such a request with > echo 1 > /dri/0/i915_edp_psr_debug > > There are no locks to serialize PSR debug enabling from > irq_postinstall() and debugfs for simplicity. As irq_postinstall() is > called only during module initialization/resume and IGT subtests > aren't expected to modify PSR debug at those times, we should be safe. Let me know what you think, I am not completely sure about this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So renaming the bit and not setting it.
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_psr.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 176dca6554f4..19429cb1f3a7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4058,7 +4058,7 @@ enum {
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
#define EDP_SU_TRACK_ENABLE (1<<30)
-#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
+#define EDP_Y_COORDINATE_INVALID (1<<26) /* GLK and CNL+ */
#define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+ */
#define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2d53f7398a6d..f12111438bcf 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
- val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
- }
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ val |= EDP_Y_COORDINATE_ENABLE;
val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/debugfs: Print sink PSR status
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1dba2c451255..c9ac946b62c9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
return "unknown";
}
+static const char *psr_sink_status(u8 val)
+{
+ static const char * const sink_status[] = {
+ "inactive",
+ "transition to active, capture and display",
+ "active, display from RFB",
+ "active, capture and display on sink device timings",
+ "transition to inactive, capture and display, timing re-sync",
+ "reserved",
+ "reserved",
+ "sink internal error"
+ };
+
+ val &= DP_PSR_SINK_STATE_MASK;
+ if (val < ARRAY_SIZE(sink_status))
+ return sink_status[val];
+
+ return "unknown";
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
psr2, psr2_live_status(psr2));
}
+
+ if (dev_priv->psr.enabled) {
+ struct drm_dp_aux *aux = &dev_priv->psr.enabled->aux;
+ u8 val;
+
+ if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) == 1)
+ seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
+ psr_sink_status(val));
+ }
mutex_unlock(&dev_priv->psr.lock);
intel_runtime_pm_put(dev_priv);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/psr: Control PSR interrupts via debugfs
Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.
User can make such a request with
echo 1 > /dri/0/i915_edp_psr_debug
There are no locks to serialize PSR debug enabling from
irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
called only during module initialization/resume and IGT subtests
aren't expected to modify PSR debug at those times, we should be safe.
v2: Unroll loops (Ville)
Avoid resetting error mask bits.
v3: Unmask interrupts in postinstall() if debug was still enabled.
Avoid RMW (Ville)
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 57 +++
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_psr.c| 60 +
5 files changed, 113 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff90577da450..5e697867a8ca 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2690,6 +2690,36 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
return 0;
}
+static int
+i915_edp_psr_debug_set(void *data, u64 val)
+{
+ struct drm_i915_private *dev_priv = data;
+
+ if (!CAN_PSR(dev_priv))
+ return -ENODEV;
+
+ DRM_DEBUG_KMS("PSR debug %s\n", enableddisabled(val));
+ intel_psr_debug_control(dev_priv, !!val);
+
+ return 0;
+}
+
+static int
+i915_edp_psr_debug_get(void *data, u64 *val)
+{
+ struct drm_i915_private *dev_priv = data;
+
+ if (!CAN_PSR(dev_priv))
+ return -ENODEV;
+
+ *val = READ_ONCE(dev_priv->psr.debug);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
+ i915_edp_psr_debug_get, i915_edp_psr_debug_set,
+ "%llu\n");
+
static int i915_sink_crc(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4812,7 +4842,8 @@ static const struct i915_debugfs_files {
{"i915_guc_log_relay", &i915_guc_log_relay_fops},
{"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
{"i915_ipc_status", &i915_ipc_status_fops},
- {"i915_drrs_ctl", &i915_drrs_ctl_fops}
+ {"i915_drrs_ctl", &i915_drrs_ctl_fops},
+ {"i915_edp_psr_debug", &i915_edp_psr_debug_fops}
};
int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230ba1c3b..71577ebf6a60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -609,6 +609,7 @@ struct i915_psr {
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
+ bool debug;
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8a894adf2ca1..714570955196 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct
drm_i915_private *dev_priv,
ironlake_rps_change_irq_handler(dev_priv);
}
-static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
-{
- u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
- u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
- u32 mask = BIT(TRANSCODER_EDP);
- enum transcoder cpu_transcoder;
-
- if (INTEL_GEN(dev_priv) >= 8)
- mask |= BIT(TRANSCODER_A) |
- BIT(TRANSCODER_B) |
- BIT(TRANSCODER_C);
-
- for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
- if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
- DRM_DEBUG_KMS("Transcoder %s PSR error\n",
- transcoder_name(cpu_transcoder));
-
- if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
- DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2
vblanks\n",
- transcoder_name(cpu_transcoder));
- edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
- }
-
- if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
- DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
- transcoder_name(cpu_transcoder));
- edp_psr_imr &= ~EDP_PSR_PRE_ENTRY(cpu_transcoder);
- }
- }
-
- I915_WRITE(EDP_PSR_IMR, edp_psr_imr);
- I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
-}
-
static void ivb_display_irq_handle
Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status
On Fri, 2018-03-30 at 19:19 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > > IGT tests could be improved with sink status, knowing for sure that
> > > hardware have activate or exit PSR.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > >
> > > v3: rebased
> > >
> > > drivers/gpu/drm/i915/i915_debugfs.c | 29
> > > +
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 1dba2c451255..89dc5b05ec24 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > > return "unknown";
> > > }
> > >
> > > +static const char *psr_sink_self_refresh_status(u8 val)
> >
> > nit: psr_sink_status() is concise,
> > "psr_self_refresh" sounds
> > redundant.
> >
> > > +{
> > > + static const char * const sink_status[] = {
> > > + "inactive",
> > > + "transitioning to active",
> >
> > We muddle the meaning of these statuses by paraphrasing, it is better
> > write these strings exactly as the states are defined in the spec.
> >
> > > + "active",
> > > + "active receiving selective update",
> >
> > For example, this state corresponds to the capture of full static
> > frame
> > too.
>
>
> It is fine this way?
>
> static const char * const sink_status[] = {
> "inactive",
> "transition to active, capture and display",
> "active, display from RFB",
> "active, capture and display on sink device timings",
> "transition to inactive, capture and display, timing
> re-sync",
> "reserved",
> "reserved",
> "sink internal error"
> };
>
>
Looks good.
> >
> >
> > Reviewed-by: Dhinakaran Pandiyan with
> > the nits addressed, thanks for the patch.
> >
> > > + "transitioning to inactive",
> > > + "reserved",
> > > + "reserved",
> > > + "sink internal error"
> > > + };
> > > +
> > > + val &= DP_PSR_SINK_STATE_MASK;
> > > + if (val < ARRAY_SIZE(sink_status))
> > > + return sink_status[val];
> > > +
> > > + return "unknown";
> > > +}
> > > +
> > > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > {
> > > struct drm_i915_private *dev_priv = node_to_i915(m-
> > > >private);
> > > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> > > psr2, psr2_live_status(psr2));
> > > }
> > > +
> > > + if (dev_priv->psr.enabled) {
> > > + struct drm_dp_aux *aux = &dev_priv->psr.enabled-
> > > >aux;
> > > + u8 val;
> > > +
> > > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) ==
> > > 1)
> > > + seq_printf(m, "Sink self refresh status:
> > > 0x%x [%s]\n",
> > > +val,
> > > psr_sink_self_refresh_status(val));
> > > + }
> > > mutex_unlock(&dev_priv->psr.lock);
> > >
> > > intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Exec param to control data port coherency. (rev2)
== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev2) URL : https://patchwork.freedesktop.org/series/40181/ State : failure == Summary == Possible new issues: Test gem_exec_params: Subgroup invalid-flag: pass -> FAIL (shard-apl) Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-a: fail -> PASS (shard-snb) Test kms_cursor_crc: Subgroup cursor-256x256-onscreen: fail -> PASS (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbc-2p-scndscrn-indfb-plflip-blt: fail -> SKIP (shard-snb) Subgroup fbc-2p-scndscrn-pri-shrfb-draw-pwrite: fail -> SKIP (shard-snb) Subgroup fbcpsr-rgb101010-draw-mmap-cpu: fail -> SKIP (shard-snb) Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102887 Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-indfb-draw-pwrite: pass -> FAIL (shard-apl) fdo#103167 Subgroup psr-1p-pri-indfb-multidraw: fail -> SKIP (shard-snb) fdo#105798 Test kms_plane_lowres: Subgroup pipe-b-tiling-yf: fail -> PASS (shard-apl) fdo#103166 Test kms_vblank: Subgroup pipe-a-accuracy-idle: pass -> FAIL (shard-hsw) fdo#102583 Test testdisplay: dmesg-warn -> PASS (shard-apl) fdo#104727 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#105798 https://bugs.freedesktop.org/show_bug.cgi?id=105798 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727 shard-apltotal:3495 pass:1829 dwarn:1 dfail:0 fail:9 skip:1655 time:12853s shard-hswtotal:3495 pass:1781 dwarn:1 dfail:0 fail:3 skip:1709 time:11419s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:7030s Blacklisted hosts: shard-kbltotal:3477 pass:1921 dwarn:16 dfail:0 fail:9 skip:1530 time:9003s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8551/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.
On 30/03/18 08:42, Lis, Tomasz wrote:
On 2018-03-29 00:28, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-28 17:06:58)
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a
proper
bit within Execlist Control Register, and receiving preemption
result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be
executed,
so the Command Streamer never preempted to idle directly. In
Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.
This patch does not cover using the new preemption mechanism when
GuC is
active.
Bspec: 18922
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 45
+++-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
5 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private
*dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c
b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info
intel_cannonlake_info = {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .has_hw_preempt_to_idle = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+ func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
#define GEN8_CTX_STATUS_ACTIVE_IDLE (1 << 3)
#define GEN8_CTX_STATUS_COMPLETE (1 << 4)
#define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29)
#define GEN8_CTX_STATUS_COMPLETED_MASK \
(GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
{
- return engine->i915->preempt_context && prio >
max(rq_prio(last), 0);
+ return (engine->i915->preempt_context ||
+ HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
Well, you haven't actually disabled allocating the preempt_context
so...
Yes.. I had mixed feelings about changing needs_preempt_context() now,
as that would mean adding a temporary condition on GuC until the GuC
preemption is merged.
I will add the conditions and disable the allocation in v2 of the patch.
But at any rate, making this an engine->flag would eliminate one
pointer
dance.
Could be an interesting idea for a separate patch.
To land first ;)
:)
Sure, I can do that.
+ prio > max(rq_prio(last), 0);
}
/**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct
intel_engine_cs *engine)
execlists_set_active(&engine->execlists,
EXECLISTS_ACTIVE_PREEMPT);
}
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+ * hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+ * HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+ */
+ GEM_BUG_ON(execlists->ctrl_reg != NULL);
+
+ /* trigger preemption to idle */
+ writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
Future plans? Because just inserting the branch into
Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status
On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> >
> > v3: rebased
> >
> > drivers/gpu/drm/i915/i915_debugfs.c | 29
> > +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1dba2c451255..89dc5b05ec24 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > return "unknown";
> > }
> >
> > +static const char *psr_sink_self_refresh_status(u8 val)
>
> nit: psr_sink_status() is concise,
> "psr_self_refresh" sounds
> redundant.
>
> > +{
> > + static const char * const sink_status[] = {
> > + "inactive",
> > + "transitioning to active",
>
> We muddle the meaning of these statuses by paraphrasing, it is better
> write these strings exactly as the states are defined in the spec.
>
> > + "active",
> > + "active receiving selective update",
>
> For example, this state corresponds to the capture of full static
> frame
> too.
It is fine this way?
static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
"active, display from RFB",
"active, capture and display on sink device timings",
"transition to inactive, capture and display, timing
re-sync",
"reserved",
"reserved",
"sink internal error"
};
>
>
> Reviewed-by: Dhinakaran Pandiyan with
> the nits addressed, thanks for the patch.
>
> > + "transitioning to inactive",
> > + "reserved",
> > + "reserved",
> > + "sink internal error"
> > + };
> > +
> > + val &= DP_PSR_SINK_STATE_MASK;
> > + if (val < ARRAY_SIZE(sink_status))
> > + return sink_status[val];
> > +
> > + return "unknown";
> > +}
> > +
> > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > }
> > +
> > + if (dev_priv->psr.enabled) {
> > + struct drm_dp_aux *aux = &dev_priv->psr.enabled-
> > >aux;
> > + u8 val;
> > +
> > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) ==
> > 1)
> > + seq_printf(m, "Sink self refresh status:
> > 0x%x [%s]\n",
> > + val,
> > psr_sink_self_refresh_status(val));
> > + }
> > mutex_unlock(&dev_priv->psr.lock);
> >
> > intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] intel-gpu-top: Rewrite the tool to be safe to use
>Четверг, 29 марта 2018, 21:46 +03:00 от Tvrtko Ursulin :
>
>+#define engine_ptr(engines, n) \
>+((struct engine *)((unsigned char *)(&engines->engine) + (n) * sizeof(struct
>engine)))
I think (&engines->engine + (n)) is easier to read.
>+if (fd < 0 && !cnt->optional)
>+return -1;
I've tried to run it on Skylake on Linux 4.16, and intel_gpu_top is working, as
long as
I remove these lines. Otherwise it fails while trying "vcs1". Error message
says about
Linux 4.16, which is a bit confusing.
There are code that sets and tests "present" field of struct pmu_counter. So,
I guess, it's fine to remove the code, and thus make all counters optional?
>+
>+if (!cnt->present) {
>+strncpy(buf, "---", bufsz);
> return;
>+}
If you decide to make all counters optional, this will be used for "busy"
numbers
too. But "busy" is 6 characters wide, unlike "sema" and "wait", which are 3
each.
>--
>2.14.1
>
---
Rinat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Promote .format_mod_supported() to the lead role
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Up to now we've used the plane's modifier list as the primary
> source of information for which modifiers are supported by a
> given plane. In order to allow auxiliary metadata to be embedded
> within the bits of the modifier we need to stop doing that.
>
> Thus we have to make .format_mod_supported() aware of the plane's
> capabilities and gracefully deal with any modifier being passed
> in directly from userspace.
I took a look, and I think you have the chance to delete a whole ton of
code if you keep the assumption that the core will check that the format
is one of plane->format_types.
>
> Cc: Eric Anholt
> References:
> https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 147 +++---
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 194
> ++-
> 3 files changed, 210 insertions(+), 132 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3e7ab75e1b41..d717004be0b8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -88,15 +88,7 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> -static const uint64_t skl_format_modifiers_noccs[] = {
> - I915_FORMAT_MOD_Yf_TILED,
> - I915_FORMAT_MOD_Y_TILED,
> - I915_FORMAT_MOD_X_TILED,
> - DRM_FORMAT_MOD_LINEAR,
> - DRM_FORMAT_MOD_INVALID
> -};
> -
> -static const uint64_t skl_format_modifiers_ccs[] = {
> +static const uint64_t skl_format_modifiers[] = {
> I915_FORMAT_MOD_Yf_TILED_CCS,
> I915_FORMAT_MOD_Y_TILED_CCS,
> I915_FORMAT_MOD_Yf_TILED,
> @@ -12997,8 +12989,17 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
> }
>
> -static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +static bool i8xx_plane_format_mod_supported(struct drm_plane *_plane,
> + u32 format, u64 modifier)
> {
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + break;
> + default:
> + return false;
> + }
> +
I think you could just remove the format-dependent switch below in favor
of s/break/return true/. It's just a list of all the formats in
i8xx_primary_formats[].
> switch (format) {
> case DRM_FORMAT_C8:
> case DRM_FORMAT_RGB565:
> @@ -13011,8 +13012,17 @@ static bool i8xx_mod_supported(uint32_t format,
> uint64_t modifier)
> }
> }
>
> -static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +static bool i965_plane_format_mod_supported(struct drm_plane *_plane,
> + u32 format, u64 modifier)
> {
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + break;
> + default:
> + return false;
> + }
Again, there's no format dependence, so drop the switch statement, and
probably just reuse the mod_supported func from 8xx.
> +
> switch (format) {
> case DRM_FORMAT_C8:
> case DRM_FORMAT_RGB565:
> @@ -13027,17 +13037,37 @@ static bool i965_mod_supported(uint32_t format,
> uint64_t modifier)
> }
> }
>
> -static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +static bool skl_plane_format_mod_supported(struct drm_plane *_plane,
> +u32 format, u64 modifier)
> {
> + struct intel_plane *plane = to_intel_plane(_plane);
> +
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + case I915_FORMAT_MOD_Y_TILED:
> + case I915_FORMAT_MOD_Yf_TILED:
> + break;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + if (!plane->has_ccs)
> + return false;
> + break;
> + default:
> + return false;
> + }
> +
> switch (format) {
> case DRM_FORMAT_XRGB:
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_ARGB:
> case DRM_FORMAT_ABGR:
> - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> - return true;
> - /* fall through */
I think these SKL changes could have just been done with a "&&
plane->has_ccs" in this '-' area. I do think the new version is more
readable, though.
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED ||
> + modifier == I915_FORMAT_MOD_Y_TILED ||
> + modifier == I915_FORMAT_MOD_Yf_TILED ||
> + modifier == I915_FORMAT
Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
Francisco Jerez writes: > This series attempts to solve an energy efficiency problem of the > current active-mode non-HWP governor of the intel_pstate driver used > for the most part on low-power platforms. Under heavy IO load the > current controller tends to increase frequencies to the maximum turbo > P-state, partly due to IO wait boosting, partly due to the roughly > flat frequency response curve of the current controller (see > [6]), which causes it to ramp frequencies up and down repeatedly for > any oscillating workload (think of graphics, audio or disk IO when any > of them becomes a bottleneck), severely increasing energy usage > relative to a (throughput-wise equivalent) controller able to provide > the same average frequency without fluctuation. The core energy > efficiency improvement has been observed to be of the order of 20% via > RAPL, but it's expected to vary substantially between workloads (see > perf-per-watt comparison [2]). > > One might expect that this could come at some cost in terms of system > responsiveness, but the governor implemented in PATCH 6 has a variable > response curve controlled by a heuristic that keeps the controller in > a low-latency state unless the system is under heavy IO load for an > extended period of time. The low-latency behavior is actually > significantly more aggressive than the current governor, allowing it > to achieve better throughput in some scenarios where the load > ping-pongs between the CPU and some IO device (see PATCH 6 for more of > the rationale). The controller offers relatively lower latency than > the upstream one particularly while C0 residency is low (which by > itself contributes to mitigate the increased energy usage while on > C0). However under certain conditions the low-latency heuristic may > increase power consumption (see perf-per-watt comparison [2], the > apparent regressions are correlated with an increase in performance in > the same benchmark due to the use of the low-latency heuristic) -- If > this is a problem a different trade-off between latency and energy > usage shouldn't be difficult to achieve, but it will come at a > performance cost in some cases. I couldn't observe a statistically > significant increase in idle power consumption due to this behavior > (on BXT J3455): > > package-0 RAPL (W):XX ±0.14% x8 -> XX ±0.15% x9 > d=-0.04% ±0.14% p=61.73% > > [Absolute benchmark results are unfortunately omitted from this letter > due to company policies, but the percent change and Student's T > p-value are included above and in the referenced benchmark results] > > The most obvious impact of this series will likely be the overall > improvement in graphics performance on systems with an IGP integrated > into the processor package (though for the moment this is only enabled > on BXT+), because the TDP budget shared among CPU and GPU can > frequently become a limiting factor in low-power devices. On heavily > TDP-bound devices this series improves performance of virtually any > non-trivial graphics rendering by a significant amount (of the order > of the energy efficiency improvement for that workload assuming the > optimization didn't cause it to become non-TDP-bound). > > See [1]-[5] for detailed numbers including various graphics benchmarks > and a sample of the Phoronix daily-system-tracker. Some popular > graphics benchmarks like GfxBench gl_manhattan31 and gl_4 improve > between 5% and 11% on our systems. The exact improvement can vary > substantially between systems (compare the benchmark results from the > two different J3455 systems [1] and [3]) due to a number of factors, > including the ratio between CPU and GPU processing power, the behavior > of the userspace graphics driver, the windowing system and resolution, > the BIOS (which has an influence on the package TDP), the thermal > characteristics of the system, etc. > > Unigine Valley and Heaven improve by a similar factor on some systems > (see the J3455 results [1]), but on others the improvement is lower > because the benchmark fails to fully utilize the GPU, which causes the > heuristic to remain in low-latency state for longer, which leaves a > reduced TDP budget available to the GPU, which prevents performance > from increasing further. This can be avoided by using the alternative > heuristic parameters suggested in the commit message of PATCH 8, which > provide a lower IO utilization threshold and hysteresis for the > controller to attempt to save energy. I'm not proposing those for > upstream (yet) because they would also increase the risk for > latency-sensitive IO-heavy workloads to regress (like SynMark2 > OglTerrainFly* and some arguably poorly designed IPC-bound X11 > benchmarks). > > Discrete graphics aren't likely to experience that much of a visible > improvement from this, even though many non-IGP workloads *could* > benefit by reducing the system's energy usage while the discrete GPU > (or really, any
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Exec param to control data port coherency. (rev2)
== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev2) URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == Series 40181v2 drm/i915: Add Exec param to control data port coherency. https://patchwork.freedesktop.org/api/1.0/series/40181/revisions/2/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-cfl-s3) fdo#100368 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> FAIL (fi-ivb-3520m) k.org#198519 +2 fdo#102575 fdo#100368 k.org#198519 https://bugzilla.kernel.org/show_bug.cgi?id=198519 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:439s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:295s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:512s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:517s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:514s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-s3total:285 pass:258 dwarn:0 dfail:0 fail:1 skip:26 time:549s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:412s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:253 dwarn:0 dfail:0 fail:3 skip:29 time:422s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:659s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:597s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:533s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s ae8ce2cdcba75443f03f5f65fa1627a4e14481c9 drm-tip: 2018y-03m-30d-17h-40m-01s UTC integration manifest 415de02a8f37 drm/i915: Add Exec param to control data port coherency. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8551/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3: rebased
>
> drivers/gpu/drm/i915/i915_debugfs.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1dba2c451255..89dc5b05ec24 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> return "unknown";
> }
>
> +static const char *psr_sink_self_refresh_status(u8 val)
nit: psr_sink_status() is concise, "psr_self_refresh" sounds
redundant.
> +{
> + static const char * const sink_status[] = {
> + "inactive",
> + "transitioning to active",
We muddle the meaning of these statuses by paraphrasing, it is better
write these strings exactly as the states are defined in the spec.
> + "active",
> + "active receiving selective update",
For example, this state corresponds to the capture of full static frame
too.
Reviewed-by: Dhinakaran Pandiyan with
the nits addressed, thanks for the patch.
> + "transitioning to inactive",
> + "reserved",
> + "reserved",
> + "sink internal error"
> + };
> +
> + val &= DP_PSR_SINK_STATE_MASK;
> + if (val < ARRAY_SIZE(sink_status))
> + return sink_status[val];
> +
> + return "unknown";
> +}
> +
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> psr2, psr2_live_status(psr2));
> }
> +
> + if (dev_priv->psr.enabled) {
> + struct drm_dp_aux *aux = &dev_priv->psr.enabled->aux;
> + u8 val;
> +
> + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) == 1)
> + seq_printf(m, "Sink self refresh status: 0x%x [%s]\n",
> +val, psr_sink_self_refresh_status(val));
> + }
> mutex_unlock(&dev_priv->psr.lock);
>
> intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.
On 27/03/18 16:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.
This patch does not cover using the new preemption mechanism when GuC is
active.
Bspec: 18922
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 45 +++-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
5 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .has_hw_preempt_to_idle = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+ func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
#define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
#define GEN8_CTX_STATUS_COMPLETE (1 << 4)
#define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29)
#define GEN8_CTX_STATUS_COMPLETED_MASK \
(GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
{
- return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+ return (engine->i915->preempt_context ||
+ HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
Well, you haven't actually disabled allocating the preempt_context so...
But at any rate, making this an engine->flag would eliminate one pointer
dance.
Can't we re-use I915_SCHEDULER_CAP_PREEMPTION in
engine->i915->caps.scheduler? That btw like here to be set if
i915->preempt_context || HAS_HW_PREEMPT_TO_IDLE(i915)
+prio > max(rq_prio(last), 0);
}
/**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
}
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+*/
+ GEM_BUG_ON(execlists->ctrl_reg != NULL);
Shouldn't this check be the other way around?
+
+ /* trigger preemption to idle */
+ writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
Future plans? Because just inserting the branch into the setter of
inject_preempt_context() resolves a lot of conflicts with other work.
@@ -962,10 +987,13 @@ static void execlists_submission_tasklet(unsigned long
data)
status, buf[2*head + 1],
execl
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency. (rev2)
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev2)
URL : https://patchwork.freedesktop.org/series/40181/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
415de02a8f37 drm/i915: Add Exec param to control data port coherency.
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
coherency at data port level. Keeping the coherency at that level is disabled
-:175: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#175: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:2255:
+ DRM_DEBUG("Data Port Coherency is not available on
%s\n",
+eb.engine->name);
-:189: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#189: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:2388:
+ err = intel_lr_context_modify_data_port_coherency(eb.request,
+ (args->flags & I915_EXEC_DATA_PORT_COHERENT) != 0);
-:236: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#236: FILE: drivers/gpu/drm/i915/intel_lrc.c:290:
+intel_lr_context_modify_data_port_coherency(struct i915_request *req,
+ bool enable)
-:295: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#295: FILE: include/uapi/drm/i915_drm.h:1059:
+#define I915_EXEC_DATA_PORT_COHERENT (1<<20)
^
-:297: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#297: FILE: include/uapi/drm/i915_drm.h:1061:
+#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_DATA_PORT_COHERENT<<1))
^
total: 0 errors, 1 warnings, 5 checks, 135 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source
On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > For Geminilake and Cannonlake+ the Y-coordinate support must be
> > enabled in PSR2_CTL too.
> >
> > Spec: 7713 and 7720
> >
> > Cc: Dhinakaran Pandiyan
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> >
> > v3: rebased
> >
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > drivers/gpu/drm/i915/intel_psr.c | 16
> > 2 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 33e52cc98d99..9d61ab1288d3 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4058,6 +4058,8 @@ enum {
> > #define EDP_PSR2_CTL _MMIO(0x6f900)
> > #define EDP_PSR2_ENABLE (1<<31)
> > #define EDP_SU_TRACK_ENABLE (1<<30)
> > +#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> > +#define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+
> > */
> > #define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> > #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> > #define EDP_PSR2_TP2_TIME_500(0<<8)
> > @@ -7064,6 +7066,7 @@ enum {
> > #define CHICKEN_TRANS_A 0x420c0
> > #define CHICKEN_TRANS_B 0x420c4
> > #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
> > CHICKEN_TRANS_B)
> > +#define VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and
> > CNL+ */
> > #define DDI_TRAINING_OVERRIDE_ENABLE (1<<19)
> > #define DDI_TRAINING_OVERRIDE_VALUE (1<<18)
> > #define DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /*
> > CHICKEN_TRANS_A only */
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index fb2d0fe7106b..84e1f8be5c48 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > /* FIXME: selective update is probably totally broken
> > because it doesn't
> > * mesh at all with our frontbuffer tracking. And the hw
> > alone isn't
> > * good enough. */
> > - val |= EDP_PSR2_ENABLE |
> > - EDP_SU_TRACK_ENABLE;
> > + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > {
> > + val |= EDP_Y_COORDINATE_VALID |
> > EDP_Y_COORDINATE_ENABLE;
>
> Bspecs says Bit 26 : Y-coordinate valid
> 1b stands for "Do not include Y-coordinate valid eDP 1.4".
>
> Was "val |= EDP_Y_COORDINATE_VALID" intended?
Hum not intended, I will send a patch fixing it.
Thanks
>
>
> > + }
> >
> > if (drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_SYNCHRONIZATION_LATENCY_IN_SINK
> > ,
> > @@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct
> > intel_dp *intel_dp,
> > hsw_psr_setup_aux(intel_dp);
> >
> > if (dev_priv->psr.psr2_support) {
> > - u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> > - | PSR2_ADD_VERTICAL_LINE_COUNT;
> > + u32 chicken =
> > I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +
> > + if (INTEL_GEN(dev_priv) == 9 &&
> > !IS_GEMINILAKE(dev_priv))
> > + chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> > + |
> > PSR2_ADD_VERTICAL_LINE_COUNT);
> > +
> > + else
> > + chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
> > I915_WRITE(CHICKEN_TRANS(cpu_transcoder),
> > chicken);
> >
> > I915_WRITE(EDP_PSR_DEBUG,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed
On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote: > In the 2 eDP1.4a pannels tested set or not set bit have no effect > but is better set it and comply with specification. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan > Reviewed-by: Rodrigo Vivi patches 1-9 pushed to dinq. Thanks for patches and reviews. > --- > > v3: rebased > > drivers/gpu/drm/i915/intel_psr.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index d079cf0b034c..2d53f7398a6d 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -278,18 +278,19 @@ static void hsw_psr_enable_sink(struct intel_dp > *intel_dp) > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > struct drm_device *dev = dig_port->base.base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > + u8 dpcd_val = DP_PSR_ENABLE; > > /* Enable ALPM at sink for psr2 */ > if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm) > drm_dp_dpcd_writeb(&intel_dp->aux, > DP_RECEIVER_ALPM_CONFIG, > DP_ALPM_ENABLE); > + > + if (dev_priv->psr.psr2_enabled) > + dpcd_val |= DP_PSR_ENABLE_PSR2; > if (dev_priv->psr.link_standby) > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, > -DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE); > - else > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, > -DP_PSR_ENABLE); > + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE; > + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val); > > drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0); > } > -- > 2.16.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
>
> Spec: 7713 and 7720
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3: rebased
>
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_psr.c | 16
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 33e52cc98d99..9d61ab1288d3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4058,6 +4058,8 @@ enum {
> #define EDP_PSR2_CTL _MMIO(0x6f900)
> #define EDP_PSR2_ENABLE(1<<31)
> #define EDP_SU_TRACK_ENABLE(1<<30)
> +#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> #define EDP_PSR2_TP2_TIME_500 (0<<8)
> @@ -7064,6 +7066,7 @@ enum {
> #define CHICKEN_TRANS_A 0x420c0
> #define CHICKEN_TRANS_B 0x420c4
> #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
> CHICKEN_TRANS_B)
> +#define VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and CNL+ */
> #define DDI_TRAINING_OVERRIDE_ENABLE(1<<19)
> #define DDI_TRAINING_OVERRIDE_VALUE (1<<18)
> #define DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only
> */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index fb2d0fe7106b..84e1f8be5c48 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> + val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
Bspecs says Bit 26 : Y-coordinate valid
1b stands for "Do not include Y-coordinate valid eDP 1.4".
Was "val |= EDP_Y_COORDINATE_VALID" intended?
> + }
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> @@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct intel_dp
> *intel_dp,
> hsw_psr_setup_aux(intel_dp);
>
> if (dev_priv->psr.psr2_support) {
> - u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> - | PSR2_ADD_VERTICAL_LINE_COUNT;
> + u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> +
> + if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv))
> + chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> +| PSR2_ADD_VERTICAL_LINE_COUNT);
> +
> + else
> + chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
> I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
>
> I915_WRITE(EDP_PSR_DEBUG,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Add Exec param to control data port coherency.
The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it was in previous call for the context, a command to switch data port coherency state is added before the buffer to be executed. Rationale: The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is required. Below are answers to basic question explaining background of the functionality and reasoning for the proposed implementation: 1. Why do we need a coherency enable/disable switch for memory that is shared between CPU and GEN (GPU)? Memory coherency between CPU and GEN, while being a great feature that enables CL_MEM_SVM_FINE_GRAIN_BUFFER OCL capability on Intel GEN architecture, adds overhead related to tracking (snooping) memory inside different cache units (L1$, L2$, L3$, LLC$, etc.). At the same time, minority of modern OCL applications actually use CL_MEM_SVM_FINE_GRAIN_BUFFER (and hence require memory coherency between CPU and GPU). The goal of coherency enable/disable switch is to remove overhead of memory coherency when memory coherency is not needed. 2. Why do we need a global coherency switch? In order to support I/O commands from within EUs (Execution Units), Intel GEN ISA (GEN Instruction Set Assembly) contains dedicated "send" instructions. These send instructions provide several addressing models. One of these addressing models (named "stateless") provides most flexible I/O using plain virtual addresses (as opposed to buffer_handle+offset models). This "stateless" model is similar to regular memory load/store operations available on typical CPUs. Since this model provides I/O using arbitrary virtual addresses, it enables algorithmic designs that are based on pointer-to-pointer (e.g. buffer of pointers) concepts. For instance, it allows creating tree-like data structures such as: | NODE1 | | uint64_t data | +| | NODE* | NODE*| ++---+ / \ /\ | NODE2 || NODE3 | | uint64_t data || uint64_t data | +|+| | NODE* | NODE*|| NODE* | NODE*| ++---+++---+ Please note that pointers inside such structures can point to memory locations in different OCL allocations - e.g. NODE1 and NODE2 can reside in one OCL allocation while NODE3 resides in a completely separate OCL allocation. Additionally, such pointers can be shared with CPU (i.e. using SVM - Shared Virtual Memory feature). Using pointers from different allocations doesn't affect the stateless addressing model which even allows scattered reading from different allocations at the same time (i.e. by utilizing SIMD-nature of send instructions). When it comes to coherency programming, send instructions in stateless model can be encoded (at ISA level) to either use or disable coherency. However, for generic OCL applications (such as example with tree-like data structure), OCL compiler is not able to determine origin of memory pointed to by an arbitrary pointer - i.e. is not able to track given pointer back to a specific allocation. As such, it's not able to decide whether coherency is needed or not for specific pointer (or for specific I/O instruction). As a result, compiler encodes all stateless sends as coherent (doing otherwise would lead to functional issues resulting from data corruption). Please note that it would be possible to workaround this (e.g. based on allocations map and pointer bounds checking prior to each I/O instruction) but the performance cost of such workaround would be many times greater than the cost of keeping coherency always enabled. As such, enabling/disabling memory coherency at GEN ISA level is not feasible and alternative method is needed. Such alternative solution is to have a global coherency switch that allows disabling coherency for single (though entire) GPU submission. This is beneficial because this way we: * can enable (and pay for) coherency only in submissions that actually need coherency (submissions that use CL_MEM_SVM_FINE_GRAIN_BUFFER resources) * don't care about coherency at GEN ISA granularity (no performance impact) 3. Will coherency switch be used frequently? There are scenarios that will require frequent toggling of the coherency switch. E.g. an application has two OCL compute kernels: kern_master and kern_worker. kern_master uses, concurrently with CPU, some fine grain SVM resources (CL_MEM_SVM_F
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context
== Series Details == Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40961/ State : failure == Summary == Possible new issues: Test gem_ctx_param: Subgroup invalid-param-get: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Subgroup invalid-param-set: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Test gem_mmap_wc: Subgroup set-cache-level: pass -> SKIP (shard-snb) Test kms_cursor_crc: Subgroup cursor-64x64-dpms: pass -> FAIL (shard-snb) Known issues: Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 Subgroup flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw) fdo#100368 Subgroup flip-vs-panning-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#103821 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3496 pass:1830 dwarn:1 dfail:0 fail:9 skip:1655 time:12887s shard-hswtotal:3496 pass:1782 dwarn:1 dfail:0 fail:3 skip:1709 time:11615s shard-snbtotal:3496 pass:1371 dwarn:1 dfail:0 fail:8 skip:2116 time:7027s Blacklisted hosts: shard-kbltotal:3496 pass:1955 dwarn:1 dfail:0 fail:10 skip:1530 time:9345s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8550/shards.html ___ 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 [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context
== Series Details == Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40961/ State : success == Summary == Series 40961v1 series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context https://patchwork.freedesktop.org/api/1.0/series/40961/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> FAIL (fi-skl-guc) fdo#103191 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:511s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:510s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:590s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:425s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:424s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:506s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:657s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:446s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:532s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:511s fi-skl-guc total:285 pass:256 dwarn:0 dfail:0 fail:1 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:575s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:525s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:483s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest 7161c21aa08a drm/i915: Allow user control over preempt timeout on their important context c96747bc6976 drm/i915: Use a preemption timeout to enforce interactivity b85e8d84cd91 drm/i915/preemption: Select timeout when scheduling 9003b1d0a64a drm/i915/execlists: Try preempt-reset from softirq context 7f3c5b702350 drm/i915/execlists: Force preemption via reset on timeout 6ddb32ce734e drm/i915: Allow init_breadcrumbs to be used from irq context 33aa7c8491c9 drm/i915: Be irqsafe inside reset f719516f05ff drm/i915: Stop parking the signaler around reset 520b029fa706 drm/i915: Combine tasklet_kill and tasklet_disable 5cc163689f97 drm/i915/breadcrumbs: Keep the fake irq armed across reset 5cf71d272c49 drm/i915/selftests: Add basic sanitychecks for execlists fc3bcbc4574d drm/i915/execlists: Flush pending preemption events during reset 335269c0d938 drm/i915: Split execlists/guc reset prepartions 271227fad5d5 drm/i915: Move engine reset prepare/finish to backends 13502d2881e0 drm/i915/execlists: Refactor out complete_preempt_context() becb341ba47d drm/i915/execlists: Set queue priority from secondary port 17fe6b08c0bf drm/i915/execlists: Track begin/end of execlists submission sequences 33a1831a25b2 drm/i915/selftests: Avoid repeatedly harming the same innocent conte
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context
== Series Details ==
Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly
harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40961/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
33a1831a25b2 drm/i915/selftests: Avoid repeatedly harming the same innocent
context
17fe6b08c0bf drm/i915/execlists: Track begin/end of execlists submission
sequences
becb341ba47d drm/i915/execlists: Set queue priority from secondary port
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f6322eddaff7
("drm/i915/preemption: Allow preemption between submission ports")'
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
13502d2881e0 drm/i915/execlists: Refactor out complete_preempt_context()
271227fad5d5 drm/i915: Move engine reset prepare/finish to backends
335269c0d938 drm/i915: Split execlists/guc reset prepartions
fc3bcbc4574d drm/i915/execlists: Flush pending preemption events during reset
-:69: WARNING:LONG_LINE: line over 100 characters
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:907:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-:87: WARNING:LONG_LINE: line over 100 characters
#87: FILE: drivers/gpu/drm/i915/intel_lrc.c:921:
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
-:104: WARNING:LONG_LINE: line over 100 characters
#104: FILE: drivers/gpu/drm/i915/intel_lrc.c:935:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:105: WARNING:LONG_LINE: line over 100 characters
#105: FILE: drivers/gpu/drm/i915/intel_lrc.c:936:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
total: 0 errors, 4 warnings, 0 checks, 192 lines checked
5cf71d272c49 drm/i915/selftests: Add basic sanitychecks for execlists
-:43: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#43:
new file mode 100644
-:254: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'W' - possible side-effects?
#254: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:207:
+#define wedge_on_timeout(W, DEV, TIMEOUT) \
+ for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
+(W)->i915; \
+__fini_wedge((W)))
total: 0 errors, 1 warnings, 1 checks, 518 lines checked
5cc163689f97 drm/i915/breadcrumbs: Keep the fake irq armed across reset
520b029fa706 drm/i915: Combine tasklet_kill and tasklet_disable
-:39: WARNING:MEMORY_BARRIER: memory barrier without comment
#39: FILE: drivers/gpu/drm/i915/intel_lrc.c:1755:
+ smp_mb();
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
f719516f05ff drm/i915: Stop parking the signaler around reset
33aa7c8491c9 drm/i915: Be irqsafe inside reset
6ddb32ce734e drm/i915: Allow init_breadcrumbs to be used from irq context
7f3c5b702350 drm/i915/execlists: Force preemption via reset on timeout
-:228: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#228: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:515:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 241 lines checked
9003b1d0a64a drm/i915/execlists: Try preempt-reset from softirq context
-:115: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#115: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:600:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 176 lines checked
b85e8d84cd91 drm/i915/preemption: Select timeout when scheduling
c96747bc6976 drm/i915: Use a preemption timeout to enforce interactivity
7161c21aa08a drm/i915: Allow user control over preempt timeout on their
important context
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 05/17] drm/i915/guc/slpc: Add SLPC communication interfaces
On 3/30/2018 7:07 PM, Michal Wajdeczko wrote:
On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble
wrote:
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.h
b/drivers/gpu/drm/i915/intel_guc_slpc.h
index 66c76fe..81250c0 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.h
+++ b/drivers/gpu/drm/i915/intel_guc_slpc.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_GUC_SLPC_H_
#define _INTEL_GUC_SLPC_H_
+#include
Please use "" instead of <>
Yes. will hopefully not forget this next time :)
+
struct intel_guc_slpc {
};
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
new file mode 100644
index 000..9400af4
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
@@ -0,0 +1,211 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2015-2018 Intel Corporation
+ */
+#ifndef _INTEL_GUC_SLPC_FWIF_H_
+#define _INTEL_GUC_SLPC_FWIF_H_
+
+#include
+
+enum slpc_status {
s/slpc_status/intel_guc_slpc_status
I have done this because of following reasons:
1. GuC SLPC interface file shared by firmware team names enums/structs
as SLPM_* or SLPM_KMD_*. i understand that this isn't strict requirement. :)
2. INTEL_GUC_STATUS|EVENT|PARAM_* becomes more than 80 chars for some values
3. I wanted intel_guc_slpc_fwif.h to be included only in
intel_guc_slpc.c from where we can export functions as intel_guc_slpc_*
static functions in intel_guc_slpc.c are named as slpc_*.
In my series, point 3 above is not done but that was intent. There
is access to SLPC enums from debugfs.c. Would consolidate all in
intel_guc_slpc.c and export.
Does this plan look good?
+ SLPC_STATUS_OK = 0,
+ SLPC_STATUS_ERROR = 1,
+ SLPC_STATUS_ILLEGAL_COMMAND = 2,
+ SLPC_STATUS_INVALID_ARGS = 3,
+ SLPC_STATUS_INVALID_PARAMS = 4,
+ SLPC_STATUS_INVALID_DATA = 5,
+ SLPC_STATUS_OUT_OF_RANGE = 6,
+ SLPC_STATUS_NOT_SUPPORTED = 7,
+ SLPC_STATUS_NOT_IMPLEMENTED = 8,
+ SLPC_STATUS_NO_DATA = 9,
+ SLPC_STATUS_EVENT_NOT_REGISTERED = 10,
+ SLPC_STATUS_REGISTER_LOCKED = 11,
+ SLPC_STATUS_TEMPORARILY_UNAVAILABLE = 12,
+ SLPC_STATUS_VALUE_ALREADY_SET = 13,
+ SLPC_STATUS_VALUE_ALREADY_UNSET = 14,
+ SLPC_STATUS_VALUE_NOT_CHANGED = 15,
+ SLPC_STATUS_MEMIO_ERROR = 16,
+ SLPC_STATUS_EVENT_QUEUED_REQ_DPC = 17,
+ SLPC_STATUS_EVENT_QUEUED_NOREQ_DPC = 18,
+ SLPC_STATUS_NO_EVENT_QUEUED = 19,
+ SLPC_STATUS_OUT_OF_SPACE = 20,
+ SLPC_STATUS_TIMEOUT = 21,
+ SLPC_STATUS_NO_LOCK = 22,
+ SLPC_STATUS_MAX
s/SLPC_STATUS/INTEL_GUC_SLPC_STATUS
+};
+
+enum slpc_event_id {
s/slpc_event_id/intel_guc_slpc_event
+ SLPC_EVENT_RESET = 0,
+ SLPC_EVENT_SHUTDOWN = 1,
+ SLPC_EVENT_PLATFORM_INFO_CHANGE = 2,
+ SLPC_EVENT_DISPLAY_MODE_CHANGE = 3,
+ SLPC_EVENT_FLIP_COMPLETE = 4,
+ SLPC_EVENT_QUERY_TASK_STATE = 5,
+ SLPC_EVENT_PARAMETER_SET = 6,
+ SLPC_EVENT_PARAMETER_UNSET = 7,
s/SLPC_EVENT/INTEL_GUC_SLPC_EVENT
+};
+
+enum slpc_param_id {
s/slpc_param_id/intel_guc_slpc_param
+ SLPC_PARAM_TASK_ENABLE_GTPERF = 0,
+ SLPC_PARAM_TASK_DISABLE_GTPERF = 1,
+ SLPC_PARAM_TASK_ENABLE_BALANCER = 2,
+ SLPC_PARAM_TASK_DISABLE_BALANCER = 3,
+ SLPC_PARAM_TASK_ENABLE_DCC = 4,
+ SLPC_PARAM_TASK_DISABLE_DCC = 5,
+ SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ = 6,
+ SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ = 7,
+ SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ = 8,
+ SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ = 9,
+ SLPC_PARAM_GTPERF_THRESHOLD_MAX_FPS = 10,
+ SLPC_PARAM_GLOBAL_DISABLE_GT_FREQ_MANAGEMENT = 11,
+ SLPC_PARAM_GTPERF_ENABLE_FRAMERATE_STALLING = 12,
+ SLPC_PARAM_GLOBAL_DISABLE_RC6_MODE_CHANGE = 13,
+ SLPC_PARAM_GLOBAL_OC_UNSLICE_FREQ_MHZ = 14,
+ SLPC_PARAM_GLOBAL_OC_SLICE_FREQ_MHZ = 15,
+ SLPC_PARAM_GLOBAL_ENABLE_IA_GT_BALANCING = 16,
+ SLPC_PARAM_GLOBAL_ENABLE_ADAPTIVE_BURST_TURBO = 17,
+ SLPC_PARAM_GLOBAL_ENABLE_EVAL_MODE = 18,
+ SLPC_PARAM_GLOBAL_ENABLE_BALANCER_IN_NON_GAMING_MODE = 19,
s/SLPC_PARAM/INTEL_GUC_SLPC_PARAM
+ SLPC_MAX_PARAM,
+ SLPC_KMD_MAX_PARAM = 32,
hmm, do we really need these two ? please drop
or maybe these are related to SLPC_MAX_OVERRIDE_PARAMETERS ?
Ok. Will drop SLPC_KMD_MAX_PARAM.
There are total 192 params (MAX_OVERRIDE_PARAMS) out of which 32
(KMD_MAX_PARAM) params can be exposed
to KMD, but currently only params till MAX_PARAM < 32 are exported.
+};
+
+enum slpc_global_state {
s/slpc_global_state/intel_guc_slpc_state
+ SLPC_GLOBAL_STATE_NOT_RUNNING = 0,
+ SLPC_GLOBAL_STATE_INITIALIZING = 1,
+ SLPC_GLOBAL_STATE_RESETTING = 2,
+ SLPC_GLOBAL_STATE_RUNNING = 3,
+ SLPC_GLOBAL_STATE_SHUTTING_DOWN = 4,
+ SLPC_GLOBAL_STATE_ERROR = 5
s/SLPC_GLOBAL_STATE/INTEL_GUC_SLPC_STATE
+};
+
+enum slpc_platform_sku {
+ SLPC_PLATFORM_SKU_UNDEFINED = 0,
+ SLPC_PLATFORM_SKU_ULX = 1,
+ SLPC_PLATFORM_SKU_ULT = 2,
+ SLPC_PLATFORM_SKU_T = 3,
+ SLPC_PLATFORM_SKU_MOBL = 4,
+ SLPC_PLATFORM_SKU_DT = 5,
+ SLPC_PLATFORM
[Intel-gfx] [PATCH 15/18] drm/i915/execlists: Try preempt-reset from softirq context
When circumstances allow, trying resetting the engine directly from the
preemption timeout handler. As this is softirq context, we have to be
careful both not to sleep and not to spin on anything we may be
interrupting (e.g. the submission tasklet).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 31 +++-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 121 +
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bee8a58f340f..fea275f718f5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -549,6 +549,33 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
+static int try_preempt_reset(struct intel_engine_execlists *execlists)
+{
+ struct intel_engine_cs *engine =
+ container_of(execlists, typeof(*engine), execlists);
+ int err = -EBUSY;
+
+ if (!test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted) &&
+ tasklet_trylock(&execlists->tasklet)) {
+ unsigned long *lock = &engine->i915->gpu_error.flags;
+ unsigned int bit = I915_RESET_ENGINE + engine->id;
+
+ if (!test_and_set_bit(bit, lock)) {
+ tasklet_disable_nosync(&engine->execlists.tasklet);
+ err = i915_reset_engine(engine,
+ "preemption time out");
+ tasklet_enable(&engine->execlists.tasklet);
+
+ clear_bit(bit, lock);
+ wake_up_bit(lock, bit);
+ }
+
+ tasklet_unlock(&execlists->tasklet);
+ }
+
+ return err;
+}
+
static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
{
struct intel_engine_execlists *execlists =
@@ -562,7 +589,9 @@ static enum hrtimer_restart preempt_timeout(struct hrtimer
*hrtimer)
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT))
return HRTIMER_NORESTART;
- queue_work(system_highpri_wq, &execlists->preempt_reset);
+ if (try_preempt_reset(execlists))
+ queue_work(system_highpri_wq, &execlists->preempt_reset);
+
return HRTIMER_NORESTART;
}
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index a8f2491eab1d..cd97a6461ec7 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -560,6 +560,126 @@ static int live_preempt_timeout(void *arg)
return err;
}
+static void __softirq_begin(void)
+{
+ local_bh_disable();
+}
+
+static void __softirq_end(void)
+{
+ local_bh_enable();
+}
+
+static void __hardirq_begin(void)
+{
+ local_irq_disable();
+}
+
+static void __hardirq_end(void)
+{
+ local_irq_enable();
+}
+
+static int live_preempt_reset(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ struct spinner spin;
+ int err = -ENOMEM;
+
+ if (!HAS_LOGICAL_RING_PREEMPTION(i915))
+ return 0;
+
+ mutex_lock(&i915->drm.struct_mutex);
+
+ if (spinner_init(&spin, i915))
+ goto err_unlock;
+
+ ctx= kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ for_each_engine(engine, i915, id) {
+ static const struct {
+ const char *name;
+ void (*critical_section_begin)(void);
+ void (*critical_section_end)(void);
+ } phases[] = {
+ { "softirq", __softirq_begin, __softirq_end },
+ { "hardirq", __hardirq_begin, __hardirq_end },
+ { }
+ };
+ const typeof(*phases) *p;
+
+ for (p = phases; p->name; p++) {
+ struct i915_request *rq;
+
+ rq = spinner_create_request(&spin, ctx, engine,
+ MI_NOOP);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ctx;
+ }
+
+ i915_request_add(rq);
+ if (!wait_for_spinner(&spin, rq)) {
+ i915_gem_set_wedged(i915);
+ err = -EIO;
+ goto err_ctx;
+ }
+
+ /* Flush to give try_preempt_reset a chance */
+ do {
+ tasklet_schedule(&engine->ex
[Intel-gfx] [PATCH 03/18] drm/i915/execlists: Set queue priority from secondary port
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
to evaluate the need for preemption. However, we only want to preempt if
we need to jump ahead of a currently executing request in ELSP. The
second reason for running the submission tasklet is amalgamate requests
into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
(Though repeatedly amalgamating requests into the active context and
triggering many lite-restore is off question gain, the goal really is to
put a context into ELSP[1] to cover the interrupt.) So if instead of
looking at the head of the queue, we look at the context in ELSP[1] we
can answer both of the questions more accurately -- we don't need to
rerun the submission tasklet unless our new request is important enough
to feed into, at least, ELSP[1].
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2d2d33becce3..a3fd9683f9d1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -712,7 +712,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
kmem_cache_free(engine->i915->priorities, p);
}
done:
- execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
+ execlists->queue_priority =
+ port != execlists->port ? rq_prio(last) : INT_MIN;
execlists->first = rb;
if (submit)
port_assign(port, last);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/18] drm/i915: Allow user control over preempt timeout on their important context
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22
drivers/gpu/drm/i915/i915_gem_context.h| 13 +
drivers/gpu/drm/i915/i915_request.c| 8 ++-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 85 ++
include/uapi/drm/i915_drm.h| 12 +
6 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..dfb0a2b698c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -749,6 +749,15 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+ case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:
+ if (!(to_i915(dev)->caps.scheduler &
I915_SCHEDULER_CAP_PREEMPTION))
+ ret = -ENODEV;
+ else if (args->size)
+ ret = -EINVAL;
+ else
+ args->value = ctx->preempt_timeout;
+ break;
+
default:
ret = -EINVAL;
break;
@@ -824,6 +833,19 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
}
break;
+ case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:
+ if (args->size)
+ ret = -EINVAL;
+ else if (args->value >= NSEC_PER_SEC)
+ ret = -EINVAL;
+ else if (!(to_i915(dev)->caps.scheduler &
I915_SCHEDULER_CAP_PREEMPTION))
+ ret = -ENODEV;
+ else if (args->value && !capable(CAP_SYS_ADMIN))
+ ret = -EPERM;
+ else
+ ctx->preempt_timeout = args->value;
+ break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 7854262ddfd9..74d4cadd729e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -150,6 +150,19 @@ struct i915_gem_context {
*/
int priority;
+ /**
+* @preempt_timeout: QoS guarantee for the high priority context
+*
+* Some clients need a guarantee that they will start executing
+* within a certain window, even at the expense of others. This entails
+* that if a preemption request is not honoured by the active context
+* within the timeout, we will reset the GPU to evict the hog and
+* run the high priority context instead.
+*
+* Timeout is stored in nanoseconds; exclusive max of 1s.
+*/
+ u32 preempt_timeout;
+
/** ggtt_offset_bias: placement restriction for context objects */
u32 ggtt_offset_bias;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index cdda3ebd51e2..eae807e56723 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1107,8 +1107,12 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
* run at the earliest possible convenience.
*/
rcu_read_lock();
- if (engine->schedule)
- engine->schedule(request, request->ctx->priority, 0);
+ if (engine->schedule) {
+ unsigned int timeout = request->ctx->preempt_timeout;
+ int priority = request->ctx->priority;
+
+ engine->schedule(request, priority, timeout);
+ }
rcu_read_unlock();
local_bh_disable();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06a4815f5f31..e87181f88f96 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1212,7 +1212,7 @@ static void execlists_submit_request(struct i915_request
*request)
spin_lock_irqsave(&engine->timeline->lock, flags);
queue_request(engine, &request->priotree, rq_prio(request));
- submit_queue(engine, rq_prio(request), 0);
+ submit_queue(engine, rq_prio(request), request->ctx->preempt_timeout);
GEM_BUG_ON(!engine->execlists.first);
GEM_BUG_ON(list_empty(&request->priotree.link));
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 1970a4658c5c..121180b87fd7 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -783,6 +783,90 @@ static int live_late_preempt_timeout(void *arg)
goto err_ctx_lo;
}
+static int live_context_preempt_timeout(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_gem_context *ctx_hi, *ctx_
[Intel-gfx] [PATCH 08/18] drm/i915/selftests: Add basic sanitychecks for execlists
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +
.../gpu/drm/i915/selftests/i915_live_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/intel_lrc.c | 506 +
3 files changed, 511 insertions(+)
create mode 100644 drivers/gpu/drm/i915/selftests/intel_lrc.c
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6217118633fd..cba1ecda126a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2693,3 +2693,7 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
}
}
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftests/intel_lrc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index 9c76f0305b6a..8bf6aa573226 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -20,4 +20,5 @@ selftest(evict, i915_gem_evict_live_selftests)
selftest(hugepages, i915_gem_huge_page_live_selftests)
selftest(contexts, i915_gem_context_live_selftests)
selftest(hangcheck, intel_hangcheck_live_selftests)
+selftest(execlists, intel_execlists_live_selftests)
selftest(guc, intel_guc_live_selftest)
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
new file mode 100644
index ..ef3d739e0a15
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -0,0 +1,506 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "../i915_selftest.h"
+
+#include "mock_context.h"
+
+struct spinner {
+ struct drm_i915_private *i915;
+ struct drm_i915_gem_object *hws;
+ struct drm_i915_gem_object *obj;
+ u32 *batch;
+ void *seqno;
+};
+
+static int spinner_init(struct spinner *spin, struct drm_i915_private *i915)
+{
+ void *vaddr;
+ int err;
+
+ GEM_BUG_ON(INTEL_GEN(i915) < 8);
+
+ memset(spin, 0, sizeof(*spin));
+ spin->i915 = i915;
+
+ spin->hws = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(spin->hws)) {
+ err = PTR_ERR(spin->hws);
+ goto err;
+ }
+
+ spin->obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(spin->obj)) {
+ err = PTR_ERR(spin->obj);
+ goto err_hws;
+ }
+
+ i915_gem_object_set_cache_level(spin->hws, I915_CACHE_LLC);
+ vaddr = i915_gem_object_pin_map(spin->hws, I915_MAP_WB);
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ goto err_obj;
+ }
+ spin->seqno = memset(vaddr, 0xff, PAGE_SIZE);
+
+ vaddr = i915_gem_object_pin_map(spin->obj,
+ HAS_LLC(i915) ? I915_MAP_WB :
I915_MAP_WC);
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ goto err_unpin_hws;
+ }
+ spin->batch = vaddr;
+
+ return 0;
+
+err_unpin_hws:
+ i915_gem_object_unpin_map(spin->hws);
+err_obj:
+ i915_gem_object_put(spin->obj);
+err_hws:
+ i915_gem_object_put(spin->hws);
+err:
+ return err;
+}
+
+static unsigned int seqno_offset(u64 fence)
+{
+ return offset_in_page(sizeof(u32) * fence);
+}
+
+static u64 hws_address(const struct i915_vma *hws,
+ const struct i915_request *rq)
+{
+ return hws->node.start + seqno_offset(rq->fence.context);
+}
+
+static int emit_recurse_batch(struct spinner *spin,
+ struct i915_request *rq,
+ u32 arbitration_command)
+{
+ struct i915_address_space *vm = &rq->ctx->ppgtt->base;
+ struct i915_vma *hws, *vma;
+ u32 *batch;
+ int err;
+
+ vma = i915_vma_instance(spin->obj, vm, NULL);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ hws = i915_vma_instance(spin->hws, vm, NULL);
+ if (IS_ERR(hws))
+ return PTR_ERR(hws);
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ return err;
+
+ err = i915_vma_pin(hws, 0, 0, PIN_USER);
+ if (err)
+ goto unpin_vma;
+
+ i915_vma_move_to_active(vma, rq, 0);
+ if (!i915_gem_object_has_active_reference(vma->obj)) {
+ i915_gem_object_get(vma->obj);
+ i915_gem_object_set_active_reference(vma->obj);
+ }
+
+ i915_vma_move_to_active(hws, rq, 0);
+ if (!i915_gem_object_has_active_reference(hws->obj)) {
+ i915_gem_object_get(hws->obj);
+ i915_gem_object_set_active_ref
[Intel-gfx] [PATCH 07/18] drm/i915/execlists: Flush pending preemption events during reset
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 127 +++
1 file changed, 87 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5c1324c37549..6217118633fd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -889,34 +889,14 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
local_irq_restore(flags);
}
-/*
- * Check the unread Context Status Buffers and manage the submission of new
- * contexts to the ELSP accordingly.
- */
-static void execlists_submission_tasklet(unsigned long data)
+static void process_csb(struct intel_engine_cs *engine)
{
- struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *dev_priv = engine->i915;
+ struct drm_i915_private *i915 = engine->i915;
bool fw = false;
- /*
-* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
- GEM_BUG_ON(!dev_priv->gt.awake);
-
- /*
-* Prefer doing test_and_clear_bit() as a two stage operation to avoid
-* imposing the cost of a locked atomic transaction when submitting a
-* new request (outside of the context-switch interrupt).
-*/
- while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
+ do {
/* The HWSP contains a (cacheable) mirror of the CSB */
const u32 *buf =
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
@@ -924,28 +904,27 @@ static void execlists_submission_tasklet(unsigned long
data)
if (unlikely(execlists->csb_use_mmio)) {
buf = (u32 * __force)
- (dev_priv->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
- execlists->csb_head = -1; /* force mmio read of CSB
ptrs */
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ execlists->csb_head = -1; /* force mmio read of CSB */
}
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_head == -1)) { /* following a reset
*/
+ if (unlikely(execlists->csb_head == -1)) { /* after a reset */
if (!fw) {
- intel_uncore_forcewake_get(dev_priv,
-
execlists->fw_domains);
+ intel_uncore_forcewake_get(i915,
execlists->fw_domains);
fw = true;
}
- head = readl(dev_priv->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
execlists->csb_head = head;
} else {
const int write_idx =
- intel_hws_csb_write_index(dev_priv) -
+ intel_hws_csb_write_index(i915) -
I915_HWS_CSB_BUF0_INDEX;
head = execlists->csb_head;
@@ -953,8 +932,8 @@ static void execlists_submission_tasklet(unsigned long data)
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
engine->name,
- head, GEN8_CSB_READ_PTR(readl(dev_priv->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine,
[Intel-gfx] [PATCH 17/18] drm/i915: Use a preemption timeout to enforce interactivity
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being banned from submitting future requests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 18 ++
drivers/gpu/drm/i915/intel_display.c | 18 +-
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230ba1c3b..87388feb973d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3150,8 +3150,9 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
struct intel_rps_client *rps);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- int priority);
+ int priority, unsigned int timeout);
#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
+#define I915_PREEMPTION_TIMEOUT_DISPLAY (20 * 1000 * 1000) /* 20 ms */
int __must_check
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a860d501134e..3760133ca08e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -469,7 +469,8 @@ i915_gem_object_wait_reservation(struct reservation_object
*resv,
return timeout;
}
-static void __fence_set_priority(struct dma_fence *fence, int prio)
+static void __fence_set_priority(struct dma_fence *fence,
+int prio, unsigned int timeout)
{
struct i915_request *rq;
struct intel_engine_cs *engine;
@@ -482,11 +483,12 @@ static void __fence_set_priority(struct dma_fence *fence,
int prio)
rcu_read_lock();
if (engine->schedule)
- engine->schedule(rq, prio, 0);
+ engine->schedule(rq, prio, timeout);
rcu_read_unlock();
}
-static void fence_set_priority(struct dma_fence *fence, int prio)
+static void fence_set_priority(struct dma_fence *fence,
+ int prio, unsigned int timeout)
{
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -494,16 +496,16 @@ static void fence_set_priority(struct dma_fence *fence,
int prio)
int i;
for (i = 0; i < array->num_fences; i++)
- __fence_set_priority(array->fences[i], prio);
+ __fence_set_priority(array->fences[i], prio, timeout);
} else {
- __fence_set_priority(fence, prio);
+ __fence_set_priority(fence, prio, timeout);
}
}
int
i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- int prio)
+ int prio, unsigned int timeout)
{
struct dma_fence *excl;
@@ -518,7 +520,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object
*obj,
return ret;
for (i = 0; i < count; i++) {
- fence_set_priority(shared[i], prio);
+ fence_set_priority(shared[i], prio, timeout);
dma_fence_put(shared[i]);
}
@@ -528,7 +530,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object
*obj,
}
if (excl) {
- fence_set_priority(excl, prio);
+ fence_set_priority(excl, prio, timeout);
dma_fence_put(excl);
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 415fb8cf2cf4..8ce2019746cc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12788,7 +12788,23 @@ intel_prepare_plane_fb(struct drm_plane *plane,
ret = intel_plane_pin_fb(to_intel_plane_state(new_state));
- i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+ /*
+* Reschedule our dependencies, and ensure we run within a timeout.
+*
+* Note that if the timeout is exceeded, then whoever was running that
+* prevented us from acquiring the GPU is declared rogue and reset. An
+* unresponsive process will then be banned in order to preserve
+* interactivity. Since this can be seen as a bit heavy-handed, we
+* select a timeout for when the dropped frames start to become a
+* noticeable nuisance for the user (20 ms, i.e. preemption was blocked
+* for more than a frame). Note, this is only a timeout for a delay in
+* preempting the curre
[Intel-gfx] [PATCH 09/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting an engine.
It also allows us to react better to the user poking around debugfs for
testing missed irqs.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 671a6d61e29d..0a2128c6b418 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -130,11 +130,12 @@ static void intel_breadcrumbs_hangcheck(struct timer_list
*t)
static void intel_breadcrumbs_fake_irq(struct timer_list *t)
{
- struct intel_engine_cs *engine = from_timer(engine, t,
- breadcrumbs.fake_irq);
+ struct intel_engine_cs *engine =
+ from_timer(engine, t, breadcrumbs.fake_irq);
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- /* The timer persists in case we cannot enable interrupts,
+ /*
+* The timer persists in case we cannot enable interrupts,
* or if we have previously seen seqno/interrupt incoherency
* ("missed interrupt" syndrome, better known as a "missed breadcrumb").
* Here the worker will wake up every jiffie in order to kick the
@@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct timer_list
*t)
if (!b->irq_armed)
return;
+ /* If the user has disabled the fake-irq, restore the hangchecking */
+ if (!test_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings)) {
+ mod_timer(&b->hangcheck, wait_timeout());
+ return;
+ }
+
mod_timer(&b->fake_irq, jiffies + 1);
}
@@ -840,15 +847,22 @@ void intel_engine_reset_breadcrumbs(struct
intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- cancel_fake_irq(engine);
spin_lock_irq(&b->irq_lock);
+ /*
+* Leave the fake_irq timer enabled (if it is running), but clear the
+* bit so that it turns itself off on its next wake up and goes back
+* to the long hangcheck interval if still required.
+*/
+ clear_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
+
if (b->irq_enabled)
irq_enable(engine);
else
irq_disable(engine);
- /* We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
+ /*
+* We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
* GPU is active and may have already executed the MI_USER_INTERRUPT
* before the CPU is ready to receive. However, the engine is currently
* idle (we haven't started it yet), there is no possibility for a
@@ -857,9 +871,6 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
*/
clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- if (b->irq_armed)
- enable_fake_irq(b);
-
spin_unlock_irq(&b->irq_lock);
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/18] drm/i915/execlists: Force preemption via reset on timeout
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
v2: Install the timer on scheduling the preempt request; long before we
even try to inject preemption into the ELSP, as the tasklet/injection
may itself be blocked.
v3: Update the guc to handle the preemption/tasklet timer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++
drivers/gpu/drm/i915/intel_lrc.c| 82 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 ++-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 66 +++
4 files changed, 151 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 0e0655430480..d10068579285 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -627,6 +627,9 @@ static void complete_preempt_context(struct intel_engine_cs
*engine)
GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT);
+ hrtimer_try_to_cancel(&execlists->preempt_timer);
+
execlists_cancel_port_requests(execlists);
execlists_unwind_incomplete_requests(execlists);
@@ -739,6 +742,7 @@ static void guc_dequeue(struct intel_engine_cs *engine)
kmem_cache_free(engine->i915->priorities, p);
}
done:
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT);
execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
execlists->first = rb;
if (submit) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 731f8de56ea0..bee8a58f340f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -549,10 +549,50 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
+static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
+{
+ struct intel_engine_execlists *execlists =
+ container_of(hrtimer, typeof(*execlists), preempt_timer);
+
+ GEM_TRACE("%s\n",
+ container_of(execlists,
+ struct intel_engine_cs,
+ execlists)->name);
+
+ if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT))
+ return HRTIMER_NORESTART;
+
+ queue_work(system_highpri_wq, &execlists->preempt_reset);
+ return HRTIMER_NORESTART;
+}
+
+static void preempt_reset(struct work_struct *work)
+{
+ struct intel_engine_execlists *execlists =
+ container_of(work, typeof(*execlists), preempt_reset);
+ struct intel_engine_cs *engine =
+ container_of(execlists, struct intel_engine_cs, execlists);
+
+ GEM_TRACE("%s\n", engine->name);
+
+ tasklet_disable(&execlists->tasklet);
+
+ execlists->tasklet.func(execlists->tasklet.data);
+
+ if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT))
+ i915_handle_error(engine->i915, BIT(engine->id), 0,
+ "preemption time out on %s", engine->name);
+
+ tasklet_enable(&execlists->tasklet);
+}
+
static void complete_preempt_context(struct intel_engine_execlists *execlists)
{
GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT);
+ hrtimer_try_to_cancel(&execlists->preempt_timer);
+
execlists_cancel_port_requests(execlists);
execlists_unwind_incomplete_requests(execlists);
@@ -722,6 +762,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
kmem_cache_free(engine->i915->priorities, p);
}
done:
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT_TIMEOUT);
execlists->queue_priority =
port != execlists->port ? rq_prio(last) : INT_MIN;
execlists->first = rb;
@@ -1099,16 +1140,38 @@ static void queue_request(struct intel_engine_cs
*engine,
list_add_tail(&pt->link, &lookup_priolist(engine, pt, prio)->requests);
}
-static void __submit_queue(struct intel_engine_cs *engine, int prio)
+static void __submit_queue(struct intel_engine_cs *engine,
+ int prio, unsigned int timeout)
{
- engine->execlists.queue_priority = prio;
- tasklet_hi_schedule(&engine->execlists.tasklet);
+ struct intel_engine_execlists * const execlists = &engine->execlists;
+ int old = execlists->queue_priority;
+
+ GEM_TRACE("%s prio=%d (previous=%d)\n", engine->name, prio, old);
+
+ i
[Intel-gfx] [PATCH 12/18] drm/i915: Be irqsafe inside reset
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a6acb1d5ad3..a866fe304de1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3041,15 +3041,17 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
*/
request = i915_gem_find_active_request(engine);
if (request) {
+ unsigned long flags;
+
i915_gem_context_mark_innocent(request->ctx);
dma_fence_set_error(&request->fence, -EAGAIN);
/* Rewind the engine to replay the incomplete rq */
- spin_lock_irq(&engine->timeline->lock);
+ spin_lock_irqsave(&engine->timeline->lock, flags);
request = list_prev_entry(request, link);
if (&request->link == &engine->timeline->requests)
request = NULL;
- spin_unlock_irq(&engine->timeline->lock);
+ spin_unlock_irqrestore(&engine->timeline->lock, flags);
}
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/18] drm/i915/execlists: Track begin/end of execlists submission sequences
We would like to start doing some bookkeeping at the beginning, between
contexts and at the end of execlists submission. We already mark the
beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
when the HW is idle. This give us a pair of sequence points we can then
expand on for further bookkeeping.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Francisco Jerez
---
drivers/gpu/drm/i915/intel_lrc.c| 42 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 -
2 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f60b61bf8b3b..2d2d33becce3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -374,6 +374,19 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
+static inline void
+execlists_user_begin(struct intel_engine_execlists *execlists,
+const struct execlist_port *port)
+{
+ execlists_set_active_once(execlists, EXECLISTS_ACTIVE_USER);
+}
+
+static inline void
+execlists_user_end(struct intel_engine_execlists *execlists)
+{
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
+}
+
static inline void
execlists_context_schedule_in(struct i915_request *rq)
{
@@ -711,7 +724,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
spin_unlock_irq(&engine->timeline->lock);
if (submit) {
- execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
+ execlists_user_begin(execlists, execlists->port);
execlists_submit_ports(engine);
}
@@ -742,7 +755,7 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
port++;
}
- execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
+ execlists_user_end(execlists);
}
static void clear_gtiir(struct intel_engine_cs *engine)
@@ -873,7 +886,7 @@ static void execlists_submission_tasklet(unsigned long data)
{
struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = &engine->execlists;
- struct execlist_port * const port = execlists->port;
+ struct execlist_port *port = execlists->port;
struct drm_i915_private *dev_priv = engine->i915;
bool fw = false;
@@ -1012,9 +1025,19 @@ static void execlists_submission_tasklet(unsigned long
data)
GEM_BUG_ON(count == 0);
if (--count == 0) {
+ /*
+* On the final event corresponding to the
+* submission of this context, we expect either
+* an element-switch event or a completion
+* event (and on completion, the active-idle
+* marker). No more preemptions, lite-restore
+* or otherwise
+*/
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
GEM_BUG_ON(port_isset(&port[1]) &&
!(status &
GEN8_CTX_STATUS_ELEMENT_SWITCH));
+ GEM_BUG_ON(!port_isset(&port[1]) &&
+ !(status &
GEN8_CTX_STATUS_ACTIVE_IDLE));
GEM_BUG_ON(!i915_request_completed(rq));
execlists_context_schedule_out(rq);
trace_i915_request_out(rq);
@@ -1023,17 +1046,14 @@ static void execlists_submission_tasklet(unsigned long
data)
GEM_TRACE("%s completed ctx=%d\n",
engine->name, port->context_id);
- execlists_port_complete(execlists, port);
+ port = execlists_port_complete(execlists, port);
+ if (port_isset(port))
+ execlists_user_begin(execlists, port);
+ else
+ execlists_user_end(execlists);
} else {
port_set(port, port_pack(rq, count));
}
-
- /* After the final element, the hw should be idle */
- GEM_BUG_ON(port_count(port) == 0 &&
- !(status & GEN8_CTX_STATUS_ACTIVE_IDLE));
- if (port_count(port) == 0)
- execlists_clear_active(execlists,
- EXECLISTS_ACTIVE_USER);
}
if (head != execlists->csb_head) {
[Intel-gfx] [PATCH 16/18] drm/i915/preemption: Select timeout when scheduling
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
triggered preemption for the dependency chain, we can assume that no
preemption along that chain is more important than the current request,
ergo we need only consider the current timeout. Realising this, we can
then pass control of the preemption timeout to the caller for greater
flexibility.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 106 -
5 files changed, 114 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a866fe304de1..a860d501134e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -482,7 +482,7 @@ static void __fence_set_priority(struct dma_fence *fence,
int prio)
rcu_read_lock();
if (engine->schedule)
- engine->schedule(rq, prio);
+ engine->schedule(rq, prio, 0);
rcu_read_unlock();
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 585242831974..cdda3ebd51e2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1108,7 +1108,7 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
*/
rcu_read_lock();
if (engine->schedule)
- engine->schedule(request, request->ctx->priority);
+ engine->schedule(request, request->ctx->priority, 0);
rcu_read_unlock();
local_bh_disable();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fea275f718f5..06a4815f5f31 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1240,7 +1240,8 @@ pt_lock_engine(struct i915_priotree *pt, struct
intel_engine_cs *locked)
return engine;
}
-static void execlists_schedule(struct i915_request *request, int prio)
+static void execlists_schedule(struct i915_request *request,
+ int prio, unsigned int timeout)
{
struct intel_engine_cs *engine;
struct i915_dependency *dep, *p;
@@ -1336,7 +1337,7 @@ static void execlists_schedule(struct i915_request
*request, int prio)
if (prio > engine->execlists.queue_priority &&
i915_sw_fence_done(&pt_to_request(pt)->submit))
- __submit_queue(engine, prio, 0);
+ __submit_queue(engine, prio, timeout);
}
spin_unlock_irq(&engine->timeline->lock);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 80c303bb54c8..1e85123534a8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -463,13 +463,15 @@ struct intel_engine_cs {
*/
void(*submit_request)(struct i915_request *rq);
- /* Call when the priority on a request has changed and it and its
+ /*
+* Call when the priority on a request has changed and it and its
* dependencies may need rescheduling. Note the request itself may
* not be ready to run!
*
* Called under the struct_mutex.
*/
- void(*schedule)(struct i915_request *request, int priority);
+ void(*schedule)(struct i915_request *request,
+ int priority, unsigned int timeout);
/*
* Cancel all requests on the hardware, or queued for execution.
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index cd97a6461ec7..1970a4658c5c 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -457,7 +457,7 @@ static int live_late_preempt(void *arg)
goto err_wedged;
}
- engine->schedule(rq, I915_PRIORITY_MAX);
+ engine->schedule(rq, I915_PRIORITY_MAX, 0);
if (!wait_for_spinner(&spin_hi, rq)) {
pr_err("High priority context failed to preempt the low
priority context\n");
@@ -680,6 +680,109 @@ static int live_preempt_reset(void *arg)
return err;
}
+static int live_late_preempt_timeout(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_gem_context *ctx_hi, *ctx_lo;
+ struct spinner spin_hi, spin_lo;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
[Intel-gfx] [PATCH 06/18] drm/i915: Split execlists/guc reset prepartions
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_submission.c | 41 +
drivers/gpu/drm/i915/intel_lrc.c| 11 +---
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ef2e29959c5b..0e0655430480 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -784,6 +784,46 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
}
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists * const execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*
+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to prevent
+* a race between reset and set-wedged. It is not, so we do the best
+* we can atm and make sure we don't lock the machine up in the more
+* common case of recursively being called from set-wedged from inside
+* i915_reset.
+*/
+ if (!atomic_read(&execlists->tasklet.count))
+ tasklet_kill(&execlists->tasklet);
+ tasklet_disable(&execlists->tasklet);
+
+ /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+ if (engine->i915->guc.preempt_wq)
+ flush_workqueue(engine->i915->guc.preempt_wq);
+
+ return i915_gem_find_active_request(engine);
+}
+
/*
* Everything below here is concerned with setup & teardown, and is
* therefore not part of the somewhat time-critical batch-submission
@@ -1243,6 +1283,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
&engine->execlists;
execlists->tasklet.func = guc_submission_tasklet;
+ engine->reset.prepare = guc_reset_prepare;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 42f9af625e88..5c1324c37549 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1759,16 +1759,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
tasklet_kill(&execlists->tasklet);
tasklet_disable(&execlists->tasklet);
- /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
- if (engine->i915->guc.preempt_wq)
- flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
}
@@ -2158,6 +2148,7 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->cancel_requests = execlists_cancel_requests;
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
+ engine->reset.prepare = execlists_reset_prepare;
engine->park = NULL;
engine->unpark = NULL;
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/18] drm/i915: Allow init_breadcrumbs to be used from irq context
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 0a2128c6b418..ca0b04d9747c 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -846,8 +846,9 @@ static void cancel_fake_irq(struct intel_engine_cs *engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
- spin_lock_irq(&b->irq_lock);
+ spin_lock_irqsave(&b->irq_lock, flags);
/*
* Leave the fake_irq timer enabled (if it is running), but clear the
@@ -871,7 +872,7 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
*/
clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- spin_unlock_irq(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
}
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/18] drm/i915: Combine tasklet_kill and tasklet_disable
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the tasklet abuse into its own function and tweak it such that
we only do a synchronous operation the first time it is disabled around
the reset. This allows us to avoid the sync inside a softirq context in
subsequent patches.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cba1ecda126a..8fe9e62c5d18 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1745,6 +1745,16 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
return init_workarounds_ring(engine);
}
+static void tasklet_kill_and_disable(struct tasklet_struct *t)
+{
+ if (!atomic_read(&t->count))
+ tasklet_kill(t);
+
+ if (atomic_inc_return(&t->count) == 1)
+ tasklet_unlock_wait(t);
+ smp_mb();
+}
+
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -1769,9 +1779,7 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
* common case of recursively being called from set-wedged from inside
* i915_reset.
*/
- if (!atomic_read(&execlists->tasklet.count))
- tasklet_kill(&execlists->tasklet);
- tasklet_disable(&execlists->tasklet);
+ tasklet_kill_and_disable(&execlists->tasklet);
/*
* We want to flush the pending context switches, having disabled
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/18] drm/i915: Stop parking the signaler around reset
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so that the GPU doesn't emit the breadcrumb for our chosen
"guilty" request.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/intel_lrc.c| 21 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++
3 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 038867c96809..8a6acb1d5ad3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2928,18 +2928,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
*/
intel_uncore_forcewake_get(engine->i915, FORCEWAKE_ALL);
- /*
-* Prevent the signaler thread from updating the request
-* state (by calling dma_fence_signal) as we are processing
-* the reset. The write from the GPU of the seqno is
-* asynchronous and the signaler thread may see a different
-* value to us and declare the request complete, even though
-* the reset routine have picked that request as the active
-* (incomplete) request. This conflict is not handled
-* gracefully!
-*/
- kthread_park(engine->breadcrumbs.signaler);
-
request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
@@ -3136,8 +3124,6 @@ void i915_gem_reset_finish_engine(struct intel_engine_cs
*engine)
{
engine->reset.finish(engine);
- kthread_unpark(engine->breadcrumbs.signaler);
-
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8fe9e62c5d18..731f8de56ea0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1755,6 +1755,21 @@ static void tasklet_kill_and_disable(struct
tasklet_struct *t)
smp_mb();
}
+static void set_stop_engine(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+ const i915_reg_t mode = RING_MI_MODE(base);
+
+ GEM_TRACE("%s\n", engine->name);
+ I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
+ if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, MODE_IDLE,
+1000, 0,
+NULL))
+ GEM_TRACE("%s: timed out on STOP_RING -> IDLE\n", engine->name);
+}
+
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -1801,6 +1816,12 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
if (request) {
unsigned long flags;
+ /*
+* Prevent the breadcrumb from advancing before we decide
+* which request is currently active.
+*/
+ set_stop_engine(engine);
+
spin_lock_irqsave(&engine->timeline->lock, flags);
list_for_each_entry_from_reverse(request,
&engine->timeline->requests,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5dadbc435c0e..226c00aecd8a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -530,8 +530,26 @@ static int init_ring_common(struct intel_engine_cs *engine)
return ret;
}
+static void set_stop_engine(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+ const i915_reg_t mode = RING_MI_MODE(base);
+
+ I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
+ if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, MODE_IDLE,
+1000, 0,
+NULL))
+ DRM_DEBUG_DRIVER("%s: timed out on STOP_RING\n",
+engine->name);
+}
+
static struct i915_request *reset_prepare(struct intel_engine_cs *engine)
{
+ if (INTEL_GEN(engine->i915) >= 3)
+ set_stop_engine(engine);
+
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 04/18] drm/i915/execlists: Refactor out complete_preempt_context()
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Reviewed-by: Jeff McGee #v1
---
drivers/gpu/drm/i915/intel_guc_submission.c | 26 +-
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
2 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 207cda062626..ef2e29959c5b 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -621,6 +621,21 @@ static void wait_for_guc_preempt_report(struct
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
}
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+ execlists_cancel_port_requests(execlists);
+ execlists_unwind_incomplete_requests(execlists);
+
+ wait_for_guc_preempt_report(engine);
+ intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
/**
* guc_submit() - Submit commands through GuC
* @engine: engine associated with the commands
@@ -762,15 +777,8 @@ static void guc_submission_tasklet(unsigned long data)
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
- GUC_PREEMPT_FINISHED) {
- execlists_cancel_port_requests(&engine->execlists);
- execlists_unwind_incomplete_requests(execlists);
-
- wait_for_guc_preempt_report(engine);
-
- execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
- intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
- }
+ GUC_PREEMPT_FINISHED)
+ complete_preempt_context(engine);
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a3fd9683f9d1..51e930323626 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -545,8 +545,18 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
- execlists_clear_active(&engine->execlists, EXECLISTS_ACTIVE_HWACK);
- execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+ execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
+static void complete_preempt_context(struct intel_engine_execlists *execlists)
+{
+ GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+ execlists_cancel_port_requests(execlists);
+ execlists_unwind_incomplete_requests(execlists);
+
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -994,14 +1004,7 @@ static void execlists_submission_tasklet(unsigned long
data)
if (status & GEN8_CTX_STATUS_COMPLETE &&
buf[2*head + 1] ==
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
-
- execlists_cancel_port_requests(execlists);
- execlists_unwind_incomplete_requests(execlists);
-
- GEM_BUG_ON(!execlists_is_active(execlists,
-
EXECLISTS_ACTIVE_PREEMPT));
- execlists_clear_active(execlists,
-
EXECLISTS_ACTIVE_PREEMPT);
+ complete_preempt_context(execlists);
continue;
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/18] drm/i915: Move engine reset prepare/finish to backends
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_gem.c | 47 +++---
drivers/gpu/drm/i915/intel_lrc.c| 59 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +++--
4 files changed, 88 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b10c5f..038867c96809 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2917,7 +2917,7 @@ static bool engine_stalled(struct intel_engine_cs *engine)
struct i915_request *
i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
{
- struct i915_request *request = NULL;
+ struct i915_request *request;
/*
* During the reset sequence, we must prevent the engine from
@@ -2940,40 +2940,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
*/
kthread_park(engine->breadcrumbs.signaler);
- /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*
-* Note that this needs to be a single atomic operation on the
-* tasklet (flush existing tasks, prevent new tasks) to prevent
-* a race between reset and set-wedged. It is not, so we do the best
-* we can atm and make sure we don't lock the machine up in the more
-* common case of recursively being called from set-wedged from inside
-* i915_reset.
-*/
- if (!atomic_read(&engine->execlists.tasklet.count))
- tasklet_kill(&engine->execlists.tasklet);
- tasklet_disable(&engine->execlists.tasklet);
-
- /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
- if (engine->i915->guc.preempt_wq)
- flush_workqueue(engine->i915->guc.preempt_wq);
-
- if (engine->irq_seqno_barrier)
- engine->irq_seqno_barrier(engine);
-
- request = i915_gem_find_active_request(engine);
+ request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
@@ -3114,13 +3081,8 @@ void i915_gem_reset_engine(struct intel_engine_cs
*engine,
if (request)
request = i915_gem_reset_request(engine, request);
- if (request) {
- DRM_DEBUG_DRIVER("resetting %s to restart from tail of request
0x%x\n",
-engine->name, request->global_seqno);
- }
-
/* Setup the CS to resume from the breadcrumb of the hung request */
- engine->reset_hw(engine, request);
+ engine->reset.reset(engine, request);
}
void i915_gem_reset(struct drm_i915_private *dev_priv)
@@ -3172,7 +3134,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
{
- tasklet_enable(&engine->execlists.tasklet);
+ engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 51e930323626..42f9af625e88 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1732,8 +1732,48 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
return init_workarounds_ring(engine);
}
-static void reset_common_ring(struct intel_engine_cs *engine,
- struct i915_request *request)
+static struct i915_request *
+execlists_reset_prepare(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists * const execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second
[Intel-gfx] [PATCH 01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrumb. This is really only a problem for the selftest as
normally there is a large interlude between resets (hangcheck), or we
focus on resetting just one engine and so avoid repeatedly resetting
innocents.
Something to try would be a preempt-to-idle to quiesce the engine before
reset, so that innocent contexts would be spared the reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 48 ++--
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d354627882e3..684060ed8db6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1886,6 +1886,8 @@ void i915_reset(struct drm_i915_private *i915)
int ret;
int i;
+ GEM_TRACE("flags=%lx\n", error->flags);
+
might_sleep();
lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags));
@@ -2016,6 +2018,7 @@ int i915_reset_engine(struct intel_engine_cs *engine,
const char *msg)
struct i915_request *active_request;
int ret;
+ GEM_TRACE("%s flags=%lx\n", engine->name, error->flags);
GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, &error->flags));
active_request = i915_gem_reset_prepare_engine(engine);
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 9e4e0ad62724..d03abe7f8a53 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -979,6 +979,23 @@ static int igt_wait_reset(void *arg)
return err;
}
+static int wait_for_others(struct drm_i915_private *i915,
+ struct intel_engine_cs *exclude)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, i915, id) {
+ if (engine == exclude)
+ continue;
+
+ if (wait_for(intel_engine_is_idle(engine), 10))
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int igt_reset_queue(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1027,13 +1044,36 @@ static int igt_reset_queue(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
+ /*
+* XXX We don't handle resetting the kernel context
+* very well. If we trigger a device reset twice in
+* quick succession while the kernel context is
+* executing, we may end up skipping the breadcrumb.
+* This is really only a problem for the selftest as
+* normally there is a large interlude between resets
+* (hangcheck), or we focus on resetting just one
+* engine and so avoid repeatedly resetting innocents.
+*/
+ err = wait_for_others(i915, engine);
+ if (err) {
+ pr_err("%s(%s): Failed to idle other inactive
engines after device reset\n",
+ __func__, engine->name);
+ i915_request_put(rq);
+ i915_request_put(prev);
+
+ GEM_TRACE_DUMP();
+ i915_gem_set_wedged(i915);
+ goto fini;
+ }
+
if (!wait_for_hang(&h, prev)) {
struct drm_printer p =
drm_info_printer(i915->drm.dev);
- pr_err("%s: Failed to start request %x, at
%x\n",
- __func__, prev->fence.seqno,
hws_seqno(&h, prev));
- intel_engine_dump(prev->engine, &p,
- "%s\n", prev->engine->name);
+ pr_err("%s(%s): Failed to start request %x, at
%x\n",
+ __func__, engine->name,
+ prev->fence.seqno, hws_seqno(&h, prev));
+ intel_engine_dump(engine, &p,
+ "%s\n", engine->name);
i915_request_put(rq);
i915_request_put(prev)
[Intel-gfx] Preemption reset from timer; CI now 110% happier
Fixed up the couple of bugs in the selftests that CI was tripping over, or so I hope... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.
On 2018-03-29 00:28, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-28 17:06:58)
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.
This patch does not cover using the new preemption mechanism when GuC is
active.
Bspec: 18922
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 45
+++-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
5 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .has_hw_preempt_to_idle = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+ func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
#define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
#define GEN8_CTX_STATUS_COMPLETE (1 << 4)
#define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29)
#define GEN8_CTX_STATUS_COMPLETED_MASK \
(GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
{
- return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+ return (engine->i915->preempt_context ||
+ HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
Well, you haven't actually disabled allocating the preempt_context so...
Yes.. I had mixed feelings about changing needs_preempt_context() now,
as that would mean adding a temporary condition on GuC until the GuC
preemption is merged.
I will add the conditions and disable the allocation in v2 of the patch.
But at any rate, making this an engine->flag would eliminate one pointer
dance.
Could be an interesting idea for a separate patch.
To land first ;)
:)
Sure, I can do that.
+prio > max(rq_prio(last), 0);
}
/**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
}
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+*/
+ GEM_BUG_ON(execlists->ctrl_reg != NULL);
+
+ /* trigger preemption to idle */
+ writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
Future plans? Because just inserting the branch into the setter of
inject_preempt_contex
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable
== Series Details == Series: series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40952/ State : failure == Summary == Series 40952v1 series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable https://patchwork.freedesktop.org/api/1.0/series/40952/revisions/1/mbox/ Possible new issues: Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c-frame-sequence: pass -> FAIL (fi-skl-guc) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:533s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:515s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:579s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:423s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:314s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:470s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:660s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:285 pass:256 dwarn:0 dfail:0 fail:1 skip:28 time:427s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:513s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest 660298fe1189 trace: Mention trace_clock=global when warning about unstable clocks 935d891f5719 trace: Default to using trace_global_clock if sched_clock is unstable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8549/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 01/17] drm/i915/guc/slpc: Add SLPC control to enable_guc modparam
Thanks for the review. Will update with all suggestions in the next rev.
On 3/30/2018 6:07 PM, Michal Wajdeczko wrote:
On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
GuC is currently being used for submission and HuC authentication.
Choices can be configured through enable_guc modparam. GuC SLPC is GT
Power and Performance management feature in GuC. Add another option to
enable_guc modparam to control SLPC.
v1: Add early call to sanitize enable_guc_slpc in intel_guc_ucode_init
Remove sanitize enable_guc_slpc call before firmware version check
is performed. (ChrisW)
Version check is added in next patch and that will be done as part
of slpc_enable_sanitize function in the next patch. (Sagar) Updated
slpc option sanitize function call for platforms without GuC
support.
This was caught by CI BAT.
v2: Changed parameter to dev_priv for HAS_SLPC macro. (David)
Code indentation based on checkpatch.
v3: Rebase.
v4: Moved sanitization of SLPC option post GuC load.
v5: Removed function intel_slpc_enabled. Planning to rely only on kernel
parameter. Moved sanitization prior to GuC load to use the parameter
during SLPC state setup during to GuC load. (Sagar)
v6: Commit message update. Rebase.
v7: Moved SLPC option sanitization to intel_uc_sanitize_options.
v8: Clearing SLPC option on GuC load failure. Change moved from later
patch. (Sagar)
v9: s/enable_slpc/enable_guc_slpc. Rebase w.r.t modparam change.
v10: Rebase. Separate modparam is not needed now that we maintain all
options in single param enable_guc.
Suggested-by: Paulo Zanoni
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_uc.c | 23 +++
drivers/gpu/drm/i915/intel_uc.h | 6 ++
4 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..40b799b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -150,9 +150,10 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
"2=default swing(400mV))");
i915_param_named_unsafe(enable_guc, int, 0400,
- "Enable GuC load for GuC submission and/or HuC load. "
+ "Enable GuC load for GuC submission and/or HuC load and/or GuC
SLPC. "
"Required functionality can be selected using bitmask values. "
- "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+ "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load, "
+ "4=GuC SLPC)");
Maybe to avoid later surprise, we should explicitly say that:
+ "4=GuC SLPC [requires GuC submission])");
i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..2484925 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -32,6 +32,7 @@ struct drm_printer;
#define ENABLE_GUC_SUBMISSION BIT(0)
#define ENABLE_GUC_LOAD_HUC BIT(1)
+#define ENABLE_GUC_SLPC BIT(2)
#define I915_PARAMS_FOR_EACH(param) \
param(char *, vbt_firmware, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 1cffaf7..0e4a97f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -56,9 +56,15 @@ static int __get_platform_enable_guc(struct
drm_i915_private *dev_priv)
struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
int enable_guc = 0;
- /* Default is to enable GuC/HuC if we know their firmwares */
- if (intel_uc_fw_is_selected(guc_fw))
+ /*
+ * Default is to enable GuC submission/SLPC/HuC if we know their
+ * firmwares
+ */
+ if (intel_uc_fw_is_selected(guc_fw)) {
enable_guc |= ENABLE_GUC_SUBMISSION;
+ enable_guc |= ENABLE_GUC_SLPC;
+ }
+
if (intel_uc_fw_is_selected(huc_fw))
enable_guc |= ENABLE_GUC_LOAD_HUC;
@@ -110,10 +116,11 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
if (i915_modparams.enable_guc < 0)
i915_modparams.enable_guc =
__get_platform_enable_guc(dev_priv);
- DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
+ DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s slpc:%s)\n",
i915_modparams.enable_guc,
yesno(intel_uc_is_using_guc_submission()),
- yesno(intel_uc_is_using_huc()));
+ yesno(intel_uc_is_using_huc()),
+ yesno(intel_uc_is_using_guc_slpc()));
/* Verify GuC firmware availability */
if (intel_uc_is_using_guc() && !intel_uc_fw_is_selected(guc_fw)) {
@@ -123,6 +130,14
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable
== Series Details == Series: series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40952/ State : warning == Summary == $ dim checkpatch origin/drm-tip 935d891f5719 trace: Default to using trace_global_clock if sched_clock is unstable -:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #17: Delta way too big! 18446743856563626466 ts=18446744054496180323 write stamp = 197932553857 -:47: WARNING:PREFER_PR_LEVEL: Prefer [subsystem eg: netdev]_warn([subsystem]dev, ... then dev_warn(dev, ... then pr_warn(... to printk(KERN_WARNING ... #47: FILE: kernel/trace/trace.c:8515: + printk(KERN_WARNING total: 0 errors, 2 warnings, 0 checks, 28 lines checked 660298fe1189 trace: Mention trace_clock=global when warning about unstable clocks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks
Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson Cc: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index dcf1c4dd3efe..88098d7fac06 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -2637,7 +2637,8 @@ rb_handle_timestamp(struct ring_buffer_per_cpu *cpu_buffer, sched_clock_stable() ? "" : "If you just came from a suspend/resume,\n" "please switch to the trace global clock:\n" - " echo global > /sys/kernel/debug/tracing/trace_clock\n"); + " echo global > /sys/kernel/debug/tracing/trace_clock\n" + "or add trace_clock=global to the kernel command line\n"); info->add_timestamp = 1; } -- 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable
Across suspend, we may see a very large drift in timestamps if the sched
clock is unstable, prompting the global trace's ringbuffer code to warn
and suggest switching to the global clock. Preempt this request by
detecting when the sched clock is unstable (determined during
late_initcall) and automatically switching the default clock over to
trace_global_clock.
This should prevent requiring user interaction to resolve warnings such
as:
Delta way too big! 18446743856563626466 ts=18446744054496180323 write stamp
= 197932553857
If you just came from a suspend/resume,
please switch to the trace global clock:
echo global > /sys/kernel/debug/tracing/trace_clock
Signed-off-by: Chris Wilson
Cc: Steven Rostedt (VMware)
---
v2: Tell the user what's happening and what they can do to correct it.
---
kernel/trace/trace.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 13baf85b27d8..7c155fa879e1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include "trace.h"
@@ -8505,3 +8506,21 @@ __init static int clear_boot_tracer(void)
fs_initcall(tracer_init_tracefs);
late_initcall_sync(clear_boot_tracer);
+
+#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
+__init static int tracing_set_default_clock(void)
+{
+ /* sched_clock_stable() is determined in late_initcall */
+ if (trace_boot_clock || sched_clock_stable()) {
+ printk(KERN_WARNING
+ "Unstable clock detected, switching default tracing
clock to \"global\"\n"
+ "If you want to keep using the local clock, then add:\n"
+ " \"trace_clock=local\"\n"
+ "on the kernel command line\n");
+ tracing_set_clock(&global_trace, "global");
+ }
+
+ return 0;
+}
+late_initcall_sync(tracing_set_default_clock);
+#endif
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
Hi Tvrtko,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180329]
[cannot apply to v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tvrtko-Ursulin/drm-i915-execlists-Consistent-seqno-reporting-in-GEM_TRACE/20180330-120802
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x0-03302126 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/interrupt.h:6:0,
from drivers/gpu//drm/i915/intel_lrc.c:134:
drivers/gpu//drm/i915/intel_lrc.c: In function
'execlists_cancel_port_requests':
>> drivers/gpu//drm/i915/intel_lrc.c:730:13: error: format '%lu' expects
>> argument of type 'long unsigned int', but argument 3 has type 'int'
>> [-Werror=format=]
GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
^
include/linux/kernel.h:635:33: note: in definition of macro
'__trace_printk_check_format'
trace_printk_check_format(fmt, ##args); \
^
include/linux/kernel.h:672:3: note: in expansion of macro 'do_trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__); \
^
drivers/gpu//drm/i915/i915_gem.h:55:24: note: in expansion of macro
'trace_printk'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
drivers/gpu//drm/i915/intel_lrc.c:730:3: note: in expansion of macro
'GEM_TRACE'
GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
^
drivers/gpu//drm/i915/intel_lrc.c:730:13: error: format '%lu' expects
argument of type 'long unsigned int', but argument 4 has type 'int'
[-Werror=format=]
GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
^
include/linux/kernel.h:688:29: note: in definition of macro 'do_trace_printk'
__trace_printk(_THIS_IP_, fmt, ##args); \
^
drivers/gpu//drm/i915/i915_gem.h:55:24: note: in expansion of macro
'trace_printk'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
drivers/gpu//drm/i915/intel_lrc.c:730:3: note: in expansion of macro
'GEM_TRACE'
GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
^
cc1: all warnings being treated as errors
vim +730 drivers/gpu//drm/i915/intel_lrc.c
720
721 void
722 execlists_cancel_port_requests(struct intel_engine_execlists * const
execlists)
723 {
724 struct execlist_port *port = execlists->port;
725 unsigned int num_ports = execlists_num_ports(execlists);
726
727 while (num_ports-- && port_isset(port)) {
728 struct i915_request *rq = port_request(port);
729
> 730 GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
731rq->engine->name, port - execlists->port,
732rq->fence.context, rq->fence.seqno,
rq->global_seqno);
733
734 GEM_BUG_ON(!execlists->active);
735 intel_engine_context_out(rq->engine);
736
737 execlists_context_status_change(rq,
738
i915_request_completed(rq) ?
739
INTEL_CONTEXT_SCHEDULE_OUT :
740
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
741
742 i915_request_put(rq);
743
744 memset(port, 0, sizeof(*port));
745 port++;
746 }
747 }
748
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/24] drm_framebuffer boilerplate removal
On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: > Hi, > I've been working on a getfb2[0] ioctl, which amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support multiple planes. > > Thanks to Noralf's recent work, drivers can just store GEM objects > directly in drm_framebuffer. I use this directly in getfb2: we need > direct access to the GEM objects and not a vfunc in order to not hand > out duplicate GEM names for the same object. > > This series converts all drivers except for nouveau, which was a > little too non-trivial for my comfort, to storing GEM objects directly > in drm_framebuffer. For those drivers whose driver_framebuffer struct > was nothing but drm_framebuffer + BO, it deletes the driver-specific > struct. It also makes use of Noralf's generic framebuffer helpers for > create_handle and destroy where possible. > > I don't have the hardware for most of these drivers, so have had to > settle for just staring really hard at the diff. > > I intend to remove create_handle when all drivers are converted over > to placing BOs directly inside drm_framebuffer. For most drivers > there's a relatively easy conversion to using the helpers for > basically all framebuffer handling and fbdev emulation as well, though > that's a bit further than I was willing to go without hardware to test > on ... Series is: Acked-by: Alex Deucher > > Cheers, > Daniel > > [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable
On Fri, 30 Mar 2018 15:07:53 +0100 Chris Wilson wrote: > Sure, I was mainly floating the idea of trying to pick sensible > defaults. Unstable clocks are quite rare nowadays, the ones we have in > the lab are a pair of Core2 Duo. I still have a box too ;-) I'm not so against having global_clock become default if the TSC is unstable. But there needs to be a printk warning (not a WARN, but something like: Warning: TSC unstable, switching tracing_clock default to "global" If you want to keep local, then add "trace_clock=local" on the kernel command line. -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Avoid repeatedly harming the same innocent context
== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup cursor-vs-flip-atomic-transitions: pass -> FAIL (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbcpsr-2p-scndscrn-spr-indfb-move: skip -> FAIL (shard-snb) Subgroup fbcpsr-rgb101010-draw-render: skip -> FAIL (shard-snb) Subgroup psr-2p-primscrn-spr-indfb-onoff: skip -> FAIL (shard-snb) Test kms_plane_lowres: Subgroup pipe-a-tiling-none: pass -> FAIL (shard-snb) Test kms_vblank: Subgroup pipe-a-query-idle: pass -> FAIL (shard-snb) Known issues: Test gem_softpin: Subgroup noreloc-s3: pass -> INCOMPLETE (shard-snb) fdo#103375 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 Subgroup flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw) fdo#100368 Test kms_setmode: Subgroup basic: fail -> PASS (shard-apl) fdo#99912 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-apltotal:3495 pass:1833 dwarn:1 dfail:0 fail:6 skip:1655 time:12857s shard-hswtotal:3495 pass:1783 dwarn:1 dfail:0 fail:1 skip:1709 time:11682s shard-snbtotal:3398 pass:1320 dwarn:1 dfail:0 fail:10 skip:2066 time:6563s Blacklisted hosts: shard-kbltotal:3495 pass:1958 dwarn:1 dfail:0 fail:8 skip:1528 time:9256s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8548/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Hi,
On 30-03-18 15:25, Hans de Goede wrote:
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)
Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.
Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.
The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...
Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.
We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.
Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.
To elaborate on this, the excluding of the first 4k of the stolen memory
region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
which in turn causes intel_find_initial_plane_obj() to call
intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
completely turns off the display which leads to a very ugly flickering
of the display at boot (as well as replacing the vendor logo with a
black screen).
I think we can all agree that this behavior is undesirable and even a
regression in behavior caused by the fix to exclude the first 4k.
Chris, if my patch is not an acceptable way to fix this, then how do you
suggest that we fix this?
Digging a bit deeper I found this:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol16-workarounds.pdf
Which says:
"WaSkipStolenMemoryFirstPage:
WA to skip the first page of stolen
memory due to sporadic HW write on *CS Idle"
And also about FBC:
"First line of FBC getting corrupted when FBC
compressed frame buffer offset is programmed to
zero. Command streamers are doing flush writes to
base of stolen.
WA: New restriction to program FBC compressed
frame buffer offset to at least 4KB."
So using the first 4kB for the *framebuffer* as done by the GOP will
not cause any major problems (freezes, hangs, etc.), and commit
d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") was correct in deducing that the problem was
likely that some *vital* information was being stored i the first 4k
and that go
[Intel-gfx] [PATCH 00/24] drm_framebuffer boilerplate removal
Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects directly in drm_framebuffer. I use this directly in getfb2: we need direct access to the GEM objects and not a vfunc in order to not hand out duplicate GEM names for the same object. This series converts all drivers except for nouveau, which was a little too non-trivial for my comfort, to storing GEM objects directly in drm_framebuffer. For those drivers whose driver_framebuffer struct was nothing but drm_framebuffer + BO, it deletes the driver-specific struct. It also makes use of Noralf's generic framebuffer helpers for create_handle and destroy where possible. I don't have the hardware for most of these drivers, so have had to settle for just staring really hard at the diff. I intend to remove create_handle when all drivers are converted over to placing BOs directly inside drm_framebuffer. For most drivers there's a relatively easy conversion to using the helpers for basically all framebuffer handling and fbdev emulation as well, though that's a bit further than I was willing to go without hardware to test on ... Cheers, Daniel [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable
Quoting Steven Rostedt (2018-03-30 14:48:45) > On Thu, 29 Mar 2018 23:25:57 +0100 > Chris Wilson wrote: > > > Across suspend, we may see a very large drift in timestamps if the sched > > clock is unstable, prompting the global trace's ringbuffer code to warn > > and suggest switching to the global clock. Preempt this request by > > detecting when the sched clock is unstable (determined during > > late_initcall) and automatically switching the default clock over to > > trace_global_clock. > > > > This should prevent requiring user interaction to resolve warnings such > > as: > > > > Delta way too big! 18446743856563626466 ts=18446744054496180323 write > > stamp = 197932553857 > > If you just came from a suspend/resume, > > please switch to the trace global clock: > > echo global > /sys/kernel/debug/tracing/trace_clock > > global clock has a much higher overhead than the local clock. I rather > not have it automatically switch even when there's no stable TSC. That > will be annoying to myself as I have boxes that this would switch on > and I prefer to keep the local clock. My counter argument would be that it comes as a bit of a shock to the user to find out their debugging session was rendered invalid because the tracer chose to use a clock that it knew was unsuitable for the job. :) > One can also decide the clock with the kernel command line. Should we > update that message to also say: > > Or set the global clock via the kernel command line with > "trace_clock=global" > > ? Sure, I was mainly floating the idea of trying to pick sensible defaults. Unstable clocks are quite rare nowadays, the ones we have in the lab are a pair of Core2 Duo. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable
On Thu, 29 Mar 2018 23:25:57 +0100
Chris Wilson wrote:
> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sched clock is unstable (determined during
> late_initcall) and automatically switching the default clock over to
> trace_global_clock.
>
> This should prevent requiring user interaction to resolve warnings such
> as:
>
> Delta way too big! 18446743856563626466 ts=18446744054496180323 write
> stamp = 197932553857
> If you just came from a suspend/resume,
> please switch to the trace global clock:
> echo global > /sys/kernel/debug/tracing/trace_clock
global clock has a much higher overhead than the local clock. I rather
not have it automatically switch even when there's no stable TSC. That
will be annoying to myself as I have boxes that this would switch on
and I prefer to keep the local clock.
One can also decide the clock with the kernel command line. Should we
update that message to also say:
Or set the global clock via the kernel command line with
"trace_clock=global"
?
-- Steve
>
> Signed-off-by: Chris Wilson
> Cc: Steven Rostedt (VMware)
> ---
> kernel/trace/trace.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 13baf85b27d8..c5462513db90 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "trace.h"
> @@ -8505,3 +8506,15 @@ __init static int clear_boot_tracer(void)
>
> fs_initcall(tracer_init_tracefs);
> late_initcall_sync(clear_boot_tracer);
> +
> +#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
> +__init static int tracing_set_default_clock(void)
> +{
> + /* sched_clock_stable() is determined in late_initcall */
> + if (!trace_boot_clock && !sched_clock_stable())
> + tracing_set_clock(&global_trace, "global");
> +
> + return 0;
> +}
> +late_initcall_sync(tracing_set_default_clock);
> +#endif
___
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/selftests: Avoid repeatedly harming the same innocent context
== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : success == Summary == Series 40941v1 drm/i915/selftests: Avoid repeatedly harming the same innocent context https://patchwork.freedesktop.org/api/1.0/series/40941/revisions/1/mbox/ Known issues: Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:435s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:531s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:512s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:589s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:316s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:427s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:439s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:514s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:581s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:532s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:486s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest 477c0fa0c0b5 drm/i915/selftests: Avoid repeatedly harming the same innocent context == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8548/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 05/17] drm/i915/guc/slpc: Add SLPC communication interfaces
On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble
wrote:
Communication with SLPC is via Host to GuC interrupt through shared data
and parameters. This patch defines the structure of shared data,
parameters, data structure to be passed as input and received as output
from SLPC. This patch also defines the events to be sent as input and
status values output by GuC on processing SLPC events.
SLPC shared data has details of SKU type, Slice count, IA Perf MSR
values,
SLPC state, Power source/plan, SLPC tasks status. Parameters allow
overriding task control, frequency range etc.
v1: fix whitespace (Sagar)
v2-v3: Rebase.
v4: Updated with GuC firmware v9.
v5: Added definition of input and output data structures for SLPC
events. Updated commit message.
v6: Removed definition of host2guc_slpc. Will be added in the next
patch that uses it. Commit subject update. Rebase.
v7: Added definition of SLPC_RESET_FLAG_TDR_OCCURRED to be sent
throgh SLPC reset in case of engine reset. Moved all Host/SLPC
interfaces from later patches to this patch. Commit message update.
v8: Updated value of SLPC_RESET_FLAG_TDR_OCCURRED.
v9: Removed struct slpc_param, slpc_paramlist and corresponding defines.
Will be added in later patches where they are used.
v10: Rebase. Prepared separate header for SLPC firmware interface.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_slpc.h | 2 +
drivers/gpu/drm/i915/intel_guc_slpc_fwif.h | 211
+
2 files changed, 213 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.h
b/drivers/gpu/drm/i915/intel_guc_slpc.h
index 66c76fe..81250c0 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.h
+++ b/drivers/gpu/drm/i915/intel_guc_slpc.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_GUC_SLPC_H_
#define _INTEL_GUC_SLPC_H_
+#include
Please use "" instead of <>
+
struct intel_guc_slpc {
};
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
new file mode 100644
index 000..9400af4
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_slpc_fwif.h
@@ -0,0 +1,211 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2015-2018 Intel Corporation
+ */
+#ifndef _INTEL_GUC_SLPC_FWIF_H_
+#define _INTEL_GUC_SLPC_FWIF_H_
+
+#include
+
+enum slpc_status {
s/slpc_status/intel_guc_slpc_status
+ SLPC_STATUS_OK = 0,
+ SLPC_STATUS_ERROR = 1,
+ SLPC_STATUS_ILLEGAL_COMMAND = 2,
+ SLPC_STATUS_INVALID_ARGS = 3,
+ SLPC_STATUS_INVALID_PARAMS = 4,
+ SLPC_STATUS_INVALID_DATA = 5,
+ SLPC_STATUS_OUT_OF_RANGE = 6,
+ SLPC_STATUS_NOT_SUPPORTED = 7,
+ SLPC_STATUS_NOT_IMPLEMENTED = 8,
+ SLPC_STATUS_NO_DATA = 9,
+ SLPC_STATUS_EVENT_NOT_REGISTERED = 10,
+ SLPC_STATUS_REGISTER_LOCKED = 11,
+ SLPC_STATUS_TEMPORARILY_UNAVAILABLE = 12,
+ SLPC_STATUS_VALUE_ALREADY_SET = 13,
+ SLPC_STATUS_VALUE_ALREADY_UNSET = 14,
+ SLPC_STATUS_VALUE_NOT_CHANGED = 15,
+ SLPC_STATUS_MEMIO_ERROR = 16,
+ SLPC_STATUS_EVENT_QUEUED_REQ_DPC = 17,
+ SLPC_STATUS_EVENT_QUEUED_NOREQ_DPC = 18,
+ SLPC_STATUS_NO_EVENT_QUEUED = 19,
+ SLPC_STATUS_OUT_OF_SPACE = 20,
+ SLPC_STATUS_TIMEOUT = 21,
+ SLPC_STATUS_NO_LOCK = 22,
+ SLPC_STATUS_MAX
s/SLPC_STATUS/INTEL_GUC_SLPC_STATUS
+};
+
+enum slpc_event_id {
s/slpc_event_id/intel_guc_slpc_event
+ SLPC_EVENT_RESET = 0,
+ SLPC_EVENT_SHUTDOWN = 1,
+ SLPC_EVENT_PLATFORM_INFO_CHANGE = 2,
+ SLPC_EVENT_DISPLAY_MODE_CHANGE = 3,
+ SLPC_EVENT_FLIP_COMPLETE = 4,
+ SLPC_EVENT_QUERY_TASK_STATE = 5,
+ SLPC_EVENT_PARAMETER_SET = 6,
+ SLPC_EVENT_PARAMETER_UNSET = 7,
s/SLPC_EVENT/INTEL_GUC_SLPC_EVENT
+};
+
+enum slpc_param_id {
s/slpc_param_id/intel_guc_slpc_param
+ SLPC_PARAM_TASK_ENABLE_GTPERF = 0,
+ SLPC_PARAM_TASK_DISABLE_GTPERF = 1,
+ SLPC_PARAM_TASK_ENABLE_BALANCER = 2,
+ SLPC_PARAM_TASK_DISABLE_BALANCER = 3,
+ SLPC_PARAM_TASK_ENABLE_DCC = 4,
+ SLPC_PARAM_TASK_DISABLE_DCC = 5,
+ SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ = 6,
+ SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ = 7,
+ SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ = 8,
+ SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ = 9,
+ SLPC_PARAM_GTPERF_THRESHOLD_MAX_FPS = 10,
+ SLPC_PARAM_GLOBAL_DISABLE_GT_FREQ_MANAGEMENT = 11,
+ SLPC_PARAM_GTPERF_ENABLE_FRAMERATE_STALLING = 12,
+ SLPC_PARAM_GLOBAL_DISABLE_RC6_MODE_CHANGE = 13,
+ SLPC_PARAM_GLOBAL_OC_UNSLICE_FREQ_MHZ = 14,
+ SLPC_PARAM_GLOBAL_OC_SLICE_FREQ_MHZ = 15,
+ SLPC_PARAM_GLOBAL_ENABLE_IA_GT_BALANCING = 16,
+ SLPC_PARAM_GLOBAL_ENABLE_ADAPTIVE_BURST_TURBO = 17,
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
== Series Details == Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers URL : https://patchwork.freedesktop.org/series/40929/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 Subgroup flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw) fdo#100368 +1 Subgroup flip-vs-panning-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#103821 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3495 pass:1831 dwarn:1 dfail:0 fail:7 skip:1655 time:12913s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11419s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:6970s Blacklisted hosts: shard-kbltotal:3495 pass:1946 dwarn:12 dfail:0 fail:9 skip:1528 time:9154s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8547/shards.html ___ 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/selftests: Avoid repeatedly harming the same innocent context
== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : warning == Summary == $ dim checkpatch origin/drm-tip 477c0fa0c0b5 drm/i915/selftests: Avoid repeatedly harming the same innocent context -:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #57: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:983: +static int wait_for_others(struct drm_i915_private *i915, + struct intel_engine_cs *exclude) total: 0 errors, 0 warnings, 1 checks, 78 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)
Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.
Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.
The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...
Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.
We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.
Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Avoid repeatedly harming the same innocent context
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrumb. This is really only a problem for the selftest as
normally there is a large interlude between resets (hangcheck), or we
focus on resetting just one engine and so avoid repeatedly resetting
innocents.
Something to try would be a preempt-to-idle to quiesce the engine before
reset, so that innocent contexts would be spared the reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 48 ++--
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d354627882e3..684060ed8db6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1886,6 +1886,8 @@ void i915_reset(struct drm_i915_private *i915)
int ret;
int i;
+ GEM_TRACE("flags=%lx\n", error->flags);
+
might_sleep();
lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags));
@@ -2016,6 +2018,7 @@ int i915_reset_engine(struct intel_engine_cs *engine,
const char *msg)
struct i915_request *active_request;
int ret;
+ GEM_TRACE("%s flags=%lx\n", engine->name, error->flags);
GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, &error->flags));
active_request = i915_gem_reset_prepare_engine(engine);
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 9e4e0ad62724..122a32e0a69d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -979,6 +979,23 @@ static int igt_wait_reset(void *arg)
return err;
}
+static int wait_for_others(struct drm_i915_private *i915,
+ struct intel_engine_cs *exclude)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, i915, id) {
+ if (engine == exclude)
+ continue;
+
+ if (wait_for(intel_engine_is_idle(engine), 10))
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int igt_reset_queue(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1027,13 +1044,36 @@ static int igt_reset_queue(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
+ /*
+* XXX We don't handle resetting the kernel context
+* very well. If we trigger a device reset twice in
+* quick succession while the kernel context is
+* executing, we may end up skipping the breadcrumb.
+* This is really only a problem for the selftest as
+* normally there is a large interlude between resets
+* (hangcheck), or we focus on resetting just one
+* engine and so avoid repeatedly resetting innocents.
+*/
+ err = wait_for_others(i915, engine);
+ if (err) {
+ pr_err("%s(%s): Failed to idle other inactive
engines after device reset\n",
+ __func__, engine->name);
+ i915_request_put(rq);
+ i915_request_put(prev);
+
+ GEM_TRACE_DUMP();
+ i915_gem_set_wedged(i915);
+ goto fini;
+ }
+
if (!wait_for_hang(&h, prev)) {
struct drm_printer p =
drm_info_printer(i915->drm.dev);
- pr_err("%s: Failed to start request %x, at
%x\n",
- __func__, prev->fence.seqno,
hws_seqno(&h, prev));
- intel_engine_dump(prev->engine, &p,
- "%s\n", prev->engine->name);
+ pr_err("%s(%s): Failed to start request %x, at
%x\n",
+ __func__, engine->name,
+ prev->fence.seqno, hws_seqno(&h, prev));
+ intel_engine_dump(engine, &p,
+ "%s\n", engine->name);
i915_request_put(rq);
i915_request_put(prev
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
== Series Details == Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers URL : https://patchwork.freedesktop.org/series/40929/ State : success == Summary == Series 40929v1 drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers https://patchwork.freedesktop.org/api/1.0/series/40929/revisions/1/mbox/ fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:429s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:533s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:295s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:518s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:558s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:518s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:421s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:470s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:500s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:509s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:581s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:402s Blacklisted hosts: fi-cnl-psr total:285 pass:254 dwarn:3 dfail:0 fail:2 skip:26 time:515s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:484s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest bfdc21d08f2b drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8547/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Quoting Hans de Goede (2018-03-30 13:37:40)
> Hi,
>
> On 30-03-18 14:30, Chris Wilson wrote:
> > Quoting Hans de Goede (2018-03-30 13:27:15)
> >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> >> skipping the first 4k by passing 4096 as start of the address range passed
> >> to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
> >> reserve the firmware framebuffer so that we can inherit it would always
> >> fail, as the firmware framebuffer starts at address 0.
> >>
> >> Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> >> everything >= gen8") says in its commit message: "This is confirmed to fix
> >> Skylake screen flickering issues (probably caused by the fact that we
> >> initialized a ring in the first page of stolen, but I didn't 100% confirm
> >> this theory)."
> >>
> >> Which suggests that it is safe to use the first page for a linear
> >> framebuffer as the firmware is doing.
> >>
> >> This commit always passes 0 as start to drm_mm_init() and works around
> >> WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> >> by insuring the start address passed by to drm_mm_insert_node_in_range()
> >> is always 4k or more. All entry points to i915_gem_stolen.c go through
> >> i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> >> objects such as ring-buffers will not be allocated in the first 4k.
> >>
> >> The one exception is i915_gem_object_create_stolen_for_preallocated()
> >> which directly calls drm_mm_reserve_node() which now will be able to
> >> use the first 4k.
> >>
> >> This fixes the i915 driver no longer being able to inherit the firmware
> >> framebuffer on gen8+, which fixes the video output changing from the
> >> vendor logo to a black screen as soon as the i915 driver is loaded
> >> (on systems without fbcon).
> >
> > We've been told by the HW guys not to use the first page. (That's my
> > understanding from every time this gets questioned.)
>
> Yet the GOP is happily using the first page. I think we may need to make
> a difference here between the GPU not using the first page and the
> display engine/pipeline not using the first page. Note that my patch
> only influences the inheriting of the initial framebuffer as allocated
> by the GOP. It does not influence any other allocations from the
> reserved range, those will still all avoid the first page.
>
> Without this patch fastboot / flickerfree support is essentially broken
> on any gen8+ hardware given that one of the goals of atomic is to be
> able to do flickerfree transitions I think that this warrants a closer
> look then just simply saying never use the first page.
The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)
Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.
Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 01/17] drm/i915/guc/slpc: Add SLPC control to enable_guc modparam
On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
GuC is currently being used for submission and HuC authentication.
Choices can be configured through enable_guc modparam. GuC SLPC is GT
Power and Performance management feature in GuC. Add another option to
enable_guc modparam to control SLPC.
v1: Add early call to sanitize enable_guc_slpc in intel_guc_ucode_init
Remove sanitize enable_guc_slpc call before firmware version check
is performed. (ChrisW)
Version check is added in next patch and that will be done as part
of slpc_enable_sanitize function in the next patch. (Sagar) Updated
slpc option sanitize function call for platforms without GuC support.
This was caught by CI BAT.
v2: Changed parameter to dev_priv for HAS_SLPC macro. (David)
Code indentation based on checkpatch.
v3: Rebase.
v4: Moved sanitization of SLPC option post GuC load.
v5: Removed function intel_slpc_enabled. Planning to rely only on kernel
parameter. Moved sanitization prior to GuC load to use the parameter
during SLPC state setup during to GuC load. (Sagar)
v6: Commit message update. Rebase.
v7: Moved SLPC option sanitization to intel_uc_sanitize_options.
v8: Clearing SLPC option on GuC load failure. Change moved from later
patch. (Sagar)
v9: s/enable_slpc/enable_guc_slpc. Rebase w.r.t modparam change.
v10: Rebase. Separate modparam is not needed now that we maintain all
options in single param enable_guc.
Suggested-by: Paulo Zanoni
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_uc.c| 23 +++
drivers/gpu/drm/i915/intel_uc.h| 6 ++
4 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..40b799b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -150,9 +150,10 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
"2=default swing(400mV))");
i915_param_named_unsafe(enable_guc, int, 0400,
- "Enable GuC load for GuC submission and/or HuC load. "
+ "Enable GuC load for GuC submission and/or HuC load and/or GuC SLPC. "
"Required functionality can be selected using bitmask values. "
- "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+ "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load, "
+ "4=GuC SLPC)");
Maybe to avoid later surprise, we should explicitly say that:
+ "4=GuC SLPC [requires GuC submission])");
i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..2484925 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -32,6 +32,7 @@ struct drm_printer;
#define ENABLE_GUC_SUBMISSION BIT(0)
#define ENABLE_GUC_LOAD_HUCBIT(1)
+#define ENABLE_GUC_SLPCBIT(2)
#define I915_PARAMS_FOR_EACH(param) \
param(char *, vbt_firmware, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 1cffaf7..0e4a97f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -56,9 +56,15 @@ static int __get_platform_enable_guc(struct
drm_i915_private *dev_priv)
struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
int enable_guc = 0;
- /* Default is to enable GuC/HuC if we know their firmwares */
- if (intel_uc_fw_is_selected(guc_fw))
+ /*
+* Default is to enable GuC submission/SLPC/HuC if we know their
+* firmwares
+*/
+ if (intel_uc_fw_is_selected(guc_fw)) {
enable_guc |= ENABLE_GUC_SUBMISSION;
+ enable_guc |= ENABLE_GUC_SLPC;
+ }
+
if (intel_uc_fw_is_selected(huc_fw))
enable_guc |= ENABLE_GUC_LOAD_HUC;
@@ -110,10 +116,11 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
if (i915_modparams.enable_guc < 0)
i915_modparams.enable_guc = __get_platform_enable_guc(dev_priv);
- DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
+ DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s slpc:%s)\n",
i915_modparams.enable_guc,
yesno(intel_uc_is_using_guc_submission()),
-yesno(intel_uc_is_using_huc()));
+yesno(intel_uc_is_using_huc()),
+yesno(intel_uc_is_using_guc_slpc()));
/* Verify GuC firmware availability */
if (intel_uc_is_using_guc
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences
== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck: pass -> INCOMPLETE (shard-apl) Test gem_ctx_param: Subgroup invalid-param-get: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Subgroup invalid-param-set: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-toggle: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 Subgroup flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw) fdo#100368 Subgroup flip-vs-panning-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#103821 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-c-planes: pass -> INCOMPLETE (shard-hsw) fdo#103375 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3477 pass:1810 dwarn:1 dfail:0 fail:9 skip:1655 time:12396s shard-hswtotal:3494 pass:1778 dwarn:1 dfail:0 fail:4 skip:1709 time:10821s shard-snbtotal:3496 pass:1373 dwarn:1 dfail:0 fail:5 skip:2117 time:6993s Blacklisted hosts: shard-kbltotal:3496 pass:1929 dwarn:29 dfail:1 fail:9 skip:1528 time:9218s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8546/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Quoting Hans de Goede (2018-03-30 13:27:15)
> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> skipping the first 4k by passing 4096 as start of the address range passed
> to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
> reserve the firmware framebuffer so that we can inherit it would always
> fail, as the firmware framebuffer starts at address 0.
>
> Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> everything >= gen8") says in its commit message: "This is confirmed to fix
> Skylake screen flickering issues (probably caused by the fact that we
> initialized a ring in the first page of stolen, but I didn't 100% confirm
> this theory)."
>
> Which suggests that it is safe to use the first page for a linear
> framebuffer as the firmware is doing.
>
> This commit always passes 0 as start to drm_mm_init() and works around
> WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> by insuring the start address passed by to drm_mm_insert_node_in_range()
> is always 4k or more. All entry points to i915_gem_stolen.c go through
> i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> objects such as ring-buffers will not be allocated in the first 4k.
>
> The one exception is i915_gem_object_create_stolen_for_preallocated()
> which directly calls drm_mm_reserve_node() which now will be able to
> use the first 4k.
>
> This fixes the i915 driver no longer being able to inherit the firmware
> framebuffer on gen8+, which fixes the video output changing from the
> vendor logo to a black screen as soon as the i915 driver is loaded
> (on systems without fbcon).
We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index af915d041281..ad949cc30928 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -51,6 +51,10 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *dev_priv,
if (!drm_mm_initialized(&dev_priv->mm.stolen))
return -ENODEV;
+ /* WaSkipStolenMemoryFirstPage:bdw+ */
+ if (INTEL_GEN(dev_priv) >= 8 && start < 4096)
+ start = 4096;
+
mutex_lock(&dev_priv->mm.stolen_lock);
ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node,
size, alignment, 0,
@@ -343,7 +347,6 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
{
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
- resource_size_t stolen_usable_start;
mutex_init(&dev_priv->mm.stolen_lock);
@@ -435,17 +438,11 @@ int i915_gem_init_stolen(struct drm_i915_private
*dev_priv)
(u64)resource_size(&dev_priv->dsm) >> 10,
((u64)resource_size(&dev_priv->dsm) - reserved_total)
>> 10);
- stolen_usable_start = 0;
- /* WaSkipStolenMemoryFirstPage:bdw+ */
- if (INTEL_GEN(dev_priv) >= 8)
- stolen_usable_start = 4096;
-
dev_priv->stolen_usable_size =
- resource_size(&dev_priv->dsm) - reserved_total -
stolen_usable_start;
+ resource_size(&dev_priv->dsm) - reserved_total;
/* Basic memrange allocator for stolen space. */
- drm_mm_init(&dev_priv->mm.stolen, stolen_usable_start,
- dev_priv->stolen_usable_size);
+ drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->stolen_usable_size);
return 0;
}
--
2.17.0.rc2
___
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 [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences
== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : success == Summary == Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences https://patchwork.freedesktop.org/api/1.0/series/40927/revisions/1/mbox/ Known issues: Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7500u) fdo#105128 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:432s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:545s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:513s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:518s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:507s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:468s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:259 dwarn:2 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:437s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:500s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:574s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:398s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:552s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:486s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest b742993888d6 drm/i915: Allow user control over preempt timeout on their important context c9542a8112fd drm/i915: Use a preemption timeout to enforce interactivity 57ea892580e5 drm/i915/preemption: Select timeout when scheduling 1df46bdfe4a3 drm/i915/execlists: Try preempt-reset from softirq context b9c1f591cc6b drm/i915/execlists: Force preemption via reset on timeout 28278ff2c649 drm/i915: Allow init_breadcrumbs to be used from irq context b7b11d47f57b drm/i915: Be irqsafe inside reset 435c7f3e4181 drm/i915: Stop parking the signaler around reset 13708e4e6f94 drm/i915: Combine tasklet_kill and tasklet_disable 165feb53f995 drm/i915/breadcrumbs: Keep the fake irq armed across reset 55488482 drm/i915/selftests: Add basic sanitychecks for execlists a46f451f9827 drm/i915/execlists: Flush pending preemption events during reset 25b87d182879 drm/i915: Split execlists/guc reset prepartions 7150789d6e56 drm/i915: Move engine reset prepare/finish to backends 06aa4edeb023 drm/i915/execlists: Refactor out complete_preempt_context() 934e303733f6 drm/i915/execlists: Set queue priority from secondary port d71000599823 drm/i915/execlists: Track begin/end of execlists submission sequences == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8546/issues.html _
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d71000599823 drm/i915/execlists: Track begin/end of execlists submission
sequences
934e303733f6 drm/i915/execlists: Set queue priority from secondary port
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f6322eddaff7
("drm/i915/preemption: Allow preemption between submission ports")'
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
06aa4edeb023 drm/i915/execlists: Refactor out complete_preempt_context()
7150789d6e56 drm/i915: Move engine reset prepare/finish to backends
25b87d182879 drm/i915: Split execlists/guc reset prepartions
a46f451f9827 drm/i915/execlists: Flush pending preemption events during reset
-:69: WARNING:LONG_LINE: line over 100 characters
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:907:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-:87: WARNING:LONG_LINE: line over 100 characters
#87: FILE: drivers/gpu/drm/i915/intel_lrc.c:921:
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
-:104: WARNING:LONG_LINE: line over 100 characters
#104: FILE: drivers/gpu/drm/i915/intel_lrc.c:935:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:105: WARNING:LONG_LINE: line over 100 characters
#105: FILE: drivers/gpu/drm/i915/intel_lrc.c:936:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
total: 0 errors, 4 warnings, 0 checks, 192 lines checked
55488482 drm/i915/selftests: Add basic sanitychecks for execlists
-:43: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#43:
new file mode 100644
-:119: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#119: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:72:
+ return hws->node.start + offset_in_page(sizeof(u32)*rq->fence.context);
^
-:247: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'W' - possible side-effects?
#247: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:200:
+#define wedge_on_timeout(W, DEV, TIMEOUT) \
+ for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
+(W)->i915; \
+__fini_wedge((W)))
total: 0 errors, 1 warnings, 2 checks, 511 lines checked
165feb53f995 drm/i915/breadcrumbs: Keep the fake irq armed across reset
13708e4e6f94 drm/i915: Combine tasklet_kill and tasklet_disable
-:39: WARNING:MEMORY_BARRIER: memory barrier without comment
#39: FILE: drivers/gpu/drm/i915/intel_lrc.c:1755:
+ smp_mb();
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
435c7f3e4181 drm/i915: Stop parking the signaler around reset
-:13: WARNING:TYPO_SPELLING: 'choosen' may be misspelled - perhaps 'chosen'?
#13:
advancing so that the GPU doesn't emit the breadcrumb for our choosen
total: 0 errors, 1 warnings, 0 checks, 85 lines checked
b7b11d47f57b drm/i915: Be irqsafe inside reset
28278ff2c649 drm/i915: Allow init_breadcrumbs to be used from irq context
b9c1f591cc6b drm/i915/execlists: Force preemption via reset on timeout
-:228: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#228: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:508:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 241 lines checked
1df46bdfe4a3 drm/i915/execlists: Try preempt-reset from softirq context
-:115: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#115: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:593:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 176 lines checked
57ea892580e5 drm/i915/preemption: Select timeout when scheduling
c9542a8112fd drm/i915: Use a preemption timeout to enforce interactivity
b742993888d6 drm/i915: Allow user control over preempt timeout on their
important context
___
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/17] drm/i915/execlists: Track begin/end of execlists submission sequences
== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : failure == Summary == Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences https://patchwork.freedesktop.org/api/1.0/series/40927/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-plain-flip: pass -> INCOMPLETE (fi-cnl-y3) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:538s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:520s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:511s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-y3total:219 pass:198 dwarn:0 dfail:0 fail:0 skip:20 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:423s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:535s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:473s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:527s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:500s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:507s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:541s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:483s 335ef9849310af26d65c54f7d2d2e9dcbce238b9 drm-tip: 2018y-03m-30d-09h-08m-40s UTC integration manifest f21a994c5239 drm/i915: Allow user control over preempt timeout on their important context 74b8058ff743 drm/i915: Use a preemption timeout to enforce interactivity 4383544ed9ef drm/i915/preemption: Select timeout when scheduling aac0236c4b8d drm/i915/execlists: Try preempt-reset from softirq context 7c900d2a6154 drm/i915/execlists: Force preemption via reset on timeout 428fcef9ca7a drm/i915: Allow init_breadcrumbs to be used from irq context 17205a44c23d drm/i915: Be irqsafe inside reset afceb077b401 drm/i915: Stop parking the signaler around reset eecceca4efe5 drm/i915: Combine tasklet_kill and tasklet_disable 5a9c6a2ad3b8 drm/i915/breadcrumbs: Keep the fake irq armed across reset cf783aa12414 drm/i915/selftests: Add basic sanitychecks for execlists d5c288d4bf37 drm/i915/execlists: Flush pending preemption events during reset 969d8ded5eba drm/i915: Split execlists/guc reset prepartions 7be12bc10a20 drm/i915: Move engine reset prepare/finish to backends fe156263d8b1 drm/i915/execlists: Refactor out complete_preempt_context() 577684ae80f3 drm/i915/execlists: Set queue priority from secondary port 0a86b9f594fb drm/i915/execlists: Track begin/end of execlists submissio
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0a86b9f594fb drm/i915/execlists: Track begin/end of execlists submission
sequences
577684ae80f3 drm/i915/execlists: Set queue priority from secondary port
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f6322eddaff7
("drm/i915/preemption: Allow preemption between submission ports")'
#25:
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
submission ports")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
fe156263d8b1 drm/i915/execlists: Refactor out complete_preempt_context()
7be12bc10a20 drm/i915: Move engine reset prepare/finish to backends
969d8ded5eba drm/i915: Split execlists/guc reset prepartions
d5c288d4bf37 drm/i915/execlists: Flush pending preemption events during reset
-:69: WARNING:LONG_LINE: line over 100 characters
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:907:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-:87: WARNING:LONG_LINE: line over 100 characters
#87: FILE: drivers/gpu/drm/i915/intel_lrc.c:921:
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
-:104: WARNING:LONG_LINE: line over 100 characters
#104: FILE: drivers/gpu/drm/i915/intel_lrc.c:935:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:105: WARNING:LONG_LINE: line over 100 characters
#105: FILE: drivers/gpu/drm/i915/intel_lrc.c:936:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
total: 0 errors, 4 warnings, 0 checks, 192 lines checked
cf783aa12414 drm/i915/selftests: Add basic sanitychecks for execlists
-:43: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#43:
new file mode 100644
-:119: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#119: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:72:
+ return hws->node.start + offset_in_page(sizeof(u32)*rq->fence.context);
^
-:247: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'W' - possible side-effects?
#247: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:200:
+#define wedge_on_timeout(W, DEV, TIMEOUT) \
+ for (__init_wedge((W), (DEV), (TIMEOUT), __builtin_return_address(0)); \
+(W)->i915; \
+__fini_wedge((W)))
total: 0 errors, 1 warnings, 2 checks, 511 lines checked
5a9c6a2ad3b8 drm/i915/breadcrumbs: Keep the fake irq armed across reset
eecceca4efe5 drm/i915: Combine tasklet_kill and tasklet_disable
-:39: WARNING:MEMORY_BARRIER: memory barrier without comment
#39: FILE: drivers/gpu/drm/i915/intel_lrc.c:1755:
+ smp_mb();
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
afceb077b401 drm/i915: Stop parking the signaler around reset
-:13: WARNING:TYPO_SPELLING: 'choosen' may be misspelled - perhaps 'chosen'?
#13:
advancing so that the GPU doesn't emit the breadcrumb for our choosen
total: 0 errors, 1 warnings, 0 checks, 85 lines checked
17205a44c23d drm/i915: Be irqsafe inside reset
428fcef9ca7a drm/i915: Allow init_breadcrumbs to be used from irq context
7c900d2a6154 drm/i915/execlists: Force preemption via reset on timeout
-:228: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#228: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:508:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 241 lines checked
aac0236c4b8d drm/i915/execlists: Try preempt-reset from softirq context
-:115: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#115: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:593:
+ ctx= kernel_context(i915);
^
total: 1 errors, 0 warnings, 0 checks, 176 lines checked
4383544ed9ef drm/i915/preemption: Select timeout when scheduling
74b8058ff743 drm/i915: Use a preemption timeout to enforce interactivity
f21a994c5239 drm/i915: Allow user control over preempt timeout on their
important context
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/17] drm/i915/preemption: Select timeout when scheduling
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
triggered preemption for the dependency chain, we can assume that no
preemption along that chain is more important than the current request,
ergo we need only consider the current timeout. Realising this, we can
then pass control of the preemption timeout to the caller for greater
flexibility.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 106 -
5 files changed, 114 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a866fe304de1..a860d501134e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -482,7 +482,7 @@ static void __fence_set_priority(struct dma_fence *fence,
int prio)
rcu_read_lock();
if (engine->schedule)
- engine->schedule(rq, prio);
+ engine->schedule(rq, prio, 0);
rcu_read_unlock();
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 585242831974..cdda3ebd51e2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1108,7 +1108,7 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
*/
rcu_read_lock();
if (engine->schedule)
- engine->schedule(request, request->ctx->priority);
+ engine->schedule(request, request->ctx->priority, 0);
rcu_read_unlock();
local_bh_disable();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dfbf0913f14e..63f09128e5ec 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1240,7 +1240,8 @@ pt_lock_engine(struct i915_priotree *pt, struct
intel_engine_cs *locked)
return engine;
}
-static void execlists_schedule(struct i915_request *request, int prio)
+static void execlists_schedule(struct i915_request *request,
+ int prio, unsigned int timeout)
{
struct intel_engine_cs *engine;
struct i915_dependency *dep, *p;
@@ -1336,7 +1337,7 @@ static void execlists_schedule(struct i915_request
*request, int prio)
if (prio > engine->execlists.queue_priority &&
i915_sw_fence_done(&pt_to_request(pt)->submit))
- __submit_queue(engine, prio, 0);
+ __submit_queue(engine, prio, timeout);
}
spin_unlock_irq(&engine->timeline->lock);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 80c303bb54c8..1e85123534a8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -463,13 +463,15 @@ struct intel_engine_cs {
*/
void(*submit_request)(struct i915_request *rq);
- /* Call when the priority on a request has changed and it and its
+ /*
+* Call when the priority on a request has changed and it and its
* dependencies may need rescheduling. Note the request itself may
* not be ready to run!
*
* Called under the struct_mutex.
*/
- void(*schedule)(struct i915_request *request, int priority);
+ void(*schedule)(struct i915_request *request,
+ int priority, unsigned int timeout);
/*
* Cancel all requests on the hardware, or queued for execution.
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 626acf46f65e..46d13cd66e44 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -450,7 +450,7 @@ static int live_late_preempt(void *arg)
goto err_wedged;
}
- engine->schedule(rq, I915_PRIORITY_MAX);
+ engine->schedule(rq, I915_PRIORITY_MAX, 0);
if (!wait_for_spinner(&spin_hi, rq)) {
pr_err("High priority context failed to preempt the low
priority context\n");
@@ -673,6 +673,109 @@ static int live_preempt_reset(void *arg)
return err;
}
+static int live_late_preempt_timeout(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_gem_context *ctx_hi, *ctx_lo;
+ struct spinner spin_hi, spin_lo;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
[Intel-gfx] [PATCH 17/17] drm/i915: Allow user control over preempt timeout on their important context
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22
drivers/gpu/drm/i915/i915_gem_context.h| 13 +
drivers/gpu/drm/i915/i915_request.c| 8 ++-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 85 ++
include/uapi/drm/i915_drm.h| 12 +
6 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..dfb0a2b698c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -749,6 +749,15 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+ case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:
+ if (!(to_i915(dev)->caps.scheduler &
I915_SCHEDULER_CAP_PREEMPTION))
+ ret = -ENODEV;
+ else if (args->size)
+ ret = -EINVAL;
+ else
+ args->value = ctx->preempt_timeout;
+ break;
+
default:
ret = -EINVAL;
break;
@@ -824,6 +833,19 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
}
break;
+ case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:
+ if (args->size)
+ ret = -EINVAL;
+ else if (args->value >= NSEC_PER_SEC)
+ ret = -EINVAL;
+ else if (!(to_i915(dev)->caps.scheduler &
I915_SCHEDULER_CAP_PREEMPTION))
+ ret = -ENODEV;
+ else if (args->value && !capable(CAP_SYS_ADMIN))
+ ret = -EPERM;
+ else
+ ctx->preempt_timeout = args->value;
+ break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 7854262ddfd9..74d4cadd729e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -150,6 +150,19 @@ struct i915_gem_context {
*/
int priority;
+ /**
+* @preempt_timeout: QoS guarantee for the high priority context
+*
+* Some clients need a guarantee that they will start executing
+* within a certain window, even at the expense of others. This entails
+* that if a preemption request is not honoured by the active context
+* within the timeout, we will reset the GPU to evict the hog and
+* run the high priority context instead.
+*
+* Timeout is stored in nanoseconds; exclusive max of 1s.
+*/
+ u32 preempt_timeout;
+
/** ggtt_offset_bias: placement restriction for context objects */
u32 ggtt_offset_bias;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index cdda3ebd51e2..eae807e56723 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1107,8 +1107,12 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
* run at the earliest possible convenience.
*/
rcu_read_lock();
- if (engine->schedule)
- engine->schedule(request, request->ctx->priority, 0);
+ if (engine->schedule) {
+ unsigned int timeout = request->ctx->preempt_timeout;
+ int priority = request->ctx->priority;
+
+ engine->schedule(request, priority, timeout);
+ }
rcu_read_unlock();
local_bh_disable();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 63f09128e5ec..3e65357d1d3f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1212,7 +1212,7 @@ static void execlists_submit_request(struct i915_request
*request)
spin_lock_irqsave(&engine->timeline->lock, flags);
queue_request(engine, &request->priotree, rq_prio(request));
- submit_queue(engine, rq_prio(request), 0);
+ submit_queue(engine, rq_prio(request), request->ctx->preempt_timeout);
GEM_BUG_ON(!engine->execlists.first);
GEM_BUG_ON(list_empty(&request->priotree.link));
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 46d13cd66e44..bc24961f38f8 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -776,6 +776,90 @@ static int live_late_preempt_timeout(void *arg)
goto err_ctx_lo;
}
+static int live_context_preempt_timeout(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_gem_context *ctx_hi, *ctx_
[Intel-gfx] [PATCH 11/17] drm/i915: Be irqsafe inside reset
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a6acb1d5ad3..a866fe304de1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3041,15 +3041,17 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
*/
request = i915_gem_find_active_request(engine);
if (request) {
+ unsigned long flags;
+
i915_gem_context_mark_innocent(request->ctx);
dma_fence_set_error(&request->fence, -EAGAIN);
/* Rewind the engine to replay the incomplete rq */
- spin_lock_irq(&engine->timeline->lock);
+ spin_lock_irqsave(&engine->timeline->lock, flags);
request = list_prev_entry(request, link);
if (&request->link == &engine->timeline->requests)
request = NULL;
- spin_unlock_irq(&engine->timeline->lock);
+ spin_unlock_irqrestore(&engine->timeline->lock, flags);
}
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Reset from within timeout for preemption Qos
Fleshed out the reset from within the timer context (hardirq) to the point where it at least passes selftests... Not that CI even likes the sanitycheck at the moment. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/17] drm/i915: Allow init_breadcrumbs to be used from irq context
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 0a2128c6b418..ca0b04d9747c 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -846,8 +846,9 @@ static void cancel_fake_irq(struct intel_engine_cs *engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
- spin_lock_irq(&b->irq_lock);
+ spin_lock_irqsave(&b->irq_lock, flags);
/*
* Leave the fake_irq timer enabled (if it is running), but clear the
@@ -871,7 +872,7 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
*/
clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- spin_unlock_irq(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
}
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/17] drm/i915/breadcrumbs: Keep the fake irq armed across reset
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting an engine.
It also allows us to react better to the user poking around debugfs for
testing missed irqs.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 671a6d61e29d..0a2128c6b418 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -130,11 +130,12 @@ static void intel_breadcrumbs_hangcheck(struct timer_list
*t)
static void intel_breadcrumbs_fake_irq(struct timer_list *t)
{
- struct intel_engine_cs *engine = from_timer(engine, t,
- breadcrumbs.fake_irq);
+ struct intel_engine_cs *engine =
+ from_timer(engine, t, breadcrumbs.fake_irq);
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- /* The timer persists in case we cannot enable interrupts,
+ /*
+* The timer persists in case we cannot enable interrupts,
* or if we have previously seen seqno/interrupt incoherency
* ("missed interrupt" syndrome, better known as a "missed breadcrumb").
* Here the worker will wake up every jiffie in order to kick the
@@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct timer_list
*t)
if (!b->irq_armed)
return;
+ /* If the user has disabled the fake-irq, restore the hangchecking */
+ if (!test_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings)) {
+ mod_timer(&b->hangcheck, wait_timeout());
+ return;
+ }
+
mod_timer(&b->fake_irq, jiffies + 1);
}
@@ -840,15 +847,22 @@ void intel_engine_reset_breadcrumbs(struct
intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- cancel_fake_irq(engine);
spin_lock_irq(&b->irq_lock);
+ /*
+* Leave the fake_irq timer enabled (if it is running), but clear the
+* bit so that it turns itself off on its next wake up and goes back
+* to the long hangcheck interval if still required.
+*/
+ clear_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
+
if (b->irq_enabled)
irq_enable(engine);
else
irq_disable(engine);
- /* We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
+ /*
+* We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
* GPU is active and may have already executed the MI_USER_INTERRUPT
* before the CPU is ready to receive. However, the engine is currently
* idle (we haven't started it yet), there is no possibility for a
@@ -857,9 +871,6 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
*/
clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- if (b->irq_armed)
- enable_fake_irq(b);
-
spin_unlock_irq(&b->irq_lock);
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
