[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Reset ring registers on rebinding contexts
== Series Details == Series: drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40763/ State : failure == Summary == Possible new issues: Test kms_flip: Subgroup flip-vs-blocking-wf-vblank: pass -> FAIL (shard-hsw) Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 Subgroup cursor-64x64-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Test kms_cursor_legacy: Subgroup flip-vs-cursor-atomic: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +1 Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_plane: Subgroup plane-panning-bottom-right-pipe-a-planes: pass -> FAIL (shard-apl) fdo#103166 Test kms_rotation_crc: Subgroup sprite-rotation-180: pass -> FAIL (shard-snb) fdo#103925 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 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#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1830 dwarn:1 dfail:0 fail:8 skip:1655 time:12914s shard-hswtotal:3478 pass:1773 dwarn:1 dfail:0 fail:4 skip:1698 time:10973s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:6966s Blacklisted hosts: shard-kbltotal:3475 pass:1943 dwarn:2 dfail:0 fail:9 skip:1520 time:9497s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8508/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged
On Wed, Mar 28, 2018 at 09:47:40AM +0300, Oleksandr Andrushchenko wrote:
> From: Noralf Trønnes
>
> Use srcu to protect drm_device.unplugged in a race free manner.
> Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
> sections preventing access to device resources that are not available
> after the device is gone.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Oleksandr Andrushchenko
> Tested-by: Oleksandr Andrushchenko
> Cc: intel-gfx@lists.freedesktop.org
When you apply/forward a patch we also need your s-o-b line, even if you
changed nothing. sob needs to reflect the full record of everyone who
handled a patch from author to when it finally lands in git.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 54
> ++-
> include/drm/drm_device.h | 9 +++-
> include/drm/drm_drv.h | 15 +
> 3 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a1b9338736e3..32a83b41ab61 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
>
> static struct dentry *drm_debugfs_root;
>
> +DEFINE_STATIC_SRCU(drm_unplug_srcu);
> +
> /*
> * DRM Minors
> * A DRM device can provide several char-dev interfaces on the DRM-Major.
> Each
> @@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_put_dev);
>
> -static void drm_device_set_unplugged(struct drm_device *dev)
> +/**
> + * drm_dev_enter - Enter device critical section
> + * @dev: DRM device
> + * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
> + *
> + * This function marks and protects the beginning of a section that should
> not
> + * be entered after the device has been unplugged. The section end is marked
> + * with drm_dev_exit(). Calls to this function can be nested.
> + *
> + * Returns:
> + * True if it is OK to enter the section, false otherwise.
> + */
> +bool drm_dev_enter(struct drm_device *dev, int *idx)
> +{
> + *idx = srcu_read_lock(&drm_unplug_srcu);
> +
> + if (dev->unplugged) {
> + srcu_read_unlock(&drm_unplug_srcu, *idx);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dev_enter);
> +
> +/**
> + * drm_dev_exit - Exit device critical section
> + * @idx: index returned from drm_dev_enter()
> + *
> + * This function marks the end of a section that should not be entered after
> + * the device has been unplugged.
> + */
> +void drm_dev_exit(int idx)
> {
> - smp_wmb();
> - atomic_set(&dev->unplugged, 1);
> + srcu_read_unlock(&drm_unplug_srcu, idx);
> }
> +EXPORT_SYMBOL(drm_dev_exit);
>
> /**
> * drm_dev_unplug - unplug a DRM device
> * @dev: DRM device
> *
> * This unplugs a hotpluggable DRM device, which makes it inaccessible to
> - * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
> + * userspace operations. Entry-points can use drm_dev_enter() and
> + * drm_dev_exit() to protect device resources in a race free manner. This
> * essentially unregisters the device like drm_dev_unregister(), but can be
> * called while there are still open users of @dev.
> */
> @@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
> drm_dev_unregister(dev);
>
> mutex_lock(&drm_global_mutex);
> - drm_device_set_unplugged(dev);
> if (dev->open_count == 0)
> drm_dev_put(dev);
> mutex_unlock(&drm_global_mutex);
> +
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(&drm_unplug_srcu);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 7c4fa32f3fc6..3a0eac2885b7 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -46,7 +46,14 @@ struct drm_device {
> /* currently active master for this device. Protected by master_mutex */
> struct drm_master *master;
>
> - atomic_t unplugged; /**< Flag whether dev is dead */
> + /**
> + * @unplugged:
> + *
> + * Flag to tell if the device has been unplugged.
> + * See drm_dev_enter() and drm_dev_is_unplugged().
> + */
> + bool unplugged;
> +
> struct inode *anon_inode; /**< inode for private
> address-space */
> char *unique; /**< unique name of the device
> */
> /*@} */
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d2
[Intel-gfx] [PATCH] drm: Use srcu to protect drm_device.unplugged
From: Noralf Trønnes
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Oleksandr Andrushchenko
Tested-by: Oleksandr Andrushchenko
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
+DEFINE_STATIC_SRCU(drm_unplug_srcu);
+
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-static void drm_device_set_unplugged(struct drm_device *dev)
+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+ *idx = srcu_read_lock(&drm_unplug_srcu);
+
+ if (dev->unplugged) {
+ srcu_read_unlock(&drm_unplug_srcu, *idx);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
{
- smp_wmb();
- atomic_set(&dev->unplugged, 1);
+ srcu_read_unlock(&drm_unplug_srcu, idx);
}
+EXPORT_SYMBOL(drm_dev_exit);
/**
* drm_dev_unplug - unplug a DRM device
* @dev: DRM device
*
* This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
* essentially unregisters the device like drm_dev_unregister(), but can be
* called while there are still open users of @dev.
*/
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
mutex_lock(&drm_global_mutex);
- drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(&drm_global_mutex);
+
+ /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+ dev->unplugged = true;
+ synchronize_srcu(&drm_unplug_srcu);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
- atomic_t unplugged; /**< Flag whether dev is dead */
+ /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+ bool unplugged;
+
struct inode *anon_inode; /**< inode for private
address-space */
char *unique; /**< unique name of the device
*/
/*@} */
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d23dcdd1bd95..7e545f5f94d3 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -624,6 +624,8 @@ void drm_dev_get(struct drm_device *dev);
void drm_dev_put(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(struct drm_device *dev);
+bool drm_dev_enter(struct drm_device *dev, int *idx);
+void drm_dev_exit(int idx);
void drm_dev_unplug(struct drm_device *dev);
/**
@@ -635,11 +637,16 @@ void drm_dev_unplug(s
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Use srcu to protect drm_device.unplugged
== Series Details == Series: drm: Use srcu to protect drm_device.unplugged URL : https://patchwork.freedesktop.org/series/40793/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Use srcu to protect drm_device.unplugged +drivers/gpu/drm/drm_drv.c:336:6: warning: context imbalance in 'drm_dev_enter' - different lock contexts for basic block +drivers/gpu/drm/drm_drv.c:356:6: warning: context imbalance in 'drm_dev_exit' - unexpected unlock ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
Chris Wilson writes: > Tvrtko uncovered a fun issue with recovering from a wedge device. In his > tests, he wedged the driver by injecting an unrecoverable hang whilst a > batch was spinning. As we reset the gpu in the middle of the spinner, > when resumed it would continue on from the next instruction in the ring > and write it's breadcrumb. However, on wedging we updated our > bookkeeping to indicate that the GPU had completed executing and would > restart from after the breadcrumb; so the emission of the stale > breadcrumb from before the reset came as a bit of a surprise. > Ok trying to make sense of the above and how the wedging works. Here is my assertions. The spinning batch was never found to be guilty of anything. On wedge we fast forwarded all engine seqnos to be what was last submitted. We did hw reset. On context image, the RING_HEAD was pointing to bb start of spin batch (or the instruction after it) On resubmitting the context, we saw a seqno write from pre reset era. So this doesn't affect only spinning batches but any busy batch that was running while we wedged? -Mika > A simple fix is to when rebinding the context into the GPU, we update > the ring register state in the context image to match our bookkeeping. > We already have to update the RING_START and RING_TAIL, so updating > RING_HEAD as well is trivial. This works because whenever we unbind the > context, we keep the bookkeeping in check; and on wedging we unbind all > contexts. > > Testcase: igt/gem_eio > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_lrc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index ba7f7831f934..654634254b64 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, > ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; > ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = > i915_ggtt_offset(ce->ring->vma); > + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; > > ce->state->obj->pin_global++; > i915_gem_context_get(ctx); > -- > 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.
Quoting Francisco Jerez (2018-03-28 07:38:45)
> This allows cpufreq governors to realize when the system becomes
> non-CPU-bound due to GPU rendering activity, which will cause the
> intel_pstate LP controller to behave more conservatively: CPU energy
> usage will be reduced when there isn't a good chance for system
> performance to scale with CPU frequency. This leaves additional TDP
> budget available for the GPU to reach higher frequencies, which is
> translated into an improvement in graphics performance to the extent
> that the workload remains TDP-limited (Most non-trivial graphics
> benchmarks out there improve significantly in TDP-constrained
> platforms, see the cover letter for some numbers). If the workload
> isn't (anymore) TDP-limited performance should stay roughly constant,
> but energy usage will be divided by a similar factor.
And that's what I thought IPS was already meant to be achieving;
intelligent distribution between different units...
> The intel_pstate LP controller is only enabled on BXT+ small-core
> platforms at this point, so this shouldn't have any effect on other
> systems.
Although that's probably only a feature for big core :)
> Signed-off-by: Francisco Jerez
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3a69b367e565..721f915115bd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -132,6 +132,7 @@
> *
> */
> #include
> +#include
>
> #include
> #include
> @@ -379,11 +380,13 @@ execlists_context_schedule_in(struct i915_request *rq)
> {
> execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
> intel_engine_context_in(rq->engine);
> + cpufreq_io_active_begin();
Since you only care about a binary value for GPU activity, we don't need
to do this on each context, just between submitting the first request
and the final completion, i.e. couple this to EXECLISTS_ACTIVE_USER.
Haven't yet gone back to check how heavy io_active_begin/end are, but I
trust you appreciate that this code is particularly latency sensitive.
-Chris
___
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: Use srcu to protect drm_device.unplugged
== Series Details == Series: drm: Use srcu to protect drm_device.unplugged URL : https://patchwork.freedesktop.org/series/40793/ State : success == Summary == Series 40793v1 drm: Use srcu to protect drm_device.unplugged https://patchwork.freedesktop.org/api/1.0/series/40793/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: pass -> FAIL (fi-skl-guc) fdo#103191 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 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:432s 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: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:297s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:521s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:523s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:519s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:571s 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:426s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:323s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:420s 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:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:477s 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:516s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:663s 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:537s 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:503s 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:443s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:529s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:488s 23c67dc0cf31917b696b87dac997aca76c0d248d drm-tip: 2018y-03m-28d-06h-36m-40s UTC integration manifest 2eceb2811170 drm: Use srcu to protect drm_device.unplugged == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8514/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 drm/i915/guc: Support for Guc responses and requests (rev5)
== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev5) URL : https://patchwork.freedesktop.org/series/28393/ State : failure == Summary == Possible new issues: Test debugfs_test: Subgroup read_all_entries_display_off: pass -> DMESG-WARN (shard-apl) Test gem_eio: Subgroup execbuf: pass -> INCOMPLETE (shard-apl) Subgroup throttle: pass -> INCOMPLETE (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test drv_missed_irq: pass -> SKIP (shard-apl) fdo#103199 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-atomic: pass -> FAIL (shard-hsw) fdo#104873 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +1 Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 +1 Test kms_plane_multiple: Subgroup atomic-pipe-a-tiling-x: pass -> FAIL (shard-snb) fdo#103166 Test kms_vblank: Subgroup pipe-b-accuracy-idle: pass -> FAIL (shard-hsw) fdo#102583 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 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#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3383 pass:1764 dwarn:2 dfail:0 fail:10 skip:1603 time:12404s shard-hswtotal:3495 pass:1777 dwarn:1 dfail:0 fail:7 skip:1709 time:11579s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:7049s Blacklisted hosts: shard-kbltotal:3345 pass:1826 dwarn:3 dfail:1 fail:11 skip:1497 time:7899s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8510/shards.html ___ 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] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
On Thu, 2018-03-22 at 15:10 -0700, Radhakrishna Sripada wrote:
> From: Anusha Srivatsa
>
> Cleanup the testcases by moving the platform checks to a single
> function.
>
> The earlier version of the path is posted here [1]
>
> v2: Make use of the property enums to get the supported rotations
> v3: Move hardcodings to a single function(Ville)
>
> [1]: https://patchwork.freedesktop.org/patch/209647/
>
> Cc: Radhakrishna Sripada
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Maarten Lankhorst
> Cc: Mika Kahola
> Cc: Manasi Navare
Tested-by: Mika Kahola
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Radhakrishna Sripada
> ---
> tests/kms_rotation_crc.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 0cd5c6e52b57..60fb9012e14e 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -43,6 +43,7 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> int devid;
> + int gen;
> } data_t;
>
> typedef struct {
> @@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
> igt_assert(drmHandleEvent(fd, &evctx) == 0);
> }
>
> +static void igt_check_rotation(data_t *data)
> +{
> + if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> + igt_require(data->gen >= 9);
> + else if (data->rotation & IGT_REFLECT_X)
> + igt_require(data->gen >= 10 ||
> + (IS_CHERRYVIEW(data->devid) && (data-
> >rotation & IGT_ROTATION_0)));
> + else if (data->rotation & IGT_ROTATION_180)
> + igt_require(data->gen >= 4);
> +}
> +
> static void test_single_case(data_t *data, enum pipe pipe,
> igt_output_t *output, igt_plane_t
> *plane,
> enum rectangle_type rect,
> @@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data,
> int plane_type, bool test_bad_form
>
> igt_display_require_output(display);
>
> + igt_check_rotation(data);
> +
> for_each_pipe_with_valid_output(display, pipe, output) {
> igt_plane_t *plane;
> int i, j;
>
> - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> - continue;
> -
> igt_output_set_pipe(output, pipe);
>
> plane = igt_output_get_plane_type(output,
> plane_type);
> @@ -538,14 +549,13 @@ igt_main
> };
>
> data_t data = {};
> - int gen = 0;
>
> igt_skip_on_simulation();
>
> igt_fixture {
> data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> data.devid = intel_get_drm_devid(data.gfx_fd);
> - gen = intel_gen(data.devid);
> + data.gen = intel_gen(data.devid);
>
> kmstest_set_vt_graphics_mode();
>
> @@ -558,16 +568,12 @@ igt_main
> igt_subtest_f("%s-rotation-%s",
> plane_test_str(subtest->plane),
> rot_test_str(subtest->rot)) {
> - igt_require(!(subtest->rot &
> - (IGT_ROTATION_90 |
> IGT_ROTATION_270)) ||
> - gen >= 9);
> data.rotation = subtest->rot;
> test_plane_rotation(&data, subtest->plane,
> false);
> }
> }
>
> igt_subtest_f("sprite-rotation-90-pos-100-0") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.pos_x = 100,
> data.pos_y = 0;
> @@ -577,7 +583,6 @@ igt_main
> data.pos_y = 0;
>
> igt_subtest_f("bad-pixel-format") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_fmt = DRM_FORMAT_RGB565;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -585,7 +590,6 @@ igt_main
> data.override_fmt = 0;
>
> igt_subtest_f("bad-tiling") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_tiling =
> LOCAL_I915_FORMAT_MOD_X_TILED;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -596,9 +600,6 @@ igt_main
> igt_subtest_f("primary-%s-reflect-x-%s",
> tiling_test_str(reflect_x->tiling),
> rot_test_str(reflect_x->rot)) {
> - igt_require(gen >= 10 ||
> - (IS_CHERRYVIEW(data.devid) &&
> reflect_x->rot == IGT_ROTATION_0
> - && reflect_x->tiling ==
> LOCAL_I915_FORMAT_MOD_X_TILED));
> data.rotation = (IGT_REFLECT_X | reflect_x-
> >rot);
> data.override_tiling = reflect_x->tiling;
> test_plane_rotation(&data,
> DRM_
Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
Op 22-03-18 om 23:10 schreef Radhakrishna Sripada:
> From: Anusha Srivatsa
>
> Cleanup the testcases by moving the platform checks to a single function.
>
> The earlier version of the path is posted here [1]
>
> v2: Make use of the property enums to get the supported rotations
> v3: Move hardcodings to a single function(Ville)
>
> [1]: https://patchwork.freedesktop.org/patch/209647/
>
> Cc: Radhakrishna Sripada
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Maarten Lankhorst
> Cc: Mika Kahola
> Cc: Manasi Navare
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Radhakrishna Sripada
> ---
> tests/kms_rotation_crc.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 0cd5c6e52b57..60fb9012e14e 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -43,6 +43,7 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> int devid;
> + int gen;
> } data_t;
>
> typedef struct {
> @@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
> igt_assert(drmHandleEvent(fd, &evctx) == 0);
> }
>
> +static void igt_check_rotation(data_t *data)
> +{
> + if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> + igt_require(data->gen >= 9);
> + else if (data->rotation & IGT_REFLECT_X)
> + igt_require(data->gen >= 10 ||
> + (IS_CHERRYVIEW(data->devid) && (data->rotation &
> IGT_ROTATION_0)));
> + else if (data->rotation & IGT_ROTATION_180)
> + igt_require(data->gen >= 4);
> +}
This still won't work as intended on CHV as it only has reflection on PIPE_B,
for X tiled fb's.
> static void test_single_case(data_t *data, enum pipe pipe,
>igt_output_t *output, igt_plane_t *plane,
>enum rectangle_type rect,
> @@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data, int
> plane_type, bool test_bad_form
>
> igt_display_require_output(display);
>
> + igt_check_rotation(data);
> +
> for_each_pipe_with_valid_output(display, pipe, output) {
> igt_plane_t *plane;
> int i, j;
>
> - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> - continue;
> -
> igt_output_set_pipe(output, pipe);
>
> plane = igt_output_get_plane_type(output, plane_type);
> @@ -538,14 +549,13 @@ igt_main
> };
>
> data_t data = {};
> - int gen = 0;
>
> igt_skip_on_simulation();
>
> igt_fixture {
> data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> data.devid = intel_get_drm_devid(data.gfx_fd);
> - gen = intel_gen(data.devid);
> + data.gen = intel_gen(data.devid);
>
> kmstest_set_vt_graphics_mode();
>
> @@ -558,16 +568,12 @@ igt_main
> igt_subtest_f("%s-rotation-%s",
> plane_test_str(subtest->plane),
> rot_test_str(subtest->rot)) {
> - igt_require(!(subtest->rot &
> - (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
> - gen >= 9);
> data.rotation = subtest->rot;
> test_plane_rotation(&data, subtest->plane, false);
> }
> }
>
> igt_subtest_f("sprite-rotation-90-pos-100-0") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.pos_x = 100,
> data.pos_y = 0;
> @@ -577,7 +583,6 @@ igt_main
> data.pos_y = 0;
>
> igt_subtest_f("bad-pixel-format") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_fmt = DRM_FORMAT_RGB565;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
> @@ -585,7 +590,6 @@ igt_main
> data.override_fmt = 0;
>
> igt_subtest_f("bad-tiling") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
> @@ -596,9 +600,6 @@ igt_main
> igt_subtest_f("primary-%s-reflect-x-%s",
> tiling_test_str(reflect_x->tiling),
> rot_test_str(reflect_x->rot)) {
> - igt_require(gen >= 10 ||
> - (IS_CHERRYVIEW(data.devid) &&
> reflect_x->rot == IGT_ROTATION_0
> - && reflect_x->tiling ==
> LOCAL_I915_FORMAT_MOD_X_TILED));
> data.rotation = (IGT_REFLECT_X | reflect_x->rot);
> data.override_tiling = reflect_x->tiling;
>
Re: [Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium
Hi Eric, Thanks for your input. On Wed, Mar 21, 2018 at 10:10:00AM -0700, Eric Anholt wrote: > Maxime Ripard writes: > > > [ Unknown signature status ] > > Hi, > > > > On Mon, Mar 05, 2018 at 03:21:26PM +0100, Maxime Ripard wrote: > >> Here is an RFC at starting to test the plane formats using the > >> Chamelium over the HDMI. This was tested using the vc4 DRM driver > >> found on the RaspberryPi. > >> > >> This is still pretty rough around the edges at this point, but I'd > >> like to get feedback on a few issues before getting any further. > >> > >> * I've used pixman for now to convert back and forth the pattern and > >> the captured frame. While this worked quite well for the RGB > >> formats since pixman supports most (but not all) of them. However, > >> the long term plan is to also test YUV and more exotic (like > >> vendor specific) formats that pixman has 0 support for. So I > >> really wonder whether this is the right approach compared to: > >> - Using something else (but what?)? > >> - Rolling our own format conversion library? > > Let's start with pixman and either extend pixman if we have formats we > need (they should be pretty amenable for non-yuv channel layouts), or > roll our own YUV bits. For tiling, I think we can just take > pixman-generated linear image content and do the tiling in igt. Ok. I guess another alternative could be to use libv4lconvert that already has a number of rgb to yuv conversions routines. I'm not sure whether adding a new dependency is ok though. > >> * I've so far had a single big test that will test all the formats > >> exposed by the planes that have a pixman representation. I wonder > >> whether this is preferrable, or if we want to have a subtest per > >> format. I guess the latter will be slightly better since we would > >> be able to catch regressions in the number of formats exposed that > >> we wouldn't be able to with the former. > > Yeah, exposing the formats as subtests is probably a good idea. I'll do that then. > >> * Kind of related, I'm not sure what is the policy when it comes to > >> tests, and whether I should merge this tests with kms_chamelium or > >> leave it as a separate file. > > I'll leave this up to the original test author. > > >> * One of the biggest challenge of the serie is to support formats > >> that have less bits than the reference frame. Indeed, the flow of > >> patterns is this one: the pattern will first be generated in > >> ARGB. It will then be converted to whatever format we want to > >> test, be fed into the display engine, that will output it, and the > >> Chamelium will capture it in ARGB. > >> However, when the plane format has less than 8 bits per color, > >> some upsampling will happen, where the less significant bits will > >> be filled with values that probably depend on the display > >> engine. Another side effect is that the CRC used in the Chamelium > >> tests cannot be used anymore. > >> The way I'm testing currently is that I'm retrieving the frame, > >> and then compare each pixels on their most significant bits. This > >> sounds inefficient, and it is, especially on the RPi that doesn't > >> have the best networking throughput out there. > >> I guess we could also generate a CRC for both an upsampling with > >> the lowest bits set to 1, and one for the lowest bits set to 0, > >> and try to see if one of them match. I guess this should cover > >> most of the situation. > > I still think that we should expect the top bits to be replicated into > the low bits, until we find hardware that just can't do that. That works for me then. I'll try to have all these changes, and send a new version then. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
Quoting Mika Kuoppala (2018-03-28 08:58:38) > Chris Wilson writes: > > > Tvrtko uncovered a fun issue with recovering from a wedge device. In his > > tests, he wedged the driver by injecting an unrecoverable hang whilst a > > batch was spinning. As we reset the gpu in the middle of the spinner, > > when resumed it would continue on from the next instruction in the ring > > and write it's breadcrumb. However, on wedging we updated our > > bookkeeping to indicate that the GPU had completed executing and would > > restart from after the breadcrumb; so the emission of the stale > > breadcrumb from before the reset came as a bit of a surprise. > > > > Ok trying to make sense of the above and how the wedging works. > Here is my assertions. > > The spinning batch was never found to be guilty of anything. It was definitely guilty. > On wedge we fast forwarded all engine seqnos to be what > was last submitted. Correct. > We did hw reset. Correct. > On context image, the RING_HEAD was pointing to bb start > of spin batch (or the instruction after it) Instruction after. > On resubmitting the context, we saw a seqno write from pre > reset era. Correct. > So this doesn't affect only spinning batches but any busy > batch that was running while we wedged? Correct. Any execlists recovery from _wedged_ would be prone to hitting this bug. legacy submission already applies the ring registers reset on recovery. Thinking of which, if we could, we should ban all contexts on wedging? Or at least process the ban accounting for a failed reset. That sounds more plausible (set_wedge() is a nasty lockless affair). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17
On 2018.03.27 17:39:53 +0300, Joonas Lahtinen wrote: > Quoting Joonas Lahtinen (2018-03-27 16:42:28) > > Quoting Zhenyu Wang (2018-03-27 11:39:42) > > > > > > Hi, Joonas > > > > > > Here's this week's gvt-next-fixes queued for 4.17. One notable change > > > is to revert previous workaround for gvt context preemption, now it > > > has full support for preemption now. > > > > I've pulled the patches, but this revert sounds fishy. Is it something > > that should have been done together with a commit in a batch introduced > > to 4.17? To me, this sounds much like a feature patch, "enable > > pre-emption on GVT context" is even written in the tag. > > > > So I'm inclined to drop this patch from -fixes pull. > > On a second thought, I'll drop the whole pull to make it less of a > hassle with rebases. Please send and updated pull with just the fix > patches. > Hi, Joonas Here's refreshed pull for 4.17 without that revert patch which also include new fixes for ggtt dma unmap and virtual display. thanks -- The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26: drm/i915/gvt: force to set all context control bits from guest (2018-03-19 17:33:30 +0800) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-28 for you to fetch changes up to d35de041470fe08321bd9a7b42483ff653764918: drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display initialization (2018-03-28 16:15:01 +0800) gvt-next-fixes-2018-03-28 - fix unhandled vfio ioctl return value (Gerd) - no-op user interrupt for vGPU (Zhipeng) - fix eventfd ctx deference (Xiong) - fix ggtt dma unmap (Changbin) - fix warning in fb decoder (Xiong) - misc cleanup Changbin Du (2): drm/i915/gvt: Missed to cancel dma map for ggtt entries drm/i915/gvt: Cancel dma map when resetting ggtt entries Gerd Hoffmann (1): drm/i915/gvt: throw error on unhandled vfio ioctls Gustavo A. R. Silva (1): drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification Xiong Zhang (3): drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore drm/i915/gvt: Delete redundant error message in fb_decode.c drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display initialization Zhipeng Gong (1): drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/display.c| 10 +++ drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++ drivers/gpu/drm/i915/gvt/gtt.c| 52 ++- drivers/gpu/drm/i915/gvt/gtt.h| 2 +- drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ++-- 7 files changed, 83 insertions(+), 28 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout
Quoting Chris Wilson (2018-03-27 10:23:26)
> Quoting Tvrtko Ursulin (2018-03-27 09:51:20)
> >
> > On 26/03/2018 12:50, Chris Wilson wrote:
> > > +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);
> > > +
> > > + queue_work(system_highpri_wq, &execlists->preempt_reset);
> >
> > I suppose indirection from hrtimer to worker is for better than jiffie
> > timeout granularity? But then queue_work might introduce some delay to
> > defeat that.
>
> Yes. It's betting on highpri_wq being just that. We can do better with
> our own RT kthread and a wakeup from the hrtimer if required.
>
> Hmm, the original plan (watchdog TDR) was to avoid using the global
> reset entirely. The per-engine reset (although needs serialising with
> itself) doesn't need struct_mutex, so we should be able to do that from
> the timer directly, and just kick off the global reset on failure.
>
> That sounds a whole lot better, let's dust off that code and see what
> breaks.
So I think something along the lines of
+static int try_execlists_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(&engine->execlists.tasklet);
+ err = i915_reset_engine(engine,
+ "preemption timeout");
+ tasklet_enable(&engine->execlists.tasklet);
+
+ clear_bit(bit, lock);
+ wake_up_bit(lock, bit);
+ }
+
+ tasklet_unlock(&execlists->tasklet);
+ }
+
+ return err;
+}
should do the trick, with a fallback to worker+i915_handle_error for the
cases where we can't claim ensure softirq safety.
There's still the issue of two resets in quick succession being treated
as a failure. That's also an issue for the current per-engine failover
to whole-device reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper
== Series Details == Series: series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper URL : https://patchwork.freedesktop.org/series/40768/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 Test kms_flip: Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102887 +1 Test kms_frontbuffer_tracking: Subgroup fbc-rgb565-draw-render: skip -> FAIL (shard-apl) fdo#103167 Test kms_plane_multiple: Subgroup atomic-pipe-a-tiling-x: pass -> FAIL (shard-snb) fdo#103166 Test kms_setmode: Subgroup basic: fail -> PASS (shard-apl) fdo#99912 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1832 dwarn:1 dfail:0 fail:7 skip:1654 time:12948s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11646s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:7004s Blacklisted hosts: shard-kbltotal:3495 pass:1955 dwarn:1 dfail:1 fail:10 skip:1528 time:9646s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8511/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/8] drm/i915/uc: Disable GuC submission during sanitize
On 3/28/2018 2:05 AM, Michal Wajdeczko wrote: We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 4aad844..ec90c81 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -330,6 +330,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (USES_GUC_SUBMISSION(dev_priv)) + intel_guc_submission_disable(guc); + guc_disable_communication(guc); intel_huc_sanitize(huc); -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/8] drm/i915/guc: Restore symmetric doorbell cleanup
On 3/28/2018 2:05 AM, Michal Wajdeczko wrote:
In commit 9192d4fb811e ("drm/i915/guc: Extract doorbell creation
from client allocation") we introduced asymmetry in doorbell cleanup
to avoid warnings due to failed communication with already reset GuC.
As we improved our reset/unload paths, we can restore symmetry in
doorbell cleanup, as GuC should be still active by now.
Suggested-by: Sagar Arun Kamble
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michal Winiarski
Cc: Chris Wilson
This looks good.
Reviewed-by: Sagar Arun Kamble
We should extend this functionality further to consider cases when GuC
doorbell deactivation flow is to be
invoked (when GuC is in sane state) and not to be invoked (when GuC is
hung) as was prepared in patchset
https://patchwork.freedesktop.org/series/33209/ but that can be done
after this series if we agree on need for such handling.
Thanks,
Sagar
---
drivers/gpu/drm/i915/intel_guc_submission.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 207cda0..26985d8 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -835,18 +835,9 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
static void guc_clients_doorbell_fini(struct intel_guc *guc)
{
- /*
-* By the time we're here, GuC has already been reset.
-* Instead of trying (in vain) to communicate with it, let's just
-* cleanup the doorbell HW and our internal state.
-*/
- if (guc->preempt_client) {
- __destroy_doorbell(guc->preempt_client);
- __update_doorbell_desc(guc->preempt_client,
- GUC_DOORBELL_INVALID);
- }
- __destroy_doorbell(guc->execbuf_client);
- __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
+ if (guc->preempt_client)
+ destroy_doorbell(guc->preempt_client);
+ destroy_doorbell(guc->execbuf_client);
}
/**
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 04/19] drm/i915/skl+: support verification of DDB HW state for NV12
From: Mahesh Kumar
For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.
v2: Addressed review comments by Maarten.
v3: Addressed review comments by Shashank Sharma.
v4: Adding reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 51 +---
3 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5b694a6..5fb0e43 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2657,7 +2657,7 @@ static int i9xx_format_to_fourcc(int format)
}
}
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
{
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7310fe..ed79a61 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1612,6 +1612,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb,
int plane,
int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c051cd3..0f99652 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3825,6 +3825,44 @@ static void skl_ddb_entry_init_from_hw(struct
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
}
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+ const enum pipe pipe,
+ const enum plane_id plane_id,
+ struct skl_ddb_allocation *ddb /* out */)
+{
+ u32 val, val2 = 0;
+ int fourcc, pixel_format;
+
+ /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+ if (plane_id == PLANE_CURSOR) {
+ val = I915_READ(CUR_BUF_CFG(pipe));
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val);
+ return;
+ }
+
+ val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+ /* No DDB allocated for disabled planes */
+ if (!(val & PLANE_CTL_ENABLE))
+ return;
+
+ pixel_format = val & PLANE_CTL_FORMAT_MASK;
+ fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+ val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+ val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+ if (fourcc == DRM_FORMAT_NV12) {
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val2);
+ skl_ddb_entry_init_from_hw(&ddb->uv_plane[pipe][plane_id], val);
+ } else {
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val);
+ }
+}
+
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */)
{
@@ -3841,16 +3879,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
- for_each_plane_id_on_crtc(crtc, plane_id) {
- u32 val;
-
- if (plane_id != PLANE_CURSOR)
- val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
- else
- val = I915_READ(CUR_BUF_CFG(pipe));
-
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
val);
- }
+ for_each_plane_id_on_crtc(crtc, plane_id)
+ skl_ddb_get_hw_plane_state(dev_priv, pipe,
+ plane_id, ddb);
intel_display_power_put(dev_priv, power_domain);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/lis
[Intel-gfx] [PATCH v17 07/19] drm/i915/skl+: make sure higher latency level has higher wm value
From: Mahesh Kumar
DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.
v2: Changed plane_num to plane_id in skl_compute_wm_levels
v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"
v4: Added reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb17464..b318a27 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,6 +4529,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+ const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
{
const struct drm_plane_state *pstate = &intel_pstate->base;
@@ -4596,6 +4597,15 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+ /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+ if (result_prev->plane_res_b > res_blocks)
+ res_blocks = result_prev->plane_res_b;
}
if (INTEL_GEN(dev_priv) >= 11) {
@@ -4679,6 +4689,13 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_id ? &wm->uv_wm[level] :
&wm->wm[level];
+ struct skl_wm_level *result_prev;
+
+ if (level)
+ result_prev = plane_id ? &wm->uv_wm[level - 1] :
+ &wm->wm[level - 1];
+ else
+ result_prev = plane_id ? &wm->uv_wm[0] : &wm->wm[0];
ret = skl_compute_plane_wm(dev_priv,
cstate,
@@ -4686,6 +4703,7 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
ddb_blocks,
level,
wm_params,
+ result_prev,
result);
if (ret)
return ret;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 01/19] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
From: Mahesh Kumar
skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.
s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe
Changes since V1:
- also change name of skl_copy_wm_for_pipe
v2: Added reviewed by from Juha-Pekka Heikkila
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 16
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..2afa7f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1186,7 +1186,7 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
};
-struct skl_wm_values {
+struct skl_ddb_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
};
@@ -1885,7 +1885,7 @@ struct drm_i915_private {
/* current hardware state */
union {
struct ilk_wm_values hw;
- struct skl_wm_values skl_hw;
+ struct skl_ddb_values skl_hw;
struct vlv_wm_values vlv;
struct g4x_wm_values g4x;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d1452fd..7f77e6d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,7 +482,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
/* Gen9+ only */
- struct skl_wm_values wm_results;
+ struct skl_ddb_values wm_results;
struct i915_sw_fence commit_ready;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 19e82aa..d2963bc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5042,9 +5042,9 @@ skl_compute_ddb(struct drm_atomic_state *state)
}
static void
-skl_copy_wm_for_pipe(struct skl_wm_values *dst,
-struct skl_wm_values *src,
-enum pipe pipe)
+skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
+ struct skl_ddb_values *src,
+ enum pipe pipe)
{
memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
sizeof(dst->ddb.y_plane[pipe]));
@@ -5095,7 +5095,7 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct skl_wm_values *results = &intel_state->wm_results;
+ struct skl_ddb_values *results = &intel_state->wm_results;
struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
@@ -5197,8 +5197,8 @@ static void skl_initial_wm(struct intel_atomic_state
*state,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct skl_wm_values *results = &state->wm_results;
- struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
+ struct skl_ddb_values *results = &state->wm_results;
+ struct skl_ddb_values *hw_vals = &dev_priv->wm.skl_hw;
enum pipe pipe = intel_crtc->pipe;
if ((results->dirty_pipes & drm_crtc_mask(&intel_crtc->base)) == 0)
@@ -5209,7 +5209,7 @@ static void skl_initial_wm(struct intel_atomic_state
*state,
if (cstate->base.active_changed)
skl_atomic_update_crtc_wm(state, cstate);
- skl_copy_wm_for_pipe(hw_vals, results, pipe);
+ skl_copy_ddb_for_pipe(hw_vals, results, pipe);
mutex_unlock(&dev_priv->wm.wm_mutex);
}
@@ -5341,7 +5341,7 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
void skl_wm_get_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct skl_wm_values *hw = &dev_priv->wm.skl_hw;
+ struct skl_ddb_values *hw = &dev_priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 09/19] drm/i915/skl: split skl_compute_ddb function
From: Mahesh Kumar
This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.
v2: Added reviewed by tag from Shashank Sharma
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
v5: Fixed checkpatch error. Changed *changed = true
to (*changed) = true;
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 157 ++--
1 file changed, 88 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3210868..becdef0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5059,69 +5059,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state
*cstate)
static int
skl_compute_ddb(struct drm_atomic_state *state)
{
- struct drm_device *dev = state->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = &intel_state->wm_results.ddb;
- uint32_t realloc_pipes = pipes_modified(state);
- int ret;
-
- /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us. Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
- if (dev_priv->wm.distrust_bios_wm) {
- ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
- state->acquire_ctx);
- if (ret)
- return ret;
-
- intel_state->active_pipe_changes = ~0;
-
- /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
- if (!intel_state->modeset)
- intel_state->active_crtcs = dev_priv->active_crtcs;
- }
-
- /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit. Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
- if (intel_state->active_pipe_changes) {
- realloc_pipes = ~0;
- intel_state->wm_results.dirty_pipes = ~0;
- }
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *cstate;
+ int ret, i;
- /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, &dev_priv->wm.skl_hw.ddb, sizeof(*ddb));
- for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
- struct intel_crtc_state *cstate;
-
- cstate = intel_atomic_get_crtc_state(state, intel_crtc);
- if (IS_ERR(cstate))
- return PTR_ERR(cstate);
-
+ for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5183,23 +5130,23 @@ skl_print_wm_changes(const struct drm_atomic_state
*state)
}
static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
{
- struct drm_crtc *crtc;
- struct drm_crtc_state *cstate;
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct skl_ddb_values *results = &intel_state->wm_results;
struct drm_device *dev = state->dev;
- struct skl_pipe_wm *pipe_wm;
- bool changed = false;
+ const struct drm_i915_private *dev_priv = to_i915(dev);
+ const struct drm_crtc *crtc;
+ const struct drm_crtc_state *cstate;
+ struct intel_crtc *intel_crtc;
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ uint32_t realloc_pipes = pipes_modified(state);
int ret, i;
/*
[Intel-gfx] [PATCH v17 08/19] drm/i915/skl+: nv12 workaround disable WM level 1-7
From: Mahesh Kumar
Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.
v2: Addressed review comments by Maarten.
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b318a27..3210868 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4653,6 +4653,17 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
}
}
+ /*
+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+ if (wp->is_planar && level >= 1 &&
+ (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
+ result->plane_en = false;
+ return 0;
+ }
+
/* The number of lines are ignored for the level 0 watermark. */
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 06/19] drm/i915/skl+: pass skl_wm_level struct to wm compute func
From: Mahesh Kumar
This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.
v2: Addressed review comments by Shashank Sharma
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_pm.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 854671f..eb17464 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,9 +4529,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
- uint16_t *out_blocks, /* out */
- uint8_t *out_lines, /* out */
- bool *enabled /* out */)
+ struct skl_wm_level *result /* out */)
{
const struct drm_plane_state *pstate = &intel_pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
@@ -4545,7 +4543,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
- *enabled = false;
+ result->plane_en = false;
return 0;
}
@@ -4626,7 +4624,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if ((level > 0 && res_lines > 31) ||
res_blocks >= ddb_allocation ||
min_disp_buf_needed >= ddb_allocation) {
- *enabled = false;
+ result->plane_en = false;
/*
* If there are no valid level 0 watermarks, then we can't
@@ -4646,9 +4644,9 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
}
/* The number of lines are ignored for the level 0 watermark. */
- *out_lines = level ? res_lines : 0;
- *out_blocks = res_blocks;
- *enabled = true;
+ result->plane_res_b = res_blocks;
+ result->plane_res_l = res_lines;
+ result->plane_en = true;
return 0;
}
@@ -4688,9 +4686,7 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
ddb_blocks,
level,
wm_params,
- &result->plane_res_b,
- &result->plane_res_l,
- &result->plane_en);
+ result);
if (ret)
return ret;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 19/19] drm/i915: Do not truncate fb sizes for NV12
As per WA 1106, to avoid corruption issues
NV12 plane height needs to be multiplier of 4
We avoid trunction in this patch so that
the buffer we send (which is multiplier of 4)
directs goes into the kernel.
Credits-to: Maarten Lankhorst
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 4
drivers/gpu/drm/i915/intel_sprite.c | 13 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0db0465..744dfc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12987,6 +12987,9 @@ intel_check_primary_plane(struct intel_plane *plane,
if (ret)
return ret;
+ if (pixel_format == DRM_FORMAT_NV12)
+ goto check_plane_surface;
+
if (!state->base.fb)
return 0;
@@ -13108,6 +13111,7 @@ intel_check_primary_plane(struct intel_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
+check_plane_surface:
if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(crtc_state, state);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 538d938..e50751d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -230,6 +230,8 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
#endif
}
+#define MULT4(x) ((x + 3) & ~0x03)
+
void
skl_update_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -261,6 +263,13 @@ skl_update_plane(struct intel_plane *plane,
crtc_w--;
crtc_h--;
+ if (fb->format->format == DRM_FORMAT_NV12) {
+ crtc_w = MULT4(crtc_w);
+ crtc_h = MULT4(crtc_h);
+ src_w = MULT4(src_w);
+ src_h = MULT4(src_h);
+ }
+
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
@@ -957,6 +966,9 @@ intel_check_sprite_plane(struct intel_plane *plane,
return 0;
}
+ if (fb->format->format && fb->format->format == DRM_FORMAT_NV12)
+ goto check_plane_surface;
+
/* Don't modify another pipe's plane */
if (plane->pipe != crtc->pipe) {
DRM_DEBUG_KMS("Wrong plane <-> crtc mapping\n");
@@ -,6 +1123,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
+check_plane_surface:
if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(crtc_state, state);
if (ret)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 16/19] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.
v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h
v3: Adding Reviewed By from Shashank Sharma
v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Shashank Sharma
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5097374..96d5262 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3633,6 +3633,11 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
if (intel_format_is_yuv(fb->format->format)) {
+ if (fb->format->format == DRM_FORMAT_NV12) {
+ plane_color_ctl |=
+ PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+ goto out;
+ }
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -3641,7 +3646,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
-
+out:
return plane_color_ctl;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 02/19] drm/i915/skl+: refactor WM calculation for NV12
From: Mahesh Kumar
Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.
v2: Addressed review comments by Maarten
v3: Rebased and addressed review comments by Maarten
v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 121 ---
3 files changed, 66 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2afa7f9..3208152 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1182,8 +1182,9 @@ static inline bool skl_ddb_entry_equal(const struct
skl_ddb_entry *e1,
}
struct skl_ddb_allocation {
- struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /*
packed/uv */
- struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+ /* packed/y */
+ struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
+ struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
};
struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7f77e6d..d7310fe 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -603,6 +603,7 @@ struct intel_pipe_wm {
struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+ bool is_planar;
};
struct skl_pipe_wm {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d2963bc..c051cd3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4009,9 +4009,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
*intel_crtc,
static unsigned int
skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
-int y)
+const int plane)
{
- struct intel_plane *plane = to_intel_plane(pstate->plane);
+ struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t data_rate;
uint32_t width = 0, height = 0;
@@ -4025,9 +4025,9 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
- if (plane->id == PLANE_CURSOR)
+ if (intel_plane->id == PLANE_CURSOR)
return 0;
- if (y && format != DRM_FORMAT_NV12)
+ if (plane == 1 && format != DRM_FORMAT_NV12)
return 0;
/*
@@ -4038,19 +4038,14 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
width = drm_rect_width(&intel_pstate->base.src) >> 16;
height = drm_rect_height(&intel_pstate->base.src) >> 16;
- /* for planar format */
- if (format == DRM_FORMAT_NV12) {
- if (y) /* y-plane data rate */
- data_rate = width * height *
- fb->format->cpp[0];
- else/* uv-plane data rate */
- data_rate = (width / 2) * (height / 2) *
- fb->format->cpp[1];
- } else {
- /* for packed formats */
- data_rate = width * height * fb->format->cpp[0];
+ /* UV plane does 1/2 pixel sub-sampling */
+ if (plane == 1 && format == DRM_FORMAT_NV12) {
+ width /= 2;
+ height /= 2;
}
+ data_rate = width * height * fb->format->cpp[plane];
+
down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
@@ -4063,8 +4058,8 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
*/
static unsigned int
skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
-unsigned *plane_data_rate,
-unsigned *plane_y_data_rate)
+unsigned int *plane_data_rate,
+unsigned int *uv_plane_data_rate)
{
struct drm_crtc_state *cstate = &intel_cstate->base;
struct drm_atomic_state *state = cstate->state;
@@ -4080,17 +4075,17 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
enum plane_id plane_id = to_intel_plane(plane)->id;
unsigned int rate;
- /* packed/uv */
+
[Intel-gfx] [PATCH v17 00/19] Add NV12 support
This patch series is adding NV12 support for Broxton display after rebasing on latest drm-tip. Initial series of the patches can be found here: https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html Previous revision history: The first version of patches were reviewed when floated by Chandra in 2015 but currently there was a design change with respect to - the way fb offset is handled - the way rotation is handled Current NV12 patch series has been ported as per the current changes on drm-tip Review comments from Ville (12th June 2017) have been addressed Review comments from Clinton A Taylor (7th July 2017) have been addressed Review comments from Clinton A Taylor (10th July 2017) have been addressed. Had missed out tested-by/reviewed-by in the patches. Fixed that error in this series. Review comments from Ville (11th July 2017) addressed. Review comments from Paauwe, Bob (29th July 2017) addressed. Update from rev 28 Aug 2017 Rebased the series. Tested with IGT for rotation, sprite and tiling combinations. IGT Links: https://patchwork.kernel.org/patch/9995943/ https://patchwork.kernel.org/patch/9995945/ Review comments by Maarten are addressed in this series. NV12 enabled for Gen10. Review comments from Shashank Sharma are addressed. IGT debug_fs test failure fixed. Added reviewed-by tag from Shashank Sharma for few patches Addressed comments from Juha-Pekka Heikkila in few patches (NV12 not to be supported for SKL) Adding an additional patch Display WA 827 for underrun during NV12 Adding more WA implementation to see if it helps underruns Addressed review comments from Ville regarding the planar formats Added minimum src height for yuv 420 planar formats Added NV12 in skl_mod_supported (review comments from Kristian Høgsberg Addressed review comments from Maarten (add checks to primary plane) Update from previous series: Fixed checkpatch errors New patch which avoids truncation for NV12 Chandra Konduru (6): drm/i915: Set scaler mode for NV12 drm/i915: Update format_is_yuv() to include NV12 drm/i915: Upscale scaler max scale for NV12 drm/i915: Add NV12 as supported format for primary plane drm/i915: Add NV12 as supported format for sprite plane drm/i915: Add NV12 support to intel_framebuffer_init Mahesh Kumar (9): drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values drm/i915/skl+: refactor WM calculation for NV12 drm/i915/skl+: add NV12 in skl_format_to_fourcc drm/i915/skl+: support verification of DDB HW state for NV12 drm/i915/skl+: NV12 related changes for WM drm/i915/skl+: pass skl_wm_level struct to wm compute func drm/i915/skl+: make sure higher latency level has higher wm value drm/i915/skl+: nv12 workaround disable WM level 1-7 drm/i915/skl: split skl_compute_ddb function Vidya Srinivas (4): drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg drm/i915: Display WA 827 drm/i915: Add checks to primary plane drm/i915: Do not truncate fb sizes for NV12 drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_atomic.c | 14 +- drivers/gpu/drm/i915/intel_display.c | 289 +-- drivers/gpu/drm/i915/intel_drv.h | 13 +- drivers/gpu/drm/i915/intel_pm.c | 438 ++- drivers/gpu/drm/i915/intel_sprite.c | 43 +++- 7 files changed, 621 insertions(+), 191 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 14/19] drm/i915: Add NV12 as supported format for sprite plane
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.
v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B
v7: Rebased (me)
v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.
v11: Addressed review comments from Shashank Sharma
v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.
v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg
v15: Added reviewed by from Juha-Pekka Heikkila
v16: Rebased the series
Tested-by: Clinton Taylor
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_sprite.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 22068e0..538d938 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1252,6 +1252,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
};
+static uint32_t skl_planar_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1346,6 +1359,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -1445,8 +1459,14 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- plane_formats = skl_plane_formats;
- num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+ plane_formats = skl_planar_formats;
+ num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+ } else {
+ plane_formats = skl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ }
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 15/19] drm/i915: Add NV12 support to intel_framebuffer_init
From: Chandra Konduru
This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.
v2:
-Fix an issue in checks added (Chandra Konduru)
v3: rebased (me)
v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case
v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.
v6: Rebased (me)
v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.
v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.
v9: Rebased (me)
v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable
v11: Addressed review comments from Shashank Sharma
v12: Adding Reviewed By from Shashank Sharma
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila
v15: Rebased the series
v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.
Tested-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5aa0628..5097374 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14210,6 +14210,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
break;
+ case DRM_FORMAT_NV12:
+ if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv)) {
+ DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+
drm_get_format_name(mode_cmd->pixel_format,
+ &format_name));
+ goto err;
+ }
+ break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
drm_get_format_name(mode_cmd->pixel_format,
&format_name));
@@ -14222,6 +14230,13 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
drm_helper_mode_fill_fb_struct(&dev_priv->drm, fb, mode_cmd);
+ if (fb->format->format == DRM_FORMAT_NV12 &&
+ (fb->width < SKL_MIN_YUV_420_SRC_W ||
+fb->height < SKL_MIN_YUV_420_SRC_H)) {
+ DRM_DEBUG_KMS("Min fb dimensions not met for planar format\n");
+ return -EINVAL;
+ }
+
for (i = 0; i < fb->format->num_planes; i++) {
u32 stride_alignment;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 05/19] drm/i915/skl+: NV12 related changes for WM
From: Mahesh Kumar
NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.
v2: Addressed review comments from Shashank Sharma.
v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 50 +---
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3208152..c592ebe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1202,6 +1202,7 @@ struct skl_wm_level {
struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
+ bool is_planar;
uint32_t width;
uint8_t cpp;
uint32_t plane_pixel_rate;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ed79a61..272c091 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -602,6 +602,7 @@ struct intel_pipe_wm {
struct skl_plane_wm {
struct skl_wm_level wm[8];
+ struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
bool is_planar;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f99652..854671f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4419,7 +4419,7 @@ static int
skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
- struct skl_wm_params *wp)
+ struct skl_wm_params *wp, int plane_id)
{
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = &intel_pstate->base;
@@ -4432,6 +4432,12 @@ skl_compute_plane_wm_params(const struct
drm_i915_private *dev_priv,
if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
+ /* only NV12 format has two planes */
+ if (plane_id == 1 && fb->format->format != DRM_FORMAT_NV12) {
+ DRM_DEBUG_KMS("Non NV12 format have single plane\n");
+ return -EINVAL;
+ }
+
wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
@@ -4439,6 +4445,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private
*dev_priv,
wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+ wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
@@ -4451,7 +4458,10 @@ skl_compute_plane_wm_params(const struct
drm_i915_private *dev_priv,
wp->width = drm_rect_width(&intel_pstate->base.src) >> 16;
}
- wp->cpp = fb->format->cpp[0];
+ if (plane_id == 1 && wp->is_planar)
+ wp->width /= 2;
+
+ wp->cpp = fb->format->cpp[plane_id];
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
intel_pstate);
@@ -4649,7 +4659,8 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
const struct skl_wm_params *wm_params,
- struct skl_plane_wm *wm)
+ struct skl_plane_wm *wm,
+ int plane_id)
{
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_plane *plane = intel_pstate->base.plane;
@@ -4657,15 +4668,19 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int level, max_level = ilk_wm_max_level(dev_priv);
+ enum plane_id intel_plane_id = intel_plane->id;
int ret;
if (WARN_ON(!intel_pstate->base.fb))
return -EINVAL;
- ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][intel_plane->id]);
+ ddb_blocks = plane_id ?
+skl_ddb_entry_size(&ddb->uv_plane[pipe][intel_plane_id]) :
+skl_ddb_entry_size(&ddb->plane[
[Intel-gfx] [PATCH v17 11/19] drm/i915: Update format_is_yuv() to include NV12
From: Chandra Konduru This patch adds NV12 to format_is_yuv() function for sprite planes. v2: -Use intel_ prefix for format_is_yuv (Ville) v3: Rebased (me) v4: Rebased and addressed review comments from Clinton A Taylor. "static function in intel_sprite.c is not available to the primary plane functions". Changed commit message - function modified for sprite planes. v5: Missed the Tested-by/Reviewed-by in the previous series Adding the same to commit message in this version. v6: Rebased (me) v7: Rebased (me) v8: Rebased (me) v9: Rebased (me) v10: Changed intel_format_is_yuv function from static to non-static. We need to use it later from other files for check. v11: Rebased the patch. format_is_yuv has already been renamed to intel_format_is_yuv in the color patch series which is already merged. This function which was previously static has already been made non-static. So this patch after rebase just adds NV12 to intel_format_is_yuv function. v12: Added reviewed by from Juha-Pekka Heikkila v13/v14/v15: Rebased the series Tested-by: Clinton Taylor Reviewed-by: Juha-Pekka Heikkila Reviewed-by: Clinton Taylor Reviewed-by: Shashank Sharma Signed-off-by: Chandra Konduru Signed-off-by: Nabendu Maiti Signed-off-by: Vidya Srinivas --- drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_sprite.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 272c091..de7ddb1 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -2054,6 +2054,7 @@ void skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc); bool skl_plane_get_hw_state(struct intel_plane *plane); bool skl_plane_has_ccs(struct drm_i915_private *dev_priv, enum pipe pipe, enum plane_id plane_id); +bool intel_format_is_yuv(uint32_t format); /* intel_tv.c */ void intel_tv_init(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index dbdcf85..0652e58 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -48,6 +48,7 @@ bool intel_format_is_yuv(u32 format) case DRM_FORMAT_UYVY: case DRM_FORMAT_VYUY: case DRM_FORMAT_YVYU: + case DRM_FORMAT_NV12: return true; default: return false; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 12/19] drm/i915: Upscale scaler max scale for NV12
From: Chandra Konduru
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series
v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Rebased (me)
v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.
v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.
v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.
v14: Addressed review comments from Maarten
Just add a check for NV12 min src height in
skl_update_scaler and retain the remaining checks
as is. Added Reviewed By from Juha-Pekka Heikkila.
v15: Rebased the series.
v16: Changed fb height restriction to be >= 16 as per
Bspec. Earlier it was > 16.
Tested-by: Clinton Taylor
Reviewed-by: Clinton Taylor
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 47 +++-
drivers/gpu/drm/i915/intel_drv.h | 5 +++-
drivers/gpu/drm/i915/intel_sprite.c | 5 +++-
3 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5fb0e43..fae1de9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3468,6 +3468,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+ case DRM_FORMAT_NV12:
+ return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4707,7 +4709,9 @@ static void cpt_verify_modeset(struct drm_device *dev,
int pipe)
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ bool plane_scaler_check,
+ uint32_t pixel_format)
{
struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
@@ -4725,6 +4729,10 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (plane_scaler_check)
+ if (pixel_format == DRM_FORMAT_NV12)
+ need_scaling = true;
+
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4764,6 +4772,12 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
+ if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ src_h < SKL_MIN_YUV_420_SRC_H) {
+ DRM_DEBUG_KMS("NV12: scaler out of range\n");
+ return -EINVAL;
+ }
+
/* range checks */
if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
@@ -4803,9 +4817,10 @@ int skl_update_scaler_crtc(struct intel_crtc_state
*state)
const struct drm_display_mode *adjusted_mode =
&state->base.adjusted_mode;
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
- &state->scaler_state.scaler_id,
- state->pipe_src_w, state->pipe_src_h,
- adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+&state->scaler_state.scaler_id,
+state->pipe_src_w, state->pipe_src_h,
+adjusted_mode->crtc_hdisplay,
+adjusted_mode->crtc_vdisplay, false, 0);
}
/**
@@ -4834,7 +4849,8 @@ static int s
[Intel-gfx] [PATCH v17 17/19] drm/i915: Display WA 827
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.
v2: Addressed review comments from Maarten and
Juha-Pekka Heikkila. Added reviewed by from
Juha-Pekka Heikkila.
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 34 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f8d97ab..8cbc633 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3806,6 +3806,9 @@ enum {
#define _CLKGATE_DIS_PSL_A 0x46520
#define _CLKGATE_DIS_PSL_B 0x46524
#define _CLKGATE_DIS_PSL_C 0x46528
+#define DUPS1_GATING_DIS (1 << 15)
+#define DUPS2_GATING_DIS (1 << 19)
+#define DUPS3_GATING_DIS (1 << 23)
#define DPF_GATING_DIS (1 << 10)
#define DPF_RAM_GATING_DIS (1 << 9)
#define DPFR_GATING_DIS (1 << 8)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 96d5262..7a60c4e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -504,6 +504,21 @@ static const struct intel_limit intel_limits_bxt = {
.p2 = { .p2_slow = 1, .p2_fast = 20 },
};
+static void
+skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+ if (IS_SKYLAKE(dev_priv))
+ return;
+
+ if (enable)
+ I915_WRITE(CLKGATE_DIS_PSL(pipe),
+ DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+ else
+ I915_WRITE(CLKGATE_DIS_PSL(pipe),
+ I915_READ(CLKGATE_DIS_PSL(pipe)) &
+ ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
+}
+
static bool
needs_modeset(const struct drm_crtc_state *state)
{
@@ -5144,6 +5159,8 @@ static bool hsw_post_update_enable_ips(const struct
intel_crtc_state *old_crtc_s
static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct intel_crtc_state *pipe_config =
intel_atomic_get_new_crtc_state(to_intel_atomic_state(old_state),
@@ -5166,6 +5183,7 @@ static void intel_post_plane_update(struct
intel_crtc_state *old_crtc_state)
to_intel_plane(primary));
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
+ struct drm_framebuffer *fb = primary_state->base.fb;
intel_fbc_post_update(crtc);
@@ -5173,6 +5191,14 @@ static void intel_post_plane_update(struct
intel_crtc_state *old_crtc_state)
(needs_modeset(&pipe_config->base) ||
!old_primary_state->base.visible))
intel_post_enable_primary(&crtc->base, pipe_config);
+
+ /* Display WA 827 */
+ if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+ IS_CANNONLAKE(dev_priv)) {
+ if (fb && fb->format->format == DRM_FORMAT_NV12)
+ skl_wa_clkgate(dev_priv, crtc->pipe, false);
+ }
+
}
}
@@ -5199,6 +5225,14 @@ static void intel_pre_plane_update(struct
intel_crtc_state *old_crtc_state,
to_intel_plane(primary));
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
+ struct drm_framebuffer *fb = primary_state->base.fb;
+
+ /* Display WA 827 */
+ if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+ IS_CANNONLAKE(dev_priv)) {
+ if (fb && fb->format->format == DRM_FORMAT_NV12)
+ skl_wa_clkgate(dev_priv, crtc->pipe, true);
+ }
intel_fbc_pre_update(crtc, pipe_config, primary_state);
/*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 13/19] drm/i915: Add NV12 as supported format for primary plane
From: Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Rebased (me)
v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)
v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.
v11: Adding Reviewed By tag from Shashank Sharma
v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg
v14: Added reviewed by from Juha-Pekka Heikkila
v15: Rebased the series
Tested-by: Clinton Taylor
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 50 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fae1de9..5aa0628 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint32_t skl_pri_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13075,6 +13091,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -13282,6 +13299,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
}
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+ if (plane_id == PLANE_PRIMARY) {
+ if (IS_SKYLAKE(dev_priv))
+ return false;
+ else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+!IS_GEMINILAKE(dev_priv))
+ return false;
+ } else if (plane_id >= PLANE_SPRITE0) {
+ if (plane_id == PLANE_CURSOR)
+ return false;
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+ if (plane_id != PLANE_SPRITE0)
+ return false;
+ } else {
+ if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+ IS_SKYLAKE(dev_priv))
+ return false;
+ }
+ }
+ return true;
+}
+
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
@@ -13342,8 +13383,13 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
if (INTEL_GEN(dev_priv) >= 9) {
- intel_primary_formats = skl_primary_formats;
- num_formats = ARRAY_SIZE(skl_primary_formats);
+ if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ intel_primary_formats = skl_pri_planar_formats;
+ num_formats = ARRAY_SIZE(skl_pri_planar_formats);
+ } else {
+ intel_primary_formats = skl_primary_formats;
+ num_formats = ARRAY_SIZE(skl_primary_formats);
+ }
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
modifiers = skl_format_modifiers_ccs;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 66d0fe4..9c58da0 100644
--- a/drivers/gpu/drm/i915/in
[Intel-gfx] [PATCH v17 18/19] drm/i915: Add checks to primary plane
Patch adds checks to primary plane related
to scaling, clipping, rotation and fb formats.
These checks currently, were being done only for sprites.
These are required for primary plane as well.
Credits-to: Maarten Lankhorst
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 128 ++-
1 file changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a60c4e..0db0465 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12956,11 +12956,16 @@ intel_check_primary_plane(struct intel_plane *plane,
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
struct drm_crtc *crtc = state->base.crtc;
+ struct drm_framebuffer *fb = state->base.fb;
int min_scale = DRM_PLANE_HELPER_NO_SCALING;
int max_scale = DRM_PLANE_HELPER_NO_SCALING;
- bool can_position = false;
- int ret;
+ bool can_position = false, can_scale = false;
uint32_t pixel_format = 0;
+ int crtc_x, crtc_y, hscale, vscale, ret;
+ uint32_t src_x, src_y, src_w, src_h, crtc_w, crtc_h;
+ struct drm_rect *src = &state->base.src;
+ struct drm_rect *dst = &state->base.dst;
+ struct drm_rect clip = {};
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
@@ -12972,6 +12977,7 @@ intel_check_primary_plane(struct intel_plane *plane,
crtc_state, pixel_format);
}
can_position = true;
+ can_scale = true;
}
ret = drm_atomic_helper_check_plane_state(&state->base,
@@ -12984,6 +12990,124 @@ intel_check_primary_plane(struct intel_plane *plane,
if (!state->base.fb)
return 0;
+ *src = drm_plane_state_src(&state->base);
+ *dst = drm_plane_state_dest(&state->base);
+
+ drm_rect_rotate(src, fb->width << 16, fb->height << 16,
+ state->base.rotation);
+
+ hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+ WARN_ON(hscale < 0);
+
+ vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+ WARN_ON(vscale < 0);
+
+ if (crtc_state->base.enable)
+ drm_mode_get_hv_timing(&crtc_state->base.mode,
+ &clip.x2, &clip.y2);
+
+ state->base.visible =
+ drm_rect_clip_scaled(src, dst, &clip, hscale, vscale);
+
+ crtc_x = dst->x1;
+ crtc_y = dst->y1;
+ crtc_w = drm_rect_width(dst);
+ crtc_h = drm_rect_height(dst);
+
+ if (state->base.visible) {
+ /* check again in case clipping clamped the results */
+ hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+ if (hscale < 0) {
+ DRM_DEBUG_KMS("Horizontal scaling factor out of
limits\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
+
+ return hscale;
+ }
+
+ vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+ if (vscale < 0) {
+ DRM_DEBUG_KMS("Vertical scaling factor out of
limits\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
+
+ return vscale;
+ }
+
+ /*
+* Make the source viewport size an exact
+* multiple of the scaling factors.
+*/
+ drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale -
drm_rect_width(src),
+drm_rect_height(dst) * vscale -
drm_rect_height(src));
+
+ drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
+ state->base.rotation);
+
+ /*
+* sanity check to make sure the src
+* viewport wasn't enlarged
+*/
+ WARN_ON(src->x1 < (int)state->base.src_x ||
+ src->y1 < (int)state->base.src_y ||
+ src->x2 > (int)state->base.src_x + state->base.src_w ||
+ src->y2 > (int)state->base.src_y + state->base.src_h);
+
+ src_x = src->x1 >> 16;
+ src_w = drm_rect_width(src) >> 16;
+ src_y = src->y1 >> 16;
+ src_h = drm_rect_height(src) >> 16;
+
+ if (intel_format_is_yuv(fb->format->format)) {
+ src_x &= ~1;
+ src_w &= ~1;
+
+ if (!can_scale)
+ crtc_w &= ~1;
+
+ if (crtc_w
[Intel-gfx] [PATCH v17 10/19] drm/i915: Set scaler mode for NV12
From: Chandra Konduru
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3: Rebased (me)
v4: Rebased (me)
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.
v9: Rebased (me)
v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.
v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.
v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr
v14: Added reviewed by from Juha-Pekka Heikkila
v15: Rebased the series
Tested-by: Clinton Taylor
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_atomic.c | 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..f8d97ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6640,6 +6640,8 @@ enum {
#define PS_SCALER_MODE_MASK (3 << 28)
#define PS_SCALER_MODE_DYN (0 << 28)
#define PS_SCALER_MODE_HQ (1 << 28)
+#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
#define PS_PLANE_SEL_MASK (7 << 25)
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index e9fb6920..bb8c168 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -328,8 +328,18 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
}
/* set scaler mode */
- if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
- scaler_state->scalers[*scaler_id].mode = 0;
+ if ((INTEL_GEN(dev_priv) >= 9) &&
+ plane_state && plane_state->base.fb &&
+ plane_state->base.fb->format->format ==
+ DRM_FORMAT_NV12) {
+ if (INTEL_GEN(dev_priv) == 9 &&
+ !IS_GEMINILAKE(dev_priv) &&
+ !IS_SKYLAKE(dev_priv))
+ scaler_state->scalers[*scaler_id].mode =
+ SKL_PS_SCALER_MODE_NV12;
+ else
+ scaler_state->scalers[*scaler_id].mode =
+ PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C)
{
/*
* when only 1 scaler is in use on either pipe A or B,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 03/19] drm/i915/skl+: add NV12 in skl_format_to_fourcc
From: Mahesh Kumar
Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.
v2: Added reviewed by tag from Mika Kahola
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Mika Kahola
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4c30c7c..5b694a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2662,6 +2662,8 @@ static int skl_format_to_fourcc(int format, bool
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+ case PLANE_CTL_FORMAT_NV12:
+ return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915/uc: Fully sanitize uC in uc_fini_hw
On 3/28/2018 2:05 AM, Michal Wajdeczko wrote:
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ec90c81..46c4dc4 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -433,19 +433,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
return ret;
}
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_fini_hw(struct drm_i915_private *i915)
{
- struct intel_guc *guc = &dev_priv->guc;
-
- if (!USES_GUC(dev_priv))
- return;
-
- GEM_BUG_ON(!HAS_GUC(dev_priv));
-
- if (USES_GUC_SUBMISSION(dev_priv))
- intel_guc_submission_disable(guc);
-
- guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
}
int intel_uc_suspend(struct drm_i915_private *i915)
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 5/8] drm/i915/uc: Use correct error code for GuC initialization failure
On 3/28/2018 2:05 AM, Michal Wajdeczko wrote:
Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).
Unfortunately since commit 121981fafe69 ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.
In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.
Fix that by always returning -EIO on uC hardware related failure.
v2: don't allow -EIO from uc_init
don't call uc_fini[_misc] on -EIO
mark guc fw as failed on hw init failure
prepare uc_fini_hw to run after earlier -EIO
v3: update comments (Sagar)
use sanitize functions on failure in init_hw (Michal)
and also sanitize guc/huc fw in fini_hw (Michal)
v4: rebase
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Michal Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
void intel_uc_fini_hw(struct drm_i915_private *i915)
{
+ struct intel_guc *guc = &i915->guc;
+
+ if (!intel_guc_is_loaded(guc))
+ return;
I feel above guc_is_loaded check is more applicable in uc_sanitize. So
callers won't have to bother if GuC is loaded or not.
w/ or w/o that change patch looks good though.
Reviewed-by: Sagar Arun Kamble
+
intel_uc_sanitize(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h b/drivers/gpu/drm/i915/intel_uc_fw.h
index dc33b12..77ad2aa 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -121,6 +121,11 @@ static inline void intel_uc_fw_sanitize(struct intel_uc_fw
*uc_fw)
uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
}
+static inline bool intel_uc_fw_is_loaded(struct intel_uc_fw *uc_fw)
+{
+ return uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS;
+}
+
/**
* intel_uc_fw_get_upload_size() - Get size of firmware needed to be uploaded.
* @uc_fw: uC firmware.
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5)
== Series Details == Series: series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5) URL : https://patchwork.freedesktop.org/series/40503/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 +1 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 +1 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +1 Test kms_plane_multiple: Subgroup atomic-pipe-a-tiling-x: pass -> FAIL (shard-snb) fdo#103166 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1831 dwarn:1 dfail:0 fail:7 skip:1655 time:12908s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11739s shard-snbtotal:3411 pass:1347 dwarn:1 dfail:0 fail:4 skip:2058 time:6819s Blacklisted hosts: shard-kbltotal:3495 pass:1953 dwarn:3 dfail:1 fail:9 skip:1529 time:9711s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8512/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw
Quoting Patchwork (2018-03-28 06:21:58) > == Series Details == > > Series: series starting with [v5,1/8] drm/i915: Correctly handle error path > in i915_gem_init_hw > URL : https://patchwork.freedesktop.org/series/40759/ > State : failure > > == Summary == > > Possible new issues: > > Test drm_mm: > Subgroup sanitycheck: > pass -> INCOMPLETE (shard-apl) <0>[ 395.621771] drv_self-57960 395583503us : intel_guc_submission_disable: intel_guc_submission_disable:1242 GEM_BUG_ON(dev_priv->gt.awake) > Test drv_hangman: > Subgroup error-state-basic: > pass -> INCOMPLETE (shard-apl) > Subgroup error-state-capture-blt: > pass -> INCOMPLETE (shard-apl) > Subgroup hangcheck-unterminated: > pass -> INCOMPLETE (shard-apl) > Test gem_eio: > Subgroup execbuf: > pass -> INCOMPLETE (shard-apl) > Subgroup in-flight-external: > pass -> INCOMPLETE (shard-apl) Wedged the machine (which then hit the same bug as gem_eio where we not calling reset_default_submission from a safe point). > Test gem_mocs_settings: > Subgroup mocs-reset-vebox: > pass -> INCOMPLETE (shard-apl) > Test gem_ringfill: > Subgroup basic-default-hang: > pass -> INCOMPLETE (shard-apl) > Test kms_flip: > Subgroup flip-vs-panning-vs-hang-interruptible: > pass -> INCOMPLETE (shard-apl) > Test kms_frontbuffer_tracking: > Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: > pass -> SKIP (shard-snb) > Test kms_vblank: > Subgroup pipe-a-query-idle-hang: > pass -> INCOMPLETE (shard-apl) > Subgroup pipe-a-wait-forked-busy: > pass -> SKIP (shard-snb) > Subgroup pipe-c-query-busy-hang: > pass -> INCOMPLETE (shard-apl) > Subgroup pipe-c-query-forked-hang: > pass -> INCOMPLETE (shard-apl) More <0>[ 395.621771] drv_self-57960 395583503us : intel_guc_submission_disable: intel_guc_submission_disable:1242 GEM_BUG_ON(dev_priv->gt.awake) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
On 27/03/2018 23:14, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.
However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.
References: HSDES#1405586840
v2:
- use fls instead of find_last_bit (Chris)
- use is_power_of_2() instead of counting bit set (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Move local variable into scope where they are used (Ursulin)
- use a new local variable to reduce long line of code (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/i915_reg.h| 4
drivers/gpu/drm/i915/intel_engine_cs.c | 20
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..4f2f5e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2691,6 +2691,10 @@ enum i915_power_well_id {
#define GEN10_F2_SS_DIS_SHIFT 18
#define GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT)
+#define GEN10_MIRROR_FUSE3 _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK 0x0F
+
#define GEN8_EU_DISABLE0 _MMIO(0x9134)
#define GEN8_EU_DIS0_S0_MASK0xff
#define GEN8_EU_DIS0_S1_SHIFT 24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4c78d1e..7be7a75 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -811,6 +811,26 @@ static u32 calculate_mcr(struct drm_i915_private
*dev_priv, u32 mcr)
static void wa_init_mcr(struct drm_i915_private *dev_priv)
{
u32 mcr;
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
Another style nitpick - sorry I did not notice it before - we typically
order assignments from functions arguments to locals first, then pure
locals. Also we typically try to make the declaration block start wide
and then narrow.
+
+ /* If more than one slice are enabled, L3Banks should be all enabled */
L3Banks should be all enabled, or enabled for all enabled slices? (That
comment below says "should have _matched_".
+ if (is_power_of_2(sseu->slice_mask)) {
+ /*
+* WaProgramMgsrForL3BankSpecificMmioReads:
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
This comment implies there will be some action taken depending on this
conditional relating to the MCR, but there is nothing there?
It is not clear to me what should and whether perhaps this comment
should be pulled up and merged with the one above the conditional.
+ u32 slice = fls(sseu->slice_mask);
+ u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+ u8 ss_mask = sseu->subslice_mask[slice];
Insert blank line after declarations.
Also, is it correct to only consider the subslice mask of the last slice
for this check?
+ /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+ WARN_ON(!((fuse3 & GEN10_L3BANK_MASK) &
+ ((ss_mask | ss_mask >> GEN10_L3BANK_PAIR_COUNT) & > +
GEN10_L3BANK_MASK)));
Mask in fuse3 is the disabled mask right, since BSpec calls them "L3
Bank Disable Select"?
Should you not be checking that none of the enabled slices have L3Bank
disabled, while the above looks like it can miss a partial mismatch?
Something like this:
u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf;
u8 disabled_mask = fuse3 & 0xf;
WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+ }
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(dev_priv, mcr);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
On 28/03/2018 10:39, Tvrtko Ursulin wrote:
On 27/03/2018 23:14, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.
However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.
References: HSDES#1405586840
v2:
- use fls instead of find_last_bit (Chris)
- use is_power_of_2() instead of counting bit set (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Move local variable into scope where they are used (Ursulin)
- use a new local variable to reduce long line of code (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_engine_cs.c | 20
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..4f2f5e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2691,6 +2691,10 @@ enum i915_power_well_id {
#define GEN10_F2_SS_DIS_SHIFT 18
#define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
+#define GEN10_MIRROR_FUSE3 _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK 0x0F
+
#define GEN8_EU_DISABLE0 _MMIO(0x9134)
#define GEN8_EU_DIS0_S0_MASK 0xff
#define GEN8_EU_DIS0_S1_SHIFT 24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4c78d1e..7be7a75 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -811,6 +811,26 @@ static u32 calculate_mcr(struct drm_i915_private
*dev_priv, u32 mcr)
static void wa_init_mcr(struct drm_i915_private *dev_priv)
{
u32 mcr;
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
Another style nitpick - sorry I did not notice it before - we typically
order assignments from functions arguments to locals first, then pure
locals. Also we typically try to make the declaration block start wide
and then narrow.
+
+ /* If more than one slice are enabled, L3Banks should be all
enabled */
L3Banks should be all enabled, or enabled for all enabled slices? (That
comment below says "should have _matched_".
+ if (is_power_of_2(sseu->slice_mask)) {
+ /*
+ * WaProgramMgsrForL3BankSpecificMmioReads:
+ * read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+ * enabled subslice, no need to redirect MCR packet
+ */
This comment implies there will be some action taken depending on this
conditional relating to the MCR, but there is nothing there?
It is not clear to me what should and whether perhaps this comment
should be pulled up and merged with the one above the conditional.
+ u32 slice = fls(sseu->slice_mask);
+ u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+ u8 ss_mask = sseu->subslice_mask[slice];
Insert blank line after declarations.
Also, is it correct to only consider the subslice mask of the last slice
for this check?
+ /*
+ * Production silicon should have matched L3Bank and
+ * subslice enabled
+ */
+ WARN_ON(!((fuse3 & GEN10_L3BANK_MASK) &
+ ((ss_mask | ss_mask >> GEN10_L3BANK_PAIR_COUNT) & >
+ GEN10_L3BANK_MASK)));
Mask in fuse3 is the disabled mask right, since BSpec calls them "L3
Bank Disable Select"?
Should you not be checking that none of the enabled slices have L3Bank
disabled, while the above looks like it can miss a partial mismatch?
Something like this:
u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf;
u8 disabled_mask = fuse3 & 0xf;
WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
Oops no, that's wrong, should be "(enabled_mask & ~disabled_mask) !=
enabled_mask)" I think. Which is then the same as WARN_ON(enabled_mask &
disabled_mask) - aka same bit is both enabled and disabled - so maybe I
got the meaning of "L3 Bank Disable Select" wrong.
Regards,
Tvrtko
+ }
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(dev_priv, mcr);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support (rev5)
== Series Details == Series: Add NV12 support (rev5) URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Series 39670v5 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/5/mbox/ Known issues: Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> INCOMPLETE (fi-skl-6700k2) fdo#104108 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 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:445s 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:545s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s 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:519s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:524s 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:409s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:567s 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:429s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:321s 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:466s 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:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:467s 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:666s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:543s fi-skl-6700k2total:109 pass:97 dwarn:0 dfail:0 fail:0 skip:11 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:433s 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:563s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:534s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:486s 23c67dc0cf31917b696b87dac997aca76c0d248d drm-tip: 2018y-03m-28d-06h-36m-40s UTC integration manifest b08f6d9c7d9f drm/i915: Do not truncate fb sizes for NV12 c41aecaf98e9 drm/i915: Add checks to primary plane 82b4f81e7de7 drm/i915: Display WA 827 6ce743fc4207 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg e8b4bbbcc545 drm/i915: Add NV12 support to intel_framebuffer_init 69e3b63ce060 drm/i915: Add NV12 as supported format for sprite plane 1b2b2dd856e3 drm/i915: Add NV12 as supported format for primary plane a427f1f95674 drm/i915: Upscale scaler max scale for NV12 1efae91653f4 drm/i915: Update format_is_yuv() to include NV12 a30ecd2216a8 drm/i915: Set scaler mode for NV12 81cdc82804c1 drm/i915/skl: split skl_compute_ddb function b0d3c7d8e11d drm/i915/skl+: nv12 workaround disable WM level 1-7 433a24c00f91 drm/i915/skl+: make sure higher latency level has higher wm value 598f017e3657 drm/i915/skl+: pass skl_wm_level struct to wm compute func 81731f8b4032 drm/i915/skl+: NV12 related changes for WM f689fdbc6991 drm/i915/skl+: support verification of DDB HW state for NV12 1fed4795e550 drm/i915/skl+: add NV12 in skl_format_to_fourcc 64e2247c7d51 drm/i915/skl+: refactor WM calculation for NV12 dced5edfaf45 drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8515/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add debugfs file to clear FIFO underruns.
Adding a i915_fifo_underrun_reset debugfs file will make it possible
for IGT tests to clear FIFO underrun fallout at the start of each
subtest, and make re-enable FBC so tests always have maximum exposure
to features used by IGT. FIFO underruns and FBC bugs will no longer
hide when an earlier subtests disables both.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105685
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681
---
drivers/gpu/drm/i915/i915_debugfs.c | 62
drivers/gpu/drm/i915/intel_display.c | 30 ++---
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_fbc.c | 26 +++
4 files changed, 109 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..27188de2c32b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4731,6 +4731,67 @@ 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 ssize_t
+i915_fifo_underrun_reset_write(struct file *filp,
+ const char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct drm_i915_private *dev_priv = filp->private_data;
+ struct intel_crtc *intel_crtc;
+ struct drm_device *dev = &dev_priv->drm;
+ int ret;
+ bool reset;
+
+ ret = kstrtobool_from_user(ubuf, cnt, &reset);
+ if (ret)
+ return ret;
+
+ if (!reset)
+ return cnt;
+
+ for_each_intel_crtc(dev, intel_crtc) {
+ struct drm_crtc_commit *commit;
+ struct intel_crtc_state *crtc_state;
+
+ ret =
drm_modeset_lock_single_interruptible(&intel_crtc->base.mutex);
+ if (ret)
+ return ret;
+
+ crtc_state = to_intel_crtc_state(intel_crtc->base.state);
+ commit = crtc_state->base.commit;
+ if (commit) {
+ ret =
wait_for_completion_interruptible(&commit->hw_done);
+ if (!ret)
+ ret =
wait_for_completion_interruptible(&commit->flip_done);
+ }
+
+ if (!ret && crtc_state->base.active) {
+ DRM_DEBUG_KMS("Re-arming FIFO underruns on pipe %c\n",
+ pipe_name(intel_crtc->pipe));
+
+ intel_crtc_arm_fifo_underrun(intel_crtc, crtc_state);
+ }
+
+ drm_modeset_unlock(&intel_crtc->base.mutex);
+
+ if (ret)
+ return ret;
+ }
+
+ ret = intel_fbc_reset_underrun(dev_priv);
+ if (ret)
+ return ret;
+
+ return cnt;
+}
+
+static const struct file_operations i915_fifo_underrun_reset_ops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .write = i915_fifo_underrun_reset_write,
+ .llseek = default_llseek,
+};
+
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
@@ -4798,6 +4859,7 @@ static const struct i915_debugfs_files {
{"i915_error_state", &i915_error_state_fops},
{"i915_gpu_info", &i915_gpu_info_fops},
#endif
+ {"i915_fifo_underrun_reset", &i915_fifo_underrun_reset_ops},
{"i915_next_seqno", &i915_next_seqno_fops},
{"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
{"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4c30c7c04f9c..3df0e8193b83 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12960,10 +12960,25 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_cstate);
}
+void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!IS_GEN2(dev_priv))
+ intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
true);
+
+ if (crtc_state->has_pch_encoder) {
+ enum pipe pch_transcoder =
+ intel_crtc_pch_transcoder(crtc);
+
+ intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
true);
+ }
+}
+
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_atomic_state *old_intel_state =
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2) URL : https://patchwork.freedesktop.org/series/40764/ State : failure == Summary == Possible new issues: Test kms_flip: Subgroup flip-vs-blocking-wf-vblank: pass -> FAIL (shard-hsw) Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: pass -> FAIL (shard-hsw) fdo#103060 +1 Subgroup 2x-flip-vs-absolute-wf_vblank-interruptible: pass -> FAIL (shard-hsw) fdo#100368 +1 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +2 Test kms_plane_multiple: Subgroup atomic-pipe-a-tiling-x: pass -> FAIL (shard-snb) fdo#103166 Test kms_vblank: Subgroup pipe-b-accuracy-idle: pass -> FAIL (shard-hsw) fdo#102583 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1831 dwarn:1 dfail:0 fail:7 skip:1655 time:12914s shard-hswtotal:3495 pass:1777 dwarn:1 dfail:0 fail:7 skip:1709 time:11595s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:6999s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8513/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: Add debugfs file to clear FIFO underruns.
On Wed, 28 Mar 2018, Maarten Lankhorst
wrote:
> Adding a i915_fifo_underrun_reset debugfs file will make it possible
> for IGT tests to clear FIFO underrun fallout at the start of each
> subtest, and make re-enable FBC so tests always have maximum exposure
> to features used by IGT. FIFO underruns and FBC bugs will no longer
> hide when an earlier subtests disables both.
>
> Signed-off-by: Maarten Lankhorst
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105685
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681
FWIW, ack on the idea, didn't look at the implementation.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 62
>
> drivers/gpu/drm/i915/intel_display.c | 30 ++---
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_fbc.c | 26 +++
> 4 files changed, 109 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7816cd53100a..27188de2c32b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4731,6 +4731,67 @@ 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 ssize_t
> +i915_fifo_underrun_reset_write(struct file *filp,
> +const char __user *ubuf,
> +size_t cnt, loff_t *ppos)
> +{
> + struct drm_i915_private *dev_priv = filp->private_data;
> + struct intel_crtc *intel_crtc;
> + struct drm_device *dev = &dev_priv->drm;
> + int ret;
> + bool reset;
> +
> + ret = kstrtobool_from_user(ubuf, cnt, &reset);
> + if (ret)
> + return ret;
> +
> + if (!reset)
> + return cnt;
> +
> + for_each_intel_crtc(dev, intel_crtc) {
> + struct drm_crtc_commit *commit;
> + struct intel_crtc_state *crtc_state;
> +
> + ret =
> drm_modeset_lock_single_interruptible(&intel_crtc->base.mutex);
> + if (ret)
> + return ret;
> +
> + crtc_state = to_intel_crtc_state(intel_crtc->base.state);
> + commit = crtc_state->base.commit;
> + if (commit) {
> + ret =
> wait_for_completion_interruptible(&commit->hw_done);
> + if (!ret)
> + ret =
> wait_for_completion_interruptible(&commit->flip_done);
> + }
> +
> + if (!ret && crtc_state->base.active) {
> + DRM_DEBUG_KMS("Re-arming FIFO underruns on pipe %c\n",
> + pipe_name(intel_crtc->pipe));
> +
> + intel_crtc_arm_fifo_underrun(intel_crtc, crtc_state);
> + }
> +
> + drm_modeset_unlock(&intel_crtc->base.mutex);
> +
> + if (ret)
> + return ret;
> + }
> +
> + ret = intel_fbc_reset_underrun(dev_priv);
> + if (ret)
> + return ret;
> +
> + return cnt;
> +}
> +
> +static const struct file_operations i915_fifo_underrun_reset_ops = {
> + .owner = THIS_MODULE,
> + .open = simple_open,
> + .write = i915_fifo_underrun_reset_write,
> + .llseek = default_llseek,
> +};
> +
> static const struct drm_info_list i915_debugfs_list[] = {
> {"i915_capabilities", i915_capabilities, 0},
> {"i915_gem_objects", i915_gem_object_info, 0},
> @@ -4798,6 +4859,7 @@ static const struct i915_debugfs_files {
> {"i915_error_state", &i915_error_state_fops},
> {"i915_gpu_info", &i915_gpu_info_fops},
> #endif
> + {"i915_fifo_underrun_reset", &i915_fifo_underrun_reset_ops},
> {"i915_next_seqno", &i915_next_seqno_fops},
> {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
> {"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4c30c7c04f9c..3df0e8193b83 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12960,10 +12960,25 @@ static void intel_begin_crtc_commit(struct drm_crtc
> *crtc,
> intel_cstate);
> }
>
> +void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
> + struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> + if (!IS_GEN2(dev_priv))
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
> true);
> +
> + if (crtc_state->has_pch_encoder) {
> + enum pipe pch_transcoder =
> + intel_crtc_pch_transcoder(crtc);
> +
> + intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
> true);
> + }
> +}
> +
> static void intel_finish_crtc_commit(struct drm_crtc *crtc,
>
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
On 27/03/2018 22:01, Chris Wilson wrote: Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it's breadcrumb. However, on wedging we updated our bookkeeping to indicate that the GPU had completed executing and would restart from after the breadcrumb; so the emission of the stale breadcrumb from before the reset came as a bit of a surprise. A simple fix is to when rebinding the context into the GPU, we update the ring register state in the context image to match our bookkeeping. We already have to update the RING_START and RING_TAIL, so updating RING_HEAD as well is trivial. This works because whenever we unbind the context, we keep the bookkeeping in check; and on wedging we unbind all contexts. Testcase: igt/gem_eio Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Tested-by: Tvrtko Ursulin More tags when I am done reading the code - since this is very interesting. Regards, Tvrtko --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ba7f7831f934..654634254b64 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = i915_ggtt_offset(ce->ring->vma); + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ce->state->obj->pin_global++; i915_gem_context_get(ctx); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs
On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > On Mon, Mar 26, 2018 at 06:16:22PM -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
> > >
> > > v2: Unroll loops (Ville)
> > > Avoid resetting error mask bits.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Ville Syrjälä
> > > Cc: Chris Wilson
> > > Signed-off-by: Dhinakaran Pandiyan
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/i915_irq.c | 55
> > > +++--
> > > drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > > drivers/gpu/drm/i915/intel_psr.c| 54
> > >
> > > 5 files changed, 108 insertions(+), 40 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 7816cd53100a..6fd801ef7cbb 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2690,6 +2690,39 @@ 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;
> > > +
> > > + if (val < 0 || val > 1)
> > > + return -EINVAL;
> >
> > Can't be < 0.
> >
> > > +
> > > + DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> >
> > ==1 seems pointless
> > enableddisabled() could be used perhaps.
> >
>
> Will do.
>
> >
> > > + 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);
> > > @@ -4811,7 +4844,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 c9c3b2ba6a86..c0224a86344e 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -608,6 +608,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..e5aaf805c6a8 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));
> > > -
Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
On Wed, Mar 28, 2018 at 10:29:15AM +0200, Maarten Lankhorst wrote:
> Op 22-03-18 om 23:10 schreef Radhakrishna Sripada:
> > From: Anusha Srivatsa
> >
> > Cleanup the testcases by moving the platform checks to a single function.
> >
> > The earlier version of the path is posted here [1]
> >
> > v2: Make use of the property enums to get the supported rotations
> > v3: Move hardcodings to a single function(Ville)
> >
> > [1]: https://patchwork.freedesktop.org/patch/209647/
> >
> > Cc: Radhakrishna Sripada
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Rodrigo Vivi
> > Cc: Maarten Lankhorst
> > Cc: Mika Kahola
> > Cc: Manasi Navare
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > tests/kms_rotation_crc.c | 31 ---
> > 1 file changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> > index 0cd5c6e52b57..60fb9012e14e 100644
> > --- a/tests/kms_rotation_crc.c
> > +++ b/tests/kms_rotation_crc.c
> > @@ -43,6 +43,7 @@ typedef struct {
> > uint32_t override_fmt;
> > uint64_t override_tiling;
> > int devid;
> > + int gen;
> > } data_t;
> >
> > typedef struct {
> > @@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
> > igt_assert(drmHandleEvent(fd, &evctx) == 0);
> > }
> >
> > +static void igt_check_rotation(data_t *data)
> > +{
> > + if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> > + igt_require(data->gen >= 9);
> > + else if (data->rotation & IGT_REFLECT_X)
> > + igt_require(data->gen >= 10 ||
> > + (IS_CHERRYVIEW(data->devid) && (data->rotation &
> > IGT_ROTATION_0)));
> > + else if (data->rotation & IGT_ROTATION_180)
> > + igt_require(data->gen >= 4);
> > +}
> This still won't work as intended on CHV as it only has reflection on PIPE_B,
> for X tiled fb's.
s/X tiled//
>
>
> > static void test_single_case(data_t *data, enum pipe pipe,
> > igt_output_t *output, igt_plane_t *plane,
> > enum rectangle_type rect,
> > @@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data, int
> > plane_type, bool test_bad_form
> >
> > igt_display_require_output(display);
> >
> > + igt_check_rotation(data);
> > +
> > for_each_pipe_with_valid_output(display, pipe, output) {
> > igt_plane_t *plane;
> > int i, j;
> >
> > - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> > - continue;
> > -
> > igt_output_set_pipe(output, pipe);
> >
> > plane = igt_output_get_plane_type(output, plane_type);
> > @@ -538,14 +549,13 @@ igt_main
> > };
> >
> > data_t data = {};
> > - int gen = 0;
> >
> > igt_skip_on_simulation();
> >
> > igt_fixture {
> > data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> > data.devid = intel_get_drm_devid(data.gfx_fd);
> > - gen = intel_gen(data.devid);
> > + data.gen = intel_gen(data.devid);
> >
> > kmstest_set_vt_graphics_mode();
> >
> > @@ -558,16 +568,12 @@ igt_main
> > igt_subtest_f("%s-rotation-%s",
> > plane_test_str(subtest->plane),
> > rot_test_str(subtest->rot)) {
> > - igt_require(!(subtest->rot &
> > - (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
> > - gen >= 9);
> > data.rotation = subtest->rot;
> > test_plane_rotation(&data, subtest->plane, false);
> > }
> > }
> >
> > igt_subtest_f("sprite-rotation-90-pos-100-0") {
> > - igt_require(gen >= 9);
> > data.rotation = IGT_ROTATION_90;
> > data.pos_x = 100,
> > data.pos_y = 0;
> > @@ -577,7 +583,6 @@ igt_main
> > data.pos_y = 0;
> >
> > igt_subtest_f("bad-pixel-format") {
> > - igt_require(gen >= 9);
> > data.rotation = IGT_ROTATION_90;
> > data.override_fmt = DRM_FORMAT_RGB565;
> > test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
> > @@ -585,7 +590,6 @@ igt_main
> > data.override_fmt = 0;
> >
> > igt_subtest_f("bad-tiling") {
> > - igt_require(gen >= 9);
> > data.rotation = IGT_ROTATION_90;
> > data.override_tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
> > test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
> > @@ -596,9 +600,6 @@ igt_main
> > igt_subtest_f("primary-%s-reflect-x-%s",
> > tiling_test_str(reflect_x->tiling),
> > rot_test_str(reflect_x->rot)) {
> > - igt_require(gen >= 10 ||
> > - (IS_CHERRYVIEW(data.devid) &&
> > reflect_x->rot == IGT_ROTATION_0
> > -&& refl
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add debugfs file to clear FIFO underruns.
== Series Details == Series: drm/i915: Add debugfs file to clear FIFO underruns. URL : https://patchwork.freedesktop.org/series/40800/ State : failure == Summary == Series 40800v1 drm/i915: Add debugfs file to clear FIFO underruns. https://patchwork.freedesktop.org/api/1.0/series/40800/revisions/1/mbox/ Possible new issues: Test kms_chamelium: Subgroup common-hpd-after-suspend: pass -> INCOMPLETE (fi-skl-6700k2) Known issues: Test kms_chamelium: Subgroup hdmi-hpd-fast: fail -> SKIP (fi-kbl-7500u) fdo#102672 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> INCOMPLETE (fi-elk-e7500) fdo#103989 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 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:445s 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:544s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:531s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:567s 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:226 pass:178 dwarn:1 dfail:0 fail:0 skip:46 fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:320s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s 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:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:431s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:663s 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:530s fi-skl-6700k2total:207 pass:190 dwarn:0 dfail:0 fail:0 skip:16 fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:511s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:433s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:451s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:588s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:408s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:540s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:485s 9c7d6257b34e627b47f5abd3512ed7abd0a2662b drm-tip: 2018y-03m-28d-10h-22m-49s UTC integration manifest 319e3f454199 drm/i915: Add debugfs file to clear FIFO underruns. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8516/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
Quoting Jackie Li (2018-03-23 01:59:22) > GuC Address Space and WOPCM Layout diagrams won't be generated correctly by > sphinx build if not using proper reST syntax. > > This patch uses reST literal blocks to make sure GuC Address Space and > WOPCM Layout diagrams to be generated correctly, and it also corrects some > errors in the diagram description. > > v2: > - Fixed errors in diagram description > > v3: > - Updated GuC Address Space kernel-doc based on Michal's suggestion > > v4: > - Added WOPCM layout and GuC address space docs into i915.rst (Joonas) > > Signed-off-by: Jackie Li > Cc: Michal Wajdeczko > Cc: Sagar Arun Kamble > Cc: Joonas Lahtinen Looks good. Thanks for the patch, I'll proceed to merge it. Reviewed-by: Joonas Lahtinen Regards, Joonas > --- > Documentation/gpu/i915.rst | 15 ++ > drivers/gpu/drm/i915/intel_guc.c | 56 > -- > drivers/gpu/drm/i915/intel_wopcm.c | 44 -- > 3 files changed, 67 insertions(+), 48 deletions(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 41dc881..7ecad71 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -335,6 +335,15 @@ objects, which has the goal to make space in gpu virtual > address spaces. > .. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c > :internal: > > +WOPCM > += > + > +WOPCM Layout > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c > + :doc: WOPCM Layout > + > GuC > === > > @@ -359,6 +368,12 @@ GuC Firmware Layout > .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fwif.h > :doc: GuC Firmware Layout > > +GuC Address Space > +- > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc.c > + :doc: GuC Address Space > + > Tracing > === > > diff --git a/drivers/gpu/drm/i915/intel_guc.c > b/drivers/gpu/drm/i915/intel_guc.c > index 8f93f5b..c5f64c7 100644 > --- a/drivers/gpu/drm/i915/intel_guc.c > +++ b/drivers/gpu/drm/i915/intel_guc.c > @@ -494,35 +494,37 @@ int intel_guc_resume(struct intel_guc *guc) > /** > * DOC: GuC Address Space > * > - * The layout of GuC address space is shown as below: > + * The layout of GuC address space is shown below: > * > - *+==> ++ <== GUC_GGTT_TOP > - *^|| > - *||| > - *||DRAM| > - *|| Memory | > - *||| > - * GuC || > - * Address +> ++ <== WOPCM Top > - * Space ^ | HW contexts RSVD | > - *| | |WOPCM | > - *| | +==> ++ <== GuC WOPCM Top > - *|GuC^|| > - *|GGTT ||| > - *|Pin GuC |GuC | > - *|Bias WOPCM | WOPCM| > - *| |Size || > - *| | ||| > - *v v v|| > - *+=+=+==> ++ <== GuC WOPCM Base > - * | Non-GuC WOPCM| > - * | (HuC/Reserved) | > - * ++ <== WOPCM Base > + * :: > * > - * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of > - * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The value > of > - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which > is > - * set in GUC_WOPCM_SIZE register. > + * +==> ++ <== GUC_GGTT_TOP > + * ^|| > + * ||| > + * ||DRAM| > + * || Memory | > + * ||| > + *GuC || > + * Address +> ++ <== WOPCM Top > + * Space ^ | HW contexts RSVD | > + * | | |WOPCM | > + * | | +==> ++ <== GuC WOPCM Top > + * |GuC^|| > + * |GGTT ||| > + * |Pin GuC |GuC | > + * |Bias WOPCM | WOPCM| > + * | |Size || > + * | | ||| > + * v v v|| > + * +=+=+==> ++ <== GuC WOPCM Base > + * | Non-GuC WOPCM| > + * | (HuC/Reserved) | > + * ++ <== WOPCM Base > + * > + * The lower part of GuC Address Space [0, ggtt_pi
Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Reset ring registers on rebinding contexts
Chris Wilson writes: > Tvrtko uncovered a fun issue with recovering from a wedge device. In his > tests, he wedged the driver by injecting an unrecoverable hang whilst a > batch was spinning. As we reset the gpu in the middle of the spinner, > when resumed it would continue on from the next instruction in the ring > and write it's breadcrumb. However, on wedging we updated our > bookkeeping to indicate that the GPU had completed executing and would > restart from after the breadcrumb; so the emission of the stale > breadcrumb from before the reset came as a bit of a surprise. > > A simple fix is to when rebinding the context into the GPU, we update > the ring register state in the context image to match our bookkeeping. > We already have to update the RING_START and RING_TAIL, so updating > RING_HEAD as well is trivial. This works because whenever we unbind the > context, we keep the bookkeeping in check; and on wedging we unbind all > contexts. s/wedging/unwedging. The context lost markup is on unwedge side tho it should not matter on which stage the unbind happends between wedge and unwedge so this minor change to commit message and Reviewed-by: Mika Kuoppala > > Testcase: igt/gem_eio > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_lrc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index ba7f7831f934..654634254b64 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, > ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; > ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = > i915_ggtt_offset(ce->ring->vma); > + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; > > ce->state->obj->pin_global++; > i915_gem_context_get(ctx); > -- > 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/27] drm/i915/gen11: add support for reading the timestamp frequency
On 09/01/18 23:28, Paulo Zanoni wrote:
The only thing that differs here is that the crystal clock freq now
has four possible values.
This patch gets rid of the "Unknown gen, unable to compute..." message
at boot for gen11.
Reviewed-by: Lionel Landwerlin
Still
Reviewed-by: Lionel Landwerlin
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/gpu/drm/i915/intel_device_info.c | 71 +---
2 files changed, 61 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index eb6c7dcd4db0..fde88cd91ef1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1138,6 +1138,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 <<
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ 0
#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ 1
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (0x7 <<
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ 0
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ 1
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_38_4_MHZ 2
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_25_MHZ 3
#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1
#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 <<
GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
index 895c41ef4abf..168f6ba83ddd 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -395,6 +395,52 @@ static u32 read_reference_ts_freq(struct drm_i915_private
*dev_priv)
return base_freq + frac_freq;
}
+static u32 gen10_get_crystal_clock_freq(struct drm_i915_private *dev_priv,
+ u32 rpm_config_reg)
+{
+ u32 f19_2_mhz = 19200;
+ u32 f24_mhz = 24000;
+ u32 crystal_clock = (rpm_config_reg &
+GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK) >>
+ GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
+
+ switch (crystal_clock) {
+ case GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
+ return f19_2_mhz;
+ case GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ:
+ return f24_mhz;
+ default:
+ MISSING_CASE(crystal_clock);
+ return 0;
+ }
+}
+
+static u32 gen11_get_crystal_clock_freq(struct drm_i915_private *dev_priv,
+ u32 rpm_config_reg)
+{
+ u32 f19_2_mhz = 19200;
+ u32 f24_mhz = 24000;
+ u32 f25_mhz = 25000;
+ u32 f38_4_mhz = 38400;
+ u32 crystal_clock = (rpm_config_reg &
+GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK) >>
+ GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
+
+ switch (crystal_clock) {
+ case GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ:
+ return f24_mhz;
+ case GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
+ return f19_2_mhz;
+ case GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_38_4_MHZ:
+ return f38_4_mhz;
+ case GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_25_MHZ:
+ return f25_mhz;
+ default:
+ MISSING_CASE(crystal_clock);
+ return 0;
+ }
+}
+
static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv)
{
u32 f12_5_mhz = 12500;
@@ -435,10 +481,9 @@ static u32 read_timestamp_frequency(struct
drm_i915_private *dev_priv)
}
return freq;
- } else if (INTEL_GEN(dev_priv) <= 10) {
+ } else if (INTEL_GEN(dev_priv) <= 11) {
u32 ctc_reg = I915_READ(CTC_MODE);
u32 freq = 0;
- u32 rpm_config_reg = 0;
/* First figure out the reference frequency. There are 2 ways
* we can compute the frequency, either through the
@@ -448,20 +493,14 @@ static u32 read_timestamp_frequency(struct
drm_i915_private *dev_priv)
if ((ctc_reg & CTC_SOURCE_PARAMETER_MASK) ==
CTC_SOURCE_DIVIDE_LOGIC) {
freq = read_reference_ts_freq(dev_priv);
} else {
- u32 crystal_clock;
-
- rpm_config_reg = I915_READ(RPM_CONFIG0);
- crystal_clock = (rpm_config_reg &
-GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK)
>>
- GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
- switch (crystal_clock) {
- case GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
- freq = f19_2_mhz;
-
Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
On 28/03/18 00:39, Paulo Zanoni wrote:
Em Ter, 2018-03-27 às 15:42 -0700, Paulo Zanoni escreveu:
Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu:
Hi Mika,
Even after this series, we're still missing support for reading
the
timestamp frequency (read_timestamp_frequency in
intel_device_info.c).
I'm pretty sure someone wrote a patch for it. Do you any idea?
If not, I can send something.
Yes, we have them. I'll see if I missed them while upstreaming and
resend in that case.
https://patchwork.freedesktop.org/patch/196710/
Hey Lionel, the Reviewed-by stamp you gave on the patch was before we
upstreamed it, so we need you (or someone else) to re-check the patch
and re-issue the reviewed-by tag. We do this because of the rebasing
that happened between the R-B tag and the upstreaming, since issues can
be introduced in between. If you can check the patch again and validate
the r-b tag (or point the issues) then we can move forward and
hopefully merge it.
Thanks,
Paulo
Thanks, just sent another Rb, please push it :)
Thanks,
-
Lionel
On 16/03/18 12:14, Mika Kuoppala wrote:
From: Oscar Mateo
In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD)
and the
Video Enhancement engines (aka VEBOX, aka VECS) could be fused
off.
Also,
each VDBOX and VEBOX has its own power well, which only exist if
the related
engine exists in the HW.
Unfortunately, we have a Catch-22 situation going on: we need the
blitter
forcewake to read the register with the fuse info, but we cannot
initialize
the forcewake domains without knowin about the engines present in
the HW.
We workaround this problem by allowing the initialization of all
forcewake
domains and then pruning the fused off ones, as per the fuse
information.
Bspec: 20680
v2: We were shifting incorrectly for vebox disable (Vinay)
v3: Assert mmio is ready and warn if we have attempted to
initialize
forcewake for fused-off engines (Paulo)
v4:
- Use INTEL_GEN in new code (Tvrtko)
- Shorter local variable (Tvrtko, Michal)
- Keep "if (!...) continue" style (Tvrtko)
- No unnecessary BUG_ON (Tvrtko)
- WARN_ON and cleanup if wrong mask (Tvrtko, Michal)
- Use I915_READ_FW (Michal)
- Use I915_MAX_VCS/VECS macros (Michal)
v5: Rebased by Rodrigo fixing conflicts on top of:
commit 33def1ff7b0 ("drm/i915: Simplify intel_engines_init")
v6: Fix v5. Remove info->num_rings. (by Oscar)
v7: Rebase (Rodrigo).
v8:
-
s/intel_device_info_fused_off_engines/intel_device_info_init_mmio
(Chris)
- Make vdbox_disable & vebox_disable local variables (Chris)
v9:
- Move function declaration to intel_device_info.h (Michal)
- Missing indent in bit fields definitions (Michal)
- When RC6 is enabled by BIOS, the fuse register cannot be
read
until
the blitter powerwell is awake. Shuffle where the fuse is
read, prune
the forcewake domains after the fact and change the commit
message
accordingly (Vinay, Sagar, Chris).
v10:
- Improved commit message (Sagar)
- New line in header file (Sagar)
- Specify the message in fw_domain_reset applies to ICL+
(Sagar)
Cc: Paulo Zanoni
Cc: Vinay Belgaumkar
Cc: Tvrtko Ursulin
Cc: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Signed-off-by: Rodrigo Vivi
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++
drivers/gpu/drm/i915/i915_reg.h | 5 +++
drivers/gpu/drm/i915/intel_device_info.c | 47
+++
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
drivers/gpu/drm/i915/intel_uncore.c | 56
drivers/gpu/drm/i915/intel_uncore.h | 1 +
6 files changed, 115 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 3df5193487f3..83df8e21cec0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1033,6 +1033,10 @@ static int i915_driver_init_mmio(struct
drm_i915_private *dev_priv)
intel_uncore_init(dev_priv);
+ intel_device_info_init_mmio(dev_priv);
+
+ intel_uncore_prune(dev_priv);
+
intel_uc_init_mmio(dev_priv);
ret = intel_engines_init_mmio(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index cf7c837d6a09..982e72e73e99 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2545,6 +2545,11 @@ enum i915_power_well_id {
#define GEN10_EU_DISABLE3_MMIO(0x9140)
#define GEN10_EU_DIS_SS_MASK 0xff
+#define GEN11_GT_VEBOX_VDBOX_DISABLE _MMIO(0x9140)
+#define GEN11_GT_VDBOX_DISABLE_MASK 0xff
+#define GEN11_GT_VEBOX_DISABLE_SHIFT 16
+#define GEN11_GT_VEBOX_DISABLE_MASK (0xff <<
GEN11_GT_VEBOX_DISABLE_SHIFT)
+
#define GEN6_BSD_SLEEP_PSMI_CONTROL _MMIO(0x12050)
#define GEN6_BSD_SLEEP_MSG_DISABLE (1 << 0)
#define GEN6_BSD_SLEEP_FLUSH_DISABLE (1 << 2)
diff --gi
Re: [Intel-gfx] [PATCH v4] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
Quoting Joonas Lahtinen (2018-03-28 14:27:19) > Quoting Jackie Li (2018-03-23 01:59:22) > > GuC Address Space and WOPCM Layout diagrams won't be generated correctly by > > sphinx build if not using proper reST syntax. > > > > This patch uses reST literal blocks to make sure GuC Address Space and > > WOPCM Layout diagrams to be generated correctly, and it also corrects some > > errors in the diagram description. > > > > v2: > > - Fixed errors in diagram description > > > > v3: > > - Updated GuC Address Space kernel-doc based on Michal's suggestion > > > > v4: > > - Added WOPCM layout and GuC address space docs into i915.rst (Joonas) > > > > Signed-off-by: Jackie Li > > Cc: Michal Wajdeczko > > Cc: Sagar Arun Kamble > > Cc: Joonas Lahtinen > > Looks good. Thanks for the patch, I'll proceed to merge it. For future reference, please use a single canonical name in patches (especially the Signed-off-by: field as it is the most important one: https://www.kernel.org/doc/html/v4.13/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin ). It'll also help when looking at the statistics, too. In this case our S-o-b checking tool complained that the patch author has not signed off their work (due to the difference in writing). Regards, Joonas > > Reviewed-by: Joonas Lahtinen > > Regards, Joonas > > > --- > > Documentation/gpu/i915.rst | 15 ++ > > drivers/gpu/drm/i915/intel_guc.c | 56 > > -- > > drivers/gpu/drm/i915/intel_wopcm.c | 44 -- > > 3 files changed, 67 insertions(+), 48 deletions(-) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 41dc881..7ecad71 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -335,6 +335,15 @@ objects, which has the goal to make space in gpu > > virtual address spaces. > > .. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c > > :internal: > > > > +WOPCM > > += > > + > > +WOPCM Layout > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c > > + :doc: WOPCM Layout > > + > > GuC > > === > > > > @@ -359,6 +368,12 @@ GuC Firmware Layout > > .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fwif.h > > :doc: GuC Firmware Layout > > > > +GuC Address Space > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc.c > > + :doc: GuC Address Space > > + > > Tracing > > === > > > > diff --git a/drivers/gpu/drm/i915/intel_guc.c > > b/drivers/gpu/drm/i915/intel_guc.c > > index 8f93f5b..c5f64c7 100644 > > --- a/drivers/gpu/drm/i915/intel_guc.c > > +++ b/drivers/gpu/drm/i915/intel_guc.c > > @@ -494,35 +494,37 @@ int intel_guc_resume(struct intel_guc *guc) > > /** > > * DOC: GuC Address Space > > * > > - * The layout of GuC address space is shown as below: > > + * The layout of GuC address space is shown below: > > * > > - *+==> ++ <== GUC_GGTT_TOP > > - *^|| > > - *||| > > - *||DRAM| > > - *|| Memory | > > - *||| > > - * GuC || > > - * Address +> ++ <== WOPCM Top > > - * Space ^ | HW contexts RSVD | > > - *| | |WOPCM | > > - *| | +==> ++ <== GuC WOPCM Top > > - *|GuC^|| > > - *|GGTT ||| > > - *|Pin GuC |GuC | > > - *|Bias WOPCM | WOPCM| > > - *| |Size || > > - *| | ||| > > - *v v v|| > > - *+=+=+==> ++ <== GuC WOPCM Base > > - * | Non-GuC WOPCM| > > - * | (HuC/Reserved) | > > - * ++ <== WOPCM Base > > + * :: > > * > > - * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists > > of > > - * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The > > value of > > - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size > > which is > > - * set in GUC_WOPCM_SIZE register. > > + * +==> ++ <== GUC_GGTT_TOP > > + * ^|| > > + * ||| > > + * ||DRAM| > > + * || Memory | > > + * ||| > > + *GuC || > > + * Address +> ++ <== WOPCM Top > > + * Space ^ | HW contexts RSV
[Intel-gfx] [PATCH] 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 | 397 +
3 files changed, 402 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 6cf396d0c70f..d848d297728b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2665,3 +2665,7 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
}
}
}
+
+#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 ..6ae5a44b2b45
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -0,0 +1,397 @@
+/*
+ * 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 *seqno;
+ u32 *batch;
+};
+
+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 u64 hws_address(const struct i915_vma *hws,
+ const struct i915_request *rq)
+{
+ return hws->node.start + offset_in_page(sizeof(u32)*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_reference(hws->obj);
+ }
+
+ batch = spin->batch;
+
+ *batch++ = MI_STORE_DWORD_I
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler
Quoting Michał Winiarski (2018-03-23 14:34:04) > We're seeing "RPM wakelock ref not held during HW access" warning > otherwise. And since IRQ are synced for runtime suspend, we can use the > variant without wakeref assert. > > Reported-by: Marta Löfstedt > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710 > Signed-off-by: Michał Winiarski > Cc: Chris Wilson > Cc: Marta Löfstedt > Cc: Michal Wajdeczko Reviewed-by: Joonas Lahtinen Regards, Joonas ___ 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: Add basic sanitychecks for execlists
== Series Details == Series: drm/i915/selftests: Add basic sanitychecks for execlists URL : https://patchwork.freedesktop.org/series/40805/ State : warning == Summary == $ dim checkpatch origin/drm-tip 90e2fd06c407 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, 409 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Use srcu to protect drm_device.unplugged
== Series Details == Series: drm: Use srcu to protect drm_device.unplugged URL : https://patchwork.freedesktop.org/series/40793/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 +2 Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 +1 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-b-planes: pass -> FAIL (shard-apl) fdo#103375 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-apltotal:3495 pass:1830 dwarn:1 dfail:0 fail:8 skip:1655 time:12974s shard-hswtotal:3495 pass:1780 dwarn:1 dfail:0 fail:4 skip:1709 time:11632s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:7102s Blacklisted hosts: shard-kbltotal:3495 pass:1956 dwarn:1 dfail:1 fail:9 skip:1528 time:9683s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8514/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 drm/i915/selftests: Add basic sanitychecks for execlists
== Series Details == Series: drm/i915/selftests: Add basic sanitychecks for execlists URL : https://patchwork.freedesktop.org/series/40805/ State : success == Summary == Series 40805v1 drm/i915/selftests: Add basic sanitychecks for execlists https://patchwork.freedesktop.org/api/1.0/series/40805/revisions/1/mbox/ Known issues: 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-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-ilk-650) fdo#104008 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 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:426s 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:381s 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:295s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 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: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:258 dwarn:0 dfail:0 fail:1 skip:26 time:542s 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:585s 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:319s 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:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:437s 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:466s 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:664s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:539s 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:498s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:427s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:455s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:591s 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:524s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:489s 5e344e06e59a0a76da1aea2d8a011f037cf0caba drm-tip: 2018y-03m-28d-12h-15m-33s UTC integration manifest 90e2fd06c407 drm/i915/selftests: Add basic sanitychecks for execlists == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8517/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Delay updating ring register state after resume
Chris Wilson writes:
> Now that we reload both RING_HEAD and RING_TAIL when rebinding the
> context, we do not need to scrub those registers immediately on resume.
>
> v2: Handle the perma-pinned contexts.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 31 ---
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 654634254b64..2bf5128efb26 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2536,13 +2536,14 @@ static int execlists_context_deferred_alloc(struct
> i915_gem_context *ctx,
> return ret;
> }
>
> -void intel_lr_context_resume(struct drm_i915_private *dev_priv)
> +void intel_lr_context_resume(struct drm_i915_private *i915)
> {
> struct intel_engine_cs *engine;
> struct i915_gem_context *ctx;
> enum intel_engine_id id;
>
> - /* Because we emit WA_TAIL_DWORDS there may be a disparity
> + /*
> + * Because we emit WA_TAIL_DWORDS there may be a disparity
>* between our bookkeeping in ce->ring->head and ce->ring->tail and
>* that stored in context. As we only write new commands from
>* ce->ring->tail onwards, everything before that is junk. If the GPU
> @@ -2552,27 +2553,19 @@ void intel_lr_context_resume(struct drm_i915_private
> *dev_priv)
>* So to avoid that we reset the context images upon resume. For
>* simplicity, we just zero everything out.
>*/
> - list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
> - for_each_engine(engine, dev_priv, id) {
> - struct intel_context *ce = &ctx->engine[engine->id];
> - u32 *reg;
> -
> - if (!ce->state)
> - continue;
> + list_for_each_entry(ctx, &i915->contexts.list, link) {
> + for_each_engine(engine, i915, id) {
> + struct intel_context *ce = &ctx->engine[id];
>
> - reg = i915_gem_object_pin_map(ce->state->obj,
> - I915_MAP_WB);
> - if (WARN_ON(IS_ERR(reg)))
> + if (!ce->ring)
> continue;
>
> - reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
> - reg[CTX_RING_HEAD+1] = 0;
> - reg[CTX_RING_TAIL+1] = 0;
> -
> - ce->state->obj->mm.dirty = true;
> - i915_gem_object_unpin_map(ce->state->obj);
> -
> intel_ring_reset(ce->ring, 0);
> +
> + if (ce->pin_count) { /* otherwise done in context_pin */
From my understanding this is for kernel context only. So the comment
should mention the kernel context.
Reviewed-by: Mika Kuoppala
> + ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
> + ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
> + }
> }
> }
> }
> --
> 2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler
Quoting Daniele Ceraolo Spurio (2018-03-23 19:17:49) > > > On 23/03/18 05:34, Michał Winiarski wrote: > > We're seeing "RPM wakelock ref not held during HW access" warning > > otherwise. And since IRQ are synced for runtime suspend, we can use the > > variant without wakeref assert. > > > > Reported-by: Marta Löfstedt > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710 > > Signed-off-by: Michał Winiarski > > Cc: Chris Wilson > > Cc: Marta Löfstedt > > Cc: Michal Wajdeczko > > --- > > drivers/gpu/drm/i915/intel_guc.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_guc.c > > b/drivers/gpu/drm/i915/intel_guc.c > > index 8f93f5bef8fd..6787a3116783 100644 > > --- a/drivers/gpu/drm/i915/intel_guc.c > > +++ b/drivers/gpu/drm/i915/intel_guc.c > > @@ -391,9 +391,9 @@ void intel_guc_to_host_event_handler(struct intel_guc > > *guc) > >* clears out the bit on handling the 1st interrupt. > >*/ > > spin_lock(&guc->irq_lock); > > - val = I915_READ(SOFT_SCRATCH(15)); > > + val = I915_READ_FW(SOFT_SCRATCH(15)); > > GuC registers are in forcewake range, so don't we need to manually grab > forcewake if we use the _FW variant of the read/write macros? Hmm, with the Bugzilla tag and all, wasn't this patch tested specifically to fix the bug? Regards, Joonas PS. If there's a bugfix, it should really be a separate patch that can be immediately merged and the bug should get fixed by the patch with Bugzilla: is merged. > > Daniele > > > msg = val & guc->msg_enabled_mask; > > - I915_WRITE(SOFT_SCRATCH(15), val & ~msg); > > + I915_WRITE_FW(SOFT_SCRATCH(15), val & ~msg); > > spin_unlock(&guc->irq_lock); > > > > if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER | > > > ___ > 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] drm: Use srcu to protect drm_device.unplugged
On Wed, Mar 28, 2018 at 10:38:35AM +0300, Oleksandr Andrushchenko wrote:
> From: Noralf Trønnes
>
> Use srcu to protect drm_device.unplugged in a race free manner.
> Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
> sections preventing access to device resources that are not available
> after the device is gone.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Noralf Trønnes
> Signed-off-by: Oleksandr Andrushchenko
> Reviewed-by: Oleksandr Andrushchenko
> Tested-by: Oleksandr Andrushchenko
> Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Oleksandr, please push to drm-misc-next once you have dim tools setup up
and everything.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 54
> ++-
> include/drm/drm_device.h | 9 +++-
> include/drm/drm_drv.h | 15 +
> 3 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a1b9338736e3..32a83b41ab61 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
>
> static struct dentry *drm_debugfs_root;
>
> +DEFINE_STATIC_SRCU(drm_unplug_srcu);
> +
> /*
> * DRM Minors
> * A DRM device can provide several char-dev interfaces on the DRM-Major.
> Each
> @@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_put_dev);
>
> -static void drm_device_set_unplugged(struct drm_device *dev)
> +/**
> + * drm_dev_enter - Enter device critical section
> + * @dev: DRM device
> + * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
> + *
> + * This function marks and protects the beginning of a section that should
> not
> + * be entered after the device has been unplugged. The section end is marked
> + * with drm_dev_exit(). Calls to this function can be nested.
> + *
> + * Returns:
> + * True if it is OK to enter the section, false otherwise.
> + */
> +bool drm_dev_enter(struct drm_device *dev, int *idx)
> +{
> + *idx = srcu_read_lock(&drm_unplug_srcu);
> +
> + if (dev->unplugged) {
> + srcu_read_unlock(&drm_unplug_srcu, *idx);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dev_enter);
> +
> +/**
> + * drm_dev_exit - Exit device critical section
> + * @idx: index returned from drm_dev_enter()
> + *
> + * This function marks the end of a section that should not be entered after
> + * the device has been unplugged.
> + */
> +void drm_dev_exit(int idx)
> {
> - smp_wmb();
> - atomic_set(&dev->unplugged, 1);
> + srcu_read_unlock(&drm_unplug_srcu, idx);
> }
> +EXPORT_SYMBOL(drm_dev_exit);
>
> /**
> * drm_dev_unplug - unplug a DRM device
> * @dev: DRM device
> *
> * This unplugs a hotpluggable DRM device, which makes it inaccessible to
> - * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
> + * userspace operations. Entry-points can use drm_dev_enter() and
> + * drm_dev_exit() to protect device resources in a race free manner. This
> * essentially unregisters the device like drm_dev_unregister(), but can be
> * called while there are still open users of @dev.
> */
> @@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
> drm_dev_unregister(dev);
>
> mutex_lock(&drm_global_mutex);
> - drm_device_set_unplugged(dev);
> if (dev->open_count == 0)
> drm_dev_put(dev);
> mutex_unlock(&drm_global_mutex);
> +
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(&drm_unplug_srcu);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 7c4fa32f3fc6..3a0eac2885b7 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -46,7 +46,14 @@ struct drm_device {
> /* currently active master for this device. Protected by master_mutex */
> struct drm_master *master;
>
> - atomic_t unplugged; /**< Flag whether dev is dead */
> + /**
> + * @unplugged:
> + *
> + * Flag to tell if the device has been unplugged.
> + * See drm_dev_enter() and drm_dev_is_unplugged().
> + */
> + bool unplugged;
> +
> struct inode *anon_inode; /**< inode for private
> address-space */
> char *unique; /**< unique name of the device
> */
> /*@} */
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d23dcdd1bd95..7e545f5f94d3 100644
> -
[Intel-gfx] ✓ Fi.CI.IGT: success for Add NV12 support (rev5)
== Series Details == Series: Add NV12 support (rev5) URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 Subgroup 2x-plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 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 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1832 dwarn:1 dfail:0 fail:7 skip:1655 time:12934s shard-hswtotal:3495 pass:1781 dwarn:1 dfail:0 fail:3 skip:1709 time:11627s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:7011s Blacklisted hosts: shard-kbltotal:3361 pass:1861 dwarn:20 dfail:1 fail:9 skip:1468 time:9263s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8515/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 8/8] HAX: Enable GuC for CI
On 3/28/2018 2:05 AM, Michal Wajdeczko wrote: v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index fec5514..bbb2c36 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *i915) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; This is not needed now that GuC logging is fixed. return enable_guc; } -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 3/27/2018 4:13 PM, Chris Wilson wrote:
Quoting Zhang, Yunwei (2018-03-27 23:49:27)
On 3/27/2018 3:27 PM, Chris Wilson wrote:
Quoting Yunwei Zhang (2018-03-27 23:14:16)
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 39
--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(dev_priv, mcr);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.
So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris
Hi Chris,
The comment mentioned 0xFDC needs to be reset to 0 was before this WA
was introduced, in later HW, this WA requires 0xFDC to be programmed to
a enabled slice/subslice.
What this patch does it to initialize 0xFDC once at the initialization
(also it will be called after engine reset/TDR/coming out of c6) and
make sure every time it is changed, it will be reprogrammed to a enabled
slice/subslice so that a MMIO
read will get the correct value. read_subslice_reg changes the 0xFDC
value and if it is set to 0, it will cause MMIO read to return invalid
value for s/ss specific registers.
What mmio read? The only accessor should be this function.
And still the two comments are in direct conflict with each other.
-Chris
This function is only used in INST_DONE case which you need to iterate
through each slice/subslice to check and makes sense to program MCR for
each s/ss combination. But there could be inadvertent read into this
range without using this function, the value would be wrong without this
WA.
Anyway, the comment is not right given the latest WA required, I will
submit a new patc
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Quoting Zhang, Yunwei (2018-03-28 16:54:26)
>
>
> On 3/27/2018 4:13 PM, Chris Wilson wrote:
> > Quoting Zhang, Yunwei (2018-03-27 23:49:27)
> >>
> >> On 3/27/2018 3:27 PM, Chris Wilson wrote:
> >>> Quoting Yunwei Zhang (2018-03-27 23:14:16)
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any
> MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
>
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all
> cases
> across slice/subslice. There are rare occasions such as INSTDONE that
> this
> value will be dependent on slice/subslice combo, in such cases, we need
> to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg.
>
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
>
> References: HSD#1405586840, BSID#0575
>
> v2:
> - use fls() instead of find_last_bit() (Chris)
> - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
> - rebase on latest tip
> v5:
> - Added references (Mika)
> - Change the ordered of passing arguments and etc. (Ursulin)
>
> Cc: Oscar Mateo
> Cc: Michel Thierry
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Signed-off-by: Yunwei Zhang
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 39
> --
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..4c78d1e 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct
> drm_i915_private *i915, int type)
> }
> }
>
> +static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
> +{
> + const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
> + u32 slice = fls(sseu->slice_mask);
> + u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> + return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> + u32 mcr;
> +
> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> + mcr = calculate_mcr(dev_priv, mcr);
> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
> static inline uint32_t
> read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private
> *dev_priv, int slice,
> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>
> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
> /*
> * The HW expects the slice and sublice selectors to be reset
> to 0
> * after reading out the registers.
> */
> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> + WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
> +(mcr & mcr_slice_subslice_mask));
> mcr &= ~mcr_slice_subslice_mask;
> mcr |= mcr_slice_subslice_select;
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> ret = I915_READ_FW(reg);
>
> - mcr &= ~mcr_slice_subslice_mask;
> + /*
> +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> +* expects mcr to be programed to a enabled slice/subslice pair
> +* before any MMIO read into slice/subslice register
> +*/
> >>> So the read was above, where we did set the subslice_select
> >>> appropriately. Here we are resetting back to 0 *after* the read, as the
> >>> comment before indicates.
> >>>
> >>> So what are you trying to accomplish with this patch? Other than leaving
> >>> the code in conflict with itself.
> >>> -Chris
> >> Hi Chris,
> >>
> >> The comment mentioned 0xFDC needs to be reset to 0 was before this WA
> >> was introduced, in later HW, this WA requires 0xFDC to be programmed to
> >> a enabled slice/subslice.
> >>
> >> What this patch does it to initialize 0xFDC once at the initialization
> >> (also i
Re: [Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT
On 3/27/2018 3:49 PM, Michel Thierry wrote:
On 3/27/2018 2:41 PM, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
v2: filter disabled messages (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry #1
^ still applies for v2, but I would wait for Daniele's blessing
Acked-by: Daniele Ceraolo Spurio
A minor comment below.
Daniele
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct
*ct, const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
if we end up here from the goto with len == 0 this print will probably
not output a fully clear message (error with a correct action number and
no data). Not a blocker because we can still infer it was a length issue.
break;
___
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 v1] drm/i915/gen11: Preempt-to-idle support in execlists.
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.
+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_context() resolves a lot of conflicts with other work.
My arguments for separate function are:
- better code readability
- keeping the symmetry between execlist and GuC f
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 3/28/2018 9:03 AM, Chris Wilson wrote:
Quoting Zhang, Yunwei (2018-03-28 16:54:26)
On 3/27/2018 4:13 PM, Chris Wilson wrote:
Quoting Zhang, Yunwei (2018-03-27 23:49:27)
On 3/27/2018 3:27 PM, Chris Wilson wrote:
Quoting Yunwei Zhang (2018-03-27 23:14:16)
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 39
--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(dev_priv, mcr);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.
So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris
Hi Chris,
The comment mentioned 0xFDC needs to be reset to 0 was before this WA
was introduced, in later HW, this WA requires 0xFDC to be programmed to
a enabled slice/subslice.
What this patch does it to initialize 0xFDC once at the initialization
(also it will be called after engine reset/TDR/coming out of c6) and
make sure every time it is changed, it will be reprogrammed to a enabled
slice/subslice so that a MMIO
read will get the correct value. read_subslice_reg changes the 0xFDC
value and if it is set to 0, it will cause MMIO read to return invalid
value for s/ss specific registers.
What mmio read? The only accessor should be this function.
And still the two comments are in direct conflict with each other.
-Chris
This function is only used in INST_DONE case which you need to iterate
through each slice/subslice to check and makes sense to program MCR for
each s/ss combination. But there could be inadvertent read into this
range without using this function, the value would be wro
Re: [Intel-gfx] [PATCH] drm/i915: Add debugfs file to clear FIFO underruns.
Op 28-03-18 om 12:21 schreef Jani Nikula: > On Wed, 28 Mar 2018, Maarten Lankhorst > wrote: >> Adding a i915_fifo_underrun_reset debugfs file will make it possible >> for IGT tests to clear FIFO underrun fallout at the start of each >> subtest, and make re-enable FBC so tests always have maximum exposure >> to features used by IGT. FIFO underruns and FBC bugs will no longer >> hide when an earlier subtests disables both. >> >> Signed-off-by: Maarten Lankhorst >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105685 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681 > FWIW, ack on the idea, didn't look at the implementation. Well I had a NV12 test that produced FIFO underruns, did some quick testing against the i915_fifo_underrun_reset file and manually writing it does reset FIFO underruns. Immediately after i915_fbc_status still reads "FBC disabled: underrun detected", but this is cleared by the next atomic commit. So I think it works, and can be used for igt in the way I wrote it. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
On Fri, Mar 23, 2018 at 05:28:03PM +0100, Noralf Trønnes wrote:
>
> Den 23.03.2018 16.35, skrev Ville Syrjala:
> > From: Ville Syrjälä
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane mutex in fb->dirty() unless we also plumb down the acquire
> > context.
> >
> > Instead it seems simpler to split the fb->dirty() into a tinydrm
> > specific lower level hook that can be called from
> > mipi_dbi_enable_flush() and from a generic higher level
> > tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> > vfuncs table we'll just stick it into tinydrm_device directly
> > for now.
> >
> > v2: Deal with the fb->dirty() in tinydrm_display_pipe_update() as weel
> > (Noralf)
> >
> > Cc: "Noralf Trønnes"
> > Cc: David Lechner
> > Signed-off-by: Ville Syrjälä
> > Reviewed-by: Noralf Trønnes
> > ---
>
> Tested mi0823qt which covers core and mipi-dbi:
>
> Tested-by: Noralf Trønnes
Thanks. Both patches now pushed to drm-misc-next.
>
> > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30
> > ++
> > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c| 5 ++---
> > drivers/gpu/drm/tinydrm/ili9225.c | 23 ++--
> > drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
> > drivers/gpu/drm/tinydrm/mipi-dbi.c | 30
> > ++
> > drivers/gpu/drm/tinydrm/repaper.c | 28
> >
> > drivers/gpu/drm/tinydrm/st7586.c | 23 ++--
> > drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
> > include/drm/tinydrm/mipi-dbi.h | 4 +++-
> > include/drm/tinydrm/tinydrm-helpers.h | 5 +
> > include/drm/tinydrm/tinydrm.h | 4
> > 11 files changed, 78 insertions(+), 78 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > index d1c3ce9ab294..dcd390163a4a 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > @@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> > }
> > EXPORT_SYMBOL(tinydrm_merge_clips);
> >
> > +int tinydrm_fb_dirty(struct drm_framebuffer *fb,
> > +struct drm_file *file_priv,
> > +unsigned int flags, unsigned int color,
> > +struct drm_clip_rect *clips,
> > +unsigned int num_clips)
> > +{
> > + struct tinydrm_device *tdev = fb->dev->dev_private;
> > + struct drm_plane *plane = &tdev->pipe.plane;
> > + int ret = 0;
> > +
> > + drm_modeset_lock(&plane->mutex, NULL);
> > +
> > + /* fbdev can flush even when we're not interested */
> > + if (plane->state->fb == fb) {
> > + mutex_lock(&tdev->dirty_lock);
> > + ret = tdev->fb_dirty(fb, file_priv, flags,
> > +color, clips, num_clips);
> > + mutex_unlock(&tdev->dirty_lock);
> > + }
> > +
> > + drm_modeset_unlock(&plane->mutex);
> > +
> > + if (ret)
> > + dev_err_once(fb->dev->dev,
> > +"Failed to update display %d\n", ret);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(tinydrm_fb_dirty);
> > +
> > /**
> >* tinydrm_memcpy - Copy clip buffer
> >* @dst: Destination buffer
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > index 11ae950b0fc9..e68b528ae64d 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > @@ -125,9 +125,8 @@ void tinydrm_display_pipe_update(struct
> > drm_simple_display_pipe *pipe,
> > struct drm_crtc *crtc = &tdev->pipe.crtc;
> >
> > if (fb && (fb != old_state->fb)) {
> > - pipe->plane.fb = fb;
> > - if (fb->funcs->dirty)
> > - fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> > + if (tdev->fb_dirty)
> > + tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
> > }
> >
> > if (crtc->state->event) {
> > diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
> > b/drivers/gpu/drm/tinydrm/ili9225.c
> > index 089d22798c8b..0874e877b111 100644
> > --- a/drivers/gpu/drm/tinydrm/ili9225.c
> > +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> > @@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
> > bool full;
> > void *tr;
> >
> > - mutex_lock(&tdev->dirty_lock);
> > -
> > if (!mipi->enabled)
> > - goto out_unlock;
> > -
> > - /* fbdev can flush even when we're not interested */
> > - if (tdev->pipe.plane.fb != fb)
> > - goto out_unlock;
> > + return 0;
> >
> > full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
> >fb->width, fb->height);
> > @@ -108,7 +102,7 @
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
On 27/03/2018 22:01, Chris Wilson wrote: Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it's breadcrumb. However, on wedging we updated our bookkeeping to indicate that the GPU had completed executing and would restart from after the breadcrumb; so the emission of the stale breadcrumb from before the reset came as a bit of a surprise. A simple fix is to when rebinding the context into the GPU, we update the ring register state in the context image to match our bookkeeping. We already have to update the RING_START and RING_TAIL, so updating RING_HEAD as well is trivial. This works because whenever we unbind the context, we keep the bookkeeping in check; and on wedging we unbind all contexts. Testcase: igt/gem_eio Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ba7f7831f934..654634254b64 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = i915_ggtt_offset(ce->ring->vma); + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ce->state->obj->pin_global++; i915_gem_context_get(ctx); After quite some amount of walking trough the code, looking at traces and chatting on IRC: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
Quoting Tvrtko Ursulin (2018-03-28 17:26:37) > > On 27/03/2018 22:01, Chris Wilson wrote: > > Tvrtko uncovered a fun issue with recovering from a wedge device. In his > > tests, he wedged the driver by injecting an unrecoverable hang whilst a > > batch was spinning. As we reset the gpu in the middle of the spinner, > > when resumed it would continue on from the next instruction in the ring > > and write it's breadcrumb. However, on wedging we updated our > > bookkeeping to indicate that the GPU had completed executing and would > > restart from after the breadcrumb; so the emission of the stale > > breadcrumb from before the reset came as a bit of a surprise. > > > > A simple fix is to when rebinding the context into the GPU, we update > > the ring register state in the context image to match our bookkeeping. > > We already have to update the RING_START and RING_TAIL, so updating > > RING_HEAD as well is trivial. This works because whenever we unbind the > > context, we keep the bookkeeping in check; and on wedging we unbind all > > contexts. > > > > Testcase: igt/gem_eio > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index ba7f7831f934..654634254b64 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, > > ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; > > ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = > > i915_ggtt_offset(ce->ring->vma); > > + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; > > > > ce->state->obj->pin_global++; > > i915_gem_context_get(ctx); > > > > After quite some amount of walking trough the code, looking at traces > and chatting on IRC: > > Reviewed-by: Tvrtko Ursulin I feel like it is one of those that is going to be asked about in 6 months time and I'll have to admit the shameful secret. Smoke and mirrors, smoke and mirrors. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler
On Wed, Mar 28, 2018 at 04:51:55PM +0300, Joonas Lahtinen wrote: > Quoting Daniele Ceraolo Spurio (2018-03-23 19:17:49) > > > > > > On 23/03/18 05:34, Michał Winiarski wrote: > > > We're seeing "RPM wakelock ref not held during HW access" warning > > > otherwise. And since IRQ are synced for runtime suspend, we can use the > > > variant without wakeref assert. > > > > > > Reported-by: Marta Löfstedt > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710 > > > Signed-off-by: Michał Winiarski > > > Cc: Chris Wilson > > > Cc: Marta Löfstedt > > > Cc: Michal Wajdeczko > > > --- > > > drivers/gpu/drm/i915/intel_guc.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_guc.c > > > b/drivers/gpu/drm/i915/intel_guc.c > > > index 8f93f5bef8fd..6787a3116783 100644 > > > --- a/drivers/gpu/drm/i915/intel_guc.c > > > +++ b/drivers/gpu/drm/i915/intel_guc.c > > > @@ -391,9 +391,9 @@ void intel_guc_to_host_event_handler(struct intel_guc > > > *guc) > > >* clears out the bit on handling the 1st interrupt. > > >*/ > > > spin_lock(&guc->irq_lock); > > > - val = I915_READ(SOFT_SCRATCH(15)); > > > + val = I915_READ_FW(SOFT_SCRATCH(15)); > > > > GuC registers are in forcewake range, so don't we need to manually grab > > forcewake if we use the _FW variant of the read/write macros? > > Hmm, with the Bugzilla tag and all, wasn't this patch tested > specifically to fix the bug? > > Regards, Joonas > > PS. If there's a bugfix, it should really be a separate patch that can > be immediately merged and the bug should get fixed by the patch with > Bugzilla: is merged. Daniele is correct - we do need the forcewake. The WARN is caused by the fact that we're not doing pm_get (and we don't need to do it). The correct fix would be to do the disable/enable_rpm_wakeref_asserts dance, however Chris suggested that since the forcewake takes time, maybe we could move the logic to tasklet. And... why not? I'll follow your advice and post it as a separate patch. -Michał > > > > > Daniele > > > > > msg = val & guc->msg_enabled_mask; > > > - I915_WRITE(SOFT_SCRATCH(15), val & ~msg); > > > + I915_WRITE_FW(SOFT_SCRATCH(15), val & ~msg); > > > spin_unlock(&guc->irq_lock); > > > > > > if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER | > > > > > ___ > > 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 i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
The rework looks good to me.
Thanks Mika for testing this.
>-Original Message-
>From: Kahola, Mika
>Sent: Wednesday, March 28, 2018 1:26 AM
>To: Sripada, Radhakrishna ; igt-
>d...@lists.freedesktop.org
>Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
>; Ville Syrjälä ;
>Vetter,
>Daniel ; Vivi, Rodrigo ;
>Maarten Lankhorst ; Navare, Manasi D
>
>Subject: Re: [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to
>one place for non exhaust fence cases
>
>On Thu, 2018-03-22 at 15:10 -0700, Radhakrishna Sripada wrote:
>> From: Anusha Srivatsa
>>
>> Cleanup the testcases by moving the platform checks to a single
>> function.
>>
>> The earlier version of the path is posted here [1]
>>
>> v2: Make use of the property enums to get the supported rotations
>> v3: Move hardcodings to a single function(Ville)
>>
>> [1]: https://patchwork.freedesktop.org/patch/209647/
>>
>> Cc: Radhakrishna Sripada
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Rodrigo Vivi
>> Cc: Maarten Lankhorst
>> Cc: Mika Kahola
>> Cc: Manasi Navare
>
>Tested-by: Mika Kahola
Reviewed-by: Anusha Srivatsa
>> Signed-off-by: Anusha Srivatsa
>> Signed-off-by: Radhakrishna Sripada
>> ---
>> tests/kms_rotation_crc.c | 31 ---
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index
>> 0cd5c6e52b57..60fb9012e14e 100644
>> --- a/tests/kms_rotation_crc.c
>> +++ b/tests/kms_rotation_crc.c
>> @@ -43,6 +43,7 @@ typedef struct {
>> uint32_t override_fmt;
>> uint64_t override_tiling;
>> int devid;
>> +int gen;
>> } data_t;
>>
>> typedef struct {
>> @@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
>> igt_assert(drmHandleEvent(fd, &evctx) == 0);
>> }
>>
>> +static void igt_check_rotation(data_t *data) {
>> +if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
>> +igt_require(data->gen >= 9);
>> +else if (data->rotation & IGT_REFLECT_X)
>> +igt_require(data->gen >= 10 ||
>> +(IS_CHERRYVIEW(data->devid) && (data-
>> >rotation & IGT_ROTATION_0)));
>> +else if (data->rotation & IGT_ROTATION_180)
>> +igt_require(data->gen >= 4);
>> +}
>> +
>> static void test_single_case(data_t *data, enum pipe pipe,
>> igt_output_t *output, igt_plane_t *plane,
>> enum rectangle_type rect,
>> @@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data,
>> int plane_type, bool test_bad_form
>>
>> igt_display_require_output(display);
>>
>> +igt_check_rotation(data);
>> +
>> for_each_pipe_with_valid_output(display, pipe, output) {
>> igt_plane_t *plane;
>> int i, j;
>>
>> -if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
>> -continue;
>> -
>> igt_output_set_pipe(output, pipe);
>>
>> plane = igt_output_get_plane_type(output, plane_type); @@ -
>538,14
>> +549,13 @@ igt_main
>> };
>>
>> data_t data = {};
>> -int gen = 0;
>>
>> igt_skip_on_simulation();
>>
>> igt_fixture {
>> data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
>> data.devid = intel_get_drm_devid(data.gfx_fd);
>> -gen = intel_gen(data.devid);
>> +data.gen = intel_gen(data.devid);
>>
>> kmstest_set_vt_graphics_mode();
>>
>> @@ -558,16 +568,12 @@ igt_main
>> igt_subtest_f("%s-rotation-%s",
>> plane_test_str(subtest->plane),
>> rot_test_str(subtest->rot)) {
>> -igt_require(!(subtest->rot &
>> -(IGT_ROTATION_90 |
>> IGT_ROTATION_270)) ||
>> -gen >= 9);
>> data.rotation = subtest->rot;
>> test_plane_rotation(&data, subtest->plane, false);
>> }
>> }
>>
>> igt_subtest_f("sprite-rotation-90-pos-100-0") {
>> -igt_require(gen >= 9);
>> data.rotation = IGT_ROTATION_90;
>> data.pos_x = 100,
>> data.pos_y = 0;
>> @@ -577,7 +583,6 @@ igt_main
>> data.pos_y = 0;
>>
>> igt_subtest_f("bad-pixel-format") {
>> -igt_require(gen >= 9);
>> data.rotation = IGT_ROTATION_90;
>> data.override_fmt = DRM_FORMAT_RGB565;
>> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
>@@ -585,7
>> +590,6 @@ igt_main
>> data.override_fmt = 0;
>>
>> igt_subtest_f("bad-tiling") {
>> -igt_require(gen >= 9);
>> data.rotation = IGT_ROTATION_90;
>> data.override_tiling =
>> LOCAL_I915_FORMAT_MOD_X_TILED;
>> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
>@@ -596,9
>> +600,6 @@ igt_main
>> igt_subtest_f("primary-%s-reflect-x-%s",
>> tiling_te
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs
On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote:
> On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > > On Mon, Mar 26, 2018 at 06:16:22PM -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
> > > >
> > > > v2: Unroll loops (Ville)
> > > > Avoid resetting error mask bits.
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Ville Syrjälä
> > > > Cc: Chris Wilson
> > > > Signed-off-by: Dhinakaran Pandiyan
> > > > ---
> > > > drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/i915_irq.c | 55
> > > > +++--
> > > > drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > > > drivers/gpu/drm/i915/intel_psr.c| 54
> > > >
> > > > 5 files changed, 108 insertions(+), 40 deletions(-)
> > > >
> > > >
> > > > +void intel_psr_debug_control(struct drm_i915_private *dev_priv, bool
> > > > enable)
> > > > +{
> > > > + u32 mask;
> > > > +
> > > > + /* No PSR interrupts on VLV/CHV */
> > > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > + return;
> > > > +
> > > > + mask = EDP_PSR_POST_EXIT(TRANSCODER_EDP) |
> > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_EDP);
> > > > +
> > > > + if (INTEL_GEN(dev_priv) >= 8)
> > > > + mask |= EDP_PSR_POST_EXIT(TRANSCODER_A) |
> > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_A) |
> > > > + EDP_PSR_POST_EXIT(TRANSCODER_B) |
> > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_B) |
> > > > + EDP_PSR_POST_EXIT(TRANSCODER_C) |
> > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_C);
> > > > +
> > > > + if (enable) {
> > > > + WRITE_ONCE(dev_priv->psr.debug, true);
> > > > + I915_WRITE(EDP_PSR_IMR, I915_READ(EDP_PSR_IMR) & ~mask);
> > >
> > > Why RMW?
> > >
> > Avoids updating this function when new PSR error bits are added in
> > i915_irq.c
>
> The usual rule is "avoid RMW unles there is a really compelling reason
> for it". There is none in this case AFAICS.
>
> >
> > Would you prefer
> >
> > mask |= EDP_PSR_ERROR(TRANCODER_A) | ... here?
> >
> > I think this has started to look ugly already. The loop was concise IMO.
> >
> > The other option is to
> >
> > #define HSW_PSR_INTR_DBG_MASK = 0x7
> > #define BDW_PSR_INTR_DBG_MASK = 0x07070707
>
> Not sure what these have to do with the RMW.
>
They don't, that was an alternative to the series of OR's we have to do
to derive the mask.
0x07070707 is the mask of all the relevant bits (error + debug). The
above definitions could be used as
if (INTEL_GEN(dev_priv) > 8)
mask = BDW_PSR_INTR_DBG_MASK;
else
mask = HSW_PSR_INTR_DBG_MASK
if (enable)
I915_WRITE(EDP_PSR_IMR, ~mask)
Anyway, I am not sure how you want this to be written at this point. Can
you suggest in code what you like to see here?
> >
> >
> >
> > > > + } else {
> > > > + I915_WRITE(EDP_PSR_IMR, I915_READ(EDP_PSR_IMR) | mask);
> > > > + WRITE_ONCE(dev_priv->psr.debug, false);
> > > > + }
> > > > +}
> > > > +
> > > > +void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32
> > > > psr_iir)
> > > > +{
> > > > + u32 transcoders = BIT(TRANSCODER_EDP);
> > > > + enum transcoder cpu_transcoder;
> > > > +
> > > > + if (INTEL_GEN(dev_priv) >= 8)
> > > > + transcoders |= BIT(TRANSCODER_A) |
> > > > + BIT(TRANSCODER_B) |
> > > > + BIT(TRANSCODER_C);
> > > > +
> > > > + for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > > > transcoders) {
> > > > + /* FIXME: Exit PSR when this happens. */
> > >
> > > Should this maybe say "retrain the link manually when this happens"?
> > >
> >
> > Yeah, we should do both in fact. Makes sense to exit PSR, link train
> > manually and keep it disabled.
>
> BTW is there a hardware mechnism to inject this failure? Would be nice
> for testing it.
>
Haven't seen anything like that in bspec.
> If there is no way, maybe we could provide garbage settings for the AUX
> stuff and that would cause the failure?
>
Probably, are you aware of a way that aux failures can be triggered in
general? We could add it as an IGT test to make sure we do get
interrupts and handle it correctly.
> >
> >
> >
> > > > + if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > > > + DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
> > > > +
[Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
From: Tvrtko Ursulin
Some messages are using %d and some %x which creates confusion while
reading the traces.
I also added:
1. Fence context/seqno to elsp traces - so it is easier to correlate
events.
2. New GEM_TRACE logging to port and request cancellation sites.
Signed-off-by: Tvrtko Ursulin
---
Crystal ball says I'll be removing everything other than the seqno format
consolidation in v2. :)
---
drivers/gpu/drm/i915/intel_lrc.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fe520c4dd999..c5e8526a2025 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -454,10 +454,12 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id =
upper_32_bits(desc));
- GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%x, prio=%d\n",
+ GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%d (fence
%llx:%d), prio=%d\n",
engine->name, n,
port[n].context_id, count,
rq->global_seqno,
+ rq->fence.context,
+ rq->fence.seqno,
rq_prio(rq));
} else {
GEM_BUG_ON(!n);
@@ -727,6 +729,10 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
while (num_ports-- && port_isset(port)) {
struct i915_request *rq = port_request(port);
+ GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
+ rq->engine->name, port - execlists->port,
+ rq->fence.context, rq->fence.seqno, rq->global_seqno);
+
GEM_BUG_ON(!execlists->active);
intel_engine_context_out(rq->engine);
@@ -802,7 +808,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s, hws global %d\n",
+ engine->name, intel_engine_get_seqno(engine));
/*
* Before we call engine->cancel_requests(), we should have exclusive
@@ -829,8 +836,12 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, &engine->timeline->requests, link) {
GEM_BUG_ON(!rq->global_seqno);
- if (!i915_request_completed(rq))
+ if (!i915_request_completed(rq)) {
+ GEM_TRACE("%s eio %llx:%d [global %d]\n",
+ rq->engine->name, rq->fence.context,
+ rq->fence.seqno, rq->global_seqno);
dma_fence_set_error(&rq->fence, -EIO);
+ }
}
/* Flush the queued requests to the timeline list (for retiring). */
@@ -839,6 +850,10 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
struct i915_priolist *p = to_priolist(rb);
list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
+ GEM_TRACE("%s submit-eio %llx:%d [global %d]\n",
+ rq->engine->name, rq->fence.context,
+ rq->fence.seqno, rq->global_seqno);
+
INIT_LIST_HEAD(&rq->priotree.link);
dma_fence_set_error(&rq->fence, -EIO);
@@ -999,10 +1014,12 @@ static void execlists_submission_tasklet(unsigned long
data)
EXECLISTS_ACTIVE_USER));
rq = port_unpack(port, &count);
- GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x, prio=%d\n",
+ GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (fence
%llx:%d), prio=%d\n",
engine->name,
port->context_id, count,
rq ? rq->global_seqno : 0,
+ rq ? rq->fence.context : 0,
+ rq ? rq->fence.seqno : 0,
rq ? rq_prio(rq) : 0);
/* Check the context/desc id for this event matches */
@@ -1706,7 +1723,7 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
struct intel_context *ce;
unsigned long flags;
- GEM_TRACE("%s seqno=%x\n",
+ GEM_TRACE("%s seqno=%d\n",
engine->name, request ? request->global_seqno : 0);
/* See execlists_cancel_requests() for the irq/spinlock split. */
--
2.14.1
___
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
Quoting Tvrtko Ursulin (2018-03-28 18:39:59)
> From: Tvrtko Ursulin
>
> Some messages are using %d and some %x which creates confusion while
> reading the traces.
>
> I also added:
>
> 1. Fence context/seqno to elsp traces - so it is easier to correlate
> events.
>
> 2. New GEM_TRACE logging to port and request cancellation sites.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Crystal ball says I'll be removing everything other than the seqno format
> consolidation in v2. :)
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index fe520c4dd999..c5e8526a2025 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -454,10 +454,12 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> desc = execlists_update_context(rq);
> GEM_DEBUG_EXEC(port[n].context_id =
> upper_32_bits(desc));
>
> - GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%x,
> prio=%d\n",
> + GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%d (fence
> %llx:%d), prio=%d\n",
> engine->name, n,
> port[n].context_id, count,
> rq->global_seqno,
> + rq->fence.context,
> + rq->fence.seqno,
> rq_prio(rq));
> } else {
> GEM_BUG_ON(!n);
> @@ -727,6 +729,10 @@ execlists_cancel_port_requests(struct
> intel_engine_execlists * const execlists)
> while (num_ports-- && port_isset(port)) {
> struct i915_request *rq = port_request(port);
>
> + GEM_TRACE("%s:port%lu cancel %llx:%d [global %d]\n",
> + rq->engine->name, port - execlists->port,
> + rq->fence.context, rq->fence.seqno,
> rq->global_seqno);
> +
> GEM_BUG_ON(!execlists->active);
> intel_engine_context_out(rq->engine);
>
> @@ -802,7 +808,8 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> struct rb_node *rb;
> unsigned long flags;
>
> - GEM_TRACE("%s\n", engine->name);
> + GEM_TRACE("%s, hws global %d\n",
> + engine->name, intel_engine_get_seqno(engine));
I've been suggesting switching over to current=%d for hws global.
Maybe "breadcrumb=%d"? Just something that is unambiguous.
> * Before we call engine->cancel_requests(), we should have exclusive
> @@ -829,8 +836,12 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> /* Mark all executing requests as skipped. */
> list_for_each_entry(rq, &engine->timeline->requests, link) {
> GEM_BUG_ON(!rq->global_seqno);
> - if (!i915_request_completed(rq))
> + if (!i915_request_completed(rq)) {
> + GEM_TRACE("%s eio %llx:%d [global %d]\n",
> + rq->engine->name, rq->fence.context,
> + rq->fence.seqno, rq->global_seqno);
> dma_fence_set_error(&rq->fence, -EIO);
> + }
> }
I've been using global_seqno=%d elsewhere. So pick one, and we'll be
consistent! I promise this time. Well, at least until I forget in the
morning.
So "fence=%llx:%d, global_seqno=%d (current=%d)" e.g.
https://patchwork.freedesktop.org/patch/213307/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register
As intel_wait_for_register_fw() may use, and if successful only use, a busy-wait loop, the might_sleep() warning is a little over-zealous. Restrict it to a might_sleep_if() a slow timeout is specified (and so the caller authorises use of a usleep). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index f37ecfc69e49..44c4654443ba 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv, u32 reg_value; int ret; - might_sleep(); + might_sleep_if(slow_timeout_ms); spin_lock_irq(&dev_priv->uncore.lock); intel_uncore_forcewake_get__locked(dev_priv, fw); @@ -2008,7 +2008,7 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv, intel_uncore_forcewake_put__locked(dev_priv, fw); spin_unlock_irq(&dev_priv->uncore.lock); - if (ret) + if (ret && slow_timeout_ms) ret = __wait_for(reg_value = I915_READ_NOTRACE(reg), (reg_value & mask) == value, slow_timeout_ms * 1000, 10, 1000); -- 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] 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 | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 671a6d61e29d..34493042cf95 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,17 @@ 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);
+ 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 +866,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 v2] 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] ✓ Fi.CI.BAT: success for drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
== Series Details == Series: drm/i915/execlists: Consistent seqno reporting in GEM_TRACE URL : https://patchwork.freedesktop.org/series/40821/ State : success == Summary == Series 40821v1 drm/i915/execlists: Consistent seqno reporting in GEM_TRACE https://patchwork.freedesktop.org/api/1.0/series/40821/revisions/1/mbox/ Warning: Kernel 32bit buildtest failed https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8518/build_32bit.log Known issues: Test drv_module_reload: Subgroup basic-reload-inject: pass -> INCOMPLETE (fi-cnl-y3) fdo#105777 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 fdo#105777 https://bugs.freedesktop.org/show_bug.cgi?id=105777 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 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:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s 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:521s 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:504s 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:564s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:510s fi-cnl-y3total:284 pass:257 dwarn:1 dfail:0 fail:0 skip:25 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:419s 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:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:406s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:435s 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:464s 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:666s 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:540s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:506s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:426s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:577s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:396s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:519s fi-glk-j4005 failed to collect. IGT log at Patchwork_8518/fi-glk-j4005/run0.log 1a854db0e982d1d8cec519ab789bd6ca28ea drm-tip: 2018y-03m-28d-16h-19m-39s UTC integration manifest ec687c517727 drm/i915/execlists: Consistent seqno reporting in GEM_TRACE == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8518/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use
From: Tvrtko Ursulin
intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
register access. This patch rewrites it to use only PMU.
Only overall command streamer busyness and GPU global data such as power
and frequencies are included in this new version.
For access to more GPU functional unit level data, an OA metric based tool
like gpu-top should be used instead.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Lionel Landwerlin
Cc: Petri Latvala
---
tools/Makefile.am | 2 +
tools/intel_gpu_top.c | 982 +-
tools/meson.build | 6 +-
3 files changed, 413 insertions(+), 577 deletions(-)
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 09b6dbcc3ece..a0b016ddd7ff 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -28,6 +28,8 @@ intel_aubdump_la_LDFLAGS = -module -avoid-version
-no-undefined
intel_aubdump_la_SOURCES = aubdump.c
intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl
+intel_gpu_top_LDADD = $(top_builddir)/lib/libigt_perf.la
+
bin_SCRIPTS = intel_aubdump
CLEANFILES = $(bin_SCRIPTS)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 098e6ce3ff86..4eef634eb436 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1,6 +1,5 @@
/*
- * Copyright © 2007 Intel Corporation
- * Copyright © 2011 Intel Corporation
+ * Copyright © 2018 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -18,701 +17,532 @@
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- *Eric Anholt
- *Eugeni Dodonov
- *
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
*/
-#include "config.h"
-
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
#include
-#ifdef HAVE_TERMIOS_H
-#include
-#endif
-#include "intel_io.h"
-#include "instdone.h"
-#include "intel_reg.h"
-#include "intel_chipset.h"
-#include "drmtest.h"
-
-#define FORCEWAKE 0xA18C
-#define FORCEWAKE_ACK 0x130090
-
-#define SAMPLES_PER_SEC 1
-#define SAMPLES_TO_PERCENT_RATIO(SAMPLES_PER_SEC / 100)
-
-#define MAX_NUM_TOP_BITS100
-
-#define HAS_STATS_REGS(devid) IS_965(devid)
-
-struct top_bit {
- struct instdone_bit *bit;
- int count;
-} top_bits[MAX_NUM_TOP_BITS];
-struct top_bit *top_bits_sorted[MAX_NUM_TOP_BITS];
-
-static uint32_t instdone, instdone1;
-
-static const char *bars[] = {
- " ",
- "▏",
- "▎",
- "▍",
- "▌",
- "▋",
- "▊",
- "▉",
- "█"
-};
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt_perf.h"
-enum stats_counts {
- IA_VERTICES,
- IA_PRIMITIVES,
- VS_INVOCATION,
- GS_INVOCATION,
- GS_PRIMITIVES,
- CL_INVOCATION,
- CL_PRIMITIVES,
- PS_INVOCATION,
- PS_DEPTH,
- STATS_COUNT
+struct pmu_pair {
+ uint64_t cur;
+ uint64_t prev;
};
-const uint32_t stats_regs[STATS_COUNT] = {
- IA_VERTICES_COUNT_QW,
- IA_PRIMITIVES_COUNT_QW,
- VS_INVOCATION_COUNT_QW,
- GS_INVOCATION_COUNT_QW,
- GS_PRIMITIVES_COUNT_QW,
- CL_INVOCATION_COUNT_QW,
- CL_PRIMITIVES_COUNT_QW,
- PS_INVOCATION_COUNT_QW,
- PS_DEPTH_COUNT_QW,
+struct pmu_counter {
+ uint64_t config;
+ unsigned int idx;
+ struct pmu_pair val;
};
-const char *stats_reg_names[STATS_COUNT] = {
- "vert fetch",
- "prim fetch",
- "VS invocations",
- "GS invocations",
- "GS prims",
- "CL invocations",
- "CL prims",
- "PS invocations",
- "PS depth pass",
+struct engine {
+ const char *name;
+ struct pmu_counter busy;
+ struct pmu_counter wait;
+ struct pmu_counter sema;
};
-uint64_t stats[STATS_COUNT];
-uint64_t last_stats[STATS_COUNT];
+struct engines {
+ unsigned int num_engines;
+ unsigned int num_counters;
+ DIR *root;
+ int fd;
+ struct pmu_pair ts;
-static unsigned long
-gettime(void)
-{
-struct timeval t;
-gettimeofday(&t, NULL);
-return (t.tv_usec + (t.tv_sec * 100));
-}
+ int rapl_fd;
+ double rapl_scale;
-static int
-top_bits_sort(const void *a, const void *b)
+ struct pmu_counter freq_req;
+ struct pmu_counter freq_act;
+ struct pmu_counter irq;
+ struct pmu_counter rc6;
+ struct pmu_counter rapl;
Re: [Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use
Quoting Tvrtko Ursulin (2018-03-28 19:29:48) > From: Tvrtko Ursulin > > intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio > register access. This patch rewrites it to use only PMU. > > Only overall command streamer busyness and GPU global data such as power > and frequencies are included in this new version. > > For access to more GPU functional unit level data, an OA metric based tool > like gpu-top should be used instead. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: Lionel Landwerlin > Cc: Petri Latvala Looked good to me. Someone might complain about the loss of "stats" mode, but we can point them towards "perf record" now. Half-reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] intel-gpu-top: Rewrite the tool to be safe to use
On 28/03/18 19:29, Tvrtko Ursulin wrote: From: Tvrtko Ursulin intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio register access. This patch rewrites it to use only PMU. Only overall command streamer busyness and GPU global data such as power and frequencies are included in this new version. For access to more GPU functional unit level data, an OA metric based tool like gpu-top should be used instead. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Lionel Landwerlin Cc: Petri Latvala Looks good to me too. Sorry, this isn't a detailed review, but since it's a lot safer : Reviewed-by: Lionel Landwerlin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register
On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > As intel_wait_for_register_fw() may use, and if successful only use, a > busy-wait loop, the might_sleep() warning is a little over-zealous. > Restrict it to a might_sleep_if() a slow timeout is specified (and so > the caller authorises use of a usleep). > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index f37ecfc69e49..44c4654443ba 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private > *dev_priv, > u32 reg_value; > int ret; > > - might_sleep(); > + might_sleep_if(slow_timeout_ms); __wait_for() already has a might_sleep(), why is this needed? > > spin_lock_irq(&dev_priv->uncore.lock); > intel_uncore_forcewake_get__locked(dev_priv, fw); > @@ -2008,7 +2008,7 @@ int __intel_wait_for_register(struct drm_i915_private > *dev_priv, > intel_uncore_forcewake_put__locked(dev_priv, fw); > spin_unlock_irq(&dev_priv->uncore.lock); > > - if (ret) > + if (ret && slow_timeout_ms) > ret = __wait_for(reg_value = I915_READ_NOTRACE(reg), >(reg_value & mask) == value, >slow_timeout_ms * 1000, 10, 1000); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.
Hi Chris,
Chris Wilson writes:
> Quoting Francisco Jerez (2018-03-28 07:38:45)
>> This allows cpufreq governors to realize when the system becomes
>> non-CPU-bound due to GPU rendering activity, which will cause the
>> intel_pstate LP controller to behave more conservatively: CPU energy
>> usage will be reduced when there isn't a good chance for system
>> performance to scale with CPU frequency. This leaves additional TDP
>> budget available for the GPU to reach higher frequencies, which is
>> translated into an improvement in graphics performance to the extent
>> that the workload remains TDP-limited (Most non-trivial graphics
>> benchmarks out there improve significantly in TDP-constrained
>> platforms, see the cover letter for some numbers). If the workload
>> isn't (anymore) TDP-limited performance should stay roughly constant,
>> but energy usage will be divided by a similar factor.
>
> And that's what I thought IPS was already meant to be achieving;
> intelligent distribution between different units...
>
I'm not aware of IPS ever being available on any small core systems.
>> The intel_pstate LP controller is only enabled on BXT+ small-core
>> platforms at this point, so this shouldn't have any effect on other
>> systems.
>
> Although that's probably only a feature for big core :)
>
Actually I wouldn't rule out it being useful on big core up front. I've
been playing around with the idea of hooking up this same interface to
the EPP preference used by HWP, which would allow the HWP controller to
reduce energy usage in GPU-bound conditions, which could potentially
leave additional TDP headroom available for the GPU -- It's not uncommon
for graphics workloads to be TDP-limited even on big core, and while
non-TDP-limited (so neither IPS nor IBC will ever help you) that would
still allow them to optimize CPU energy usage for workloads that are
consistently GPU-bound (which would mean longer battery life while
gaming on a big-core laptop).
>> Signed-off-by: Francisco Jerez
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index 3a69b367e565..721f915115bd 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -132,6 +132,7 @@
>> *
>> */
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -379,11 +380,13 @@ execlists_context_schedule_in(struct i915_request *rq)
>> {
>> execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
>> intel_engine_context_in(rq->engine);
>> + cpufreq_io_active_begin();
>
> Since you only care about a binary value for GPU activity, we don't need
> to do this on each context, just between submitting the first request
> and the final completion, i.e. couple this to EXECLISTS_ACTIVE_USER.
>
> Haven't yet gone back to check how heavy io_active_begin/end are, but I
> trust you appreciate that this code is particularly latency sensitive.
The cpufreq_io_active_begin/end() interfaces are probably as lightweight
as they can be. There's no locking involved. In cases where there
already is an overlapping request, cpufreq_io_active_begin() and
cpufreq_io_active_end() should return without doing much more than an
atomic increment and an atomic cmpxchg respectively.
That said, it wouldn't hurt to call each of them once per sequence of
overlapping requests. Do you want me to call them from
execlists_set/clear_active() themselves when bit == EXECLISTS_ACTIVE_USER,
or at each callsite of execlists_set/clear_active()? [possibly protected
with a check that execlists_is_active(EXECLISTS_ACTIVE_USER) wasn't
already the expected value]
> -Chris
signature.asc
Description: PGP signature
___
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: Only warn for might_sleep() before a slow wait_for_register
== Series Details == Series: drm/i915: Only warn for might_sleep() before a slow wait_for_register URL : https://patchwork.freedesktop.org/series/40823/ State : success == Summary == Series 40823v1 drm/i915: Only warn for might_sleep() before a slow wait_for_register https://patchwork.freedesktop.org/api/1.0/series/40823/revisions/1/mbox/ Known issues: Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7500u) fdo#105128 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 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:427s 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:378s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:546s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:294s 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:514s 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: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:562s 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:588s 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:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:425s 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:432s 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:459s 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:661s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:540s 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:513s 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:3pass:2dwarn:0 dfail:0 fail:0 skip:0 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:538s 03f62197cf791e1a517f8122e0e7257b33e0c652 drm-tip: 2018y-03m-28d-18h-18m-48s UTC integration manifest 181d8238ba72 drm/i915: Only warn for might_sleep() before a slow wait_for_register == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8519/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: Only warn for might_sleep() before a slow wait_for_register
Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40) > > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > > As intel_wait_for_register_fw() may use, and if successful only use, a > > busy-wait loop, the might_sleep() warning is a little over-zealous. > > Restrict it to a might_sleep_if() a slow timeout is specified (and so > > the caller authorises use of a usleep). > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > b/drivers/gpu/drm/i915/intel_uncore.c > > index f37ecfc69e49..44c4654443ba 100644 > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private > > *dev_priv, > > u32 reg_value; > > int ret; > > > > - might_sleep(); > > + might_sleep_if(slow_timeout_ms); > > __wait_for() already has a might_sleep(), why is this needed? To document that this routine is a sleeper, irrespective of the implementation. Sometimes it is implicit on the implementation and so should only be at the low level, sometimes we want to call out the requirements explicitly and clearly. We have "wait" in the name so shouting out that this may indeed sleep rather than busyspin seems to be in order. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, Here's a lonely fix for -next, please pull at your convenience. drm-misc-next-fixes-2018-03-28: UABI: - Mask mode type garbage from userspace (Ville) Cc: Ville Syrjälä Cheers, Sean The following changes since commit b4eec0fa537165efc3265cdbb4bac06e6bdaf596: Merge tag 'drm-intel-next-fixes-2018-03-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-23 06:19:27 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-03-28 for you to fetch changes up to b4eec0fa537165efc3265cdbb4bac06e6bdaf596: Merge tag 'drm-intel-next-fixes-2018-03-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-23 06:19:27 +1000) UABI: - Mask mode type garbage from userspace (Ville) Cc: Ville Syrjälä -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.
Quoting Francisco Jerez (2018-03-28 19:55:12) > Hi Chris, > [snip] > That said, it wouldn't hurt to call each of them once per sequence of > overlapping requests. Do you want me to call them from > execlists_set/clear_active() themselves when bit == EXECLISTS_ACTIVE_USER, > or at each callsite of execlists_set/clear_active()? [possibly protected > with a check that execlists_is_active(EXECLISTS_ACTIVE_USER) wasn't > already the expected value] No, I was thinking of adding an execlists_start()/execlists_stop() [naming suggestions welcome, begin/end?] where we could hook additional bookkeeping into. -Chris ___ 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/breadcrumbs: Keep the fake irq armed across reset (rev2)
== Series Details == Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2) URL : https://patchwork.freedesktop.org/series/40825/ State : success == Summary == Series 40825v2 drm/i915/breadcrumbs: Keep the fake irq armed across reset https://patchwork.freedesktop.org/api/1.0/series/40825/revisions/2/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7500u) fdo#105128 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 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: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:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:300s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:517s 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:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:417s 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:514s 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:422s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s 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:419s 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:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:654s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s 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:509s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:511s 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:443s 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:403s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:530s 03f62197cf791e1a517f8122e0e7257b33e0c652 drm-tip: 2018y-03m-28d-18h-18m-48s UTC integration manifest 6bdfb0f56307 drm/i915/breadcrumbs: Keep the fake irq armed across reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8520/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Reset ring registers on rebinding contexts
Quoting Patchwork (2018-03-28 08:07:45) > == Series Details == > > Series: drm/i915/execlists: Reset ring registers on rebinding contexts > URL : https://patchwork.freedesktop.org/series/40763/ > State : failure > > == Summary == > > Possible new issues: > > Test kms_flip: > Subgroup flip-vs-blocking-wf-vblank: > pass -> FAIL (shard-hsw) Tvrtko, thankyou for such an interesting bug, now please stop messing around with gem_eio ;) Pushed, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register
On Wed, 2018-03-28 at 20:13 +0100, Chris Wilson wrote: > Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40) > > > > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > > > As intel_wait_for_register_fw() may use, and if successful only use, a > > > busy-wait loop, the might_sleep() warning is a little over-zealous. > > > Restrict it to a might_sleep_if() a slow timeout is specified (and so > > > the caller authorises use of a usleep). > > > > > > Signed-off-by: Chris Wilson > > > --- > > > drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > > b/drivers/gpu/drm/i915/intel_uncore.c > > > index f37ecfc69e49..44c4654443ba 100644 > > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct > > > drm_i915_private *dev_priv, > > > u32 reg_value; > > > int ret; > > > > > > - might_sleep(); > > > + might_sleep_if(slow_timeout_ms); > > > > __wait_for() already has a might_sleep(), why is this needed? > > To document that this routine is a sleeper, irrespective of the > implementation. Sometimes it is implicit on the implementation and so > should only be at the low level, sometimes we want to call out the > requirements explicitly and clearly. We have "wait" in the name so > shouting out that this may indeed sleep rather than busyspin seems to > be in order. > -Chris Fair enough. There seems to be a side effect from the second hunk that your commit message does not explicitly state. > - if (ret) > + if (ret && slow_timeout_ms) This results in a different return value if condition == true and slow_timeout_ms == 0 after fast_timeout_us was exceeded. Previously, __intel_wait_for_register would have passed along the 0 from __wait_for(), now it returns -ETIMEDOUT. Which means this change should have been a separate patch. As the patch itself is sensible, Reviewed-by: Dhinakaran Pandiyan > ___ > 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] ✗ Fi.CI.IGT: failure for drm/i915/guc: Support for Guc responses and requests (rev5)
Quoting Patchwork (2018-03-28 09:22:48) > == Series Details == > > Series: drm/i915/guc: Support for Guc responses and requests (rev5) > URL : https://patchwork.freedesktop.org/series/28393/ > State : failure > > == Summary == > > Possible new issues: > > Test debugfs_test: > Subgroup read_all_entries_display_off: > pass -> DMESG-WARN (shard-apl) > Test gem_eio: > Subgroup execbuf: > pass -> INCOMPLETE (shard-apl) > Subgroup throttle: > pass -> INCOMPLETE (shard-apl) intel_engines_reset_default_submission() being called from an inopportune time. Applied the series, thanks for the patches and review. I did notice a residual XXX, some potential use of IS_ALIGNED() might be clearer than x % y, and maybe using circ_buffer.h. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add basic sanitychecks for execlists
== Series Details == Series: drm/i915/selftests: Add basic sanitychecks for execlists URL : https://patchwork.freedesktop.org/series/40805/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-onoff: fail -> PASS (shard-snb) Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-toggle: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 +1 Subgroup blocking-wf_vblank: fail -> PASS (shard-hsw) fdo#100368 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: pass -> DMESG-WARN (shard-snb) fdo#103167 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 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 shard-apltotal:3496 pass:1831 dwarn:1 dfail:1 fail:7 skip:1655 time:12767s shard-hswtotal:3496 pass:1782 dwarn:1 dfail:0 fail:3 skip:1709 time:11454s shard-snbtotal:3496 pass:1375 dwarn:2 dfail:0 fail:2 skip:2117 time:6922s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8517/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] HAX enable GuC submission for CI
From: Michal Wajdeczko Stolen from... Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/guc: enable guc interrupts unconditionally in uc_resume
Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC
interrupts enabled when using GuC").
Not really needed since i915_gem_init_hw is called before uc_resume, but
it brings symmetry to uc_suspend.
Signed-off-by: Michel Thierry
Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
---
drivers/gpu/drm/i915/intel_uc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 081e42462aad..1cffaf7b5dbe 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -480,8 +480,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- if (i915_modparams.guc_log_level)
- gen9_enable_guc_interrupts(i915);
+ gen9_enable_guc_interrupts(i915);
err = intel_guc_resume(guc);
if (err) {
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
