Re: [Intel-gfx] [PATCH] drm/i915: Disable THP until we have a GPU read BW W/A
On Mon, 2017-11-27 at 13:36 +, Rantala, Valtteri wrote:
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Monday, November 27, 2017 11:13 AM
> > To: Intel graphics driver community testing & development > g...@lists.freedesktop.org>
> > Cc: Joonas Lahtinen ; Auld, Matthew
> > ; Chris Wilson ; Jani
> > Nikula ; Vivi, Rodrigo
> > ;
> > Rantala, Valtteri ; Tamminen, Eero T
> >
> > Subject: [PATCH] drm/i915: Disable THP until we have a GPU read BW W/A
> >
> > We seem to be missing some W/A for 2M pages and are getting a hit on raw
> > GPU read bandwidths (even 30%) even though the GPU write bandwidths
> > improve (even 10%).
> >
> > For now, disable THP, which is our only practical source of 2M pages until
> > we
> > have a W/A for the issue.
> >
> > v2:
> > - Be explicit that we talk about GPU bandwidths (Eero)
> > - s/deny/never/ because that's why (Chris)
> >
> > Reported-by: Valtteri Rantala
> > Fixes: b901bb89324a ("drm/i915/gemfs: enable THP")
> > Signed-off-by: Joonas Lahtinen
> > Cc: Matthew Auld
> > Cc: Chris Wilson
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Cc: Valtteri Rantala
> > Cc: Eero Tamminen
> > Reviewed-by: Chris Wilson
> > Reviewed-by: Matthew Auld
>
> Tested-by: Valtteri Rantala
I'm merging the patch, thanks for the report, reviews and testing!
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
On Tue, Nov 28, 2017 at 05:22:00PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2017-11-28 17:07:07) > > cross-release ftl > > Fwiw, this isn't cross-release but us reloading the module many times, > creating a whole host of new lockclasses. Even more fun is when the > module gets a slightly different address and the new lock address hashes > into an old lock... > > I did think about a module-hook to revoke the stale lockclasses, but > that still leaves all the hashed chains. > > This particular nuisance was temporarily pushed back by teaching igt not > to reload i915.ko on a whim. Ah ... Added your explanation to the commit message, and I guess that just means we'll have to carry it ourselves :-/ I'll still send them out if CI approves to lockdep folks, just as an fyi. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] lockdep: finer-grained completion key for kthread
== Series Details == Series: series starting with [1/2] lockdep: finer-grained completion key for kthread URL : https://patchwork.freedesktop.org/series/34556/ State : success == Summary == Blacklisted hosts: shard-hswtotal:2661 pass:1532 dwarn:2 dfail:0 fail:11 skip:1116 time:8786s shard-snbtotal:2559 pass:1238 dwarn:12 dfail:4 fail:7 skip:1296 time:7820s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7328/shards.html ___ 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/guc: Fix doc reference to intel_guc_fw.c
== Series Details == Series: drm/i915/guc: Fix doc reference to intel_guc_fw.c URL : https://patchwork.freedesktop.org/series/34557/ State : success == Summary == Blacklisted hosts: shard-hswtotal:2560 pass:1471 dwarn:8 dfail:0 fail:9 skip:1071 time:8745s shard-snbtotal:2588 pass:1239 dwarn:19 dfail:6 fail:7 skip:1313 time:7811s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7329/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Consolidate checks for engine stats availability
On 11/28/2017 6:34 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.
My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.
v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Sagar Arun Kamble
Cc: Sagar Arun Kamble
Reviewed-by: Chris Wilson (v2)
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
5 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 3357b690ce90..c3c641ec962b 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event
*event)
return config_enabled_bit(event->attr.config);
}
-static bool supports_busy_stats(struct drm_i915_private *i915)
-{
- return INTEL_GEN(i915) >= 8;
-}
-
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
*/
- else if (supports_busy_stats(i915))
+ else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
{
- return supports_busy_stats(engine->i915) &&
+ return intel_engine_supports_stats(engine) &&
(engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index d27e124d826a..a35f8d3a55fd 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1527,8 +1527,10 @@ void intel_engines_reset_default_submission(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- for_each_engine(engine, i915, id)
+ for_each_engine(engine, i915, id) {
engine->set_default_submission(engine);
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+ }
}
/**
@@ -1829,7 +1831,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return -ENODEV;
spin_lock_irqsave(&engine->stats.lock, flags);
@@ -1890,7 +1892,7 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return;
spin_lock_irqsave(&engine->stats.lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+ engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 479f880c0f2f..b811f7cddd7e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1983,6 +1983,8 @@ intel_engine_setup_execlist(struct intel_engine_cs
*engine)
I am seeing intel_engine_init_execlist function in drm-tip. and that
will get called for < gen 8 too so this
may not be right place. Setting it in logical_ring_setup and clearing in
intel_init_ring_buffer is more clearer I guess.
execlists->queue = RB_ROOT;
execlists->first = NULL;
+
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index
[Intel-gfx] ✓ Fi.CI.IGT: success for Simplify hunting for drm card sysfs root
== Series Details == Series: Simplify hunting for drm card sysfs root URL : https://patchwork.freedesktop.org/series/34559/ State : success == Summary == Blacklisted hosts: shard-hswtotal:2661 pass:1524 dwarn:11 dfail:0 fail:10 skip:1116 time:9265s shard-kbltotal:2325 pass:1553 dwarn:19 dfail:15 fail:13 skip:716 time:8743s shard-snbtotal:2508 pass:1216 dwarn:15 dfail:7 fail:5 skip:1260 time:7103s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_560/shards.html ___ 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/i915: follow single notation for workaround number
== Series Details == Series: series starting with [1/2] drm/i915: follow single notation for workaround number URL : https://patchwork.freedesktop.org/series/34563/ State : success == Summary == Blacklisted hosts: shard-apltotal:2436 pass:1501 dwarn:22 dfail:16 fail:13 skip:877 time:11059s shard-hswtotal:2635 pass:1515 dwarn:9 dfail:0 fail:10 skip:1100 time:8893s shard-kbltotal:2414 pass:1604 dwarn:23 dfail:12 fail:15 skip:753 time:9101s shard-snbtotal:2583 pass:1248 dwarn:18 dfail:5 fail:7 skip:1302 time:7832s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7330/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags
From: Tvrtko Ursulin
Will be adding a new per-engine flags shortly so it makes sense
to consolidate.
v2: Keep the original code flow in intel_engine_cleanup_cmd_parser.
(Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Reviewed-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 7 ---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 8 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index b11629beeb63..ccb5ba043b63 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -26,6 +26,7 @@
*/
#include "i915_drv.h"
+#include "intel_ringbuffer.h"
/**
* DOC: batch buffer command parser
@@ -940,7 +941,7 @@ void intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
return;
}
- engine->needs_cmd_parser = true;
+ engine->flags |= I915_ENGINE_NEEDS_CMD_PARSER;
}
/**
@@ -952,7 +953,7 @@ void intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
*/
void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine)
{
- if (!engine->needs_cmd_parser)
+ if (!intel_engine_needs_cmd_parser(engine))
return;
fini_hash_table(engine);
@@ -1350,7 +1351,7 @@ int i915_cmd_parser_get_version(struct drm_i915_private
*dev_priv)
/* If the command parser is not enabled, report 0 - unsupported */
for_each_engine(engine, dev_priv, id) {
- if (engine->needs_cmd_parser) {
+ if (intel_engine_needs_cmd_parser(engine)) {
active = true;
break;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 14d9e61a1e06..70ccd63cbf8e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -271,7 +271,7 @@ static inline u64 gen8_noncanonical_addr(u64 address)
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
- return eb->engine->needs_cmd_parser && eb->batch_len;
+ return intel_engine_needs_cmd_parser(eb->engine) && eb->batch_len;
}
static int eb_create(struct i915_execbuffer *eb)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0f38d7b43f31..a91ce63b88b6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -539,7 +539,8 @@ struct intel_engine_cs {
struct intel_engine_hangcheck hangcheck;
- bool needs_cmd_parser;
+#define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)
+ unsigned int flags;
/*
* Table of commands the command parser needs to know about
@@ -598,6 +599,11 @@ struct intel_engine_cs {
} stats;
};
+static inline bool intel_engine_needs_cmd_parser(struct intel_engine_cs
*engine)
+{
+ return engine->flags & I915_ENGINE_NEEDS_CMD_PARSER;
+}
+
static inline void
execlists_set_active(struct intel_engine_execlists *execlists,
unsigned int bit)
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/i915: Consolidate checks for engine stats availability
From: Tvrtko Ursulin
Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.
My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.
v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
(Chris Wilson)
v5: Move flag setting to logical_ring_setup.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Sagar Arun Kamble
Cc: Sagar Arun Kamble
Reviewed-by: Chris Wilson (v2)
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
5 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c0ee9d68b04..e8e2faf4982f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event
*event)
return config_enabled_bit(event->attr.config);
}
-static bool supports_busy_stats(struct drm_i915_private *i915)
-{
- return INTEL_GEN(i915) >= 8;
-}
-
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
*/
- else if (supports_busy_stats(i915))
+ else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
{
- return supports_busy_stats(engine->i915) &&
+ return intel_engine_supports_stats(engine) &&
(engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index fede62daf3e1..3143b8ed7a0c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1561,8 +1561,10 @@ void intel_engines_reset_default_submission(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
- for_each_engine(engine, i915, id)
+ for_each_engine(engine, i915, id) {
engine->set_default_submission(engine);
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+ }
}
/**
@@ -1863,7 +1865,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return -ENODEV;
spin_lock_irqsave(&engine->stats.lock, flags);
@@ -1924,7 +1926,7 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return;
spin_lock_irqsave(&engine->stats.lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+ engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 570864583e28..904d9f821c2f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1963,6 +1963,8 @@ logical_ring_setup(struct intel_engine_cs *engine)
/* Intentionally left blank. */
engine->buffer = NULL;
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
RING_ELSP(engine),
FW_REG_WRITE);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a91ce63b88b6..c68ab3ead83c 100644
--- a/drivers/gpu/drm/i915/in
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: apply Display WA #1178 to fix type C dongles
== Series Details == Series: drm/i915/cnl: apply Display WA #1178 to fix type C dongles URL : https://patchwork.freedesktop.org/series/34566/ State : success == Summary == Blacklisted hosts: shard-apltotal:2458 pass:1522 dwarn:23 dfail:16 fail:13 skip:877 time:11304s shard-hswtotal:2635 pass:1512 dwarn:9 dfail:0 fail:10 skip:1103 time:8851s shard-kbltotal:2394 pass:1584 dwarn:24 dfail:10 fail:16 skip:754 time:8972s shard-snbtotal:2575 pass:1252 dwarn:16 dfail:4 fail:6 skip:1294 time:7719s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7331/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/2] drm/i915: Consolidate checks for engine stats availability
On Wed, 2017-11-29 at 08:24 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Sagar noticed the check can be consolidated between the engine stats > implementation and the PMU. > > My first choice was a static inline helper but that got into include > ordering mess quickly fast so I went with a macro instead. At some point > we should perhaps looking into taking out the non-ringubffer bits from > intel_ringbuffer.h into a new intel_engine.h or something. > > v2: Use engine->flags. (Chris Wilson) > v3: Rebase and mark GuC as not yet supported. (Chris Wilson) > v4: Move flag setting to intel_engines_reset_default_submission. > (Chris Wilson) > v5: Move flag setting to logical_ring_setup. > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Sagar Arun Kamble > Cc: Sagar Arun Kamble > Reviewed-by: Chris Wilson (v2) Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs
On 28/11/2017 21:39, Chris Wilson wrote:
Quoting Chris Wilson (2017-11-28 20:56:23)
Quoting Tvrtko Ursulin (2017-11-28 18:17:54)
On 20/11/2017 12:23, Lionel Landwerlin wrote:
This enables userspace to discover the engines available on the GPU.
Here is the layout on a Skylake GT4:
/sys/devices/pci:00/:00:02.0/drm/card0/gt
On this one I think Joonas had a concern that it is difficult for
userspace to get to the sysfs root from the drm file descriptor.
Lionel pointed out that for master nodes it is quite easy:
fstat(fd, &st);
sprintf(sysfs_root, "/sys/dev/char/%u:%u", major(st.st_rdev),
minor(st.st_rdev));
For render nodes it is trickier in a way that they would have to
additional resolve an unknown master drm card number. For instance:
/sys/dev/char/%u:%u/device/drm/cardX
Where the "X" is unknown.
But, is it even an use case for render nodes to try and get to the
sysfs root of the master card? Are they allowed to do so?
Yes. Mesa uses render nodes, and mesa needs the topology for its
performance monitoring api.
So /sys/dev/char/226:128/ does not link to /sys/dev/char/226:0/. Maybe
we should just add a card symlink from each minor back to our sysfs
root? That seems doable.
Then we just need open("/sys/dev/char/%u:%u/card");
There is a link via what I wrote above -
"/sys/dev/char/%u:%u/device/drm/cardX", but the "X" part is cumbersome.
Adding a link with a constant name would indeed be better, but I wasn't
sure if it is conceptually allowed and even forgot to mention it.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_sysfs: igt_sysfs_path only works for master nodes
On 28/11/2017 20:52, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-11-28 18:09:56) From: Tvrtko Ursulin DRM code defines the minor range for master nodes as 0-63, so express that explicitly near the top of the function. We do use rendernodes, so we had better support them correctly. I thought the premise of /sys/dev/char/$maj:$min/ was that it would work with render as well as master nodes. It's doable, but since the current code does not support them I did not feel the responsibility to extend the functionality in that way. Regards, Tvrtko ___ 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/guc: Update default GuC FW for SKL/BXT/KBL
== Series Details == Series: drm/i915/guc: Update default GuC FW for SKL/BXT/KBL URL : https://patchwork.freedesktop.org/series/34590/ State : success == Summary == Blacklisted hosts: shard-apltotal:2436 pass:1501 dwarn:22 dfail:16 fail:13 skip:877 time:10965s shard-hswtotal:2635 pass:1515 dwarn:9 dfail:0 fail:10 skip:1100 time:8840s shard-kbltotal:2396 pass:1589 dwarn:21 dfail:12 fail:14 skip:752 time:8951s shard-snbtotal:2569 pass:1244 dwarn:16 dfail:6 fail:6 skip:1294 time:7325s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7332/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [QUERY] How many CI mails is too many?
On Tue, Nov 28, 2017 at 01:16:50PM +0200, Arkadiusz Hiler wrote: > On Mon, Nov 27, 2017 at 09:10:37PM +0530, Sagar Arun Kamble wrote: > > I feel we generally tend to ignore the results mails for series that > > we are not actively involved on (although we might be interested in > > series itself). Also if number of revisions some series can undergo is > > high, this tendency can grow. > > It is true that I don't care that much about results tied to series I am > not interested in, but I don't find this too distracting. They are > nested nicely in the thread and are also very easy to distinguish > visually. > > > How about the option of sending the results mails to only author and > > all committers. Ideally, author should include at lease one committer > > and in that case we can possibly avoid mail to all committers. I had the same idea but then I thought that sometimes if I want to apply some series of patches I would like to know what is a status of that patch (fail or not) so maybe sending that to author only can be not really good idea. -Ewelina > > > > Another option would be no results mails at all and enforce authors to > > ensure all green at > > https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated > > > > Thanks > > Sagar > > In my mind the CI system should complement mailing list, not change it > or require unnecessary, external interactions. By sending the result to > intel-gfx we get the gist of the results here, with the direct links to > the patchwork and intel-gfx-ci grids provided (so no need to hunt for > those). > > The results also stores nicely in the online mailing list archives if we > send it to the intel-gfx@fdo. > > Searchability and easy categorization is an added bonus if you subscribe > to dozen or so mailing lists. > > Cheers, > Arek > > > On 11/27/2017 8:24 PM, Arkadiusz Hiler wrote: > > > Hey all, > > > > > > For some time already CI sends out 1-2 mails per series per (re)run, i.e. > > > BAT > > > results and "full IGT" results (if BAT has not failed). > > > > > > Recently we have added 32bit build check, and if that fails it sends out > > > additional mail In-Reply-To the series. > > > > > > I am working on adding some static checks to the CI (spare and checkpatch > > > at the > > > moment, more may come in the future), which may generate even more > > > commotion on > > > the mailing list. > > > > > > How much of CI noise is too much and how you would like to have the > > > results > > > grouped? > > > > > > Couple of options to start the discussion: > > > > > > 1. Group all static checks (and the 32bit build?) into one mail: > > > - just one additional mail, > > > - may be hard to read in case of catastrophic failure, > > > - we can send it only when something actually fails. > > > > > > 2. Send out the results as a part of BAT results: > > > - even less noise than (1), > > > - BAT results already feel cluttered, this may decrease readability. > > > > > > 3. Have each check as a separate mail, but send it only if the check > > > fails: > > > - noisy: may result in many mails, depending how many checks fail, > > > - easier to read and easier to follow on patchwork. > > > > > > Any opinions? Any other ideas? > ___ > 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
[Intel-gfx] [PATCH v6 2/2] drm/i915: Consolidate checks for engine stats availability
From: Tvrtko Ursulin
Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.
My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.
v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
(Chris Wilson)
v5: Move flag setting to logical_ring_setup.
v6: intel_engines_reset_default_submission is the wrong place to set the
flag - it needs to be in execlists_set_default_submission. (Sagar)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Sagar Arun Kamble
Cc: Sagar Arun Kamble
Reviewed-by: Chris Wilson (v2)
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 4
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
5 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c0ee9d68b04..e8e2faf4982f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event
*event)
return config_enabled_bit(event->attr.config);
}
-static bool supports_busy_stats(struct drm_i915_private *i915)
-{
- return INTEL_GEN(i915) >= 8;
-}
-
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
*/
- else if (supports_busy_stats(i915))
+ else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
{
- return supports_busy_stats(engine->i915) &&
+ return intel_engine_supports_stats(engine) &&
(engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index fede62daf3e1..cffd0c812b7e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1863,7 +1863,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return -ENODEV;
spin_lock_irqsave(&engine->stats.lock, flags);
@@ -1924,7 +1924,7 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return;
spin_lock_irqsave(&engine->stats.lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+ engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 570864583e28..ef513e1c10f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1919,6 +1919,8 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->park = NULL;
engine->unpark = NULL;
+
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
}
static void
@@ -1963,6 +1965,8 @@ logical_ring_setup(struct intel_engine_cs *engine)
/* Intentionally left blank. */
engine->buffer = NULL;
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
RING_ELSP(engine),
FW_REG_WRITE);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a91ce63b88b6..c68ab3ead83c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Consolidate checks for engine stats availability
On 11/29/2017 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.
My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.
v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
(Chris Wilson)
v5: Move flag setting to logical_ring_setup.
v6: intel_engines_reset_default_submission is the wrong place to set the
flag - it needs to be in execlists_set_default_submission. (Sagar)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Sagar Arun Kamble
Cc: Sagar Arun Kamble
Reviewed-by: Chris Wilson (v2)
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 4
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
5 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c0ee9d68b04..e8e2faf4982f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event
*event)
return config_enabled_bit(event->attr.config);
}
-static bool supports_busy_stats(struct drm_i915_private *i915)
-{
- return INTEL_GEN(i915) >= 8;
-}
-
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
*/
- else if (supports_busy_stats(i915))
+ else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
{
- return supports_busy_stats(engine->i915) &&
+ return intel_engine_supports_stats(engine) &&
(engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index fede62daf3e1..cffd0c812b7e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1863,7 +1863,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return -ENODEV;
spin_lock_irqsave(&engine->stats.lock, flags);
@@ -1924,7 +1924,7 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return;
spin_lock_irqsave(&engine->stats.lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+ engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 570864583e28..ef513e1c10f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1919,6 +1919,8 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->park = NULL;
engine->unpark = NULL;
+
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
}
static void
@@ -1963,6 +1965,8 @@ logical_ring_setup(struct intel_engine_cs *engine)
/* Intentionally left blank. */
engine->buffer = NULL;
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
RING_ELSP(engine),
FW_REG_WRITE);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"
== Series Details == Series: Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" URL : https://patchwork.freedesktop.org/series/34592/ State : success == Summary == Series 34592v1 Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" https://patchwork.freedesktop.org/api/1.0/series/34592/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:387s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:514s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:506s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:504s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:490s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:470s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:288 pass:178 dwarn:1 dfail:0 fail:1 skip:108 time:266s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:372s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:257s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:435s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:482s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:528s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:447s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:544s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:517s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:507s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:443s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:548s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:412s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:598s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:548s c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest f3a0a1dcb11a Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] lockdep: finer-grained completion key for kthread
Ideally we'd create the key through a macro at the real callers and
pass it all the way down. This would give us better coverage for cases
where a bunch of kthreads are created for the same thing.
But this gets the job done meanwhile and unblocks our CI. Refining
later on is always possible.
v2:
- make it compile
- use the right map (Tvrtko)
v3:
lockdep insist on a static key, so the cheap way didn't work. Wire
2 keys through all the callers.
I didn't extend this up to alloc_workqueue because the
lockdep_invariant_state() call should separate the work functions from
the workqueue kthread logic and prevent cross-release state from
leaking between unrelated work queues that happen to reuse the same
kthreads.
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter
---
include/linux/kthread.h | 48 -
kernel/kthread.c| 70 ++---
2 files changed, 90 insertions(+), 28 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..3763a9657928 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
#include
#include
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
void *data,
int node,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
/**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int
(*threadfn)(void *data),
*/
#define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_node(threadfn, data, node, &__exited_key,\
+ &__parked_key, namefmt, ##arg); \
+})
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
void *data,
unsigned int cpu,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+ &__parked_key, namefmt); \
+})
+
/**
* kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
int kthread_worker_fn(void *worker_ptr);
-__printf(2, 3)
+__printf(4, 5)
struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
+ const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)
\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker(flags, &__exited_key, &__parked_key, \
+ ##namefmt); \
+})
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker(cpu, flags, &__exited_key, &__parked_key,\
+ ##namefmt); \
+})
bool kthread_queue_work(struct kthread_worker *worker,
struct kthread_work *work);
d
[Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
cross-release ftl
From Chris:
"Fwiw, this isn't cross-release but us reloading the module many times,
creating a whole host of new lockclasses. Even more fun is when the
module gets a slightly different address and the new lock address hashes
into an old lock...
"I did think about a module-hook to revoke the stale lockclasses, but
that still leaves all the hashed chains.
"This particular nuisance was temporarily pushed back by teaching igt not
to reload i915.ko on a whim."
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter
---
kernel/locking/lockdep_internals.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep_internals.h
b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
#else
#define MAX_LOCKDEP_ENTRIES32768UL
-#define MAX_LOCKDEP_CHAINS_BITS16
+#define MAX_LOCKDEP_CHAINS_BITS17
/*
* Stack-trace: tightly packed array of stack backtrace
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [QUERY] How many CI mails is too many?
Quoting Chris Wilson (2017-11-28 10:16:17) > Quoting Daniel Vetter (2017-11-28 10:08:56) > > On Tue, Nov 28, 2017 at 11:06 AM, Chris Wilson > > wrote: > > > Quoting Joonas Lahtinen (2017-11-28 08:15:13) > > >> On Mon, 2017-11-27 at 16:54 +0200, Arkadiusz Hiler wrote: > > >> > Hey all, > > >> > > > >> > For some time already CI sends out 1-2 mails per series per (re)run, > > >> > i.e. BAT > > >> > results and "full IGT" results (if BAT has not failed). > > >> > > > >> > Recently we have added 32bit build check, and if that fails it sends > > >> > out > > >> > additional mail In-Reply-To the series. > > >> > > > >> > I am working on adding some static checks to the CI (spare and > > >> > checkpatch at the > > >> > moment, more may come in the future), which may generate even more > > >> > commotion on > > >> > the mailing list. > > >> > > > >> > How much of CI noise is too much and how you would like to have the > > >> > results > > >> > grouped? > > >> > > > >> > Couple of options to start the discussion: > > >> > > > >> > 1. Group all static checks (and the 32bit build?) into one mail: > > >> > - just one additional mail, > > >> > - may be hard to read in case of catastrophic failure, > > >> > - we can send it only when something actually fails. > > >> > > > >> > 2. Send out the results as a part of BAT results: > > >> > - even less noise than (1), > > >> > - BAT results already feel cluttered, this may decrease > > >> > readability. > > >> > > > >> > 3. Have each check as a separate mail, but send it only if the check > > >> > fails: > > >> > - noisy: may result in many mails, depending how many checks fail, > > >> > - easier to read and easier to follow on patchwork. > > >> > > >> The best user experience I could think of; > > >> > > >> 1. If all CI checks succeed, delay and only send one mail with all the > > >> results. This would indicate it's good to merge, go do it. > > >> 2. When a CI checks fail, immediately send that out so the developer > > >> gets to work on the fix. > > >> > > >> Above requires that all the checks complete rather quickly and a trust > > >> is gained to the system so that the absence of e-mail always means the > > >> series is doing good, not that the system is clogged in some way :) > > > > > > Or just 2. The first being the compilation report; saying we > > > have received your patch and it compiles fine, it will be queued to the > > > farm currently in slot N (or it doesn't even compile!). The second being > > > the success or failure of the CI run. > > > > > > From the user pov, we can't do anything until the CI report so > > > intermediate emails saying congrats are just fluff. Useful simply to > > > know the patch hasn't fall out of the system, but not supplying any > > > actionable information. > > > > BAT was meant to be that mail, with the added benefit that if a series > > fails the basic sanity check you can ignore it for review and > > everything. Still not quite there yet (and the recently undone change > > of ratelimiting didn't help). > > The compile check should take 30s(?) on the build host with all the > distcc/ccache. It's going to be rare to develop a long queue and > significant latency; whereas one developer can flood the system with 5 > different series they happen to have queued, repeat for everyone getting > to work in the morning. One thing I forgot to mention, is that trybot has a large latency for that single BAT success email. Having a quick "patch received; compiles" response from the system would give a nice bit of reassurance. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.
On Wed, Nov 22, 2017 at 03:05:55PM -0800, Anusha Srivatsa wrote:
> From: Joseph Garvey
>
> Test that horizontal flip works with supported rotations. Includes
> a fix for the unrotated fb which was not being positioned correctly
> with portrait and landscape rectangles.
>
> v2:(from Anusha)
> - Change 180 degree rotation to follow the rest, use
> igt_swap(), make flip variable a bool. Format the
> patch correctly (Ville, Petri Latvala)
>
> v3: (From Anusha)
> - Correct the name of subtests in order to avoid duplication
> of names (Arek)
>
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Joseph Garvey
> Cc: Ville Syrjälä
> Cc: Petri Latvala
> Cc: Arkadiusz Hiler
> ---
> lib/igt_kms.c| 2 +-
> lib/igt_kms.h| 5 ++
> tests/kms_rotation_crc.c | 198
> +--
> 3 files changed, 164 insertions(+), 41 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index a572fc6..3034e44 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -3050,7 +3050,7 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
> *plane,
>
> static const char *rotation_name(igt_rotation_t rotation)
> {
> - switch (rotation) {
> + switch (rotation & IGT_ROTATION_MASK) {
> case IGT_ROTATION_0:
> return "0°";
> case IGT_ROTATION_90:
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 8dc118c..b83a828 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -281,8 +281,13 @@ typedef enum {
> IGT_ROTATION_90 = 1 << 1,
> IGT_ROTATION_180 = 1 << 2,
> IGT_ROTATION_270 = 1 << 3,
> + IGT_REFLECT_X= 1 << 4,
> + IGT_REFLECT_Y= 1 << 5,
> } igt_rotation_t;
>
> +#define IGT_ROTATION_MASK \
> + (IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 | IGT_ROTATION_270)
> +
> typedef struct {
> /*< private >*/
> igt_pipe_t *pipe;
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 5aec8fa..9e13667 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -32,6 +32,7 @@ typedef struct {
> igt_display_t display;
> struct igt_fb fb;
> struct igt_fb fb_reference;
> + struct igt_fb fb_unrotated;
> struct igt_fb fb_modeset;
> struct igt_fb fb_flip;
> igt_crc_t ref_crc;
> @@ -43,8 +44,59 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> bool flips;
> + int devid;
> } data_t;
>
> +typedef struct {
> + float r;
> + float g;
> + float b;
> +} rgb_color_t;
> +
> +static void set_color(rgb_color_t *color, float r, float g, float b)
> +{
> + color->r = r;
> + color->g = g;
> + color->b = b;
> +}
> +
> +static void rotate_colors(rgb_color_t *tl, rgb_color_t *tr, rgb_color_t *br,
> + rgb_color_t *bl, igt_rotation_t rotation)
> +{
> + rgb_color_t bl_tmp, br_tmp, tl_tmp, tr_tmp;
> +
> + if (rotation & IGT_REFLECT_X) {
> + igt_swap(*tl, *tr);
> + igt_swap(*bl, *br);
> + }
> +
> + if (rotation & IGT_ROTATION_90) {
> + bl_tmp = *bl;
> + br_tmp = *br;
> + tl_tmp = *tl;
> + tr_tmp = *tr;
> + *tl = tr_tmp;
> + *bl = tl_tmp;
> + *tr = br_tmp;
> + *br = bl_tmp;
> + } else if (rotation & IGT_ROTATION_180) {
> + igt_swap(*tl, *br);
> + igt_swap(*tr, *bl);
> + } else if (rotation & IGT_ROTATION_270) {
> + bl_tmp = *bl;
> + br_tmp = *br;
> + tl_tmp = *tl;
> + tr_tmp = *tr;
> + *tl = bl_tmp;
> + *bl = br_tmp;
> + *tr = tl_tmp;
> + *br = tr_tmp;
> + }
> +}
> +
> +#define RGB_COLOR(color) \
> + color.r, color.g, color.b
> +
> static void
> paint_squares(data_t *data, igt_rotation_t rotation,
> struct igt_fb *fb, float o)
> @@ -52,35 +104,21 @@ paint_squares(data_t *data, igt_rotation_t rotation,
> cairo_t *cr;
> unsigned int w = fb->width;
> unsigned int h = fb->height;
> + rgb_color_t tl, tr, bl, br;
>
> cr = igt_get_cairo_ctx(data->gfx_fd, fb);
>
> - if (rotation == IGT_ROTATION_180) {
> - cairo_translate(cr, w, h);
> - cairo_rotate(cr, M_PI);
> - }
> + set_color(&tl, o, 0.0f, 0.0f);
> + set_color(&tr, 0.0f, o, 0.0f);
> + set_color(&br, o, o, o);
> + set_color(&bl, 0.0f, 0.0f, o);
>
> - if (rotation == IGT_ROTATION_90) {
> - /* Paint 4 squares with width == height in Green, White,
> - Blue, Red Clockwise order to look like 270 degree rotated*/
> - igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, o, 0.0);
> - igt_paint_color(cr, w / 2, 0, w / 2, h / 2, o, o, o);
> - igt_paint_color(cr, 0, h / 2, w / 2, h / 2, o, 0.0, 0.0);
> - igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 0.0, o);
> - } else
Re: [Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
Quoting Daniel Vetter (2017-11-29 09:46:36) > cross-release ftl > > From Chris: > > "Fwiw, this isn't cross-release but us reloading the module many times, > creating a whole host of new lockclasses. Even more fun is when the > module gets a slightly different address and the new lock address hashes > into an old lock... > > "I did think about a module-hook to revoke the stale lockclasses, but > that still leaves all the hashed chains. > > "This particular nuisance was temporarily pushed back by teaching igt not > to reload i915.ko on a whim." > > Cc: Tvrtko Ursulin > Cc: Marta Lofstedt > References: https://bugs.freedesktop.org/show_bug.cgi?id=103707 > Signed-off-by: Daniel Vetter Yes, I think we need to carry this for CI. cross-release will add many more chains, and since we already exhausted the previous array we will need more (and just reducing the number of module reloads only gives a temporary respite). Doubling the array doesn't seem like it'll buy us much time though? Could we afford 20 bits? Might we not also need to expand the lockclasses array? That we could just double? In principle acked-by for core-for-CI, I think we need a bit surer ground before saying that in general lockdep needs a larger array. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 0/7] drm/fbdev: Panel orientation connector property support
On Tue, Nov 28, 2017 at 02:36:09PM +0100, Hans de Goede wrote: > Hi, > > On 28-11-17 11:27, Daniel Vetter wrote: > > On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote: > > > Hi All, > > > > > > Here is v6 of my series to add a "panel orientation" property to > > > the drm-connector for the LCD panel to let userspace know about LCD > > > panels which are not mounted upright, as well as detecting upside-down > > > panels without needing quirks (like we do for 90 degree rotated screens). > > > > > > Bartlomiej, can we please have your Acked-by for merging patches 1, > > > 6 and 7 through the drm tree? > > > > > > New in v6: > > > -Fix / reference kernel-doc comments > > > -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI > > > -Move i915 dsi hardware rotation state read-out to intel_dsi_init() > > > > > > New in v5: > > > -Add kernel-doc comment documenting drm_get_panel_orientation_quirk() > > > -drm_fb_helper: Only use hardware (crtc primary plane) rotation for > > > 180 degrees for now as 9-/270 degrees rotation requires special handling > > > > > > New in v4: > > > -Fix drm_fb_helper code setting an invalid rotation value on the primary > > > plane of disabled/unused crtcs (caught by Fi.CI) > > > > > > New in v3: > > > -As requested by Daniel v3 moves the quirks over from the fbdev > > > subsys to the drm subsys. I've done this by simpy starting with a copy > > > of > > > the quirk table and eventually removing the fbdev version. > > > > > > The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5 > > > are all drm patches and patches 6-7 are fbdev/fbcon patches again. As > > > discussed previously the plan is to merge all 7 patches through the > > > drm tree. > > > > I think from the drm and i915 side of things this all looks ready (well > > pls double-check that CI also approves before merging). > > The CI says state is warning, see: > https://patchwork.freedesktop.org/series/32447/ > and specifically: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7290/shards.html > > Which I find hard to read as I see no tests going to orange, only > 3 tests moving to red, which AFAICT is failed. Clicking on the tests > link to get history all 3 tests seem to fail in the same way quite > often (2 out of 3) or somewhat often (the last one). Also the failures > seem unrelated to my changes > > So how do I deal with this, resend v7 to get CI to run again and hope > I get a success result for all tests this time ? -rc1 set CI on fire, we had to entirely disable reporting shard results. Note that in the mail report you get annotations of known bugs, and the skip<->pass flip-floppers are fallout from CI being on fire. So looks all good to go. -Daniel > > > Just needs an ack/review from Bart, and then it's probably simplest if you > > merge it all through drm-misc - the i915 side is tiny. > > Ok, I will wait for an Ack from Bart and then merge this through drm-misc, > thank you for the review. > > Regards, > > Hans > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev4)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev4) URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Series 34354v4 series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags https://patchwork.freedesktop.org/api/1.0/series/34354/revisions/4/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:447s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:520s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:506s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:484s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:474s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:420s fi-gdg-551 total:288 pass:179 dwarn:1 dfail:0 fail:0 skip:108 time:272s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:356s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:257s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:429s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:478s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:529s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:477s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:589s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:448s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:541s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:517s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:510s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:452s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:550s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:419s Blacklisted hosts: fi-cfl-s2total:288 pass:254 dwarn:8 dfail:0 fail:0 skip:26 time:621s fi-cnl-y total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:24 c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest 23fae9483e08 drm/i915: Consolidate checks for engine stats availability caf6e484864c drm/i915: Move engine->needs_cmd_parser to engine->flags == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7334/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
Quoting Chris Wilson (2017-11-29 09:57:14) > Quoting Daniel Vetter (2017-11-29 09:46:36) > > cross-release ftl > > > > From Chris: > > > > "Fwiw, this isn't cross-release but us reloading the module many times, > > creating a whole host of new lockclasses. Even more fun is when the > > module gets a slightly different address and the new lock address hashes > > into an old lock... > > > > "I did think about a module-hook to revoke the stale lockclasses, but > > that still leaves all the hashed chains. > > > > "This particular nuisance was temporarily pushed back by teaching igt not > > to reload i915.ko on a whim." > > > > Cc: Tvrtko Ursulin > > Cc: Marta Lofstedt > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103707 > > Signed-off-by: Daniel Vetter > > In principle acked-by for core-for-CI, I think we need a bit surer > ground before saying that in general lockdep needs a larger array. For upstreaming, I wonder if we could sell them on a kconfig? That way Tomi could adjust it more easily in his kconfig.git than having us provide a patch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unifying debugfs return codes for unsupported features
On 11/28/2017 9:12 PM, Michal Wajdeczko wrote:
Instead of trying different seq_puts messages, lets use common
-ENODEV error code to indicate missing/unsupported feature.
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
Cc: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/i915_debugfs.c | 47 ++---
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2829447..5023acd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1635,10 +1635,8 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- if (!HAS_FBC(dev_priv)) {
- seq_puts(m, "FBC unsupported on this chipset\n");
- return 0;
- }
+ if (!HAS_FBC(dev_priv))
+ return -ENODEV;
intel_runtime_pm_get(dev_priv);
mutex_lock(&dev_priv->fbc.lock);
@@ -1714,10 +1712,8 @@ static int i915_ips_status(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- if (!HAS_IPS(dev_priv)) {
- seq_puts(m, "not supported\n");
- return 0;
- }
+ if (!HAS_IPS(dev_priv))
+ return -ENODEV;
intel_runtime_pm_get(dev_priv);
@@ -1803,10 +1799,8 @@ static int i915_ring_freq_table(struct seq_file *m, void *unused)
int gpu_freq, ia_freq;
unsigned int max_gpu_freq, min_gpu_freq;
- if (!HAS_LLC(dev_priv)) {
- seq_puts(m, "unsupported on this chipset\n");
- return 0;
- }
+ if (!HAS_LLC(dev_priv))
+ return -ENODEV;
intel_runtime_pm_get(dev_priv);
@@ -2287,7 +2281,7 @@ static int i915_huc_load_status_info(struct seq_file *m, void *data)
struct drm_printer p;
if (!HAS_HUC_UCODE(dev_priv))
- return 0;
+ return -ENODEV;
p = drm_seq_file_printer(m);
intel_uc_fw_dump(&dev_priv->huc.fw, &p);
@@ -2305,8 +2299,8 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
struct drm_printer p;
u32 tmp, i;
- if (!HAS_GUC_UCODE(dev_priv))
- return 0;
+ if (!HAS_GUC(dev_priv))
+ return -ENODEV;
p = drm_seq_file_printer(m);
intel_uc_fw_dump(&dev_priv->guc.fw, &p);
@@ -2400,6 +2394,9 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = &dev_priv->guc;
+ if (!HAS_GUC(dev_priv))
+ return -ENODEV;
+
if (!check_guc_submission(m))
Should this function check_guc_submission be updated in this patch with
proper message now?
Should we add HAS_GUC check to i915_guc_log_control_get as well?
return 0;
@@ -2428,6 +2425,9 @@ static int i915_guc_stage_pool(struct seq_file *m, void *data)
unsigned int tmp;
int index;
+ if (!HAS_GUC(dev_priv))
+ return -ENODEV;
+
if (!check_guc_submission(m))
return 0;
@@ -2482,6 +2482,9 @@ static int i915_guc_log_dump(struct seq_file *m, void *data)
u32 *log;
int i = 0;
+ if (!HAS_GUC(dev_priv))
+ return -ENODEV;
+
if (dump_load_err)
obj = dev_priv->guc.load_err_log;
else if (dev_priv->guc.log.vma)
@@ -2576,10 +2579,8 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
enum pipe pipe;
bool enabled = false;
- if (!HAS_PSR(dev_priv)) {
- seq_puts(m, "PSR not supported\n");
- return 0;
- }
+ if (!HAS_PSR(dev_priv))
+ return -ENODEV;
intel_runtime_pm_get(dev_priv);
@@ -2818,10 +2819,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_csr *csr;
- if (!HAS_CSR(dev_priv)) {
- seq_puts(m, "not supported\n");
- return 0;
- }
+ if (!HAS_CSR(dev_priv))
+ return -ENODEV;
csr = &dev_priv->csr;
@@ -3357,7 +3356,7 @@ static int i915_ddb_info(struct seq_file *m, void *unused)
int plane;
if (INTEL_GEN(dev_priv) < 9)
- return 0;
+ return -ENODEV;
drm_modeset_lock_all(dev);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] lockdep: finer-grained completion key for kthread
== Series Details == Series: series starting with [1/2] lockdep: finer-grained completion key for kthread URL : https://patchwork.freedesktop.org/series/34603/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh DESCEND objtool CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/thermal/intel_powerclamp.o In file included from drivers/thermal/intel_powerclamp.c:45:0: drivers/thermal/intel_powerclamp.c: In function ‘start_power_clamp_worker’: ./include/linux/kthread.h:212:52: error: passing argument 4 of ‘_kthread_create_worker’ from incompatible pointer type [-Werror=incompatible-pointer-types] _kthread_create_worker(cpu, flags, &__exited_key, &__parked_key,\ ^ drivers/thermal/intel_powerclamp.c:497:11: note: in expansion of macro ‘kthread_create_worker_on_cpu’ worker = kthread_create_worker_on_cpu(cpu, 0, "kidle_inject/%ld", cpu); ^~~~ ./include/linux/kthread.h:193:1: note: expected ‘const char *’ but argument is of type ‘struct lock_class_key *’ _kthread_create_worker(unsigned int flags, ^~ cc1: some warnings being treated as errors scripts/Makefile.build:316: recipe for target 'drivers/thermal/intel_powerclamp.o' failed make[2]: *** [drivers/thermal/intel_powerclamp.o] Error 1 scripts/Makefile.build:569: recipe for target 'drivers/thermal' failed make[1]: *** [drivers/thermal] Error 2 Makefile:1012: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Consolidate checks for engine stats availability
Quoting Tvrtko Ursulin (2017-11-29 09:27:56) > From: Tvrtko Ursulin > > Sagar noticed the check can be consolidated between the engine stats > implementation and the PMU. > > My first choice was a static inline helper but that got into include > ordering mess quickly fast so I went with a macro instead. At some point > we should perhaps looking into taking out the non-ringubffer bits from > intel_ringbuffer.h into a new intel_engine.h or something. > > v2: Use engine->flags. (Chris Wilson) > v3: Rebase and mark GuC as not yet supported. (Chris Wilson) > v4: Move flag setting to intel_engines_reset_default_submission. > (Chris Wilson) > v5: Move flag setting to logical_ring_setup. > v6: intel_engines_reset_default_submission is the wrong place to set the > flag - it needs to be in execlists_set_default_submission. (Sagar) > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Sagar Arun Kamble > Cc: Sagar Arun Kamble > Reviewed-by: Chris Wilson (v2) > --- > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 570864583e28..ef513e1c10f3 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1919,6 +1919,8 @@ static void execlists_set_default_submission(struct > intel_engine_cs *engine) > > engine->park = NULL; > engine->unpark = NULL; > + > + engine->flags |= I915_ENGINE_SUPPORTS_STATS; > } > > static void > @@ -1963,6 +1965,8 @@ logical_ring_setup(struct intel_engine_cs *engine) > /* Intentionally left blank. */ > engine->buffer = NULL; > > + engine->flags |= I915_ENGINE_SUPPORTS_STATS; Now that you've added it to execlists_set_default_submission, you can remove the flag from here, as it will be set by the call from intel_engine_init_common(). Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
On Wed, Nov 29, 2017 at 10:01:09AM +, Chris Wilson wrote: > Quoting Chris Wilson (2017-11-29 09:57:14) > > Quoting Daniel Vetter (2017-11-29 09:46:36) > > > cross-release ftl > > > > > > From Chris: > > > > > > "Fwiw, this isn't cross-release but us reloading the module many times, > > > creating a whole host of new lockclasses. Even more fun is when the > > > module gets a slightly different address and the new lock address hashes > > > into an old lock... > > > > > > "I did think about a module-hook to revoke the stale lockclasses, but > > > that still leaves all the hashed chains. > > > > > > "This particular nuisance was temporarily pushed back by teaching igt not > > > to reload i915.ko on a whim." > > > > > > Cc: Tvrtko Ursulin > > > Cc: Marta Lofstedt > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103707 > > > Signed-off-by: Daniel Vetter > > > > In principle acked-by for core-for-CI, I think we need a bit surer > > ground before saying that in general lockdep needs a larger array. > > For upstreaming, I wonder if we could sell them on a kconfig? That way > Tomi could adjust it more easily in his kconfig.git than having us > provide a patch. I'll submit both (once CI is taken care of) to lockdep folks and hear what they think about this issue. Maybe fixing module reload is already on their plans, maybe not. Same really for the kthread fix, lockdep code (and maintainers) are funky enough that I don't really dwell too much in there ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/2] drm/i915: Consolidate checks for engine stats availability
From: Tvrtko Ursulin
Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.
My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.
v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
(Chris Wilson)
v5: Move flag setting to logical_ring_setup.
v6: intel_engines_reset_default_submission is the wrong place to set the
flag - it needs to be in execlists_set_default_submission. (Sagar)
v7: Flag setting in logical_ring_setup is not required. (Chris)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Sagar Arun Kamble
Cc: Sagar Arun Kamble
Reviewed-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble (v6)
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c0ee9d68b04..e8e2faf4982f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event
*event)
return config_enabled_bit(event->attr.config);
}
-static bool supports_busy_stats(struct drm_i915_private *i915)
-{
- return INTEL_GEN(i915) >= 8;
-}
-
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
*/
- else if (supports_busy_stats(i915))
+ else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
{
- return supports_busy_stats(engine->i915) &&
+ return intel_engine_supports_stats(engine) &&
(engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index fede62daf3e1..cffd0c812b7e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1863,7 +1863,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return -ENODEV;
spin_lock_irqsave(&engine->stats.lock, flags);
@@ -1924,7 +1924,7 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
{
unsigned long flags;
- if (INTEL_GEN(engine->i915) < 8)
+ if (!intel_engine_supports_stats(engine))
return;
spin_lock_irqsave(&engine->stats.lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+ engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 570864583e28..2a8160f603ab 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1919,6 +1919,8 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->park = NULL;
engine->unpark = NULL;
+
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a91ce63b88b6..c68ab3ead83c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -540,6 +540,7 @@ struct intel_engine_cs {
struct intel_engine_hangcheck hangcheck;
#define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)
+#define I915_ENGINE_SUPPORTS_STATS BIT(1)
unsigned int flags;
/*
@@ -604,6 +605,11 @@ static inline boo
Re: [Intel-gfx] [PATCH i-g-t] i-g-t: kms_plane_scaling: Enhanced scaling tests
On Mon, Nov 27, 2017 at 09:20:33AM +, Srinivas, Vidya wrote:
>
>
> > -Original Message-
> > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Monday, November 27, 2017 2:47 PM
> > To: Srinivas, Vidya
> > Cc: intel-gfx
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] i-g-t: kms_plane_scaling: Enhanced
> > scaling tests
> >
> > Somehow I forgot to send out my irc feedback to the m-l.
> >
> > On Wed, Nov 22, 2017 at 9:15 AM, Vidya Srinivas
> > wrote:
> > > +igt_main
> > > {
> > > data_t data = {};
> > >
> > > @@ -308,11 +765,26 @@ igt_simple_main
> > > data.drm_fd = drm_open_driver(DRIVER_INTEL);
> > > igt_require_pipe_crc(data.drm_fd);
> > > igt_display_init(&data.display, data.drm_fd);
> > > + igt_require(data.display.is_atomic);
> > > data.devid = intel_get_drm_devid(data.drm_fd);
> > >
> > > data.num_scalers = intel_gen(data.devid) >= 9 ? 2 : 0;
> > >
> > > - test_plane_scaling(&data);
> > > -
> > > + //test_plane_scaling(&data);
You're commenting out the existing testcase ...
> > > + igt_subtest_f("scaler_with_pixel_format") {
> > > + test_scaler_with_pixel_format(&data);
> > > + }
> > > + igt_subtest_f("scaler_with_rotation") {
> > > + test_scaler_with_rotation(&data);
> > > + }
> > > + igt_subtest_f("scaler_with_multiple_planes") {
> > > + test_scaler_with_multiple_planes(&data);
> > > + }
> > > + igt_subtest_f("scaler_with_clipping_clamping") {
> > > + test_scaler_with_clipping_clamping_scenario(&data);
> > > + }
> > > + igt_subtest_f("scaler_with_multi_pipe_plane") {
> > > + test_scaler_with_multi_pipe_plane(&data);
> > > + }
> >
> > Commenting out the existing testcase and replacing it with new ones
> > entirely, without explaining what's wrong with the old one, or removing it
> > (we have git for source control, not comments), and how new tests are
> > better isn't how we do things. Presumably the existing tests once worked, so
> > the first step should be to fix that up first and explain why the changes
> > are
> > necessary. When this code was typed 2 years ago someone put some
> > thought into it, throwing all that work away isn't good.
> >
> > And _then_ (in follow-up patches) fix the gaps in test coverage.
> >
> > Thanks, Daniel
>
> Thank you. I think the explanation was missing. This test with format
> will enhance the existing cases. I will work on these and re-submit the same.
Which means it's not enhancing it, it's outright remove it and replacing
with something new. Either you need to show that the existing testcase is
totally broken (with a patch that removes it and explain why it's
unfixable).
Or (and that's really the preferred thing), patch 1 in this series fixes
up the existing test as the first step.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.
On 11/29/2017 6:31 AM, Yaodong Li wrote:
On 11/16/2017 08:00 PM, Sagar Arun Kamble wrote:
On 11/17/2017 3:17 AM, Michal Wajdeczko wrote:
On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble
wrote:
Typo in the subject.
GLK showing failure to load GuC with this approach on CI.
On 11/15/2017 10:47 PM, Jackie Li wrote:
Static WOPCM partitioning will lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.
This patch enables the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset is set to
HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM
space.
v2:
- Removed intel_wopcm_init (Ville/Sagar/Joonas)
- Renamed and Moved the intel_wopcm_partition into intel_guc
(Sagar)
- Removed unnecessary function calls (Joonas)
- Init GuC WOPCM partition as soon as firmware fetching is
completed
Signed-off-by: Jackie Li
+ err = do_wopcm_partition(i915, offset + huc_size, reserved);
+ if (err) {
+ if (!huc_size)
+ goto fail;
+
+ /* Partition without loading HuC FW. */
+ err = do_wopcm_partition(i915, offset, reserved);
+ if (err)
+ goto fail;
+ }
+
+ /*
+ * Check hardware restriction on Gen9
+ * GuC WOPCM size is at least 4 bytes larger than GuC WOPCM
base due
+ * to hardware limitation on Gen9.
+ */
+ if (IS_GEN9(i915)) {
+ wopcm_base = wp->offset + GEN9_GUC_WOPCM_OFFSET;
+ if (unlikely(wopcm_base > wp->size))
+ goto fail;
+
+ delta = wp->size - wopcm_base;
+ if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
+ goto fail;
+ }
+
+ if (guc_fw->fetch_status == INTEL_UC_FIRMWARE_SUCCESS) {
+ guc_size = guc_fw->header_size + guc_fw->ucode_size;
+ /* Need 8K stack for GuC */
+ guc_size += GUC_WOPCM_STACK_RESERVED;
+ }
+
+ if (guc_size > wp->size)
+ goto fail;
+
+ DRM_DEBUG_DRIVER("GuC WOPCM offset %dKB, size %dKB, top %dKB\n",
+ wp->offset >> 10, wp->size >> 10, wp->top >> 10);
+
+ return;
+
+fail:
+ DRM_ERROR("WOPCM partitioning failed. Falling back to
execlist mode\n");
+
+ intel_uc_fini_fw(i915);
This is correct but should be handled from intel_uc_init_fw with this
function returning status.
it's a good idea. I will do it.
Something like this will be good
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 1e2a30a..04c45d0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -90,6 +90,15 @@ void intel_uc_init_fw(struct drm_i915_private *dev_priv)
{
intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
+
+ ret = intel_uc_init_wopcm_partition(dev_priv);
+ if (ret) {
+ intel_uc_fw_fini(&dev_priv->guc.fw);
+ intel_uc_fw_fini(&dev_priv->huc.fw);
+ i915_modparams.enable_guc_loading = 0;
+ i915_modparams.enable_guc_submission = 0;
+ i915_modparams.guc_log_level = -1;
+ }
}
+ /* GuC submission won't work without valid GuC WOPCM
partition */
+ if (i915_modparams.enable_guc_submission)
+ i915_modparams.enable_guc_submission = 0;
+
+ i915_modparams.enable_guc_loading = 0;
+}
This sanitization will be handled by intel_guc_fw_upload during
intel_uc_init_hw so not needed.
It's too late to do it until intel_uc_init_hw.
Yes. Let us not do wopcm_init in uc_init_hw as wopcm_init is one time task.
This modparam update is correct.
what I wanted to guarantee here was guc submission
would be disabled as long as the partitioning failed, so that we won't
need to allocate the kernel
context above guc wopcm top. we sure can ignore the partitioning
failure can continue allocating
the context above guc wopcm top, but the problem is we don't have a
valid guc wopcm top value
if the partitioning was failed. another benefit to disable the guc
here is we won't even bother to call
down into the logics in intel_uc_init_hw since we've already known for
sure. I cannot enable guc
submission on the partitioning failure.
Agree.
+
void intel_uc_init_fw(struct drm_i915_private *dev_priv)
{
intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
+ guc_init_wopcm_partition(dev_priv);
Create intel_uc_init_wopcm_partition(dev_priv) and call
intel_guc_init_wopcm_partition(guc) from there.
hmm, I'm not sure what benefit you expect from this call chain ?
wanted to avoid firmware specific calls from here but I was wrong as
we are not expecting this function to be called from
outside of intel_uc. sorry.
}
void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
@@
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5) URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Series 34354v5 series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags https://patchwork.freedesktop.org/api/1.0/series/34354/revisions/5/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-pnv-d510) fdo#101600 Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) fdo#102473 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:266 dwarn:1 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:451s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:508s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:489s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:471s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:288 pass:179 dwarn:1 dfail:0 fail:0 skip:108 time:265s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:370s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:257s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:487s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:526s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:479s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:529s fi-pnv-d510 total:288 pass:223 dwarn:0 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:455s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:541s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:517s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:518s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:542s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:413s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:609s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:566s fi-bxt-dsi failed to collect. IGT log at Patchwork_7336/fi-bxt-dsi/igt.log c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest 36d8fac885fd drm/i915: Consolidate checks for engine stats availability c4f8928a7be4 drm/i915: Move engine->needs_cmd_parser to engine->flags == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7336/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.
This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.
Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.
v2:
* Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
* Protect macro body with braces. (Jani Nikula)
v3:
* Add dedicated power domain for clarity. (Chris, Imre)
* Commit message and comment text updates.
* Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
firmware release.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak
Acked-by: Chris Wilson
Cc: Chris Wilson
Cc: Dmitry Rogozhkin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 4
drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 4
4 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..17340aadc566 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+ (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
+ IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
+
#include "i915_trace.h"
static inline bool intel_vtd_active(void)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..feec2a621120 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
intel_runtime_pm_put(dev_priv);
+
+ if (NEEDS_CSR_GT_PERF_WA(dev_priv))
+ intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
out_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..619377a05810 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
+ /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+ if (NEEDS_CSR_GT_PERF_WA(i915))
+ intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
intel_runtime_pm_get_noresume(i915);
i915->gt.awake = true;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..f491c7aaa096 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -130,6 +130,8 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "INIT";
case POWER_DOMAIN_MODESET:
return "MODESET";
+ case POWER_DOMAIN_GT_IRQ:
+ return "GT_IRQ";
default:
MISSING_CASE(domain);
return "?";
@@ -1705,6 +1707,7 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define SKL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
+ BIT_ULL(POWER_DOMAIN_GT_IRQ) | \
BIT_ULL(POWER_DOMAIN_MODESET) | \
BIT_ULL(POWER_DOMAIN_AUX_A) | \
BIT_ULL(POWER_DOMAIN_INIT))
@@ -1785,6 +1788,7 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define GLK_DISPLAY_DC_OFF_P
Re: [Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"
On Fri, Nov 24, 2017 at 05:17:48PM +0200, Arkadiusz Hiler wrote:
> This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492
> and gets rid of the config option from the meson.build.
>
> It was needed only for the Android support.
>
> Signed-off-by: Arkadiusz Hiler
Acked-by: Daniel Vetter
on both patches.
I think there's a bunch more things that are only optional because of
Android. Stuff like udev and glib iirc. But maybe we want to keep those,
to avoid to much pain for the next time around someone wants to implement
Android support natively.
-Daniel
> ---
> configure.ac | 6 +-
> lib/igt_aux.c | 35 +++
> meson.build | 5 +
> 3 files changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1ac2e8e8..84c6e646 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -123,11 +123,7 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.82])
> PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> PKG_CHECK_MODULES(KMOD, [libkmod])
> -PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
> -AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
> -if test x"$procps" = xyes; then
> - AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
> -fi
> +PKG_CHECK_MODULES(PROCPS, [libprocps])
> PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes],
> [have_valgrind=no])
>
> if test x$have_valgrind = xyes; then
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index a41ae2f1..e2424109 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -48,7 +48,9 @@
> #include
> #include
> #include
> -#include
> +
> +#include
> +
> #include "drmtest.h"
> #include "i915_drm.h"
> #include "intel_chipset.h"
> @@ -68,10 +70,6 @@
> #include/* for dirname() */
> #endif
>
> -#ifdef HAVE_PROCPS
> -#include
> -#endif
> -
> /**
> * SECTION:igt_aux
> * @short_description: Auxiliary libraries and support functions
> @@ -1296,7 +1294,6 @@ void igt_set_module_param_int(const char *name, int val)
> * This function sends the signal @sig for a process found in process table
> * with name @comm.
> */
> -#ifdef HAVE_PROCPS
> int igt_terminate_process(int sig, const char *comm)
> {
> PROCTAB *proc;
> @@ -1321,19 +1318,7 @@ int igt_terminate_process(int sig, const char *comm)
> closeproc(proc);
> return err;
> }
> -#else
> -#warning "No procps, using naive implementation of igt_terminate_process"
>
> -int igt_terminate_process(int sig, const char *comm)
> -{
> - char pkill_cmd[NAME_MAX];
> -
> - snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
> - return system(pkill_cmd);
> -}
> -#endif
> -
> -#ifdef HAVE_PROCPS
> struct pinfo {
> pid_t pid;
> const char *comm;
> @@ -1515,7 +1500,6 @@ __igt_lsof(const char *dir)
>
> closeproc(proc);
> }
> -#endif
>
> /**
> * igt_lsof: Lists information about files opened by processes.
> @@ -1524,7 +1508,6 @@ __igt_lsof(const char *dir)
> * This function mimics (a restrictive form of) lsof(8), but also shows
> * information about opened fds.
> */
> -#ifdef HAVE_PROCPS
> void
> igt_lsof(const char *dpath)
> {
> @@ -1549,18 +1532,6 @@ igt_lsof(const char *dpath)
>
> free(sanitized);
> }
> -#else
> -#warning "No procps, using naive implementation of igt_lsof"
> -
> -void
> -igt_lsof(const char *dpath)
> -{
> - char lsof_cmd[NAME_MAX];
> -
> - snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
> - system(lsof_cmd);
> -}
> -#endif
>
> static struct igt_siglatency {
> timer_t timer;
> diff --git a/meson.build b/meson.build
> index 2361866b..8e01b05d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -37,10 +37,7 @@ libdrm_amdgpu = dependency('libdrm_amdgpu', required :
> false)
>
> pciaccess = dependency('pciaccess', version : '>=0.10')
> libkmod = dependency('libkmod')
> -libprocps = dependency('libprocps', required : false)
> -if libprocps.found()
> - config.set('HAVE_PROCPS', 1)
> -endif
> +libprocps = dependency('libprocps', required : true)
>
> valgrind = dependency('valgrind', required : false)
> if valgrind.found()
> --
> 2.13.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
Quoting Tvrtko Ursulin (2017-11-29 10:59:27)
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
>
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
>
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
>
> v2:
> * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> * Protect macro body with braces. (Jani Nikula)
>
> v3:
> * Add dedicated power domain for clarity. (Chris, Imre)
> * Commit message and comment text updates.
> * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak
> Acked-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Dmitry Rogozhkin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_gem.c | 4
> drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> 4 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..17340aadc566 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_AUX_D,
> POWER_DOMAIN_GMBUS,
> POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
>
> POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define GT_FREQUENCY_MULTIPLIER 50
> #define GEN9_FREQ_SCALER 3
>
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
We can't have a dmc_payload unless CSR, right?
> + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
> +
> #include "i915_trace.h"
>
> static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..feec2a621120 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
>
> if (INTEL_GEN(dev_priv) >= 6)
> gen6_rps_idle(dev_priv);
> +
> intel_runtime_pm_put(dev_priv);
> +
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
Which is the outer wakeref? I expect runtime, being device-global, to be
the outer wakeref, with display_power_put being the inner subset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
>
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
>
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
>
> v2:
> * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> * Protect macro body with braces. (Jani Nikula)
>
> v3:
> * Add dedicated power domain for clarity. (Chris, Imre)
> * Commit message and comment text updates.
> * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak
> Acked-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Dmitry Rogozhkin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_gem.c | 4
> drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> 4 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..17340aadc566 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_AUX_D,
> POWER_DOMAIN_GMBUS,
> POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
>
> POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define GT_FREQUENCY_MULTIPLIER 50
> #define GEN9_FREQ_SCALER 3
>
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
Doesn't this check race with the async dmc loading? I.e. when you submit
something right at boot-up, before DMC is fully loaded, we might end up
with an unbalanced pm refcount.
I think given that DMC is strongly recommended there shouldn't be a real
cost with making this unconditional.
With that changed:
Reviewed-by: Daniel Vetter
> + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
> +
> #include "i915_trace.h"
>
> static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..feec2a621120 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
>
> if (INTEL_GEN(dev_priv) >= 6)
> gen6_rps_idle(dev_priv);
> +
> intel_runtime_pm_put(dev_priv);
> +
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> out_unlock:
> mutex_unlock(&dev_priv->drm.struct_mutex);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a90bdd26571f..619377a05810 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
>
> GEM_BUG_ON(!i915->gt.active_requests);
>
> + /*
> + * It seems that the DMC likes to transition between the DC states a lot
> + * when there are no connected displays (no active power domains) during
> + * command submission.
> + *
> + * This activity has negative impact on the performance of the chip with
> + * huge latencies observed in the interrupt handler and elsewhere.
> + *
> + * Work around it by grabbing a GT IRQ power domain whilst there is any
> + * GT activity, preventing any DC state transitions.
> + */
> + if (NEEDS_CSR_GT_PERF_WA(i915))
> + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> +
> intel_runtime_pm_get_noresume(i915);
> i915->gt.awake = true;
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 8315499452dc..f491c7aaa096 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -130,6 +130,8 @@ intel_display_power_domain_str(enum
> intel_display_power_domain domain)
> return "INIT";
> case POWER_DOMAIN_MODESET:
> return "MODESET";
> + case POWER_DOMAIN_GT_IRQ:
> + return "GT_IRQ";
> default:
> MISSING_CASE(domain);
> return "?";
> @@ -1705,6 +1707,7 @@ void intel_d
[Intel-gfx] [PATCH i-g-t 1/2] lib: avoid < in gtkdoc comments
For reasons entirely not clear to me meson gtkdoc runs in strict xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself is to dense to correctly escape this stuff. Paper around this. Signed-off-by: Daniel Vetter --- lib/igt_aux.c | 4 ++-- lib/igt_core.c| 4 ++-- lib/igt_debugfs.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/igt_aux.c b/lib/igt_aux.c index 0bcf792c64e9..62b30ce0e01b 100644 --- a/lib/igt_aux.c +++ b/lib/igt_aux.c @@ -1000,7 +1000,7 @@ void igt_drop_root(void) * @var: var lookup to to enable this wait * * Waits for a key press when run interactively and when the corresponding debug - * var is set in the --interactive-debug= variable. Multiple keys + * var is set in the --interactive-debug=$var variable. Multiple keys * can be specified as a comma-separated list or alternatively "all" if a wait * should happen for all cases. * @@ -1041,7 +1041,7 @@ void igt_debug_wait_for_keypress(const char *var) * @expected: message to be printed as expected behaviour before wait for keys Y/n * * Waits for a key press when run interactively and when the corresponding debug - * var is set in the --interactive-debug= variable. Multiple vars + * var is set in the --interactive-debug=$var variable. Multiple vars * can be specified as a comma-separated list or alternatively "all" if a wait * should happen for all cases. * diff --git a/lib/igt_core.c b/lib/igt_core.c index 6ce83becd18b..5f1d1d34dbc6 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -164,10 +164,10 @@ * test logic. * * - When adding a new feature test function which uses igt_skip() internally, - * use the _require_ naming scheme. When you + * use the_require_ naming scheme. When you * instead add a feature test function which returns a boolean, because your * main test logic must take different actions depending upon the feature's - * availability, then instead use the _has_. + * availability, then instead use the _has_ . * * - As already mentioned eschew explicit error handling logic as much as * possible. If your test absolutely has to handle the error of some function diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index 5670099f1480..156c1d45ef58 100644 --- a/lib/igt_debugfs.c +++ b/lib/igt_debugfs.c @@ -231,7 +231,7 @@ int igt_debugfs_dir(int device) * @mode: mode bits as used by open() * * This opens a debugfs file as a Unix file descriptor. The filename should be - * relative to the drm device's root, i.e. without "drm/". + * relative to the drm device's root, i.e. without "drm/$minor". * * Returns: * The Unix file descriptor for the debugfs file or -1 if that didn't work out. -- 2.15.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] meson: gtkdoc support
Bunch of neat improvements:
- xml generates correctly depend upon the test binaries
- no need to re-run autogen.sh when new chapters/functions get added,
all handed by meson
Still one issue:
- the gtkdoc target doesn't depend upon the custom_target yet, hacked
around using build_by_default: true
This is an issue known to upstream already:
https://github.com/mesonbuild/meson/issues/2148
v2: Bump meson version to 0.42, since that's the first release which
adds the build dir when running the gtkdoc tools, and hence allows
including generated files.
v2:
- Undo the bump, it's only needed for generated source files. Other
generated files as input should work with 0.40 already.
- Generate version.xml from version.xml.in, which allows us to keep
the &version; entity.
v3: Add github issue link.
Signed-off-by: Daniel Vetter
---
docs/meson.build | 1 +
.../intel-gpu-tools/generate_description_xml.sh| 44
.../intel-gpu-tools/generate_programs_xml.sh | 22 ++
docs/reference/intel-gpu-tools/meson.build | 80 ++
docs/reference/meson.build | 1 +
meson.build| 3 +
meson.sh | 2 +-
tests/meson.build | 6 +-
8 files changed, 157 insertions(+), 2 deletions(-)
create mode 100644 docs/meson.build
create mode 100644 docs/reference/intel-gpu-tools/generate_description_xml.sh
create mode 100755 docs/reference/intel-gpu-tools/generate_programs_xml.sh
create mode 100644 docs/reference/intel-gpu-tools/meson.build
create mode 100644 docs/reference/meson.build
diff --git a/docs/meson.build b/docs/meson.build
new file mode 100644
index ..ead14c4015d9
--- /dev/null
+++ b/docs/meson.build
@@ -0,0 +1 @@
+subdir('reference')
diff --git a/docs/reference/intel-gpu-tools/generate_description_xml.sh
b/docs/reference/intel-gpu-tools/generate_description_xml.sh
new file mode 100644
index ..8e39e0c4c289
--- /dev/null
+++ b/docs/reference/intel-gpu-tools/generate_description_xml.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+output=$1
+filter=$2
+testlist=$3
+testdir=$(dirname $testlist)
+
+echo "" > $output
+echo ">
$output
+echo "
\"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
+echo "[" >> $output
+echo " http://www.w3.org/2003/XInclude'\">" >> $output
+echo " " >> $output
+echo "]>" >> $output
+echo "" >> $output
+echo "Description" >> $output
+for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
+ echo "" >> $output;
+ echo "$test" | perl -pe
's/(?<=_)$(KEYWORDS)(?=(_|\W))/\1<\/acronym>/g' >> $output;
+ echo "" >> $output;
+ if ./$testprog --list-subtests > /dev/null ; then
+ echo "Subtests" >> $output;
+ subtest_list=`./$testprog --list-subtests`;
+ subtest_count=`echo $subtest_list | wc -w`;
+ if [ $subtest_count -gt 100 ]; then
+ echo "This test has over 100 subtests. " >>
$output;
+ echo "Run $test
--list-subtests to list them." >> $output;
+ else
+ echo "" >> $output;
+ for subtest in $subtest_list; do
+ echo "" >> $output;
+ echo "$subtest" | perl -pe
's/\b$(KEYWORDS)\b/\1<\/acronym>/g' >> $output;
+ echo "" >> $output;
+ done;
+ echo "" >> $output;
+ fi;
+ echo "" >> $output;
+ fi;
+ echo "" >> $output;
+done;
+echo "" >> $output
diff --git a/docs/reference/intel-gpu-tools/generate_programs_xml.sh
b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
new file mode 100755
index ..73adc8cc7bfc
--- /dev/null
+++ b/docs/reference/intel-gpu-tools/generate_programs_xml.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+output=$1
+filter=$2
+testlist=$3
+
+echo "" > $output
+echo ">
$output
+echo "
\"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd\""; >> $output
+echo "[" >> $output
+echo " http://www.w3.org/2003/XInclude'\">" >> $output
+echo " " >> $output
+echo "]>" >> $output
+echo "" >> $output
+echo "Programs" >> $output
+echo ""
>> $output
+for test in `cat $testlist | tr ' ' '\n' | grep "^$filter" | sort`; do
+ echo "" >> $output;
+ echo "$test" >> $output;
+done;
+echo "" >> $output
+echo "" >> $output
diff --git a/docs/reference/intel-gpu-tools/meson.build
b/docs/reference/intel-gpu-tools/meson.build
new file mode 100644
index ..1c009229aae2
--- /dev/null
+++ b/docs/reference/intel-gpu-tools/meson.build
@@ -0,0 +1,80 @@
+gnome = import('gnome')
+
+ignore_headers = [
+ 'gen6_render.h',
+ 'gen7_media.h',
+ 'gen7_render.h',
+ 'gen8_media.h',
+ 'gen8_render.h',
+ 'gpgpu
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Restore GT performance in headless mode with DMC loaded (rev3)
== Series Details == Series: drm/i915: Restore GT performance in headless mode with DMC loaded (rev3) URL : https://patchwork.freedesktop.org/series/24017/ State : warning == Summary == Series 24017v3 drm/i915: Restore GT performance in headless mode with DMC loaded https://patchwork.freedesktop.org/api/1.0/series/24017/revisions/3/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-r) Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:443s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:511s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:507s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:507s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:480s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:469s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:288 pass:178 dwarn:1 dfail:0 fail:1 skip:108 time:269s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:358s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:255s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:433s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:486s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:528s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:480s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:535s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:589s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:544s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:525s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:510s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:549s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:414s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:602s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:549s c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest 93f678ee3268 drm/i915: Restore GT performance in headless mode with DMC loaded == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7337/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] lockdep: finer-grained completion key for kthread
Ideally we'd create the key through a macro at the real callers and
pass it all the way down. This would give us better coverage for cases
where a bunch of kthreads are created for the same thing.
But this gets the job done meanwhile and unblocks our CI. Refining
later on is always possible.
v2:
- make it compile
- use the right map (Tvrtko)
v3:
lockdep insist on a static key, so the cheap way didn't work. Wire
2 keys through all the callers.
I didn't extend this up to alloc_workqueue because the
lockdep_invariant_state() call should separate the work functions from
the workqueue kthread logic and prevent cross-release state from
leaking between unrelated work queues that happen to reuse the same
kthreads.
v4: CI found more compile fail :-/
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter
---
include/linux/kthread.h | 48 -
kernel/kthread.c| 70 ++---
2 files changed, 90 insertions(+), 28 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..7a9463f0be5c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
#include
#include
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
void *data,
int node,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
/**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int
(*threadfn)(void *data),
*/
#define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_node(threadfn, data, node, &__exited_key,\
+ &__parked_key, namefmt, ##arg); \
+})
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
void *data,
unsigned int cpu,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+ &__parked_key, namefmt); \
+})
+
/**
* kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
int kthread_worker_fn(void *worker_ptr);
-__printf(2, 3)
+__printf(4, 5)
struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
+ const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)
\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker(flags, &__exited_key, &__parked_key, \
+ ##namefmt); \
+})
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker_on_cpu(cpu, flags, &__exited_key, &__parked_key,\
+ ##namefmt); \
+})
bool kthread_queue_work(struct kthread_worker *worker,
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
On 29/11/2017 11:12, Daniel Vetter wrote:
On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.
This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.
Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.
v2:
* Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
* Protect macro body with braces. (Jani Nikula)
v3:
* Add dedicated power domain for clarity. (Chris, Imre)
* Commit message and comment text updates.
* Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
firmware release.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak
Acked-by: Chris Wilson
Cc: Chris Wilson
Cc: Dmitry Rogozhkin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 4
drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 4
4 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..17340aadc566 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+ (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
Doesn't this check race with the async dmc loading? I.e. when you submit
something right at boot-up, before DMC is fully loaded, we might end up
with an unbalanced pm refcount.
Oh yeah, well spotted.
I think given that DMC is strongly recommended there shouldn't be a real
cost with making this unconditional.
I don't know, not liking it on the first go. But then again I have no
idea how much power would that waste for use cases where DMC fw is
deliberately not present.
Perhaps it would be acceptable to mark GT busy during the async CSR
load. Chris, any thoughts?
Regards,
Tvrtko
With that changed:
Reviewed-by: Daniel Vetter
+ IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
+
#include "i915_trace.h"
static inline bool intel_vtd_active(void)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..feec2a621120 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
intel_runtime_pm_put(dev_priv);
+
+ if (NEEDS_CSR_GT_PERF_WA(dev_priv))
+ intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
out_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..619377a05810 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
+ /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+ if (NEEDS_CSR_GT_PERF_WA(i915))
+ intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
intel_runtime_pm_get_noresume(i915);
i915->gt.awake = true;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..f491c7aaa096 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -130,6 +130,8 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "INIT";
case POWER_DOMAIN_MODESET:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] lib: avoid < in gtkdoc comments
== Series Details == Series: series starting with [1/2] lib: avoid < in gtkdoc comments URL : https://patchwork.freedesktop.org/series/34609/ State : success == Summary == IGT patchset tested on top of latest successful build 380cc811486ba3fefbe3ebe4761afa7e169dcd3e tests/perf_pmu: Sync invalid-init with i915 changes with latest DRM-Tip kernel build CI_DRM_3404 c544c3050125 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest No testlist changes. Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-pnv-d510) fdo#101600 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 +1 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:386s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:528s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:512s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:510s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:489s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:475s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:432s fi-gdg-551 total:288 pass:178 dwarn:1 dfail:0 fail:1 skip:108 time:270s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:360s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:262s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:492s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:526s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-pnv-d510 total:288 pass:223 dwarn:0 dfail:0 fail:0 skip:65 time:591s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:542s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:570s fi-skl-6700k total:288 pass:263 dwarn:0 dfail:0 fail:1 skip:24 time:507s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:451s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:554s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:418s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:608s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:560s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_562/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
Quoting Tvrtko Ursulin (2017-11-29 11:34:27) > > On 29/11/2017 11:12, Daniel Vetter wrote: > > I think given that DMC is strongly recommended there shouldn't be a real > > cost with making this unconditional. > > I don't know, not liking it on the first go. But then again I have no > idea how much power would that waste for use cases where DMC fw is > deliberately not present. > > Perhaps it would be acceptable to mark GT busy during the async CSR > load. Chris, any thoughts? It's tightly coupled to requests, adding in an external call seems troublesome. What's the reason for depending on the CSR being loaded? The old fw is broke no matter what, it doesn't get any more broken by us holding a powerwell wakeref. I think we should go for simplicity and always take the powerwell along with the rpm? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
On 29/11/2017 11:40, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-11-29 11:34:27) On 29/11/2017 11:12, Daniel Vetter wrote: I think given that DMC is strongly recommended there shouldn't be a real cost with making this unconditional. I don't know, not liking it on the first go. But then again I have no idea how much power would that waste for use cases where DMC fw is deliberately not present. Perhaps it would be acceptable to mark GT busy during the async CSR load. Chris, any thoughts? It's tightly coupled to requests, adding in an external call seems troublesome. What's the reason for depending on the CSR being loaded? The old fw is broke no matter what, it doesn't get any more broken by us holding a powerwell wakeref. I think we should go for simplicity and always take the powerwell along with the rpm? It's the unknown, maybe only for me, on how much power always holding the power well would waste for use cases where DMC firmware has been deliberately removed. If I understand correctly that the Daniel's and your proposal is to just got with HAS_CSR as the wa/ criteria, instead of fw loaded check. 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: Restore GT performance in headless mode with DMC loaded
Quoting Tvrtko Ursulin (2017-11-29 11:53:41) > > On 29/11/2017 11:40, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-11-29 11:34:27) > >> > >> On 29/11/2017 11:12, Daniel Vetter wrote: > >>> I think given that DMC is strongly recommended there shouldn't be a real > >>> cost with making this unconditional. > >> > >> I don't know, not liking it on the first go. But then again I have no > >> idea how much power would that waste for use cases where DMC fw is > >> deliberately not present. > >> > >> Perhaps it would be acceptable to mark GT busy during the async CSR > >> load. Chris, any thoughts? > > > > It's tightly coupled to requests, adding in an external call seems > > troublesome. > > > > What's the reason for depending on the CSR being loaded? The old fw is > > broke no matter what, it doesn't get any more broken by us holding a > > powerwell wakeref. I think we should go for simplicity and always take > > the powerwell along with the rpm? > > It's the unknown, maybe only for me, on how much power always holding > the power well would waste for use cases where DMC firmware has been > deliberately removed. > > If I understand correctly that the Daniel's and your proposal is to just > got with HAS_CSR as the wa/ criteria, instead of fw loaded check. If I am reading the powerwell code correctly, it already takes the dmc fw into account. I would transfer the problem to there :) i.e. we have an unconditional call from gt:mark_busy, gt:mark_idle and the powerwell code knows what needs to be done under the different circumstances. -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 series starting with lockdep: finer-grained completion key for kthread (rev2)
== Series Details == Series: series starting with lockdep: finer-grained completion key for kthread (rev2) URL : https://patchwork.freedesktop.org/series/34603/ State : success == Summary == Series 34603v2 series starting with lockdep: finer-grained completion key for kthread https://patchwork.freedesktop.org/api/1.0/series/34603/revisions/2/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:444s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:384s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:516s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:283s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:505s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:492s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:474s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:288 pass:178 dwarn:1 dfail:0 fail:1 skip:108 time:272s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:363s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:264s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:484s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:528s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:598s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:540s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:569s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:521s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:503s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:453s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:557s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:419s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:611s c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest c7410e9c26c2 lockdep: Up MAX_LOCKDEP_CHAINS 68049d7ef928 lockdep: finer-grained completion key for kthread == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7338/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 2/3] tests/gem_pin: Drop gem_pin.c
gem_pin ABI is going away (Chris).
Signed-off-by: Abdiel Janulgue
Reviewed-by: Joonas Lahtinen
---
tests/Makefile.sources | 1 -
tests/gem_pin.c| 248 -
tests/meson.build | 1 -
3 files changed, 250 deletions(-)
delete mode 100644 tests/gem_pin.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 84d80a3..4f936e7 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -111,7 +111,6 @@ TESTS_progs = \
gem_mocs_settings \
gem_partial_pwrite_pread \
gem_persistent_relocs \
- gem_pin \
gem_pipe_control_store_loop \
gem_ppgtt \
gem_pread \
diff --git a/tests/gem_pin.c b/tests/gem_pin.c
deleted file mode 100644
index 9ea3b1e..000
--- a/tests/gem_pin.c
+++ /dev/null
@@ -1,248 +0,0 @@
-/*
- * Copyright © 20013 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * 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:
- *Chris Wilson
- *
- */
-
-/* Exercises pinning of small bo */
-
-#include "igt.h"
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-
-IGT_TEST_DESCRIPTION("Exercises pinning of small buffer objects.");
-
-#define COPY_BLT_CMD(2<<29|0x53<<22|0x6)
-#define BLT_WRITE_ALPHA (1<<21)
-#define BLT_WRITE_RGB (1<<20)
-
-static void exec(int fd, uint32_t handle, uint32_t offset)
-{
- struct drm_i915_gem_execbuffer2 execbuf;
- struct drm_i915_gem_exec_object2 gem_exec[1];
- struct drm_i915_gem_relocation_entry gem_reloc[1];
-
- gem_reloc[0].offset = 1024;
- gem_reloc[0].delta = 0;
- gem_reloc[0].target_handle = handle;
- gem_reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
- gem_reloc[0].write_domain = 0;
- gem_reloc[0].presumed_offset = 0;
-
- gem_exec[0].handle = handle;
- gem_exec[0].relocation_count = 1;
- gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
- gem_exec[0].alignment = 0;
- gem_exec[0].offset = 0;
- gem_exec[0].flags = 0;
- gem_exec[0].rsvd1 = 0;
- gem_exec[0].rsvd2 = 0;
-
- execbuf.buffers_ptr = to_user_pointer(gem_exec);
- execbuf.buffer_count = 1;
- execbuf.batch_start_offset = 0;
- execbuf.batch_len = 8;
- execbuf.cliprects_ptr = 0;
- execbuf.num_cliprects = 0;
- execbuf.DR1 = 0;
- execbuf.DR4 = 0;
- execbuf.flags = 0;
- i915_execbuffer2_set_context_id(execbuf, 0);
- execbuf.rsvd2 = 0;
-
- do_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
- igt_assert(gem_exec[0].offset == offset);
-}
-
-static int gem_linear_blt(int fd,
- uint32_t *batch,
- uint32_t src,
- uint32_t dst,
- uint32_t length,
- struct drm_i915_gem_relocation_entry *reloc)
-{
- uint32_t *b = batch;
-
- *b++ = COPY_BLT_CMD | BLT_WRITE_ALPHA | BLT_WRITE_RGB;
- *b++ = 0x66 << 16 | 1 << 25 | 1 << 24 | (4*1024);
- *b++ = 0;
- *b++ = (length / (4*1024)) << 16 | 1024;
- *b++ = 0;
- reloc->offset = (b-batch-1) * sizeof(uint32_t);
- reloc->delta = 0;
- reloc->target_handle = dst;
- reloc->read_domains = I915_GEM_DOMAIN_RENDER;
- reloc->write_domain = I915_GEM_DOMAIN_RENDER;
- reloc->presumed_offset = 0;
- reloc++;
- if (intel_gen(intel_get_drm_devid(fd)) >= 8)
- *b++ = 0; /* FIXME */
-
- *b++ = 0;
- *b++ = 4*1024;
- *b++ = 0;
- reloc->offset = (b-batch-1) * sizeof(uint32_t);
- reloc->delta = 0;
- reloc->target_handle = src;
- reloc->read_domains = I915_GEM_DOMAIN_RENDER;
- reloc->write_domain = 0;
- reloc->presumed_offset = 0;
- reloc++;
- if (intel_gen(intel_get_drm_devid(fd)) >= 8)
-
[Intel-gfx] [PATCH i-g-t v2 3/3] tests/gem_seqno_wrap: Drop gem_seqno_wrap.c
gem_seqno_wrap is defunct as the debug API withered away. The
handling of wraparound under many different workloads is tested by
gem_exec_whisper (Chris).
Signed-off-by: Abdiel Janulgue
Reviewed-by: Joonas Lahtinen
---
tests/Makefile.sources | 1 -
tests/gem_seqno_wrap.c | 483 -
tests/meson.build | 1 -
3 files changed, 485 deletions(-)
delete mode 100644 tests/gem_seqno_wrap.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4f936e7..e4e06d0 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -132,7 +132,6 @@ TESTS_progs = \
gem_ring_sync_copy \
gem_ring_sync_loop \
gem_ringfill \
- gem_seqno_wrap \
gem_set_tiling_vs_blt \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
deleted file mode 100644
index c8cad5f..000
--- a/tests/gem_seqno_wrap.c
+++ /dev/null
@@ -1,483 +0,0 @@
-/*
- * Copyright (c) 2012 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * 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:
- *Mika Kuoppala
- *
- */
-
-/*
- * This test runs blitcopy -> rendercopy with multiple buffers over wrap
- * boundary.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "igt.h"
-#include "igt_sysfs.h"
-#include "intel_bufmgr.h"
-
-IGT_TEST_DESCRIPTION("Runs blitcopy -> rendercopy with multiple buffers over"
-" wrap boundary.");
-
-static int drm_fd;
-static int debugfs;
-static int devid;
-static int card_index = 0;
-static uint32_t last_seqno = 0;
-
-static struct intel_batchbuffer *batch_blt;
-static struct intel_batchbuffer *batch_3d;
-
-struct option_struct {
- int rounds;
- int background;
- int timeout;
- int dontwrap;
- int prewrap_space;
- int random;
- int buffers;
-};
-
-static struct option_struct options;
-
-static void init_buffer(drm_intel_bufmgr *bufmgr,
- struct igt_buf *buf,
- drm_intel_bo *bo,
- int width, int height)
-{
- /* buf->bo = drm_intel_bo_alloc(bufmgr, "", size, 4096); */
- buf->bo = bo;
- buf->size = width * height * 4;
- igt_assert(buf->bo);
- buf->tiling = I915_TILING_NONE;
- buf->num_tiles = width * height * 4;
- buf->stride = width * 4;
-}
-
-static void
-set_bo(drm_intel_bo *bo, uint32_t val, int width, int height)
-{
- int size = width * height;
- uint32_t *vaddr;
-
- drm_intel_gem_bo_start_gtt_access(bo, true);
- vaddr = bo->virtual;
- while (size--)
- *vaddr++ = val;
-}
-
-static void
-cmp_bo(drm_intel_bo *bo, uint32_t val, int width, int height)
-{
- int size = width * height;
- uint32_t *vaddr;
-
- drm_intel_gem_bo_start_gtt_access(bo, false);
- vaddr = bo->virtual;
- while (size--) {
- igt_assert_f(*vaddr++ == val,
-"%d: 0x%x differs from assumed 0x%x\n"
-"seqno_before_test 0x%x, "
-" approximated seqno on test fail 0x%x\n",
-width * height - size, *vaddr-1, val,
-last_seqno, last_seqno + val * 2);
- }
-}
-
-static drm_intel_bo *
-create_bo(drm_intel_bufmgr *bufmgr, uint32_t val, int width, int height)
-{
- drm_intel_bo *bo;
-
- bo = drm_intel_bo_alloc(bufmgr, "bo", width * height * 4, 0);
- igt_assert(bo);
-
- /* gtt map doesn't have a write parameter, so just keep the mapping
-* around (to avoid the set_domain with the gtt write domain set) and
-* manually tell the kernel when we start access the gtt. */
- drm_intel_gem_bo_map_gtt(bo);
-
- set_bo(bo, val, width, height);
-
-
[Intel-gfx] [PATCH i-g-t v2 1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c
gem_hangcheck_forcewake has been superseded by drv_hangman, and a lot of
other very extensive hangchecking that is not run by CI (Chris).
v2: Split into multiple patches (Antonio Argenziano)
Signed-off-by: Abdiel Janulgue
Reviewed-by: Joonas Lahtinen
---
tests/Makefile.sources | 1 -
tests/gem_hangcheck_forcewake.c | 123
tests/meson.build | 1 -
3 files changed, 125 deletions(-)
delete mode 100644 tests/gem_hangcheck_forcewake.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 34ca71a..84d80a3 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -99,7 +99,6 @@ TESTS_progs = \
gem_gtt_cpu_tlb \
gem_gtt_hog \
gem_gtt_speed \
- gem_hangcheck_forcewake \
gem_largeobject \
gem_linear_blits \
gem_lut_handle \
diff --git a/tests/gem_hangcheck_forcewake.c b/tests/gem_hangcheck_forcewake.c
deleted file mode 100644
index a3e7554..000
--- a/tests/gem_hangcheck_forcewake.c
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * Copyright © 2011 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * 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:
- *Daniel Vetter
- *
- */
-
-#include "igt.h"
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "drm.h"
-#include "intel_bufmgr.h"
-
-IGT_TEST_DESCRIPTION("Provoke the hangcheck timer on an otherwise idle"
-" system.");
-
-/*
- * Testcase: Provoke the hangcheck timer on an otherwise idle system
- *
- * This tries to hit forcewake locking bugs when the hangcheck runs. Somehow we
- * often luck out and the hangcheck runs while someone else is already holding
- * the dev->struct_mutex.
- *
- * It's imperative that nothing else runs while this test runs, i.e. kill your
X
- * session, please.
- */
-
-static drm_intel_bufmgr *bufmgr;
-struct intel_batchbuffer *batch;
-
-uint32_t blob[2048*2048];
-
-#define MAX_BLT_SIZE 128
-igt_simple_main
-{
- drm_intel_bo *bo = NULL;
- uint32_t tiling_mode = I915_TILING_X;
- unsigned long pitch, act_size;
- int fd, i, devid;
-
- igt_skip_on_simulation();
-
- memset(blob, 'A', sizeof(blob));
-
- fd = drm_open_driver(DRIVER_INTEL);
- igt_require_gem(fd);
-
- bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
- drm_intel_bufmgr_gem_enable_reuse(bufmgr);
- devid = intel_get_drm_devid(fd);
- batch = intel_batchbuffer_alloc(bufmgr, devid);
-
- act_size = 2048;
- igt_info("filling ring\n");
- drm_intel_bo_unreference(bo);
- bo = drm_intel_bo_alloc_tiled(bufmgr, "tiled bo", act_size, act_size,
- 4, &tiling_mode, &pitch, 0);
-
- drm_intel_bo_subdata(bo, 0, act_size*act_size*4, blob);
-
- if (IS_965(devid))
- pitch /= 4;
-
- for (i = 0; i < 1; i++) {
- BLIT_COPY_BATCH_START(XY_SRC_COPY_BLT_SRC_TILED |
- XY_SRC_COPY_BLT_DST_TILED);
- OUT_BATCH((3 << 24) | /* 32 bits */
- (0xcc << 16) | /* copy ROP */
- pitch);
- OUT_BATCH(0 << 16 | 1024);
- OUT_BATCH((2048) << 16 | (2048));
- OUT_RELOC_FENCED(bo, I915_GEM_DOMAIN_RENDER,
I915_GEM_DOMAIN_RENDER, 0);
- OUT_BATCH(0 << 16 | 0);
- OUT_BATCH(pitch);
- OUT_RELOC_FENCED(bo, I915_GEM_DOMAIN_RENDER, 0, 0);
- ADVANCE_BATCH();
-
- if (batch->gen >= 6) {
- BEGIN_BATCH(3, 0);
- OUT_BATCH(XY_SETUP_CLIP_BLT_CMD);
- OUT_BATCH(0);
- OUT_BATCH(0);
- ADVANCE_BATCH();
- }
- }
-
- igt_info("waiting\n");
- sleep(10);
-
- igt_info("done waiting,
Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble
wrote:
On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).
+
+ /* Making sure that our auto is well defined */
+ GEM_BUG_ON(auto_enable_guc < 0);
+ GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+ GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+ if (i915_modparams.enable_guc < 0)
+ i915_modparams.enable_guc = auto_enable_guc;
+
+ if (i915_modparams.enable_guc > 0) {
+ if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+ DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+i915_modparams.enable_guc,
+!HAS_GUC(dev_priv) ? "no GuC hardware" :
+"no GuC firmware");
+ i915_modparams.enable_guc = 0;
+ }
}
- /* A negative value means "use platform default" */
- if (i915_modparams.enable_guc_loading < 0)
- i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
- /* Verify firmware version */
- if (i915_modparams.enable_guc_loading) {
- if (HAS_HUC_UCODE(dev_priv))
- intel_huc_select_fw(&dev_priv->huc);
-
- if (intel_guc_fw_select(&dev_priv->guc))
- i915_modparams.enable_guc_loading = 0;
+ if (i915_modparams.enable_guc & 2) {
+ if (!HAS_HUC_FW(dev_priv)) {
+ DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc, "no HuC firmware");
+ i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess. Sorry
I did not see this earlier.
My understanding is that if user had specified non-zero positive value of
'enable_guc' then it means that he requests *all* GuC options to be
available
(something like our old '2=required' mode). If any of required option is
not
available then we should not try to cherry-pick/drop single option.
Note that if user don't care about specific option, then user should use
-1(auto)
mode and rely on driver decision what is available and in which
configuration.
And for 'auto' mode we try to make sure to do not select broken
configurations.
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"
== Series Details == Series: Revert "Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" URL : https://patchwork.freedesktop.org/series/34592/ State : success == Summary == Blacklisted hosts: shard-hswtotal:2661 pass:1527 dwarn:7 dfail:2 fail:9 skip:1116 time:9323s shard-snbtotal:2644 pass:1288 dwarn:10 dfail:0 fail:12 skip:1333 time:7799s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html ___ 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 [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev4)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev4) URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Blacklisted hosts: shard-apltotal:2412 pass:1516 dwarn:14 dfail:10 fail:12 skip:854 time:11519s shard-hswtotal:2661 pass:1522 dwarn:8 dfail:1 fail:11 skip:1119 time:9175s shard-kbltotal:2361 pass:1578 dwarn:12 dfail:12 fail:12 skip:739 time:8257s shard-snbtotal:2539 pass:1229 dwarn:13 dfail:8 fail:8 skip:1277 time:6709s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7334/shards.html ___ 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 [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5) URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Blacklisted hosts: shard-apltotal:2431 pass:1516 dwarn:13 dfail:11 fail:13 skip:872 time:11588s shard-hswtotal:2661 pass:1527 dwarn:9 dfail:1 fail:8 skip:1116 time:9311s shard-kbltotal:2440 pass:1631 dwarn:14 dfail:12 fail:13 skip:763 time:8562s shard-snbtotal:2540 pass:1228 dwarn:16 dfail:8 fail:6 skip:1278 time:6839s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7336/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: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 11:10:58AM +, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-11-29 10:59:27)
> > From: Tvrtko Ursulin
> >
> > It seems that the DMC likes to transition between the DC states a lot when
> > there are no connected displays (no active power domains) during command
> > submission.
> >
> > This activity on DC states has a negative impact on the performance of the
> > chip with huge latencies observed in the interrupt handlers and elsewhere.
> > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > eight.
> >
> > Work around it by introducing a new power domain named,
> > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > held for the duration of command submission activity.
> >
> > v2:
> > * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > * Protect macro body with braces. (Jani Nikula)
> >
> > v3:
> > * Add dedicated power domain for clarity. (Chris, Imre)
> > * Commit message and comment text updates.
> > * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
> >firmware release.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > Testcase: igt/gem_exec_nop/headless
> > Cc: Imre Deak
> > Acked-by: Chris Wilson
> > Cc: Chris Wilson
> > Cc: Dmitry Rogozhkin
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 5 +
> > drivers/gpu/drm/i915/i915_gem.c | 4
> > drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> > 4 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index bddd65839f60..17340aadc566 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_AUX_D,
> > POWER_DOMAIN_GMBUS,
> > POWER_DOMAIN_MODESET,
> > + POWER_DOMAIN_GT_IRQ,
> > POWER_DOMAIN_INIT,
> >
> > POWER_DOMAIN_NUM,
> > @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> > #define GT_FREQUENCY_MULTIPLIER 50
> > #define GEN9_FREQ_SCALER 3
> >
> > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
>
> We can't have a dmc_payload unless CSR, right?
>
> > + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
> > +
> > #include "i915_trace.h"
> >
> > static inline bool intel_vtd_active(void)
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 354b0546a191..feec2a621120 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >
> > if (INTEL_GEN(dev_priv) >= 6)
> > gen6_rps_idle(dev_priv);
> > +
> > intel_runtime_pm_put(dev_priv);
> > +
> > + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> > + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
>
> Which is the outer wakeref? I expect runtime, being device-global, to be
> the outer wakeref, with display_power_put being the inner subset.
Yes, logically the runtime ref is the outer one. But
intel_display_power_get() takes a runtime ref too and both runtime and
display power references can be held for "a long time" and so can be
taken in both order.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5)
On 29/11/2017 10:58, Patchwork wrote: == Series Details == Series: series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags (rev5) URL : https://patchwork.freedesktop.org/series/34354/ State : success == Summary == Series 34354v5 series starting with [v2,1/2] drm/i915: Move engine->needs_cmd_parser to engine->flags https://patchwork.freedesktop.org/api/1.0/series/34354/revisions/5/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> PASS (fi-bdw-gvtdvm) fdo#103938 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-pnv-d510) fdo#101600 Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) fdo#102473 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: fail -> PASS (fi-skl-6700k) fdo#103191 Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:266 dwarn:1 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:451s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:508s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:489s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:471s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:288 pass:179 dwarn:1 dfail:0 fail:0 skip:108 time:265s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:370s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:257s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:487s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:526s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:479s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:529s fi-pnv-d510 total:288 pass:223 dwarn:0 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:455s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:541s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:517s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:518s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:542s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:413s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:609s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:566s fi-bxt-dsi failed to collect. IGT log at Patchwork_7336/fi-bxt-dsi/igt.log c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest 36d8fac885fd drm/i915: Consolidate checks for engine stats availability c4f8928a7be4 drm/i915: Move engine->needs_cmd_parser to engine->flags Pushed, thanks for the review. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint
Checking for a tainted kernel is a convenient way to see if the test
generated a critical error such as a oops, or machine check.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Radoslaw Szwichtenberg
---
lib/Makefile.sources | 2 ++
lib/igt_core.c | 19 +-
lib/igt_kernel_taint.c | 95 ++
lib/igt_kernel_taint.h | 34 ++
4 files changed, 149 insertions(+), 1 deletion(-)
create mode 100644 lib/igt_kernel_taint.c
create mode 100644 lib/igt_kernel_taint.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6e968d9f..15215390 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -22,6 +22,8 @@ lib_source_list = \
igt_gt.h\
igt_gvt.c \
igt_gvt.h \
+ igt_kernel_taint.c \
+ igt_kernel_taint.h \
igt_primes.c\
igt_primes.h\
igt_rand.c \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 6ce83bec..7e656323 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -63,6 +63,7 @@
#include "intel_chipset.h"
#include "intel_io.h"
#include "igt_debugfs.h"
+#include "igt_kernel_taint.h"
#include "version.h"
#include "config.h"
@@ -258,6 +259,7 @@ static bool list_subtests = false;
static char *run_single_subtest = NULL;
static bool run_single_subtest_found = false;
static const char *in_subtest = NULL;
+static unsigned long saved_kernel_taint;
static struct timespec subtest_time;
static clockid_t igt_clock = (clockid_t)-1;
static bool in_fixture = false;
@@ -1002,6 +1004,8 @@ bool __igt_run_subtest(const char *subtest_name)
return false;
}
+ saved_kernel_taint = igt_read_kernel_taint();
+
kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str,
subtest_name);
igt_debug("Starting subtest: %s\n", subtest_name);
@@ -1148,8 +1152,21 @@ void __igt_skip_check(const char *file, const int line,
void igt_success(void)
{
succeeded_one = true;
- if (in_subtest)
+ if (in_subtest) {
+ unsigned long new_kernel_taints =
+ igt_read_kernel_taint() & ~saved_kernel_taint;
+ unsigned int tainted = igt_kernel_tainted(new_kernel_taints);
+
+ if (tainted) {
+ igt_kernel_taint_print(new_kernel_taints);
+ if (tainted & TAINT_ERROR)
+ exit_subtest("FAIL");
+ else
+ exit_subtest("WARN");
+ }
+
exit_subtest("SUCCESS");
+ }
}
/**
diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
new file mode 100644
index ..86d9cd20
--- /dev/null
+++ b/lib/igt_kernel_taint.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * 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.
+ */
+
+#include
+#include
+
+#include "igt.h"
+#include "igt_kernel_taint.h"
+#include "igt_sysfs.h"
+
+#define BIT(x) (1ul << (x))
+
+static const struct kernel_taint {
+ const char *msg;
+ unsigned int flags;
+} taints[] = {
+ { "Non-GPL module loaded" },
+ { "Forced module load" },
+ { "Unsafe SMP processor" },
+ { "Forced module unload" },
+ { "Machine Check Exception", TAINT_WARN },
+ { "Bad page detected", TAINT_ERROR },
+ { "Tainted by user request", TAINT_WARN },
+ { "System is on fire", TAINT_ERROR },
+ { "ACPI DSDT has been overridden by user" },
+ { "OOPS", TAINT_ERROR },
+ { "Staging driver loaded; are you mad?" },
+ { "Severe firmware bug workaround active", TAINT_WARN },
+ { "Out-of-tree module loaded" },
+ { "Unsigned module loaded" },
+ { "Soft-lockup detected", TAINT_WARN },
+ { "Kernel has been live patched
[Intel-gfx] [PATCH 2/2] drm/i915: HACK enable GuC for testing
From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_params.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 8321bd86cba5..69ee2484c6bb 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -42,8 +42,8 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc_loading, 0) \ - param(int, enable_guc_submission, 0) \ + param(int, enable_guc_loading, 1) \ + param(int, enable_guc_submission, 1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Add GuC support for engine busy stats
From: Tvrtko Ursulin
Wire up the engine busy stats accounting to the GuC submission backend.
Since there is not context out interrupt we need to place the accounting
callbacks per-request in order to correctly pair with user interrupts.
v2: Rebase.
v3: Commit update.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 912ff143d531..d80d2a3214da 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -781,6 +781,7 @@ static void guc_dequeue(struct intel_engine_cs *engine)
INIT_LIST_HEAD(&rq->priotree.link);
__i915_gem_request_submit(rq);
+ intel_engine_context_in(rq->engine);
trace_i915_gem_request_in(rq,
port_index(port, execlists));
last = rq;
@@ -813,6 +814,7 @@ static void guc_submission_tasklet(unsigned long data)
rq = port_request(&port[0]);
while (rq && i915_gem_request_completed(rq)) {
+ intel_engine_context_out(rq->engine);
trace_i915_gem_request_out(rq);
i915_gem_request_put(rq);
@@ -1453,8 +1455,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
-
- engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
return 0;
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint
Quoting Chris Wilson (2017-11-29 12:30:23)
> Checking for a tainted kernel is a convenient way to see if the test
> generated a critical error such as a oops, or machine check.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Radoslaw Szwichtenberg
> ---
> diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> new file mode 100644
> index ..86d9cd20
> --- /dev/null
> +++ b/lib/igt_kernel_taint.c
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * 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.
> + */
> +
> +#include
> +#include
> +
> +#include "igt.h"
> +#include "igt_kernel_taint.h"
> +#include "igt_sysfs.h"
> +
> +#define BIT(x) (1ul << (x))
> +
> +static const struct kernel_taint {
> + const char *msg;
> + unsigned int flags;
> +} taints[] = {
> + { "Non-GPL module loaded" },
> + { "Forced module load" },
> + { "Unsafe SMP processor" },
> + { "Forced module unload" },
> + { "Machine Check Exception", TAINT_WARN },
> + { "Bad page detected", TAINT_ERROR },
> + { "Tainted by user request", TAINT_WARN },
Since unsafe modparams generate these and we are still using them
extensively, we should probably ignore this one.
> + { "System is on fire", TAINT_ERROR },
> + { "ACPI DSDT has been overridden by user" },
> + { "OOPS", TAINT_ERROR },
> + { "Staging driver loaded; are you mad?" },
> + { "Severe firmware bug workaround active", TAINT_WARN },
> + { "Out-of-tree module loaded" },
> + { "Unsigned module loaded" },
> + { "Soft-lockup detected", TAINT_WARN },
> + { "Kernel has been live patched" },
> +};
> +
> +unsigned long igt_read_kernel_taint(void)
One thing I haven't checked is whether we can clear the kernel taints.
At the moment, once we see an oops, we never report a second test
generating another oops.
-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 series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c
== Series Details == Series: series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c URL : https://patchwork.freedesktop.org/series/34614/ State : success == Summary == IGT patchset tested on top of latest successful build 380cc811486ba3fefbe3ebe4761afa7e169dcd3e tests/perf_pmu: Sync invalid-init with i915 changes with latest DRM-Tip kernel build CI_DRM_3405 22153f2e9d4d drm-tip: 2017y-11m-29d-11h-53m-01s UTC integration manifest Testlist changes: -igt@gem_hangcheck_forcewake -igt@gem_pin -igt@gem_seqno_wrap Test kms_frontbuffer_tracking: Subgroup basic: incomplete -> PASS (fi-skl-6700k) fdo#103735 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103735 https://bugs.freedesktop.org/show_bug.cgi?id=103735 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:444s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:448s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:387s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:517s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:493s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:474s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:423s fi-gdg-551 total:288 pass:178 dwarn:1 dfail:0 fail:1 skip:108 time:268s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:535s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:382s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:261s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:436s fi-ivb-3770 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:455s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:527s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:474s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:532s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:542s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:566s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:523s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:512s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:452s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:420s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:613s fi-cnl-y total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:556s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:480s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_563/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 11:34:27AM +, Tvrtko Ursulin wrote:
>
> On 29/11/2017 11:12, Daniel Vetter wrote:
> > On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > It seems that the DMC likes to transition between the DC states a lot when
> > > there are no connected displays (no active power domains) during command
> > > submission.
> > >
> > > This activity on DC states has a negative impact on the performance of the
> > > chip with huge latencies observed in the interrupt handlers and elsewhere.
> > > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > > eight.
> > >
> > > Work around it by introducing a new power domain named,
> > > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > > held for the duration of command submission activity.
> > >
> > > v2:
> > > * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > > * Protect macro body with braces. (Jani Nikula)
> > >
> > > v3:
> > > * Add dedicated power domain for clarity. (Chris, Imre)
> > > * Commit message and comment text updates.
> > > * Apply to all big-core GEN9 parts apart for Skylake which is pending
> > > DMC
> > > firmware release.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > > Testcase: igt/gem_exec_nop/headless
> > > Cc: Imre Deak
> > > Acked-by: Chris Wilson
> > > Cc: Chris Wilson
> > > Cc: Dmitry Rogozhkin
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 5 +
> > > drivers/gpu/drm/i915/i915_gem.c | 4
> > > drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> > > 4 files changed, 27 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index bddd65839f60..17340aadc566 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > > POWER_DOMAIN_AUX_D,
> > > POWER_DOMAIN_GMBUS,
> > > POWER_DOMAIN_MODESET,
> > > + POWER_DOMAIN_GT_IRQ,
> > > POWER_DOMAIN_INIT,
> > > POWER_DOMAIN_NUM,
> > > @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> > > #define GT_FREQUENCY_MULTIPLIER 50
> > > #define GEN9_FREQ_SCALER 3
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
> >
> > Doesn't this check race with the async dmc loading? I.e. when you submit
> > something right at boot-up, before DMC is fully loaded, we might end up
> > with an unbalanced pm refcount.
>
> Oh yeah, well spotted.
>
> > I think given that DMC is strongly recommended there shouldn't be a real
> > cost with making this unconditional.
>
> I don't know, not liking it on the first go. But then again I have no idea
> how much power would that waste for use cases where DMC fw is deliberately
> not present.
>
> Perhaps it would be acceptable to mark GT busy during the async CSR load.
> Chris, any thoughts?
I only meant that we pm_put without pm_get (because when we would have
called pm_get dmc_payload == NULL and then != NULL when we reach the check
for pm_put).
The actual get/put vs. dmc loading should be protected already by the
async dmc load code holding pm references to prevent any havoc.
-Daniel
>
> Regards,
>
> Tvrtko
>
> > With that changed:
> >
> > Reviewed-by: Daniel Vetter
> >
> > > + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
> > > +
> > > #include "i915_trace.h"
> > > static inline bool intel_vtd_active(void)
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 354b0546a191..feec2a621120 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct
> > > *work)
> > > if (INTEL_GEN(dev_priv) >= 6)
> > > gen6_rps_idle(dev_priv);
> > > +
> > > intel_runtime_pm_put(dev_priv);
> > > +
> > > + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> > > + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> > > out_unlock:
> > > mutex_unlock(&dev_priv->drm.struct_mutex);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> > > b/drivers/gpu/drm/i915/i915_gem_request.c
> > > index a90bdd26571f..619377a05810 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > > @@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
> > > GEM_BUG_ON(!i915->gt.active_requests);
> > > + /*
> > > + * It seems that the DMC likes to transition between the DC states a lot
> > > + * when there are no connected displays (no active power domains) during
> > > + * command submissi
Re: [Intel-gfx] [PATCH] drm/i915: Fix deadlock in i830_disable_pipe()
On Tue, Nov 28, 2017 at 09:05:00PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-28 15:48:53)
> > From: Ville Syrjälä
> >
> > i830_disable_pipe() gets called from the power well code, and thus
> > we're already holding the power domain mutex. That means we can't
> > call plane->get_hw_state() as it will also try to grab the
> > same mutex and will thus deadlock.
> >
> > Replace the assert_plane() calls (which calls ->get_hw_state()) with
> > just raw register reads in i830_disable_pipe(). As a bonus we can
> > now get a warning if plane C is enabled even though we don't even
> > expose it as a drm plane.
> >
> > Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d67c7c498b34..48d9332b196f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private
> > *dev_priv, enum pipe pipe)
> > DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
> > pipe_name(pipe));
> >
> > - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
> > - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
> > + WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE ||
> > + I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE ||
> > + I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE ||
> > + I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE ||
> > + I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
>
> Ok. Avoiding mutex recursion sounds sensible, but a recursion sounds
> like a layering violation. i830_disable_pipe is only used by the
> powerwell, and I guess you could make the i830_enable_pipe in
> i9xx_crtc_disable into a call to the powerdomain instead.
That wouldn't actully work. We already hold the power domain
reference so the power well enable hook wouldn't even be called,
and even if it was it would just be a nop as the pipe is already
up and running.
I guess it would be possible to redesign that stuff somehow to do what
we want, but that probably means we'd have to redesign the power domain
initialization as well to never call the enable hook if the power well
is already active on boot.
So this would involve a bunch of work, and I can't actually see any
benefit from taking a detour through the power well code.
>
> That sounds like more work than desired to fix the immediate problem!
>
> However, I think you will miss the loss in precision by putting all the
> checks into one WARN_ON. If it either fires, we've no idea what went
> wrong?
>
> Would it be worth just making each of those a separate WARN_ON()? I
> think so.
Yeah, I guess having that extra bit of information might be somewhat
helpful. I'll split it up.
>
> Either way, I've checked that your explanation matches the code...
> Reviewed-by: Chris Wilson
Thanks.
> -Chris
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Fix deadlock in i830_disable_pipe()
From: Ville Syrjälä
i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.
Replace the assert_plane() calls (which calls ->get_hw_state()) with
just raw register reads in i830_disable_pipe(). As a bonus we can
now get a warning if plane C is enabled even though we don't even
expose it as a drm plane.
v2: Do a separate WARN_ON() for each plane (Chris)
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d67c7c498b34..674b86bbe7d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
pipe_name(pipe));
- assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
- assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
+ WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE);
+ WARN_ON(I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
--
2.13.6
___
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] lib: avoid < in gtkdoc comments
== Series Details == Series: series starting with [1/2] lib: avoid < in gtkdoc comments URL : https://patchwork.freedesktop.org/series/34609/ State : success == Summary == Blacklisted hosts: shard-apltotal:2452 pass:1519 dwarn:28 dfail:15 fail:9 skip:877 time:12292s shard-hswtotal:2650 pass:1518 dwarn:8 dfail:0 fail:10 skip:1113 time:9009s shard-kbltotal:2293 pass:1455 dwarn:90 dfail:12 fail:13 skip:715 time:8063s shard-snbtotal:2576 pass:1253 dwarn:16 dfail:4 fail:8 skip:1293 time:6763s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_562/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] meson: build a full dependency for lib_igt_perf
meson prefers packages dependencies over passing arount static
libraries, because those also include linker flags, include dirs and
everything else.
While at it pull the special cases out from the common build stanzas
like we do with other special cases.
Just a bit of ocd to keep everything polished.
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
benchmarks/meson.build | 9 +++--
lib/meson.build| 5 -
overlay/meson.build| 4 ++--
tests/meson.build | 11 +--
4 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/benchmarks/meson.build b/benchmarks/meson.build
index fa7f07643a97..4afd204f82b2 100644
--- a/benchmarks/meson.build
+++ b/benchmarks/meson.build
@@ -12,7 +12,6 @@ benchmark_progs = [
'gem_prw',
'gem_set_domain',
'gem_syslatency',
- 'gem_wsim',
'kms_vblank',
'prime_lookup',
'vgem_mmap',
@@ -31,11 +30,9 @@ endif
foreach prog : benchmark_progs
# FIXME meson doesn't like binaries with the same name
# meanwhile just suffix with _bench
- link = []
- if prog == 'gem_wsim'
- link += lib_igt_perf
- endif
executable(prog + '_bench', prog + '.c',
- link_with : link,
dependencies : test_deps)
endforeach
+
+executable('gem_wsim_bench', 'gem_wsim.c',
+ dependencies : test_deps + [ lib_igt_perf ])
diff --git a/lib/meson.build b/lib/meson.build
index 29d89cf09b58..d06d85b438b2 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -180,8 +180,11 @@ lib_igt = declare_dependency(link_with : lib_igt_build,
igt_deps = [ lib_igt ] + lib_deps
-lib_igt_perf = static_library('igt_perf',
+lib_igt_perf_build = static_library('igt_perf',
['igt_perf.c']
)
+lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
+ include_directories : inc)
+
subdir('tests')
diff --git a/overlay/meson.build b/overlay/meson.build
index 6b479eb89890..afacff5ecf60 100644
--- a/overlay/meson.build
+++ b/overlay/meson.build
@@ -21,7 +21,8 @@ dri2proto = dependency('dri2proto', version : '>= 2.6',
required : false)
cairo_xlib = dependency('cairo-xlib', required : false)
xrandr = dependency('xrandr', version : '>=1.3', required : false)
-gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm, libdrm_intel ]
+gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm,
+ libdrm_intel, lib_igt_perf ]
both_x11_src = ''
@@ -55,6 +56,5 @@ if xrandr.found() and cairo.found()
include_directories : inc,
c_args : gpu_overlay_cflags,
dependencies : gpu_overlay_deps,
- link_with : lib_igt_perf,
install : true)
endif
diff --git a/tests/meson.build b/tests/meson.build
index 088c37ec9b15..58fe0b0557a3 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -193,7 +193,6 @@ test_progs = [
'kms_vblank',
'meta_test',
'perf',
- 'perf_pmu',
'pm_backlight',
'pm_lpsp',
'pm_rc6_residency',
@@ -263,17 +262,17 @@ libexecdir = join_paths(get_option('prefix'),
get_option('libexecdir'), 'intel-g
test_executables = []
foreach prog : test_progs
- link = []
- if prog == 'perf_pmu'
- link += lib_igt_perf
- endif
test_executables += executable(prog, prog + '.c',
dependencies : test_deps,
install_dir : libexecdir,
- link_with : link,
install : true)
endforeach
+test_executables += executable('perf_pmu', 'perf_pmu.c',
+ dependencies : test_deps + [ lib_igt_perf ],
+ install_dir : libexecdir,
+ install : true)
+
executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
dependencies : test_deps,
install_dir : libexecdir,
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint
On Wed, 2017-11-29 at 12:40 +, Chris Wilson wrote:
> Quoting Chris Wilson (2017-11-29 12:30:23)
> > Checking for a tainted kernel is a convenient way to see if the test
> > generated a critical error such as a oops, or machine check.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Daniel Vetter
> > Cc: Radoslaw Szwichtenberg
> > ---
> > diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> > new file mode 100644
> > index ..86d9cd20
> > --- /dev/null
> > +++ b/lib/igt_kernel_taint.c
> > @@ -0,0 +1,95 @@
> > +/*
> > + * Copyright 2017 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> > next
> > + * paragraph) shall be included in all copies or substantial portions of
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include "igt.h"
> > +#include "igt_kernel_taint.h"
> > +#include "igt_sysfs.h"
> > +
> > +#define BIT(x) (1ul << (x))
> > +
> > +static const struct kernel_taint {
> > + const char *msg;
> > + unsigned int flags;
> > +} taints[] = {
> > + { "Non-GPL module loaded" },
> > + { "Forced module load" },
> > + { "Unsafe SMP processor" },
> > + { "Forced module unload" },
> > + { "Machine Check Exception", TAINT_WARN },
> > + { "Bad page detected", TAINT_ERROR },
> > + { "Tainted by user request", TAINT_WARN },
>
> Since unsafe modparams generate these and we are still using them
> extensively, we should probably ignore this one.
>
> > + { "System is on fire", TAINT_ERROR },
> > + { "ACPI DSDT has been overridden by user" },
> > + { "OOPS", TAINT_ERROR },
> > + { "Staging driver loaded; are you mad?" },
> > + { "Severe firmware bug workaround active", TAINT_WARN },
> > + { "Out-of-tree module loaded" },
> > + { "Unsigned module loaded" },
> > + { "Soft-lockup detected", TAINT_WARN },
> > + { "Kernel has been live patched" },
> > +};
> > +
> > +unsigned long igt_read_kernel_taint(void)
>
> One thing I haven't checked is whether we can clear the kernel taints.
> At the moment, once we see an oops, we never report a second test
> generating another oops.
> -Chris
I guess that clearing kernel taints is not needed when you hit oops - you
probably should stop executing tests and reboot the machine, right?
Radek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint
Quoting Szwichtenberg, Radoslaw (2017-11-29 13:14:52)
> On Wed, 2017-11-29 at 12:40 +, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-11-29 12:30:23)
> > > Checking for a tainted kernel is a convenient way to see if the test
> > > generated a critical error such as a oops, or machine check.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Daniel Vetter
> > > Cc: Radoslaw Szwichtenberg
> > > ---
> > > diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> > > new file mode 100644
> > > index ..86d9cd20
> > > --- /dev/null
> > > +++ b/lib/igt_kernel_taint.c
> > > @@ -0,0 +1,95 @@
> > > +/*
> > > + * Copyright 2017 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining
> > > a
> > > + * copy of this software and associated documentation files (the
> > > "Software"),
> > > + * to deal in the Software without restriction, including without
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute,
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > > EXPRESS
> > > OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > MERCHANTABILITY,
> > > + * 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.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +
> > > +#include "igt.h"
> > > +#include "igt_kernel_taint.h"
> > > +#include "igt_sysfs.h"
> > > +
> > > +#define BIT(x) (1ul << (x))
> > > +
> > > +static const struct kernel_taint {
> > > + const char *msg;
> > > + unsigned int flags;
> > > +} taints[] = {
> > > + { "Non-GPL module loaded" },
> > > + { "Forced module load" },
> > > + { "Unsafe SMP processor" },
> > > + { "Forced module unload" },
> > > + { "Machine Check Exception", TAINT_WARN },
> > > + { "Bad page detected", TAINT_ERROR },
> > > + { "Tainted by user request", TAINT_WARN },
> >
> > Since unsafe modparams generate these and we are still using them
> > extensively, we should probably ignore this one.
> >
> > > + { "System is on fire", TAINT_ERROR },
> > > + { "ACPI DSDT has been overridden by user" },
> > > + { "OOPS", TAINT_ERROR },
> > > + { "Staging driver loaded; are you mad?" },
> > > + { "Severe firmware bug workaround active", TAINT_WARN },
> > > + { "Out-of-tree module loaded" },
> > > + { "Unsigned module loaded" },
> > > + { "Soft-lockup detected", TAINT_WARN },
> > > + { "Kernel has been live patched" },
> > > +};
> > > +
> > > +unsigned long igt_read_kernel_taint(void)
> >
> > One thing I haven't checked is whether we can clear the kernel taints.
> > At the moment, once we see an oops, we never report a second test
> > generating another oops.
> > -Chris
>
> I guess that clearing kernel taints is not needed when you hit oops - you
> probably should stop executing tests and reboot the machine, right?
Oops in the driver tends to stop igt pretty hard. A good rule of thumb
is indeed to abandon all hope and reboot. I'm thinking that with this
sort of early-warning detection in place, we can use the kernel_taint
when we do detect a persistent error, e.g. abandon the run if one flip
times out, or if we fail to park or reset the GPU. All to make that
catastrophic error stand out and not pollute other test results.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"
On Wed, Nov 29, 2017 at 12:07:06PM +0100, Daniel Vetter wrote: > On Fri, Nov 24, 2017 at 05:17:48PM +0200, Arkadiusz Hiler wrote: > > This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492 > > and gets rid of the config option from the meson.build. > > > > It was needed only for the Android support. > > > > Signed-off-by: Arkadiusz Hiler > > Acked-by: Daniel Vetter > > on both patches. > > I think there's a bunch more things that are only optional because of > Android. Stuff like udev and glib iirc. But maybe we want to keep those, > to avoid to much pain for the next time around someone wants to implement > Android support natively. > -Daniel Pushed, thanks for Acks and R-bs! As of further cleanups, there is one really impending on us - the libunwind one. We have huge sections of the code wrapped in ifdefs which bit us more than once - it's easy to misplace code in there, code that should always be compiled. This needs a rework, initial ideas is to put all the unwind related mess into separate file and compile the whole thing conditionally - for clearer separation. We would also need "fallback" noop implementation of some of those functions. Or we may ask ourself, with Android support gone, is this really worth it and shouldn't we make libunwind non-optional and just get rid of the preprocessor macors? :-) -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] igt: Remove Android support
On Fri, 2017-11-24 at 17:17 +0200, Arkadiusz Hiler wrote: > This patch gets rid of the Android support, deleting all the hacks and > moving code around to the places it belongs. > > Android build is not really maintained properly and rots rather fast. > With recent push for Meson here and Android going for Soong it will only > accelerate. > > It's a good time to drop the illusion of providing any support. > > Cc: Daniel Vetter > Cc: Kalyan Kondapally > Cc: Petri Latvala > Cc: Radoslaw Szwichtenberg > Signed-off-by: Arkadiusz Hiler Reviewed-by: Radoslaw Szwichtenberg ___ 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 lockdep: finer-grained completion key for kthread (rev2)
== Series Details == Series: series starting with lockdep: finer-grained completion key for kthread (rev2) URL : https://patchwork.freedesktop.org/series/34603/ State : success == Summary == Blacklisted hosts: shard-apltotal:2476 pass:1560 dwarn:10 dfail:8 fail:14 skip:879 time:12836s shard-hswtotal:2661 pass:1534 dwarn:1 dfail:0 fail:9 skip:1117 time:9575s shard-kbltotal:2448 pass:1601 dwarn:49 dfail:11 fail:17 skip:764 time:9121s shard-snbtotal:2539 pass:1236 dwarn:8 dfail:8 fail:6 skip:1277 time:7128s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7338/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add GuC support for engine busy stats
== Series Details == Series: series starting with [1/2] drm/i915: Add GuC support for engine busy stats URL : https://patchwork.freedesktop.org/series/34617/ State : failure == Summary == Series 34617v1 series starting with [1/2] drm/i915: Add GuC support for engine busy stats https://patchwork.freedesktop.org/api/1.0/series/34617/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) fdo#103285 pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-7567u) pass -> DMESG-WARN (fi-kbl-r) pass -> DMESG-WARN (fi-glk-1) Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-skl-6600u) pass -> INCOMPLETE (fi-skl-6700hq) pass -> INCOMPLETE (fi-skl-6700k) pass -> INCOMPLETE (fi-skl-6770hq) pass -> INCOMPLETE (fi-skl-gvtdvm) pass -> INCOMPLETE (fi-bxt-dsi) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-7560u) pass -> INCOMPLETE (fi-kbl-7567u) pass -> INCOMPLETE (fi-kbl-r) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103285 https://bugs.freedesktop.org/show_bug.cgi?id=103285 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:505s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:108 pass:94 dwarn:1 dfail:0 fail:0 skip:12 fi-bxt-j4205 total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:485s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:478s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-glk-1 total:288 pass:259 dwarn:1 dfail:0 fail:0 skip:28 time:523s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:374s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:270s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-kbl-7500u total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-kbl-7560u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-kbl-7567u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-kbl-r total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-skl-6600u total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6700hqtotal:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6700k total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6770hqtotal:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-skl-gvtdvmtotal:108 pass:102 dwarn:1 dfail:0 fail:0 skip:4 fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:418s Blacklisted hosts: fi-cfl-s2total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-cnl-y total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:24 fi-glk-dsi total:288 pass:257 dwarn:1 dfail:0 fail:0 skip:30 time:471s 0645c6db8ac8375db3cb9f6741cfccb671ad5a0c drm-tip: 2017y-11m-29d-12h-29m-51s UTC integration manifest 965fb47f5085 drm/i915: HACK enable GuC for testing dbe7a687455e drm/i915: Add GuC support for engine busy stats == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7339/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters
On 11/29/2017 5:44 PM, Michal Wajdeczko wrote:
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble
wrote:
On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).
+
+ /* Making sure that our auto is well defined */
+ GEM_BUG_ON(auto_enable_guc < 0);
+ GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+ GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+ if (i915_modparams.enable_guc < 0)
+ i915_modparams.enable_guc = auto_enable_guc;
+
+ if (i915_modparams.enable_guc > 0) {
+ if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+ DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc,
+ !HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+ i915_modparams.enable_guc = 0;
+ }
}
- /* A negative value means "use platform default" */
- if (i915_modparams.enable_guc_loading < 0)
- i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
- /* Verify firmware version */
- if (i915_modparams.enable_guc_loading) {
- if (HAS_HUC_UCODE(dev_priv))
- intel_huc_select_fw(&dev_priv->huc);
-
- if (intel_guc_fw_select(&dev_priv->guc))
- i915_modparams.enable_guc_loading = 0;
+ if (i915_modparams.enable_guc & 2) {
+ if (!HAS_HUC_FW(dev_priv)) {
+ DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc, "no HuC firmware");
+ i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess.
Sorry I did not see this earlier.
My understanding is that if user had specified non-zero positive value of
'enable_guc' then it means that he requests *all* GuC options to be
available
(something like our old '2=required' mode). If any of required option
is not
available then we should not try to cherry-pick/drop single option.
I think we wanted to enable HuC for some platforms but not enable GuC
submission. Anusha can you
please confirm if such cherry-picking is needed through module parameter.
Note that if user don't care about specific option, then user should
use -1(auto)
mode and rely on driver decision what is available and in which
configuration.
And for 'auto' mode we try to make sure to do not select broken
configurations.
In that case we can just have 3 values for enable_guc (if cherry-picking
is not to be done)
-1: auto (whatever is available)
0: all disabled
1: all enabled if available else all disabled
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint
Quoting Chris Wilson (2017-11-29 12:30:23)
> +static const struct kernel_taint {
> + const char *msg;
> + unsigned int flags;
> +} taints[] = {
> + { "Non-GPL module loaded" },
> + { "Forced module load" },
> + { "Unsafe SMP processor" },
> + { "Forced module unload" },
> + { "Machine Check Exception", TAINT_WARN },
> + { "Bad page detected", TAINT_ERROR },
> + { "Tainted by user request", TAINT_WARN },
> + { "System is on fire", TAINT_ERROR },
> + { "ACPI DSDT has been overridden by user" },
> + { "OOPS", TAINT_ERROR },
> + { "Staging driver loaded; are you mad?" },
> + { "Severe firmware bug workaround active", TAINT_WARN },
> + { "Out-of-tree module loaded" },
> + { "Unsigned module loaded" },
> + { "Soft-lockup detected", TAINT_WARN },
> + { "Kernel has been live patched" },
There's now also TAINT_AUX, which is unused in the kernel.
{ "Some other reason!" }
Maybe should also add
const char *name;
for "AUX" etc.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add RGB565 90 degree test for gen>9
On 28.11.2017 13:53, Maarten Lankhorst wrote: Hey, Op 21-11-17 om 15:02 schreef Juha-Pekka Heikkila: Gen10 onwards 90 and 270 degree rotations are supported for RGB565 format. v2 (Ville Syrjälä): As a side effect to keep bad-pixel-format test valid on all supported platforms it need to use DRM_FORMAT_C8 now. While at it clean up kms_rotation_crc test a bit, take out test_plane_rotation_ytiled_obj() function as test_plane_rotation() can basically do the same. v3 (Ville Syrjälä): repurpose test_plane_rotation_ytiled_obj() function for bad pixel testing with DRM_FORMAT_C8 as igt doesn't support this format. Signed-off-by: Juha-Pekka Heikkila At this point there is no correct order to apply the tests then. What I would like to see is the bad-pixel-format changes in a separate commit, so we can commit that first, and then commit kernel change, watch CI results for regressions and then add the new IGT test.. With that fixed the patches can be applied. :) Hei, thanks for the comment Maarten. I'll make the change and add you as cc once done. :) /Juha-Pekka ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails
History tells us that if we cannot reset the GPU now, we never will. This
then impacts everything that is run subsequently. On failing the reset,
we mark the driver as wedged, trying to prevent further execution on the
GPU, forcing userspace to fallback to using the CPU to update its
framebuffers and let the user know what happened.
We also want to go one step further and add a taint to the kernel so that
any subsequent faults can be traced back to this failure. This is
important for igt, where if the GPU/driver fails we want to reboot and
restart testing rather than continue on into oblivion.
TAINT_DIE is colloquially known as "system on fire", which seems
appropriate for unresponsive hardware.
References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 696d5cdf2779..f08343be880c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1904,10 +1904,24 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
ret = intel_gpu_reset(i915, ALL_ENGINES);
if (ret) {
- if (ret != -ENODEV)
- DRM_ERROR("Failed to reset chip: %i\n", ret);
- else
+ /*
+* History tells us that if we cannot reset the GPU now, we
+* never will. This then impacts everything that is run
+* subsequently. On failing the reset, we mark the driver
+* as wedged, preventing further execution on the GPU.
+* We also want to go one step further and add a taint to the
+* kernel so that any subsequent faults can be traced back to
+* this failure. This is important for igt, where if the
+* GPU/driver fails we want to reboot and restart testing
+* rather than continue on into oblivion.
+*/
+ if (ret != -ENODEV) {
+ dev_err(i915->drm.dev,
+ "Failed to reset chip: %i\n", ret);
+ add_taint(TAINT_DIE, LOCKDEP_STILL_OK);
+ } else {
DRM_DEBUG_DRIVER("GPU reset disabled\n");
+ }
goto error;
}
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails
History tells us that if we cannot reset the GPU now, we never will. This
then impacts everything that is run subsequently. On failing the reset,
we mark the driver as wedged, trying to prevent further execution on the
GPU, forcing userspace to fallback to using the CPU to update its
framebuffers and let the user know what happened.
We also want to go one step further and add a taint to the kernel so that
any subsequent faults can be traced back to this failure. This is
important for igt, where if the GPU/driver fails we want to reboot and
restart testing rather than continue on into oblivion.
TAINT_DIE is colloquially known as "system on fire", which seems
appropriate for unresponsive hardware.
v2: Also taint if the recovery fails (again history shows us that is
typically fatal).
References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 696d5cdf2779..eb90ddac7f8b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1897,18 +1897,21 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
disable_irq(i915->drm.irq);
ret = i915_gem_reset_prepare(i915);
if (ret) {
- DRM_ERROR("GPU recovery failed\n");
+ dev_err(i915->drm.dev, "GPU recovery failed\n");
intel_gpu_reset(i915, ALL_ENGINES);
- goto error;
+ goto taint;
}
ret = intel_gpu_reset(i915, ALL_ENGINES);
if (ret) {
- if (ret != -ENODEV)
- DRM_ERROR("Failed to reset chip: %i\n", ret);
- else
+ if (ret != -ENODEV) {
+ dev_err(i915->drm.dev,
+ "Failed to reset chip: %i\n", ret);
+ goto taint;
+ } else {
DRM_DEBUG_DRIVER("GPU reset disabled\n");
- goto error;
+ goto error;
+ }
}
i915_gem_reset(i915);
@@ -1951,6 +1954,19 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
wake_up_bit(&error->flags, I915_RESET_HANDOFF);
return;
+taint:
+ /*
+* History tells us that if we cannot reset the GPU now, we
+* never will. This then impacts everything that is run
+* subsequently. On failing the reset, we mark the driver
+* as wedged, preventing further execution on the GPU.
+* We also want to go one step further and add a taint to the
+* kernel so that any subsequent faults can be traced back to
+* this failure. This is important for igt, where if the
+* GPU/driver fails we want to reboot and restart testing
+* rather than continue on into oblivion.
+*/
+ add_taint(TAINT_DIE, LOCKDEP_STILL_OK);
error:
i915_gem_set_wedged(i915);
i915_gem_retire_requests(i915);
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters
On Wed, 29 Nov 2017 14:40:05 +0100, Sagar Arun Kamble
wrote:
On 11/29/2017 5:44 PM, Michal Wajdeczko wrote:
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble
wrote:
On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).
+
+/* Making sure that our auto is well defined */
+GEM_BUG_ON(auto_enable_guc < 0);
+GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+if (i915_modparams.enable_guc < 0)
+i915_modparams.enable_guc = auto_enable_guc;
+
+if (i915_modparams.enable_guc > 0) {
+if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc,
+ !HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+i915_modparams.enable_guc = 0;
+}
}
-/* A negative value means "use platform default" */
-if (i915_modparams.enable_guc_loading < 0)
-i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
-/* Verify firmware version */
-if (i915_modparams.enable_guc_loading) {
-if (HAS_HUC_UCODE(dev_priv))
-intel_huc_select_fw(&dev_priv->huc);
-
-if (intel_guc_fw_select(&dev_priv->guc))
-i915_modparams.enable_guc_loading = 0;
+if (i915_modparams.enable_guc & 2) {
+if (!HAS_HUC_FW(dev_priv)) {
+DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+i915_modparams.enable_guc, "no HuC firmware");
+i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess.
Sorry I did not see this earlier.
My understanding is that if user had specified non-zero positive value
of
'enable_guc' then it means that he requests *all* GuC options to be
available
(something like our old '2=required' mode). If any of required option
is not
available then we should not try to cherry-pick/drop single option.
I think we wanted to enable HuC for some platforms but not enable GuC
submission. Anusha can you
please confirm if such cherry-picking is needed through module parameter.
Cherry-picking through module parameter is fine.
And at the same time we should treat them as mandatory options.
I was referring to cherry-picking (or more precisely droping) during call
to sanitize_options(). So when user specify guc_enable as 3(submission+huc)
we should not convert it into 2(submission only).
Note that if user don't care about specific option, then user should
use -1(auto)
mode and rely on driver decision what is available and in which
configuration.
And for 'auto' mode we try to make sure to do not select broken
configurations.
In that case we can just have 3 values for enable_guc (if cherry-picking
is not to be done)
-1: auto (whatever is available)
0: all disabled
1: all enabled if available else all disabled
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add GuC support for engine busy stats
On 29/11/2017 13:30, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915: Add GuC support for engine busy stats URL : https://patchwork.freedesktop.org/series/34617/ State : failure == Summary == Series 34617v1 series starting with [1/2] drm/i915: Add GuC support for engine busy stats https://patchwork.freedesktop.org/api/1.0/series/34617/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) fdo#103285 pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-7567u) pass -> DMESG-WARN (fi-kbl-r) pass -> DMESG-WARN (fi-glk-1) Looks like another case of alloc_workqueue under struct_mutex in the GuC code. Anyone in the mood to untangle it? :) Regards, Tvrtko Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-skl-6600u) pass -> INCOMPLETE (fi-skl-6700hq) pass -> INCOMPLETE (fi-skl-6700k) pass -> INCOMPLETE (fi-skl-6770hq) pass -> INCOMPLETE (fi-skl-gvtdvm) pass -> INCOMPLETE (fi-bxt-dsi) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-7560u) pass -> INCOMPLETE (fi-kbl-7567u) pass -> INCOMPLETE (fi-kbl-r) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103285 https://bugs.freedesktop.org/show_bug.cgi?id=103285 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:505s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:108 pass:94 dwarn:1 dfail:0 fail:0 skip:12 fi-bxt-j4205 total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:485s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:478s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-glk-1 total:288 pass:259 dwarn:1 dfail:0 fail:0 skip:28 time:523s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:374s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:270s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-kbl-7500u total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-kbl-7560u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-kbl-7567u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-kbl-r total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-skl-6600u total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6700hqtotal:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6700k total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-skl-6770hqtotal:108 pass:103 dwarn:1 dfail:0 fail:0 skip:3 fi-skl-gvtdvmtotal:108 pass:102 dwarn:1 dfail:0 fail:0 skip:4 fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:418s Blacklisted hosts: fi-cfl-s2total:108 pass:95 dwarn:1 dfail:0 fail:0 skip:11 fi-cnl-y total:244 pass:219 dwarn:0 dfail:0 fail:0 skip:24 fi-glk-dsi total:288 pass:257 dwarn:1 dfail:0 fail:0 skip:30 time:471s 0645c6db8ac8375db3cb9f6741cfccb671ad5a0c drm-tip: 2017y-11m-29d-12h-29m-51s UTC integration manifest 965fb47f5085 drm/i915: HACK enable GuC for testing dbe7a687455e drm/i915: Add GuC support for engine busy stats == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7339
Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 11:59:04AM +, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2017-11-29 11:53:41) > > > > On 29/11/2017 11:40, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2017-11-29 11:34:27) > > >> > > >> On 29/11/2017 11:12, Daniel Vetter wrote: > > >>> I think given that DMC is strongly recommended there shouldn't be a real > > >>> cost with making this unconditional. > > >> > > >> I don't know, not liking it on the first go. But then again I have no > > >> idea how much power would that waste for use cases where DMC fw is > > >> deliberately not present. > > >> > > >> Perhaps it would be acceptable to mark GT busy during the async CSR > > >> load. Chris, any thoughts? > > > > > > It's tightly coupled to requests, adding in an external call seems > > > troublesome. > > > > > > What's the reason for depending on the CSR being loaded? The old fw is > > > broke no matter what, it doesn't get any more broken by us holding a > > > powerwell wakeref. I think we should go for simplicity and always take > > > the powerwell along with the rpm? > > > > It's the unknown, maybe only for me, on how much power always holding > > the power well would waste for use cases where DMC firmware has been > > deliberately removed. > > > > If I understand correctly that the Daniel's and your proposal is to just > > got with HAS_CSR as the wa/ criteria, instead of fw loaded check. > > If I am reading the powerwell code correctly, it already takes the dmc > fw into account. I would transfer the problem to there :) i.e. we have > an unconditional call from gt:mark_busy, gt:mark_idle and the powerwell > code knows what needs to be done under the different circumstances. Yes, a power well ref for all domains is held while the firmware is being loaded, or the firmware fails to load. So taking it unconditionally is ok (not counting the platform check due to the corruption issue). > -Chris > ___ > 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/i915: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
>
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
>
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
>
> v2:
> * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> * Protect macro body with braces. (Jani Nikula)
>
> v3:
> * Add dedicated power domain for clarity. (Chris, Imre)
> * Commit message and comment text updates.
> * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak
> Acked-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Dmitry Rogozhkin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_gem.c | 4
> drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> 4 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..17340aadc566 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_AUX_D,
> POWER_DOMAIN_GMBUS,
> POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
>
> POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define GT_FREQUENCY_MULTIPLIER 50
> #define GEN9_FREQ_SCALER 3
>
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
> + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
BXT and GLK seems to be also affected so IS_GEN9().
> +
> #include "i915_trace.h"
>
> static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..feec2a621120 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
>
> if (INTEL_GEN(dev_priv) >= 6)
> gen6_rps_idle(dev_priv);
> +
> intel_runtime_pm_put(dev_priv);
> +
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> out_unlock:
> mutex_unlock(&dev_priv->drm.struct_mutex);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a90bdd26571f..619377a05810 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
>
> GEM_BUG_ON(!i915->gt.active_requests);
>
> + /*
> + * It seems that the DMC likes to transition between the DC states a lot
> + * when there are no connected displays (no active power domains) during
> + * command submission.
> + *
> + * This activity has negative impact on the performance of the chip with
> + * huge latencies observed in the interrupt handler and elsewhere.
> + *
> + * Work around it by grabbing a GT IRQ power domain whilst there is any
> + * GT activity, preventing any DC state transitions.
> + */
> + if (NEEDS_CSR_GT_PERF_WA(i915))
> + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> +
> intel_runtime_pm_get_noresume(i915);
> i915->gt.awake = true;
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 8315499452dc..f491c7aaa096 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -130,6 +130,8 @@ intel_display_power_domain_str(enum
> intel_display_power_domain domain)
> return "INIT";
> case POWER_DOMAIN_MODESET:
> return "MODESET";
> + case POWER_DOMAIN_GT_IRQ:
> + return "GT_IRQ";
> default:
> MISSING_CASE(domain);
> return "?";
> @@ -1705,6 +1707,7 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_INIT))
> #define SKL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> + BIT_ULL(POWER_DOMAIN_GT_IRQ) | \
> BIT_ULL(POWE
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c
== Series Details == Series: series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c URL : https://patchwork.freedesktop.org/series/34614/ State : success == Summary == Blacklisted hosts: shard-hswtotal:2631 pass:1511 dwarn:2 dfail:0 fail:11 skip:1106 time:s shard-snbtotal:2562 pass:1254 dwarn:8 dfail:3 fail:7 skip:1287 time:7071s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_563/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.
This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.
Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.
v2:
* Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
* Protect macro body with braces. (Jani Nikula)
v3:
* Add dedicated power domain for clarity. (Chris, Imre)
* Commit message and comment text updates.
* Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
firmware release.
v4:
* Power domain should be inner to device runtime pm. (Chris)
* Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
* Handle async DMC loading by moving the GT_IRQ power domain logic into
intel_runtime_pm. (Daniel, Chris)
* Include small core GEN9 as well. (Imre)
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak
Acked-by: Chris Wilson (v2)
Cc: Chris Wilson
Cc: Dmitry Rogozhkin
---
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
drivers/gpu/drm/i915/intel_csr.c| 29 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 44 +++--
5 files changed, 76 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..37b3da4fd0d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+ ((dev_priv)->csr.dmc_payload && \
+IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
+
#include "i915_trace.h"
static inline bool intel_vtd_active(void)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..a6f522e2d1a1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
+ intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
intel_runtime_pm_put(dev_priv);
out_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..c28a4ceb016d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
intel_runtime_pm_get_noresume(i915);
+
+ /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+ intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
i915->gt.awake = true;
intel_enable_gt_powersave(i915);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 07e4f7bc4412..8b188e9f283b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
static void csr_load_work_fn(struct work_struct *work)
{
- struct drm_i915_private *dev_priv;
- struct intel_csr *csr;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv), csr.work);
+ struct intel_csr *csr = &dev_priv->csr;
const struct firmware *fw = NULL;
+ u32 *dmc_payload;
- dev_priv = container_of(work, typeof(*dev_priv), csr.work);
- csr = &dev_priv->csr;
+ request_firmware(&fw, csr->fw_path, &dev_priv->drm.pdev->dev);
- request_firmware(&fw, dev_priv->csr.fw_path, &de
Re: [Intel-gfx] [PATCH i-g-t 5/5] tools/intel_watermark: Right justify register names
On Wed, Nov 22, 2017 at 11:44:32PM +, Pandiyan, Dhinakaran wrote:
> Reviewed-by: Dhinakaran Pandiyan for the
> series.
Series pushed. Thanks for the review.
>
>
> On Tue, 2017-11-21 at 20:49 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > I think the dump is a more legible when the register names
> > are right justified. That way the register name and its value
> > are right next to each other.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Ville Syrjälä
> > ---
> > tools/intel_watermark.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
> > index 3c70f4ec54fb..308e351dcd2f 100644
> > --- a/tools/intel_watermark.c
> > +++ b/tools/intel_watermark.c
> > @@ -248,7 +248,7 @@ static void skl_wm_dump(void)
> > }
> >
> > for (pipe = 0; pipe < num_pipes; pipe++) {
> > - printf("%-18s 0x%08x\t",
> > + printf("%18s 0x%08x\t",
> >skl_wm_linetime_reg_name(pipe),
> >wm_linetime[pipe]);
> > }
> > @@ -260,7 +260,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >
> > - printf("%-18s 0x%08x\t" ,
> > + printf("%18s 0x%08x\t" ,
> >skl_wm_reg_name(pipe, plane, level),
> >wm[level][pipe][plane]);
> > }
> > @@ -274,7 +274,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >
> > - printf("%-18s 0x%08x\t",
> > + printf("%18s 0x%08x\t",
> >skl_wm_trans_reg_name(pipe, plane),
> >wm_trans[pipe][plane]);
> > }
> > @@ -287,7 +287,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >
> > - printf("%-18s 0x%08x\t",
> > + printf("%18s 0x%08x\t",
> >skl_buf_cfg_reg_name(pipe, plane),
> >buf_cfg[pipe][plane]);
> > }
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.
Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were no longer disabled as part of fbdev setup.
>>> Headless units could no longer enter pc3 state because the crtc was
>>> still enabled.
>>>
>>> Fix this by calling restore_fbdev_mode when we would have called
>>> it otherwise once during initial fbdev setup.
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
>>
>> Please use dim fixes to get a more complete Cc: list for regression fixes.
>>
>>> Cc: # v4.14+
>>> Reported-by: Thomas Voegtle
>>
>> Reviewed-by: Daniel Vetter
>>
>> But please confirm with the reporter that it indeed fixes the issue before
>> pushing.
>> -Daniel
>
> I re-checked the latest version of the patch and it indeed fixes the problem.
>
> Thanks,
>
> Thomas
>
Pushed, thanks for the report. :)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Check and report if a subtest triggers a new kernel taint
== Series Details == Series: lib: Check and report if a subtest triggers a new kernel taint URL : https://patchwork.freedesktop.org/series/34616/ State : success == Summary == IGT patchset tested on top of latest successful build 643dc097156fa9a0ab9286c7c159459cfbe3079e Revert "lib/igt_aux: Make procps optional" with latest DRM-Tip kernel build CI_DRM_3407 05ece2ad7959 drm-tip: 2017y-11m-29d-13h-15m-55s UTC integration manifest No testlist changes. fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:389s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:522s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:284s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:505s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:492s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:476s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:431s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:357s fi-hsw-4770r total:288 pass:224 dwarn:0 dfail:0 fail:0 skip:64 time:261s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:483s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:485s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:535s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:477s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:592s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:543s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-skl-6700k total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:523s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:519s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:553s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:417s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:605s fi-glk-dsi total:63 pass:55 dwarn:0 dfail:0 fail:0 skip:7 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_564/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded
On Wed, Nov 29, 2017 at 02:30:30PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
>
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
>
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
>
> v2:
> * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> * Protect macro body with braces. (Jani Nikula)
>
> v3:
> * Add dedicated power domain for clarity. (Chris, Imre)
> * Commit message and comment text updates.
> * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
>
> v4:
> * Power domain should be inner to device runtime pm. (Chris)
> * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
> * Handle async DMC loading by moving the GT_IRQ power domain logic into
>intel_runtime_pm. (Daniel, Chris)
> * Include small core GEN9 as well. (Imre)
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak
> Acked-by: Chris Wilson (v2)
> Cc: Chris Wilson
> Cc: Dmitry Rogozhkin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
> drivers/gpu/drm/i915/intel_csr.c| 29 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 44
> +++--
> 5 files changed, 76 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..37b3da4fd0d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_AUX_D,
> POWER_DOMAIN_GMBUS,
> POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
>
> POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define GT_FREQUENCY_MULTIPLIER 50
> #define GEN9_FREQ_SCALER 3
>
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + ((dev_priv)->csr.dmc_payload && \
> + IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
> +
> #include "i915_trace.h"
>
> static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..a6f522e2d1a1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
>
> if (INTEL_GEN(dev_priv) >= 6)
> gen6_rps_idle(dev_priv);
> +
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> intel_runtime_pm_put(dev_priv);
> out_unlock:
> mutex_unlock(&dev_priv->drm.struct_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a90bdd26571f..c28a4ceb016d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
> GEM_BUG_ON(!i915->gt.active_requests);
>
> intel_runtime_pm_get_noresume(i915);
> +
> + /*
> + * It seems that the DMC likes to transition between the DC states a lot
> + * when there are no connected displays (no active power domains) during
> + * command submission.
> + *
> + * This activity has negative impact on the performance of the chip with
> + * huge latencies observed in the interrupt handler and elsewhere.
> + *
> + * Work around it by grabbing a GT IRQ power domain whilst there is any
> + * GT activity, preventing any DC state transitions.
> + */
> + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> +
> i915->gt.awake = true;
>
> intel_enable_gt_powersave(i915);
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 07e4f7bc4412..8b188e9f283b 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> *dev_priv,
>
> static void csr_load_work_fn(struct work_struct *work)
> {
> - struct drm_i915_private *dev_priv;
> - struct intel_csr *csr;
> + struct drm_i915_private *dev_priv =
> + container_of(work, typeof(*dev_priv), csr.work);
> + struct intel_csr *csr = &dev_priv->csr;
> const struct firmware *fw = NULL;
> +
Re: [Intel-gfx] [PATCH i-g-t 0/2] kms_plane: Enumerate outputs before planes
On Tue, Nov 21, 2017 at 09:52:52PM +0200, Imre Deak wrote: > Enumerate outputs before planes means we can avoid doing an extra > modeset when calculating the reference CRC during the test of each > plane. In addition when testing multiple outputs we can avoid a full > modeset we currently do whenever switching to a new output within a > subtest. This speeds up things especially on internal panels with long > power cycle delays. > > Below is the runtime of kms_plane on my GLK before and after the change. > I excluded from this the DPMS and suspend subtests, since those > transitions have a bigger overhead, unrelated to this change. Even better would be to push the modeset out of the subtests into igt_fixtures, so that we can amortize them over all subtests. Since somewhen in the future CI will run tests binaries-at-a-time, instead of subtests. That means we won't test all combinations of crtc/output, but for all the hw I know there's no difference really. Timestamps are a different story, but these tests here don't check for that. And yes we need to make these tests faster, especially on gen9 kms takes too long. Either way this improves a lot already, on both patches: Reviewed-by: Daniel Vetter > > With a single HDMI output: > 42s vs 26s > > With a single eDP output: > 115s vs 50s > > With eDP+HDMI output: > 171s vs 74s > > Imre Deak (2): > kms_plane: Enumerate outputs before planes in position subtests > kms_plane: Enumerate outputs before planes in panning subtests > > tests/kms_plane.c | 120 > +++--- > 1 file changed, 51 insertions(+), 69 deletions(-) > > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf
== Series Details == Series: meson: build a full dependency for lib_igt_perf URL : https://patchwork.freedesktop.org/series/34618/ State : failure == Summary == Series 34618 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded
On 29/11/2017 15:06, Imre Deak wrote:
On Wed, Nov 29, 2017 at 02:30:30PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.
This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.
Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.
v2:
* Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
* Protect macro body with braces. (Jani Nikula)
v3:
* Add dedicated power domain for clarity. (Chris, Imre)
* Commit message and comment text updates.
* Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
firmware release.
v4:
* Power domain should be inner to device runtime pm. (Chris)
* Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
* Handle async DMC loading by moving the GT_IRQ power domain logic into
intel_runtime_pm. (Daniel, Chris)
* Include small core GEN9 as well. (Imre)
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak
Acked-by: Chris Wilson (v2)
Cc: Chris Wilson
Cc: Dmitry Rogozhkin
---
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
drivers/gpu/drm/i915/intel_csr.c| 29 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 44 +++--
5 files changed, 76 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..37b3da4fd0d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+ ((dev_priv)->csr.dmc_payload && \
+IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
+
#include "i915_trace.h"
static inline bool intel_vtd_active(void)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..a6f522e2d1a1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
+ intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
intel_runtime_pm_put(dev_priv);
out_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..c28a4ceb016d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
intel_runtime_pm_get_noresume(i915);
+
+ /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+ intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
i915->gt.awake = true;
intel_enable_gt_powersave(i915);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 07e4f7bc4412..8b188e9f283b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
static void csr_load_work_fn(struct work_struct *work)
{
- struct drm_i915_private *dev_priv;
- struct intel_csr *csr;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv), csr.work);
+ struct intel_csr *csr = &dev_priv->csr;
const struct firmware *fw = NULL;
+ u32 *dmc_payload;
- dev_priv = container_of(work, typeof(*dev_priv), csr.work);
- csr = &dev_priv->csr;
+ r
[Intel-gfx] [PATCH v2 1/3] drm/i915: Fix vblank timestamp/frame counter jumps on gen2
From: Ville Syrjälä
Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.
These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.
Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.
v2: Less pointless duplication in the code (Chris)
Cc: sta...@vger.kernel.org
Cc: Daniel Vetter
Cc: Chris Wilson
Reviewed-by: Chris Wilson #v1
Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank
timestamps on gen2")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 51 +---
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f7dc7b7fed80..7280dd699316 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct
drm_i915_private *dev_priv,
return crtc->config->cpu_transcoder;
}
-static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
+static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
{
i915_reg_t reg = PIPEDSL(pipe);
u32 line1, line2;
@@ -1013,7 +1014,28 @@ static bool pipe_dsl_stopped(struct drm_i915_private
*dev_priv, enum pipe pipe)
msleep(5);
line2 = I915_READ(reg) & line_mask;
- return line1 == line2;
+ return line1 != line2;
+}
+
+static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Wait for the display line to settle/start moving */
+ if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
+ DRM_ERROR("pipe %c scanline %s wait timed out\n",
+ pipe_name(pipe), onoff(state));
+}
+
+static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, false);
+}
+
+static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, true);
}
/*
@@ -1036,7 +1058,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
*crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
- enum pipe pipe = crtc->pipe;
if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
@@ -1047,9 +1068,7 @@ static void intel_wait_for_pipe_off(struct intel_crtc
*crtc)
100))
WARN(1, "pipe_off wait timed out\n");
} else {
- /* Wait for the display line to settle */
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
- WARN(1, "pipe_off wait timed out\n");
+ intel_wait_for_pipe_scanline_stopped(crtc);
}
}
@@ -1862,15 +1881,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
POSTING_READ(reg);
/*
-* Until the pipe starts DSL will read as 0, which would cause
-* an apparent vblank timestamp jump, which messes up also the
-* frame count when it's derived from the timestamps. So let's
-* wait for the pipe to start properly before we call
-* drm_crtc_vblank_on()
+* Until the pipe starts PIPEDSL reads will return a stale value,
+* which causes an apparent vblank timestamp jump when PIPEDSL
+* resets to its proper value. That also messes up the frame count
+* when it's derived from the timestamps. So let's wait for the
+* pipe to start properly before we call drm_crtc_vblank_on()
*/
- if (dev->max_vblank_count == 0 &&
- wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset,
50))
- DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
+ if (dev->max_vblank_count == 0)
+ intel_wait_for_pipe_scanline_moving(crtc);
}
/**
@@ -14728,6 +14746,8 @@ void i830_enable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
void i830_disable
[Intel-gfx] [PATCH v2 2/3] drm/i915: Wait for pipe to start on i830 as well
From: Ville Syrjälä
We should make sure the pipe has fully started when we enable it from
the i830 "power well". Otherwise theoretically i830 could also hit
problems with vblank timestamps jumping around (since we skip the
wait during modeset on i830). Additionally moving planes between the
pipes etc. might not work correctly until both pipes are actually up and
running.
v2: Less pointless duplication in the code (Chris)
Cc: Chris Wilson
Reviewed-by: Chris Wilson #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7280dd699316..e7309d4d4992 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14679,6 +14679,7 @@ int intel_modeset_init(struct drm_device *dev)
void i830_enable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
/* 640x480@60Hz, ~25175 kHz */
struct dpll clock = {
.m1 = 18,
@@ -14742,6 +14743,8 @@ void i830_enable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
I915_WRITE(PIPECONF(pipe), PIPECONF_ENABLE | PIPECONF_PROGRESSIVE);
POSTING_READ(PIPECONF(pipe));
+
+ intel_wait_for_pipe_scanline_moving(crtc);
}
void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Pass crtc state to intel_pipe_{enable, disable}()
From: Ville Syrjälä
Get rid of the crtc->config usages from within
intel_pipe_{enable,disable}() by passing in the appropriate
crtc state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 76 +++-
1 file changed, 23 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e7309d4d4992..b547974b06bd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1038,28 +1038,14 @@ static void intel_wait_for_pipe_scanline_moving(struct
intel_crtc *crtc)
wait_for_pipe_scanline_moving(crtc, true);
}
-/*
- * intel_wait_for_pipe_off - wait for pipe to turn off
- * @crtc: crtc whose pipe to wait for
- *
- * After disabling a pipe, we can't wait for vblank in the usual way,
- * spinning on the vblank interrupt status bit, since we won't actually
- * see an interrupt when the pipe is disabled.
- *
- * On Gen4 and above:
- * wait for the pipe register state bit to turn off
- *
- * Otherwise:
- * wait for the display line value to settle (it usually
- * ends up stopping at the start of the next frame).
- *
- */
-static void intel_wait_for_pipe_off(struct intel_crtc *crtc)
+static void
+intel_wait_for_pipe_off(const struct intel_crtc_state *old_crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
if (INTEL_GEN(dev_priv) >= 4) {
+ enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
i915_reg_t reg = PIPECONF(cpu_transcoder);
/* Wait for the Pipe State to go off */
@@ -1828,19 +1814,12 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc
*crtc)
return crtc->pipe;
}
-/**
- * intel_enable_pipe - enable a pipe, asserting requirements
- * @crtc: crtc responsible for the pipe
- *
- * Enable @crtc's pipe, making sure that various hardware specific requirements
- * are met, if applicable, e.g. PLL enabled, LVDS pairs enabled, etc.
- */
-static void intel_enable_pipe(struct intel_crtc *crtc)
+static void intel_enable_pipe(const struct intel_crtc_state *new_crtc_state)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
- enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
i915_reg_t reg;
u32 val;
@@ -1854,12 +1833,12 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
* need the check.
*/
if (HAS_GMCH_DISPLAY(dev_priv)) {
- if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DSI))
+ if (intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
assert_dsi_pll_enabled(dev_priv);
else
assert_pll_enabled(dev_priv, pipe);
} else {
- if (crtc->config->has_pch_encoder) {
+ if (new_crtc_state->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv,
intel_crtc_pch_transcoder(crtc));
@@ -1887,24 +1866,15 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
* when it's derived from the timestamps. So let's wait for the
* pipe to start properly before we call drm_crtc_vblank_on()
*/
- if (dev->max_vblank_count == 0)
+ if (dev_priv->drm.max_vblank_count == 0)
intel_wait_for_pipe_scanline_moving(crtc);
}
-/**
- * intel_disable_pipe - disable a pipe, asserting requirements
- * @crtc: crtc whose pipes is to be disabled
- *
- * Disable the pipe of @crtc, making sure that various hardware
- * specific requirements are met, if applicable, e.g. plane
- * disabled, panel fitter off, etc.
- *
- * Will wait until the pipe has shut down before returning.
- */
-static void intel_disable_pipe(struct intel_crtc *crtc)
+static void intel_disable_pipe(const struct intel_crtc_state *old_crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+ enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 val;
@@ -1926,7 +1896,7 @@ static void intel_disable_pipe(struct intel_crtc *crtc)
* Double wide has implications for planes
* so best keep it
[Intel-gfx] [PATCH 0/2] lockdep cross-release fallout from -rc1
Hi all, -rc1 set our CI on fire with a pile of issues that cross-release highlights. The two patches in this series get things back into working order on our side, so we pulled them into our local branches to unblock CI and drm/i915. But they're ofc far from polished, so pls look at this more as a bug report than bugfix submission :-) Cheers, Daniel Daniel Vetter (2): lockdep: finer-grained completion key for kthread lockdep: Up MAX_LOCKDEP_CHAINS include/linux/kthread.h| 48 ++ kernel/kthread.c | 70 ++ kernel/locking/lockdep_internals.h | 2 +- 3 files changed, 91 insertions(+), 29 deletions(-) -- 2.15.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] lockdep: finer-grained completion key for kthread
Ideally we'd create the key through a macro at the real callers and
pass it all the way down. This would give us better coverage for cases
where a bunch of kthreads are created for the same thing.
But this gets the job done meanwhile and unblocks our CI. Refining
later on is always possible.
v2:
- make it compile
- use the right map (Tvrtko)
v3:
lockdep insist on a static key, so the cheap way didn't work. Wire
2 keys through all the callers.
I didn't extend this up to alloc_workqueue because the
lockdep_invariant_state() call should separate the work functions from
the workqueue kthread logic and prevent cross-release state from
leaking between unrelated work queues that happen to reuse the same
kthreads.
v4: CI found more compile fail :-/
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter
---
include/linux/kthread.h | 48 -
kernel/kthread.c| 70 ++---
2 files changed, 90 insertions(+), 28 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..7a9463f0be5c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
#include
#include
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
void *data,
int node,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
/**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int
(*threadfn)(void *data),
*/
#define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_node(threadfn, data, node, &__exited_key,\
+ &__parked_key, namefmt, ##arg); \
+})
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
void *data,
unsigned int cpu,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+ &__parked_key, namefmt); \
+})
+
/**
* kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
int kthread_worker_fn(void *worker_ptr);
-__printf(2, 3)
+__printf(4, 5)
struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
+ const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)
\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker(flags, &__exited_key, &__parked_key, \
+ ##namefmt); \
+})
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker_on_cpu(cpu, flags, &__exited_key, &__parked_key,\
+ ##namefmt); \
+})
bool kthread_queue_work(struct kthread_worker *worker,
[Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
cross-release ftl
From Chris:
"Fwiw, this isn't cross-release but us reloading the module many times,
creating a whole host of new lockclasses. Even more fun is when the
module gets a slightly different address and the new lock address hashes
into an old lock...
"I did think about a module-hook to revoke the stale lockclasses, but
that still leaves all the hashed chains.
"This particular nuisance was temporarily pushed back by teaching igt not
to reload i915.ko on a whim."
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter
---
kernel/locking/lockdep_internals.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep_internals.h
b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
#else
#define MAX_LOCKDEP_ENTRIES32768UL
-#define MAX_LOCKDEP_CHAINS_BITS16
+#define MAX_LOCKDEP_CHAINS_BITS17
/*
* Stack-trace: tightly packed array of stack backtrace
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Fix vblank timestamp/frame counter jumps on gen2
Quoting Ville Syrjala (2017-11-29 15:37:30)
> From: Ville Syrjälä
>
> Previously I was under the impression that the scanline counter
> reads 0 when the pipe is off. Turns out that's not correct, and
> instead the scanline counter simply stops when the pipe stops, and
> it retains it's last value until the pipe starts up again, at which
> point the scanline counter jumps to vblank start.
>
> These jumps can cause the timestamp to jump backwards by one frame.
> Since we use the timestamps to guesstimage also the frame counter
> value on gen2, that would cause the frame counter to also jump
> backwards, which leads to a massice difference from the previous value.
> The end result is that flips/vblank events don't appear to complete as
> they're stuck waiting for the frame counter to catch up to that massive
> difference.
>
> Fix the problem properly by actually making sure the scanline counter
> has started to move before we assume that it's safe to enable vblank
> processing.
>
> v2: Less pointless duplication in the code (Chris)
>
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson #v1
> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank
> timestamps on gen2")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Wait for pipe to start on i830 as well
Quoting Ville Syrjala (2017-11-29 15:37:31) > From: Ville Syrjälä > > We should make sure the pipe has fully started when we enable it from > the i830 "power well". Otherwise theoretically i830 could also hit > problems with vblank timestamps jumping around (since we skip the > wait during modeset on i830). Additionally moving planes between the > pipes etc. might not work correctly until both pipes are actually up and > running. > > v2: Less pointless duplication in the code (Chris) > > Cc: Chris Wilson > Reviewed-by: Chris Wilson #v1 > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Pass crtc state to intel_pipe_{enable, disable}()
Quoting Ville Syrjala (2017-11-29 15:37:32)
> From: Ville Syrjälä
>
> Get rid of the crtc->config usages from within
> intel_pipe_{enable,disable}() by passing in the appropriate
> crtc state.
>
> Signed-off-by: Ville Syrjälä
Looks mechanical, so I hope I didn't miss anything important,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
