public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH 1/5] drm/i915: Add wait_for_us
@ 2016-03-03 14:36 Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines Tvrtko Ursulin
                   ` (5 more replies)
  0 siblings, 6 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 14:36 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

This is for callers who want micro-second precision but are not
waiting from the atomic context.

v2:
  * Fix atomic waits. (Dave Gordon)
  * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_dp.c  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 15 ++++++++-------
 drivers/gpu/drm/i915/intel_psr.c |  3 ++-
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f272b3541e00..3629e293ff61 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1779,11 +1779,11 @@ static void wait_panel_status(struct intel_dp *intel_dp,
 			I915_READ(pp_stat_reg),
 			I915_READ(pp_ctrl_reg));
 
-	if (_wait_for((I915_READ(pp_stat_reg) & mask) == value, 5000, 10)) {
+	if (_wait_for((I915_READ(pp_stat_reg) & mask) == value,
+		      5 * USEC_PER_SEC, 10 * USEC_PER_MSEC))
 		DRM_ERROR("Panel status timeout: status %08x control %08x\n",
 				I915_READ(pp_stat_reg),
 				I915_READ(pp_ctrl_reg));
-	}
 
 	DRM_DEBUG_KMS("Wait complete\n");
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6c0085496fca..c2a62e9554b3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -45,8 +45,8 @@
  * having timed out, since the timeout could be due to preemption or similar and
  * we've never had a chance to check the condition before the timeout.
  */
-#define _wait_for(COND, MS, W) ({ \
-	unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1;	\
+#define _wait_for(COND, US, W) ({ \
+	unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;	\
 	int ret__ = 0;							\
 	while (!(COND)) {						\
 		if (time_after(jiffies, timeout__)) {			\
@@ -55,7 +55,7 @@
 			break;						\
 		}							\
 		if ((W) && drm_can_sleep()) {				\
-			usleep_range((W)*1000, (W)*2000);		\
+			usleep_range((W), (W)*2);			\
 		} else {						\
 			cpu_relax();					\
 		}							\
@@ -63,10 +63,11 @@
 	ret__;								\
 })
 
-#define wait_for(COND, MS) _wait_for(COND, MS, 1)
-#define wait_for_atomic(COND, MS) _wait_for(COND, MS, 0)
-#define wait_for_atomic_us(COND, US) _wait_for((COND), \
-					       DIV_ROUND_UP((US), 1000), 0)
+#define wait_for(COND, MS)	  	_wait_for((COND), (MS) * 1000, 1000)
+#define wait_for_us(COND, US)	  	_wait_for((COND), (US), 1)
+
+#define wait_for_atomic(COND, MS) 	_wait_for((COND), (MS) * 1000, 0)
+#define wait_for_atomic_us(COND, US)	_wait_for((COND), (US), 0)
 
 #define KHz(x) (1000 * (x))
 #define MHz(x) KHz(1000 * (x))
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0b42ada338c8..b1413beb00d1 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -507,7 +507,8 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
 
 		/* Wait till PSR is idle */
 		if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL) &
-			       EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
+			       EDP_PSR_STATUS_STATE_MASK) == 0,
+			       2 * USEC_PER_SEC, 10 * USEC_PER_MSEC))
 			DRM_ERROR("Timed out waiting for PSR Idle State\n");
 
 		dev_priv->psr.active = false;
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
@ 2016-03-03 14:36 ` Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 3/5] drm/i915: Kconfig for extra driver debugging Tvrtko Ursulin
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 14:36 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

I do not see that this needs to be done atomically and up to
one second is quite a long time to busy loop.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4f19ca7490c4..a59e0537c251 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1063,7 +1063,7 @@ void intel_logical_ring_stop(struct intel_engine_cs *ring)
 
 	/* TODO: Is this correct with Execlists enabled? */
 	I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
-	if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
+	if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
 		DRM_ERROR("%s :timed out trying to stop ring\n", ring->name);
 		return;
 	}
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 3/5] drm/i915: Kconfig for extra driver debugging
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines Tvrtko Ursulin
@ 2016-03-03 14:36 ` Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity Tvrtko Ursulin
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 14:36 UTC (permalink / raw)
  To: Intel-gfx; +Cc: Jani Nikula

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

v2: Added a submenu based on an idea by Chris Wilson.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/Kconfig       |  6 ++++++
 drivers/gpu/drm/i915/Kconfig.debug | 12 ++++++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/Kconfig.debug

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 20a5d0455e19..29a32b11953b 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -56,3 +56,9 @@ config DRM_I915_USERPTR
 	  selected to enabled full userptr support.
 
 	  If in doubt, say "Y".
+
+menu "drm/i915 Debugging"
+depends on DRM_I915
+depends on EXPERT
+source drivers/gpu/drm/i915/Kconfig.debug
+endmenu
diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
new file mode 100644
index 000000000000..649a562ddf17
--- /dev/null
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -0,0 +1,12 @@
+config DRM_I915_DEBUG
+        bool "Enable additional driver debugging"
+        depends on DRM_I915
+        default n
+        help
+          Choose this option to turn on extra driver debugging that may affect
+          performance but will catch some internal issues.
+
+          Recommended for driver developers only.
+
+          If in doubt, say "N".
+
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines Tvrtko Ursulin
  2016-03-03 14:36 ` [PATCH 3/5] drm/i915: Kconfig for extra driver debugging Tvrtko Ursulin
@ 2016-03-03 14:36 ` Tvrtko Ursulin
  2016-03-03 15:11   ` Chris Wilson
  2016-03-03 14:36 ` [PATCH 5/5] drm/i915: Do not wait atomically for display clocks Tvrtko Ursulin
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 14:36 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Currently the wait_for_atomic_us only allows for a millisecond
granularity which is not nice towards callers requesting small
micro-second waits.

Re-implement it so micro-second granularity is really supported
and not just in the name of the macro.

This has another beneficial side effect that it improves
"gem_latency -n 100" results by approximately 2.5% (throughput
and latencies) and 3% (CPU usage). (Note this improvement is
relative to not yet merged execlist lock uncontention patch
which moves the CSB MMIO outside this lock.)

v2:
  * Warn when used from non-atomic context (if possible).
  * Warn on too long atomic waits.

v3:
  * Added comment explaining CONFIG_PREEMPT_COUNT.
  * Fixed pre-processor indentation.
  (Chris Wilson)

v4:
 * Commit msg update (gem_latency) and rebase.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_drv.h | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2a62e9554b3..b6fcb5c800e7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -44,6 +44,10 @@
  * contexts. Note that it's important that we check the condition again after
  * having timed out, since the timeout could be due to preemption or similar and
  * we've never had a chance to check the condition before the timeout.
+ *
+ * TODO: When modesetting has fully transitioned to atomic, the below
+ * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
+ * added.
  */
 #define _wait_for(COND, US, W) ({ \
 	unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;	\
@@ -66,8 +70,31 @@
 #define wait_for(COND, MS)	  	_wait_for((COND), (MS) * 1000, 1000)
 #define wait_for_us(COND, US)	  	_wait_for((COND), (US), 1)
 
-#define wait_for_atomic(COND, MS) 	_wait_for((COND), (MS) * 1000, 0)
-#define wait_for_atomic_us(COND, US)	_wait_for((COND), (US), 0)
+/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
+#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
+# define _WAIT_FOR_ATOMIC_CHECK WARN_ON_ONCE(!in_atomic())
+#else
+# define _WAIT_FOR_ATOMIC_CHECK do { } while(0)
+#endif
+
+#define _wait_for_atomic(COND, US) ({ \
+	unsigned long end__; \
+	int ret__ = 0; \
+	_WAIT_FOR_ATOMIC_CHECK; \
+	BUILD_BUG_ON((US) > 50000); \
+	end__ = (local_clock() >> 10) + (US) + 1; \
+	while (!(COND)) { \
+		if (time_after((unsigned long)(local_clock() >> 10), end__)) { \
+			ret__ = -ETIMEDOUT; \
+			break; \
+		} \
+		cpu_relax(); \
+	} \
+	ret__; \
+})
+
+#define wait_for_atomic(COND, MS)	_wait_for_atomic((COND), (MS) * 1000)
+#define wait_for_atomic_us(COND, US)	_wait_for_atomic((COND), (US))
 
 #define KHz(x) (1000 * (x))
 #define MHz(x) KHz(1000 * (x))
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 5/5] drm/i915: Do not wait atomically for display clocks
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
                   ` (2 preceding siblings ...)
  2016-03-03 14:36 ` [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity Tvrtko Ursulin
@ 2016-03-03 14:36 ` Tvrtko Ursulin
  2016-03-03 15:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us Patchwork
  2016-03-03 17:01 ` ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2) Patchwork
  5 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 14:36 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Looks like this code does not need to wait atomically since it
otherwise takes the mutex.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 08c363127885..124342bdbe90 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9857,8 +9857,8 @@ static void broadwell_set_cdclk(struct drm_device *dev, int cdclk)
 	val |= LCPLL_CD_SOURCE_FCLK;
 	I915_WRITE(LCPLL_CTL, val);
 
-	if (wait_for_atomic_us(I915_READ(LCPLL_CTL) &
-			       LCPLL_CD_SOURCE_FCLK_DONE, 1))
+	if (wait_for_us(I915_READ(LCPLL_CTL) &
+			LCPLL_CD_SOURCE_FCLK_DONE, 1))
 		DRM_ERROR("Switching to FCLK failed\n");
 
 	val = I915_READ(LCPLL_CTL);
@@ -9892,8 +9892,8 @@ static void broadwell_set_cdclk(struct drm_device *dev, int cdclk)
 	val &= ~LCPLL_CD_SOURCE_FCLK;
 	I915_WRITE(LCPLL_CTL, val);
 
-	if (wait_for_atomic_us((I915_READ(LCPLL_CTL) &
-				LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
+	if (wait_for_us((I915_READ(LCPLL_CTL) &
+			LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
 		DRM_ERROR("Switching back to LCPLL failed\n");
 
 	mutex_lock(&dev_priv->rps.hw_lock);
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
                   ` (3 preceding siblings ...)
  2016-03-03 14:36 ` [PATCH 5/5] drm/i915: Do not wait atomically for display clocks Tvrtko Ursulin
@ 2016-03-03 15:03 ` Patchwork
  2016-03-03 17:01   ` Tvrtko Ursulin
  2016-03-03 17:01 ` ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2) Patchwork
  5 siblings, 1 reply; 14+ messages in thread
From: Patchwork @ 2016-03-03 15:03 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/5] drm/i915: Add wait_for_us
URL   : https://patchwork.freedesktop.org/series/4059/
State : failure

== Summary ==

Series 4059v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/

Test gem_sync:
        Subgroup basic-bsd:
                dmesg-fail -> PASS       (ilk-hp8440p)
Test kms_flip:
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> DMESG-WARN (hsw-gt2)
        Subgroup basic-plain-flip:
                pass       -> DMESG-WARN (snb-dellxps)
                dmesg-warn -> PASS       (hsw-brixbox)
Test kms_force_connector_basic:
        Subgroup force-edid:
                skip       -> PASS       (ilk-hp8440p)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                dmesg-warn -> PASS       (bdw-ultra)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                dmesg-warn -> PASS       (snb-dellxps)
        Subgroup basic-rte:
                pass       -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7        total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultra        total:183  pass:165  dwarn:0   dfail:0   fail:0   skip:18 
bsw-nuc-2        total:183  pass:147  dwarn:1   dfail:0   fail:1   skip:34 
byt-nuc          total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31 
hsw-brixbox      total:183  pass:163  dwarn:1   dfail:0   fail:0   skip:19 
hsw-gt2          total:183  pass:168  dwarn:1   dfail:0   fail:0   skip:14 
ilk-hp8440p      total:183  pass:125  dwarn:0   dfail:0   fail:0   skip:58 
ivb-t430s        total:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21 
skl-i5k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
skl-i7k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
snb-dellxps      total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29 

Results at /archive/results/CI_IGT_test/Patchwork_1524/

1b34b1cf252bb734775331c435b0e3a3de484db6 drm-intel-nightly: 2016y-03m-03d-13h-06m-21s UTC integration manifest
f69fa33fd56c8d11757c3f12b918b3a5b1ede935 drm/i915: Do not wait atomically for display clocks
dae20b8161fd1e3b460f176064689f28aa852210 drm/i915: Do not lie about atomic wait granularity
328f1cc8e235f05948e43c71cf4c3457185a236f drm/i915: Kconfig for extra driver debugging
0324e4ed18bbc27f6620c29bf266eaa4debee3fb drm/i915/lrc: Do not wait atomically when stopping engines
822b3c5647a918dd7f1b7a81318c82f99697a0d3 drm/i915: Add wait_for_us

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity
  2016-03-03 14:36 ` [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity Tvrtko Ursulin
@ 2016-03-03 15:11   ` Chris Wilson
  2016-03-03 15:43     ` Tvrtko Ursulin
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2016-03-03 15:11 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Thu, Mar 03, 2016 at 02:36:44PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Currently the wait_for_atomic_us only allows for a millisecond
> granularity which is not nice towards callers requesting small
> micro-second waits.

Hmm, by granularity I think of the interval between COND reads. That
should be the limiting factor in how fast we respond to the change in
event (and so for the atomic variants should be virtually the same).

Your suggestion that it is icache or similar is probably along the right
path. A quick code size measurement of a test function would be a good
supporting argument.
 
> Re-implement it so micro-second granularity is really supported
> and not just in the name of the macro.
> 
> This has another beneficial side effect that it improves
> "gem_latency -n 100" results by approximately 2.5% (throughput
> and latencies) and 3% (CPU usage). (Note this improvement is
> relative to not yet merged execlist lock uncontention patch
> which moves the CSB MMIO outside this lock.)
> 
> v2:
>   * Warn when used from non-atomic context (if possible).
>   * Warn on too long atomic waits.
> 
> v3:
>   * Added comment explaining CONFIG_PREEMPT_COUNT.
>   * Fixed pre-processor indentation.
>   (Chris Wilson)
> 
> v4:
>  * Commit msg update (gem_latency) and rebase.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index c2a62e9554b3..b6fcb5c800e7 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -44,6 +44,10 @@
>   * contexts. Note that it's important that we check the condition again after
>   * having timed out, since the timeout could be due to preemption or similar and
>   * we've never had a chance to check the condition before the timeout.
> + *
> + * TODO: When modesetting has fully transitioned to atomic, the below
> + * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
> + * added.
>   */
>  #define _wait_for(COND, US, W) ({ \
>  	unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;	\
> @@ -66,8 +70,31 @@
>  #define wait_for(COND, MS)	  	_wait_for((COND), (MS) * 1000, 1000)
>  #define wait_for_us(COND, US)	  	_wait_for((COND), (US), 1)
>  
> -#define wait_for_atomic(COND, MS) 	_wait_for((COND), (MS) * 1000, 0)
> -#define wait_for_atomic_us(COND, US)	_wait_for((COND), (US), 0)
> +/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
> +#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
> +# define _WAIT_FOR_ATOMIC_CHECK WARN_ON_ONCE(!in_atomic())
> +#else
> +# define _WAIT_FOR_ATOMIC_CHECK do { } while(0)
> +#endif
> +
> +#define _wait_for_atomic(COND, US) ({ \
> +	unsigned long end__; \
> +	int ret__ = 0; \
> +	_WAIT_FOR_ATOMIC_CHECK; \
> +	BUILD_BUG_ON((US) > 50000); \
> +	end__ = (local_clock() >> 10) + (US) + 1; \
> +	while (!(COND)) { \
> +		if (time_after((unsigned long)(local_clock() >> 10), end__)) { \

A comment here about why we can forgo the COND recheck would be
worthwhile.

/* Unlike the regular wait_for(), this atomic variant cannot be
 * preempted (and we'll just ignore the issue of irq interruptions) and
 * so we know that no time has passed since the last check of COND and
 * can immediately report the timeout.
 */
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity
  2016-03-03 15:11   ` Chris Wilson
@ 2016-03-03 15:43     ` Tvrtko Ursulin
  2016-03-03 16:10       ` Chris Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 15:43 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 03/03/16 15:11, Chris Wilson wrote:
> On Thu, Mar 03, 2016 at 02:36:44PM +0000, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Currently the wait_for_atomic_us only allows for a millisecond
>> granularity which is not nice towards callers requesting small
>> micro-second waits.
>
> Hmm, by granularity I think of the interval between COND reads. That
> should be the limiting factor in how fast we respond to the change in
> event (and so for the atomic variants should be virtually the same).

Yeah not that granularity, should I say "timeout granularity" then in 
the commit? Before if someone wanted to wait for, say 10us, it would 
have busy looped for one jiffie instead. In the timeout scenario that 
is. That is the headline improvement.

> Your suggestion that it is icache or similar is probably along the right
> path. A quick code size measurement of a test function would be a good
> supporting argument.

I am not sure. It shaves ~3.3% (12 of original 353 bytes) of the whole 
fw_domains_get which even if it is quite hot as you know, and even 3% 
from the main loop in wait for atomic (3% here is a glorious one byte). 
So I am not sure, but gem_latency results were quite convincing. 
Unexplained for me.

>> Re-implement it so micro-second granularity is really supported
>> and not just in the name of the macro.
>>
>> This has another beneficial side effect that it improves
>> "gem_latency -n 100" results by approximately 2.5% (throughput
>> and latencies) and 3% (CPU usage). (Note this improvement is
>> relative to not yet merged execlist lock uncontention patch
>> which moves the CSB MMIO outside this lock.)
>>
>> v2:
>>    * Warn when used from non-atomic context (if possible).
>>    * Warn on too long atomic waits.
>>
>> v3:
>>    * Added comment explaining CONFIG_PREEMPT_COUNT.
>>    * Fixed pre-processor indentation.
>>    (Chris Wilson)
>>
>> v4:
>>   * Commit msg update (gem_latency) and rebase.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>>   drivers/gpu/drm/i915/intel_drv.h | 31 +++++++++++++++++++++++++++++--
>>   1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>> index c2a62e9554b3..b6fcb5c800e7 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -44,6 +44,10 @@
>>    * contexts. Note that it's important that we check the condition again after
>>    * having timed out, since the timeout could be due to preemption or similar and
>>    * we've never had a chance to check the condition before the timeout.
>> + *
>> + * TODO: When modesetting has fully transitioned to atomic, the below
>> + * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
>> + * added.
>>    */
>>   #define _wait_for(COND, US, W) ({ \
>>   	unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;	\
>> @@ -66,8 +70,31 @@
>>   #define wait_for(COND, MS)	  	_wait_for((COND), (MS) * 1000, 1000)
>>   #define wait_for_us(COND, US)	  	_wait_for((COND), (US), 1)
>>
>> -#define wait_for_atomic(COND, MS) 	_wait_for((COND), (MS) * 1000, 0)
>> -#define wait_for_atomic_us(COND, US)	_wait_for((COND), (US), 0)
>> +/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
>> +#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
>> +# define _WAIT_FOR_ATOMIC_CHECK WARN_ON_ONCE(!in_atomic())
>> +#else
>> +# define _WAIT_FOR_ATOMIC_CHECK do { } while(0)
>> +#endif
>> +
>> +#define _wait_for_atomic(COND, US) ({ \
>> +	unsigned long end__; \
>> +	int ret__ = 0; \
>> +	_WAIT_FOR_ATOMIC_CHECK; \
>> +	BUILD_BUG_ON((US) > 50000); \
>> +	end__ = (local_clock() >> 10) + (US) + 1; \
>> +	while (!(COND)) { \
>> +		if (time_after((unsigned long)(local_clock() >> 10), end__)) { \
>
> A comment here about why we can forgo the COND recheck would be
> worthwhile.
>
> /* Unlike the regular wait_for(), this atomic variant cannot be
>   * preempted (and we'll just ignore the issue of irq interruptions) and
>   * so we know that no time has passed since the last check of COND and
>   * can immediately report the timeout.
>   */

Will add.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity
  2016-03-03 15:43     ` Tvrtko Ursulin
@ 2016-03-03 16:10       ` Chris Wilson
  2016-03-03 16:21         ` [PATCH v5 4/5] drm/i915: Do not lie about atomic timeout granularity Tvrtko Ursulin
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2016-03-03 16:10 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Thu, Mar 03, 2016 at 03:43:49PM +0000, Tvrtko Ursulin wrote:
> 
> On 03/03/16 15:11, Chris Wilson wrote:
> >On Thu, Mar 03, 2016 at 02:36:44PM +0000, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>
> >>Currently the wait_for_atomic_us only allows for a millisecond
> >>granularity which is not nice towards callers requesting small
> >>micro-second waits.
> >
> >Hmm, by granularity I think of the interval between COND reads. That
> >should be the limiting factor in how fast we respond to the change in
> >event (and so for the atomic variants should be virtually the same).
> 
> Yeah not that granularity, should I say "timeout granularity" then
> in the commit? Before if someone wanted to wait for, say 10us, it
> would have busy looped for one jiffie instead. In the timeout
> scenario that is. That is the headline improvement.

"timeout granularity" would be much clearer

> >Your suggestion that it is icache or similar is probably along the right
> >path. A quick code size measurement of a test function would be a good
> >supporting argument.
> 
> I am not sure. It shaves ~3.3% (12 of original 353 bytes) of the
> whole fw_domains_get which even if it is quite hot as you know, and
> even 3% from the main loop in wait for atomic (3% here is a glorious
> one byte). So I am not sure, but gem_latency results were quite
> convincing. Unexplained for me.

Ok. The small improvement in addition to stronger compile-time checks is
certainly enough justification. The motivation is usually to avoid
hitting the wait_for(register) loop in the first place, and a good
mystery is always a good read for a rainy day.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v5 4/5] drm/i915: Do not lie about atomic timeout granularity
  2016-03-03 16:10       ` Chris Wilson
@ 2016-03-03 16:21         ` Tvrtko Ursulin
  0 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 16:21 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Currently the wait_for_atomic_us only allows for a jiffie
timeout granularity which is not nice towards callers
requesting small micro-second timeouts.

Re-implement it so micro-second timeout granularity is really
supported and not just in the name of the macro.

This has another beneficial side effect that it improves
"gem_latency -n 100" results by approximately 2.5% (throughput
and latencies) and 3% (CPU usage). (Note this improvement is
relative to not yet merged execlist lock uncontention patch
which moves the CSB MMIO outside this lock.)

It also shrinks some hot functions like fw_domains_get by a
tiny 3%.

v2:
  * Warn when used from non-atomic context (if possible).
  * Warn on too long atomic waits.

v3:
  * Added comment explaining CONFIG_PREEMPT_COUNT.
  * Fixed pre-processor indentation.
  (Chris Wilson)

v4:
 * Commit msg update (gem_latency) and rebase.

v5:
 * Commit message re-wording.
 * Added comment about no need for double cond check. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_drv.h | 37 +++++++++++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2a62e9554b3..7819ddb51745 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -44,6 +44,10 @@
  * contexts. Note that it's important that we check the condition again after
  * having timed out, since the timeout could be due to preemption or similar and
  * we've never had a chance to check the condition before the timeout.
+ *
+ * TODO: When modesetting has fully transitioned to atomic, the below
+ * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
+ * added.
  */
 #define _wait_for(COND, US, W) ({ \
 	unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;	\
@@ -66,8 +70,37 @@
 #define wait_for(COND, MS)	  	_wait_for((COND), (MS) * 1000, 1000)
 #define wait_for_us(COND, US)	  	_wait_for((COND), (US), 1)
 
-#define wait_for_atomic(COND, MS) 	_wait_for((COND), (MS) * 1000, 0)
-#define wait_for_atomic_us(COND, US)	_wait_for((COND), (US), 0)
+/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
+#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
+# define _WAIT_FOR_ATOMIC_CHECK WARN_ON_ONCE(!in_atomic())
+#else
+# define _WAIT_FOR_ATOMIC_CHECK do { } while(0)
+#endif
+
+#define _wait_for_atomic(COND, US) ({ \
+	unsigned long end__; \
+	int ret__ = 0; \
+	_WAIT_FOR_ATOMIC_CHECK; \
+	BUILD_BUG_ON((US) > 50000); \
+	end__ = (local_clock() >> 10) + (US) + 1; \
+	while (!(COND)) { \
+		if (time_after((unsigned long)(local_clock() >> 10), end__)) { \
+			/* Unlike the regular wait_for(), this atomic variant \
+			 * cannot be preempted (and we'll just ignore the issue\
+			 * of irq interruptions) and so we know that no time \
+			 * has passed since the last check of COND and can \
+			 * immediately report the timeout. \
+			 */ \
+			ret__ = -ETIMEDOUT; \
+			break; \
+		} \
+		cpu_relax(); \
+	} \
+	ret__; \
+})
+
+#define wait_for_atomic(COND, MS)	_wait_for_atomic((COND), (MS) * 1000)
+#define wait_for_atomic_us(COND, US)	_wait_for_atomic((COND), (US))
 
 #define KHz(x) (1000 * (x))
 #define MHz(x) KHz(1000 * (x))
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us
  2016-03-03 15:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us Patchwork
@ 2016-03-03 17:01   ` Tvrtko Ursulin
  2016-03-03 17:20     ` Chris Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 17:01 UTC (permalink / raw)
  To: intel-gfx


On 03/03/16 15:03, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/5] drm/i915: Add wait_for_us
> URL   : https://patchwork.freedesktop.org/series/4059/
> State : failure
>
> == Summary ==
>
> Series 4059v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/
>
> Test gem_sync:
>          Subgroup basic-bsd:
>                  dmesg-fail -> PASS       (ilk-hp8440p)
> Test kms_flip:
>          Subgroup basic-flip-vs-wf_vblank:
>                  pass       -> DMESG-WARN (hsw-gt2)

Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94349

>          Subgroup basic-plain-flip:
>                  pass       -> DMESG-WARN (snb-dellxps)

Same as above.

>                  dmesg-warn -> PASS       (hsw-brixbox)
> Test kms_force_connector_basic:
>          Subgroup force-edid:
>                  skip       -> PASS       (ilk-hp8440p)
> Test kms_psr_sink_crc:
>          Subgroup psr_basic:
>                  dmesg-warn -> PASS       (bdw-ultra)
> Test pm_rpm:
>          Subgroup basic-pci-d3-state:
>                  dmesg-warn -> PASS       (snb-dellxps)
>          Subgroup basic-rte:
>                  pass       -> DMESG-WARN (bsw-nuc-2)

Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94164

>
> bdw-nuci7        total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11
> bdw-ultra        total:183  pass:165  dwarn:0   dfail:0   fail:0   skip:18
> bsw-nuc-2        total:183  pass:147  dwarn:1   dfail:0   fail:1   skip:34
> byt-nuc          total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31
> hsw-brixbox      total:183  pass:163  dwarn:1   dfail:0   fail:0   skip:19
> hsw-gt2          total:183  pass:168  dwarn:1   dfail:0   fail:0   skip:14
> ilk-hp8440p      total:183  pass:125  dwarn:0   dfail:0   fail:0   skip:58
> ivb-t430s        total:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21
> skl-i5k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
> skl-i7k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
> snb-dellxps      total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29
>
> Results at /archive/results/CI_IGT_test/Patchwork_1524/
>
> 1b34b1cf252bb734775331c435b0e3a3de484db6 drm-intel-nightly: 2016y-03m-03d-13h-06m-21s UTC integration manifest
> f69fa33fd56c8d11757c3f12b918b3a5b1ede935 drm/i915: Do not wait atomically for display clocks
> dae20b8161fd1e3b460f176064689f28aa852210 drm/i915: Do not lie about atomic wait granularity
> 328f1cc8e235f05948e43c71cf4c3457185a236f drm/i915: Kconfig for extra driver debugging
> 0324e4ed18bbc27f6620c29bf266eaa4debee3fb drm/i915/lrc: Do not wait atomically when stopping engines
> 822b3c5647a918dd7f1b7a81318c82f99697a0d3 drm/i915: Add wait_for_us

Just need some r-b's and this is merge-able then. :)

Regards,

Tvrtko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2)
  2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
                   ` (4 preceding siblings ...)
  2016-03-03 15:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us Patchwork
@ 2016-03-03 17:01 ` Patchwork
  5 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2016-03-03 17:01 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/5] drm/i915: Add wait_for_us (rev2)
URL   : https://patchwork.freedesktop.org/series/4059/
State : warning

== Summary ==

Series 4059v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/2/mbox/

Test gem_sync:
        Subgroup basic-bsd:
                dmesg-fail -> PASS       (ilk-hp8440p)
Test kms_flip:
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> DMESG-WARN (hsw-gt2)
                dmesg-warn -> PASS       (hsw-brixbox)
        Subgroup basic-plain-flip:
                pass       -> DMESG-WARN (hsw-gt2)
                dmesg-warn -> PASS       (hsw-brixbox)
Test kms_force_connector_basic:
        Subgroup force-edid:
                pass       -> SKIP       (snb-x220t)
                skip       -> PASS       (ilk-hp8440p)
        Subgroup force-load-detect:
                pass       -> SKIP       (snb-x220t)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (snb-x220t)
        Subgroup suspend-read-crc-pipe-c:
                pass       -> DMESG-WARN (bsw-nuc-2)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                dmesg-warn -> PASS       (bdw-ultra)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                dmesg-fail -> FAIL       (snb-x220t)
        Subgroup basic-rte:
                dmesg-warn -> PASS       (snb-x220t)
                pass       -> DMESG-WARN (snb-dellxps)

bdw-nuci7        total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultra        total:183  pass:165  dwarn:0   dfail:0   fail:0   skip:18 
bsw-nuc-2        total:183  pass:147  dwarn:1   dfail:0   fail:1   skip:34 
byt-nuc          total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31 
hsw-brixbox      total:183  pass:164  dwarn:0   dfail:0   fail:0   skip:19 
hsw-gt2          total:183  pass:167  dwarn:2   dfail:0   fail:0   skip:14 
ilk-hp8440p      total:183  pass:125  dwarn:0   dfail:0   fail:0   skip:58 
ivb-t430s        total:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21 
skl-i5k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
skl-i7k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
snb-dellxps      total:183  pass:152  dwarn:2   dfail:0   fail:0   skip:29 
snb-x220t        total:183  pass:151  dwarn:1   dfail:0   fail:1   skip:30 

Results at /archive/results/CI_IGT_test/Patchwork_1525/

1b34b1cf252bb734775331c435b0e3a3de484db6 drm-intel-nightly: 2016y-03m-03d-13h-06m-21s UTC integration manifest
1b6ed10ca9be75a40689764c991610cc372514ef drm/i915: Do not wait atomically for display clocks
b044bf3e3b9a8e4de1a1b12bebb81ec38f08caa5 drm/i915: Do not lie about atomic timeout granularity
30151a9c62c460bd8ddebf539680d5b73933c2c4 drm/i915: Kconfig for extra driver debugging
a84822a2d387562e6f4dae37a1f1480591c6e4c6 drm/i915/lrc: Do not wait atomically when stopping engines
2d34e4eb6f681ab525a78e55953f944e10f88d69 drm/i915: Add wait_for_us

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us
  2016-03-03 17:01   ` Tvrtko Ursulin
@ 2016-03-03 17:20     ` Chris Wilson
  2016-03-03 17:35       ` Tvrtko Ursulin
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2016-03-03 17:20 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

On Thu, Mar 03, 2016 at 05:01:15PM +0000, Tvrtko Ursulin wrote:
> 
> On 03/03/16 15:03, Patchwork wrote:
> >== Series Details ==
> >
> >Series: series starting with [1/5] drm/i915: Add wait_for_us
> >URL   : https://patchwork.freedesktop.org/series/4059/
> >State : failure
> >
> >== Summary ==
> >
> >Series 4059v1 Series without cover letter
> >http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/
> >
> >Test gem_sync:
> >         Subgroup basic-bsd:
> >                 dmesg-fail -> PASS       (ilk-hp8440p)
> >Test kms_flip:
> >         Subgroup basic-flip-vs-wf_vblank:
> >                 pass       -> DMESG-WARN (hsw-gt2)
> 
> Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94349
> 
> >         Subgroup basic-plain-flip:
> >                 pass       -> DMESG-WARN (snb-dellxps)
> 
> Same as above.
> 
> >                 dmesg-warn -> PASS       (hsw-brixbox)
> >Test kms_force_connector_basic:
> >         Subgroup force-edid:
> >                 skip       -> PASS       (ilk-hp8440p)
> >Test kms_psr_sink_crc:
> >         Subgroup psr_basic:
> >                 dmesg-warn -> PASS       (bdw-ultra)
> >Test pm_rpm:
> >         Subgroup basic-pci-d3-state:
> >                 dmesg-warn -> PASS       (snb-dellxps)
> >         Subgroup basic-rte:
> >                 pass       -> DMESG-WARN (bsw-nuc-2)
> 
> Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94164
> 
> >
> >bdw-nuci7        total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11
> >bdw-ultra        total:183  pass:165  dwarn:0   dfail:0   fail:0   skip:18
> >bsw-nuc-2        total:183  pass:147  dwarn:1   dfail:0   fail:1   skip:34
> >byt-nuc          total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31
> >hsw-brixbox      total:183  pass:163  dwarn:1   dfail:0   fail:0   skip:19
> >hsw-gt2          total:183  pass:168  dwarn:1   dfail:0   fail:0   skip:14
> >ilk-hp8440p      total:183  pass:125  dwarn:0   dfail:0   fail:0   skip:58
> >ivb-t430s        total:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21
> >skl-i5k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
> >skl-i7k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
> >snb-dellxps      total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29
> >
> >Results at /archive/results/CI_IGT_test/Patchwork_1524/
> >
> >1b34b1cf252bb734775331c435b0e3a3de484db6 drm-intel-nightly: 2016y-03m-03d-13h-06m-21s UTC integration manifest
> >f69fa33fd56c8d11757c3f12b918b3a5b1ede935 drm/i915: Do not wait atomically for display clocks
> >dae20b8161fd1e3b460f176064689f28aa852210 drm/i915: Do not lie about atomic wait granularity
> >328f1cc8e235f05948e43c71cf4c3457185a236f drm/i915: Kconfig for extra driver debugging
> >0324e4ed18bbc27f6620c29bf266eaa4debee3fb drm/i915/lrc: Do not wait atomically when stopping engines
> >822b3c5647a918dd7f1b7a81318c82f99697a0d3 drm/i915: Add wait_for_us
> 
> Just need some r-b's and this is merge-able then. :)

Series looks good, so deal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us
  2016-03-03 17:20     ` Chris Wilson
@ 2016-03-03 17:35       ` Tvrtko Ursulin
  0 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2016-03-03 17:35 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 03/03/16 17:20, Chris Wilson wrote:
> On Thu, Mar 03, 2016 at 05:01:15PM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/03/16 15:03, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: series starting with [1/5] drm/i915: Add wait_for_us
>>> URL   : https://patchwork.freedesktop.org/series/4059/
>>> State : failure
>>>
>>> == Summary ==
>>>
>>> Series 4059v1 Series without cover letter
>>> http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/
>>>
>>> Test gem_sync:
>>>          Subgroup basic-bsd:
>>>                  dmesg-fail -> PASS       (ilk-hp8440p)
>>> Test kms_flip:
>>>          Subgroup basic-flip-vs-wf_vblank:
>>>                  pass       -> DMESG-WARN (hsw-gt2)
>>
>> Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94349
>>
>>>          Subgroup basic-plain-flip:
>>>                  pass       -> DMESG-WARN (snb-dellxps)
>>
>> Same as above.
>>
>>>                  dmesg-warn -> PASS       (hsw-brixbox)
>>> Test kms_force_connector_basic:
>>>          Subgroup force-edid:
>>>                  skip       -> PASS       (ilk-hp8440p)
>>> Test kms_psr_sink_crc:
>>>          Subgroup psr_basic:
>>>                  dmesg-warn -> PASS       (bdw-ultra)
>>> Test pm_rpm:
>>>          Subgroup basic-pci-d3-state:
>>>                  dmesg-warn -> PASS       (snb-dellxps)
>>>          Subgroup basic-rte:
>>>                  pass       -> DMESG-WARN (bsw-nuc-2)
>>
>> Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=94164
>>
>>>
>>> bdw-nuci7        total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11
>>> bdw-ultra        total:183  pass:165  dwarn:0   dfail:0   fail:0   skip:18
>>> bsw-nuc-2        total:183  pass:147  dwarn:1   dfail:0   fail:1   skip:34
>>> byt-nuc          total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31
>>> hsw-brixbox      total:183  pass:163  dwarn:1   dfail:0   fail:0   skip:19
>>> hsw-gt2          total:183  pass:168  dwarn:1   dfail:0   fail:0   skip:14
>>> ilk-hp8440p      total:183  pass:125  dwarn:0   dfail:0   fail:0   skip:58
>>> ivb-t430s        total:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21
>>> skl-i5k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
>>> skl-i7k-2        total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20
>>> snb-dellxps      total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29
>>>
>>> Results at /archive/results/CI_IGT_test/Patchwork_1524/
>>>
>>> 1b34b1cf252bb734775331c435b0e3a3de484db6 drm-intel-nightly: 2016y-03m-03d-13h-06m-21s UTC integration manifest
>>> f69fa33fd56c8d11757c3f12b918b3a5b1ede935 drm/i915: Do not wait atomically for display clocks
>>> dae20b8161fd1e3b460f176064689f28aa852210 drm/i915: Do not lie about atomic wait granularity
>>> 328f1cc8e235f05948e43c71cf4c3457185a236f drm/i915: Kconfig for extra driver debugging
>>> 0324e4ed18bbc27f6620c29bf266eaa4debee3fb drm/i915/lrc: Do not wait atomically when stopping engines
>>> 822b3c5647a918dd7f1b7a81318c82f99697a0d3 drm/i915: Add wait_for_us
>>
>> Just need some r-b's and this is merge-able then. :)
>
> Series looks good, so deal.
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks! I've merged the series.

Now I have only CSB MMIO outstanding. ;)

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2016-03-03 17:35 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 3/5] drm/i915: Kconfig for extra driver debugging Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity Tvrtko Ursulin
2016-03-03 15:11   ` Chris Wilson
2016-03-03 15:43     ` Tvrtko Ursulin
2016-03-03 16:10       ` Chris Wilson
2016-03-03 16:21         ` [PATCH v5 4/5] drm/i915: Do not lie about atomic timeout granularity Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 5/5] drm/i915: Do not wait atomically for display clocks Tvrtko Ursulin
2016-03-03 15:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us Patchwork
2016-03-03 17:01   ` Tvrtko Ursulin
2016-03-03 17:20     ` Chris Wilson
2016-03-03 17:35       ` Tvrtko Ursulin
2016-03-03 17:01 ` ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2) Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox