[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Do not set the eDP link rate/lane count to max
== Series Details == Series: drm/i915/dp: Do not set the eDP link rate/lane count to max URL : https://patchwork.freedesktop.org/series/39662/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3381 pass:1778 dwarn:1 dfail:0 fail:9 skip:1591 time:11692s shard-hswtotal:3467 pass:1773 dwarn:1 dfail:0 fail:1 skip:1691 time:11685s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6806s Blacklisted hosts: shard-kbltotal:3394 pass:1857 dwarn:2 dfail:0 fail:9 skip:1525 time:8586s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8286/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/15] drm/i915/guc: Merge log relay file and channel creation
Hi Michal,
One comment was missed and another comment update suggested.
On 3/8/2018 9:16 PM, Michał Winiarski wrote:
We have all the information we need at relay_open call time.
Since there's no reason to split the process into relay_open and
relay_late_setup_files, let's remove the extra code.
v2: Remove obsoleted comments (Sagar)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc_log.c | 64 +++-
1 file changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 4eb3ebd8d6c3..ee0981f5a208 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -121,14 +121,7 @@ static struct dentry *create_buf_file_callback(const char
*filename,
if (!parent)
return NULL;
- /*
-* Not using the channel filename passed as an argument, since for each
-* channel relay appends the corresponding CPU number to the filename
-* passed in relay_open(). This should be fine as relay just needs a
-* dentry of the file associated with the channel buffer and that file's
-* name need not be same as the filename passed as an argument.
-*/
- buf_file = debugfs_create_file("guc_log", mode,
+ buf_file = debugfs_create_file(filename, mode,
parent, buf, &relay_file_operations);
return buf_file;
}
@@ -149,43 +142,6 @@ static struct rchan_callbacks relay_callbacks = {
.remove_buf_file = remove_buf_file_callback,
};
-static int guc_log_relay_file_create(struct intel_guc *guc)
-{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
- struct dentry *log_dir;
- int ret;
-
- lockdep_assert_held(&guc->log.runtime.lock);
-
- /* For now create the log file in /sys/kernel/debug/dri/0 dir */
- log_dir = dev_priv->drm.primary->debugfs_root;
-
- /*
-* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
-* not mounted and so can't create the relay file.
-* The relay API seems to fit well with debugfs only, for availing relay
-* there are 3 requirements which can be met for debugfs file only in a
-* straightforward/clean manner :-
-* i) Need the associated dentry pointer of the file, while opening
the
-* relay channel.
-* ii) Should be able to use 'relay_file_operations' fops for the file.
-* iii) Set the 'i_private' field of file's inode to the pointer of
-* relay channel buffer.
-*/
- if (!log_dir) {
- DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
- return -ENODEV;
- }
-
- ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log",
log_dir);
- if (ret < 0 && ret != -EEXIST) {
- DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
static void guc_move_to_next_buf(struct intel_guc *guc)
{
/*
@@ -271,7 +227,6 @@ static void guc_read_update_log_buffer(struct intel_guc
*guc)
/* Get the pointer to shared GuC log buffer */
log_buf_state = src_data = guc->log.runtime.buf_addr;
-
/* Get the pointer to local buffer to store the logs */
log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
@@ -443,8 +398,10 @@ static int guc_log_relay_create(struct intel_guc *guc)
* the GuC firmware logs, the channel will be linked with a file
* later on when debugfs is registered.
*/
Above comment needs to be removed/updated.
- guc_log_relay_chan = relay_open(NULL, NULL, subbuf_size,
- n_subbufs, &relay_callbacks, dev_priv);
+ guc_log_relay_chan = relay_open("guc_log",
+ dev_priv->drm.primary->debugfs_root,
+ subbuf_size, n_subbufs,
+ &relay_callbacks, dev_priv);
if (!guc_log_relay_chan) {
DRM_ERROR("Couldn't create relay chan for GuC logging\n");
@@ -649,11 +606,6 @@ int intel_guc_log_register(struct intel_guc *guc)
GEM_BUG_ON(guc_log_has_runtime(guc));
- /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/
May be this comment should not have been added as part of patch 5/15
ret = guc_log_relay_create(guc);
if (ret)
goto err;
@@ -662,18 +614,12 @@ int intel_guc_log_register(struct intel_guc *guc)
if (ret)
goto err_relay;
- ret = guc_log_relay_
[Intel-gfx] [PATCH v13 02/17] drm/i915/skl+: refactor WM calculation for NV12
From: Mahesh Kumar
Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.
v2: Addressed review comments by Maarten
v3: Rebased and addressed review comments by Maarten
v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 121 ---
3 files changed, 66 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0775e33..5abbd04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1451,8 +1451,9 @@ static inline bool skl_ddb_entry_equal(const struct
skl_ddb_entry *e1,
}
struct skl_ddb_allocation {
- struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /*
packed/uv */
- struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+ /* packed/y */
+ struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
+ struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
};
struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 75969ce..18930ad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -599,6 +599,7 @@ struct intel_pipe_wm {
struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+ bool is_planar;
};
struct skl_pipe_wm {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 797fe4d..31ef5c8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4009,9 +4009,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
*intel_crtc,
static unsigned int
skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
-int y)
+const int plane)
{
- struct intel_plane *plane = to_intel_plane(pstate->plane);
+ struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t data_rate;
uint32_t width = 0, height = 0;
@@ -4025,9 +4025,9 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
- if (plane->id == PLANE_CURSOR)
+ if (intel_plane->id == PLANE_CURSOR)
return 0;
- if (y && format != DRM_FORMAT_NV12)
+ if (plane == 1 && format != DRM_FORMAT_NV12)
return 0;
/*
@@ -4038,19 +4038,14 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
width = drm_rect_width(&intel_pstate->base.src) >> 16;
height = drm_rect_height(&intel_pstate->base.src) >> 16;
- /* for planar format */
- if (format == DRM_FORMAT_NV12) {
- if (y) /* y-plane data rate */
- data_rate = width * height *
- fb->format->cpp[0];
- else/* uv-plane data rate */
- data_rate = (width / 2) * (height / 2) *
- fb->format->cpp[1];
- } else {
- /* for packed formats */
- data_rate = width * height * fb->format->cpp[0];
+ /* UV plane does 1/2 pixel sub-sampling */
+ if (plane == 1 && format == DRM_FORMAT_NV12) {
+ width /= 2;
+ height /= 2;
}
+ data_rate = width * height * fb->format->cpp[plane];
+
down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
@@ -4063,8 +4058,8 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
*/
static unsigned int
skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
-unsigned *plane_data_rate,
-unsigned *plane_y_data_rate)
+unsigned int *plane_data_rate,
+unsigned int *uv_plane_data_rate)
{
struct drm_crtc_state *cstate = &intel_cstate->base;
struct drm_atomic_state *state = cstate->state;
@@ -4080,17 +4075,17 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
enum plane_id plane_id = to_intel_plane(plane)->id;
unsigned int rate;
- /* packed/uv */
+ /* packed/y */
rate = skl_plane_relative_data_rate(intel_cstate,
[Intel-gfx] [PATCH v13 09/17] drm/i915/skl: split skl_compute_ddb function
From: Mahesh Kumar
This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.
v2: Added reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 157 ++--
1 file changed, 88 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6476768..2c75a0d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5059,69 +5059,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state
*cstate)
static int
skl_compute_ddb(struct drm_atomic_state *state)
{
- struct drm_device *dev = state->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = &intel_state->wm_results.ddb;
- uint32_t realloc_pipes = pipes_modified(state);
- int ret;
-
- /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us. Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
- if (dev_priv->wm.distrust_bios_wm) {
- ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
- state->acquire_ctx);
- if (ret)
- return ret;
-
- intel_state->active_pipe_changes = ~0;
-
- /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
- if (!intel_state->modeset)
- intel_state->active_crtcs = dev_priv->active_crtcs;
- }
-
- /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit. Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
- if (intel_state->active_pipe_changes) {
- realloc_pipes = ~0;
- intel_state->wm_results.dirty_pipes = ~0;
- }
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *cstate;
+ int ret, i;
- /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, &dev_priv->wm.skl_hw.ddb, sizeof(*ddb));
- for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
- struct intel_crtc_state *cstate;
-
- cstate = intel_atomic_get_crtc_state(state, intel_crtc);
- if (IS_ERR(cstate))
- return PTR_ERR(cstate);
-
+ for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5183,23 +5130,23 @@ skl_print_wm_changes(const struct drm_atomic_state
*state)
}
static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
{
- struct drm_crtc *crtc;
- struct drm_crtc_state *cstate;
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct skl_ddb_values *results = &intel_state->wm_results;
struct drm_device *dev = state->dev;
- struct skl_pipe_wm *pipe_wm;
- bool changed = false;
+ const struct drm_i915_private *dev_priv = to_i915(dev);
+ const struct drm_crtc *crtc;
+ const struct drm_crtc_state *cstate;
+ struct intel_crtc *intel_crtc;
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ uint32_t realloc_pipes = pipes_modified(state);
int ret, i;
/*
* When we distrust bios wm we always need to recompute to set the
* expected DDB allocations for each CRTC.
*/
- if (to_i915(dev)->wm.distrust_bios
[Intel-gfx] [PATCH v13 03/17] drm/i915/skl+: add NV12 in skl_format_to_fourcc
From: Mahesh Kumar
Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.
v2: Added reviewed by tag from Mika Kahola
Reviewed-by: Mika Kahola
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3310840..ca19b42 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2662,6 +2662,8 @@ static int skl_format_to_fourcc(int format, bool
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+ case PLANE_CTL_FORMAT_NV12:
+ return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 15/17] drm/i915: Add NV12 support to intel_framebuffer_init
From: Chandra Konduru
This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.
v2:
-Fix an issue in checks added (Chandra Konduru)
v3: rebased (me)
v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case
v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.
v6: Rebased (me)
v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.
v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.
v9: Rebased (me)
v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable
v11: Addressed review comments from Shashank Sharma
v12: Adding Reviewed By from Shashank Sharma
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Tested-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d668eff..763ae1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14201,6 +14201,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
break;
+ case DRM_FORMAT_NV12:
+ if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv)) {
+ DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+
drm_get_format_name(mode_cmd->pixel_format,
+ &format_name));
+ goto err;
+ }
+ break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
drm_get_format_name(mode_cmd->pixel_format,
&format_name));
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 01/17] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
From: Mahesh Kumar
skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.
s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe
Changes since V1:
- also change name of skl_copy_wm_for_pipe
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 16
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..0775e33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1455,7 +1455,7 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
};
-struct skl_wm_values {
+struct skl_ddb_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
};
@@ -2151,7 +2151,7 @@ struct drm_i915_private {
/* current hardware state */
union {
struct ilk_wm_values hw;
- struct skl_wm_values skl_hw;
+ struct skl_ddb_values skl_hw;
struct vlv_wm_values vlv;
struct g4x_wm_values g4x;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..75969ce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,7 +482,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
/* Gen9+ only */
- struct skl_wm_values wm_results;
+ struct skl_ddb_values wm_results;
struct i915_sw_fence commit_ready;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6cab20c..797fe4d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5042,9 +5042,9 @@ skl_compute_ddb(struct drm_atomic_state *state)
}
static void
-skl_copy_wm_for_pipe(struct skl_wm_values *dst,
-struct skl_wm_values *src,
-enum pipe pipe)
+skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
+ struct skl_ddb_values *src,
+ enum pipe pipe)
{
memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
sizeof(dst->ddb.y_plane[pipe]));
@@ -5095,7 +5095,7 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct skl_wm_values *results = &intel_state->wm_results;
+ struct skl_ddb_values *results = &intel_state->wm_results;
struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
@@ -5197,8 +5197,8 @@ static void skl_initial_wm(struct intel_atomic_state
*state,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct skl_wm_values *results = &state->wm_results;
- struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
+ struct skl_ddb_values *results = &state->wm_results;
+ struct skl_ddb_values *hw_vals = &dev_priv->wm.skl_hw;
enum pipe pipe = intel_crtc->pipe;
if ((results->dirty_pipes & drm_crtc_mask(&intel_crtc->base)) == 0)
@@ -5209,7 +5209,7 @@ static void skl_initial_wm(struct intel_atomic_state
*state,
if (cstate->base.active_changed)
skl_atomic_update_crtc_wm(state, cstate);
- skl_copy_wm_for_pipe(hw_vals, results, pipe);
+ skl_copy_ddb_for_pipe(hw_vals, results, pipe);
mutex_unlock(&dev_priv->wm.wm_mutex);
}
@@ -5341,7 +5341,7 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
void skl_wm_get_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct skl_wm_values *hw = &dev_priv->wm.skl_hw;
+ struct skl_ddb_values *hw = &dev_priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 00/17] Add NV12 support
This patch series is adding NV12 support for Broxton display after rebasing on latest drm-tip. Initial series of the patches can be found here: https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html Previous revision history: The first version of patches were reviewed when floated by Chandra in 2015 but currently there was a design change with respect to - the way fb offset is handled - the way rotation is handled Current NV12 patch series has been ported as per the current changes on drm-tip Review comments from Ville (12th June 2017) have been addressed Review comments from Clinton A Taylor (7th July 2017) have been addressed Review comments from Clinton A Taylor (10th July 2017) have been addressed. Had missed out tested-by/reviewed-by in the patches. Fixed that error in this series. Review comments from Ville (11th July 2017) addressed. Review comments from Paauwe, Bob (29th July 2017) addressed. Update from rev 28 Aug 2017 Rebased the series. Tested with IGT for rotation, sprite and tiling combinations. IGT Links: https://patchwork.kernel.org/patch/9995943/ https://patchwork.kernel.org/patch/9995945/ Review comments by Maarten are addressed in this series. NV12 enabled for Gen10. Review comments from Shashank Sharma are addressed. IGT debug_fs test failure fixed. Added reviewed-by tag from Shashank Sharma for few patches Addressed comments from Juha-Pekka Heikkila in few patches (NV12 not to be supported for SKL) Adding an additional patch Display WA 827 for underrun during NV12 Adding more WA implementation to see if it helps underruns Update from previous series: Rebased the series Addressed review comments from Ville regarding the planar formats Added minimum src height for yuv 420 planar formats Added NV12 in skl_mod_supported Chandra Konduru (6): drm/i915: Set scaler mode for NV12 drm/i915: Update format_is_yuv() to include NV12 drm/i915: Upscale scaler max scale for NV12 drm/i915: Add NV12 as supported format for primary plane drm/i915: Add NV12 as supported format for sprite plane drm/i915: Add NV12 support to intel_framebuffer_init Mahesh Kumar (9): drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values drm/i915/skl+: refactor WM calculation for NV12 drm/i915/skl+: add NV12 in skl_format_to_fourcc drm/i915/skl+: support verification of DDB HW state for NV12 drm/i915/skl+: NV12 related changes for WM drm/i915/skl+: pass skl_wm_level struct to wm compute func drm/i915/skl+: make sure higher latency level has higher wm value drm/i915/skl+: nv12 workaround disable WM level 1-7 drm/i915/skl: split skl_compute_ddb function Vidya Srinivas (2): drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg drm/i915: Display WA 827 drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_atomic.c | 14 +- drivers/gpu/drm/i915/intel_display.c | 179 +++--- drivers/gpu/drm/i915/intel_drv.h | 12 +- drivers/gpu/drm/i915/intel_pm.c | 438 ++- drivers/gpu/drm/i915/intel_sprite.c | 28 ++- 7 files changed, 486 insertions(+), 200 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 14/17] drm/i915: Add NV12 as supported format for sprite plane
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.
v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B
v7: Rebased (me)
v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.
v11: Addressed review comments from Shashank Sharma
v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.
v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported
Tested-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_sprite.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a6e4ea5..3651fe4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1250,6 +1250,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
};
+static uint32_t skl_planar_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1344,6 +1357,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -1443,8 +1457,14 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- plane_formats = skl_plane_formats;
- num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+ plane_formats = skl_planar_formats;
+ num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+ } else {
+ plane_formats = skl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ }
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 07/17] drm/i915/skl+: make sure higher latency level has higher wm value
From: Mahesh Kumar
DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.
v2: Changed plane_num to plane_id in skl_compute_wm_levels
v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"
v4: Added reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 90bf446..efa3367 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,6 +4529,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+ const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
{
const struct drm_plane_state *pstate = &intel_pstate->base;
@@ -4596,6 +4597,15 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+ /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+ if (result_prev->plane_res_b > res_blocks)
+ res_blocks = result_prev->plane_res_b;
}
if (INTEL_GEN(dev_priv) >= 11) {
@@ -4679,6 +4689,13 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_id ? &wm->uv_wm[level] :
&wm->wm[level];
+ struct skl_wm_level *result_prev;
+
+ if (level)
+ result_prev = plane_id ? &wm->uv_wm[level - 1] :
+ &wm->wm[level - 1];
+ else
+ result_prev = plane_id ? &wm->uv_wm[0] : &wm->wm[0];
ret = skl_compute_plane_wm(dev_priv,
cstate,
@@ -4686,6 +4703,7 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
ddb_blocks,
level,
wm_params,
+ result_prev,
result);
if (ret)
return ret;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 04/17] drm/i915/skl+: support verification of DDB HW state for NV12
From: Mahesh Kumar
For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.
v2: Addressed review comments by Maarten.
v3: Addressed review comments by Shashank Sharma.
v4: Adding reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 51 +---
3 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ca19b42..34f7225 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2657,7 +2657,7 @@ static int i9xx_format_to_fourcc(int format)
}
}
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
{
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 18930ad..dffe875 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1608,6 +1608,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb,
int plane,
int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 31ef5c8..ae91c7a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3825,6 +3825,44 @@ static void skl_ddb_entry_init_from_hw(struct
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
}
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+ const enum pipe pipe,
+ const enum plane_id plane_id,
+ struct skl_ddb_allocation *ddb /* out */)
+{
+ u32 val, val2 = 0;
+ int fourcc, pixel_format;
+
+ /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+ if (plane_id == PLANE_CURSOR) {
+ val = I915_READ(CUR_BUF_CFG(pipe));
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val);
+ return;
+ }
+
+ val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+ /* No DDB allocated for disabled planes */
+ if (!(val & PLANE_CTL_ENABLE))
+ return;
+
+ pixel_format = val & PLANE_CTL_FORMAT_MASK;
+ fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+ val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+ val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+ if (fourcc == DRM_FORMAT_NV12) {
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val2);
+ skl_ddb_entry_init_from_hw(&ddb->uv_plane[pipe][plane_id], val);
+ } else {
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id], val);
+ }
+}
+
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */)
{
@@ -3841,16 +3879,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
- for_each_plane_id_on_crtc(crtc, plane_id) {
- u32 val;
-
- if (plane_id != PLANE_CURSOR)
- val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
- else
- val = I915_READ(CUR_BUF_CFG(pipe));
-
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
val);
- }
+ for_each_plane_id_on_crtc(crtc, plane_id)
+ skl_ddb_get_hw_plane_state(dev_priv, pipe,
+ plane_id, ddb);
intel_display_power_put(dev_priv, power_domain);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 08/17] drm/i915/skl+: nv12 workaround disable WM level 1-7
From: Mahesh Kumar
Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.
v2: Addressed review comments by Maarten.
v3: Adding reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index efa3367..6476768 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4653,6 +4653,17 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
}
}
+ /*
+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+ if (wp->is_planar && level >= 1 &&
+ (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
+ result->plane_en = false;
+ return 0;
+ }
+
/* The number of lines are ignored for the level 0 watermark. */
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
From: Chandra Konduru
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series
v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Rebased (me)
v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.
v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.
v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.
Tested-by: Clinton Taylor
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Uma Shankar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 78 ++--
drivers/gpu/drm/i915/intel_drv.h | 4 +-
drivers/gpu/drm/i915/intel_sprite.c | 3 +-
3 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 34f7225..7fd8354 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+ case DRM_FORMAT_NV12:
+ return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct drm_device *dev,
int pipe)
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ bool plane_scaler_check,
+ uint32_t pixel_format)
{
struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
@@ -4723,6 +4727,10 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (plane_scaler_check)
+ if (pixel_format == DRM_FORMAT_NV12)
+ need_scaling = true;
+
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4763,17 +4771,32 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
}
/* range checks */
- if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
- dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
-
- src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
- dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H) {
- DRM_DEBUG_KMS("scaler_user index %u.%u: src %ux%u dst %ux%u "
- "size is out of scaler range\n",
- intel_crtc->pipe, scaler_user, src_w, src_h, dst_w,
dst_h);
- return -EINVAL;
- }
-
+ if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12) {
+ if (src_h > SKL_MIN_YUV_420_SRC_H)
+ goto check_scaler_range;
+ else
+ goto failed_range;
+ } else {
+ if (src_h >= SKL_MIN_SRC_H)
+ goto check_scaler_range;
+ else
+ goto failed_range;
+ }
+check_scaler_range:
+ if (src_w >= SKL_MIN_SRC_W || dst_w >= SKL_MIN_DST_W ||
+ dst_h >= SKL_MIN_DST_H || src_w <= SKL_MAX_SRC_W ||
+ src_h <= SKL_MAX_SRC_H || dst_w <= SKL_MAX_DST_W ||
+ dst_h <= SKL_MAX_DST_H)
+ goto scaler_range_ok;
+
+failed_range:
+ DRM_DEBUG_KMS("scaler_user index %u.%u: src %ux%u dst %ux%u "
+ "size is out of scaler range\n",
+ intel_crtc->pipe, scaler_u
[Intel-gfx] [PATCH v13 11/17] drm/i915: Update format_is_yuv() to include NV12
From: Chandra Konduru This patch adds NV12 to format_is_yuv() function for sprite planes. v2: -Use intel_ prefix for format_is_yuv (Ville) v3: Rebased (me) v4: Rebased and addressed review comments from Clinton A Taylor. "static function in intel_sprite.c is not available to the primary plane functions". Changed commit message - function modified for sprite planes. v5: Missed the Tested-by/Reviewed-by in the previous series Adding the same to commit message in this version. v6: Rebased (me) v7: Rebased (me) v8: Rebased (me) v9: Rebased (me) v10: Changed intel_format_is_yuv function from static to non-static. We need to use it later from other files for check. v11: Rebased the patch. format_is_yuv has already been renamed to intel_format_is_yuv in the color patch series which is already merged. This function which was previously static has already been made non-static. So this patch after rebase just adds NV12 to intel_format_is_yuv function. Tested-by: Clinton Taylor Reviewed-by: Clinton Taylor Reviewed-by: Shashank Sharma Signed-off-by: Chandra Konduru Signed-off-by: Nabendu Maiti Signed-off-by: Vidya Srinivas --- drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_sprite.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index e5c17f5..483f6ce 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -2049,6 +2049,7 @@ void skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc); bool skl_plane_get_hw_state(struct intel_plane *plane); bool skl_plane_has_ccs(struct drm_i915_private *dev_priv, enum pipe pipe, enum plane_id plane_id); +bool intel_format_is_yuv(uint32_t format); /* intel_tv.c */ void intel_tv_init(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index dbdcf85..0652e58 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -48,6 +48,7 @@ bool intel_format_is_yuv(u32 format) case DRM_FORMAT_UYVY: case DRM_FORMAT_VYUY: case DRM_FORMAT_YVYU: + case DRM_FORMAT_NV12: return true; default: return false; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 13/17] drm/i915: Add NV12 as supported format for primary plane
From: Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Rebased (me)
v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)
v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.
v11: Adding Reviewed By tag from Shashank Sharma
v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported.
Tested-by: Clinton Taylor
Reviewed-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 50 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7fd8354..d668eff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint32_t skl_pri_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13074,6 +13090,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -13280,6 +13297,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
}
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+ if (plane_id == PLANE_PRIMARY) {
+ if (IS_SKYLAKE(dev_priv))
+ return false;
+ else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+ !IS_GEMINILAKE(dev_priv))
+ return false;
+ } else if (plane_id >= PLANE_SPRITE0) {
+ if (plane_id == PLANE_CURSOR)
+ return false;
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+ if (plane_id != PLANE_SPRITE0)
+ return false;
+ } else {
+ if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+ IS_SKYLAKE(dev_priv))
+ return false;
+ }
+ }
+ return true;
+}
+
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
@@ -13340,8 +13381,13 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
if (INTEL_GEN(dev_priv) >= 9) {
- intel_primary_formats = skl_primary_formats;
- num_formats = ARRAY_SIZE(skl_primary_formats);
+ if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ intel_primary_formats = skl_pri_planar_formats;
+ num_formats = ARRAY_SIZE(skl_pri_planar_formats);
+ } else {
+ intel_primary_formats = skl_primary_formats;
+ num_formats = ARRAY_SIZE(skl_primary_formats);
+ }
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
modifiers = skl_format_modifiers_ccs;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dadfa09..31ef593 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2052,6 +2052,8 @@ bool skl_plane_get_hw_state(struct intel_plane *plane);
bool skl_plane_has_ccs(struct drm_i9
[Intel-gfx] [PATCH v13 05/17] drm/i915/skl+: NV12 related changes for WM
From: Mahesh Kumar
NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.
v2: Addressed review comments from Shashank Sharma.
v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 50 +---
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5abbd04..11551f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1471,6 +1471,7 @@ struct skl_wm_level {
struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
+ bool is_planar;
uint32_t width;
uint8_t cpp;
uint32_t plane_pixel_rate;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dffe875..e5c17f5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -598,6 +598,7 @@ struct intel_pipe_wm {
struct skl_plane_wm {
struct skl_wm_level wm[8];
+ struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
bool is_planar;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ae91c7a..8c612ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4419,7 +4419,7 @@ static int
skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
- struct skl_wm_params *wp)
+ struct skl_wm_params *wp, int plane_id)
{
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = &intel_pstate->base;
@@ -4432,6 +4432,12 @@ skl_compute_plane_wm_params(const struct
drm_i915_private *dev_priv,
if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
+ /* only NV12 format has two planes */
+ if (plane_id == 1 && fb->format->format != DRM_FORMAT_NV12) {
+ DRM_DEBUG_KMS("Non NV12 format have single plane\n");
+ return -EINVAL;
+ }
+
wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
@@ -4439,6 +4445,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private
*dev_priv,
wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+ wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
@@ -4451,7 +4458,10 @@ skl_compute_plane_wm_params(const struct
drm_i915_private *dev_priv,
wp->width = drm_rect_width(&intel_pstate->base.src) >> 16;
}
- wp->cpp = fb->format->cpp[0];
+ if (plane_id == 1 && wp->is_planar)
+ wp->width /= 2;
+
+ wp->cpp = fb->format->cpp[plane_id];
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
intel_pstate);
@@ -4649,7 +4659,8 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
const struct skl_wm_params *wm_params,
- struct skl_plane_wm *wm)
+ struct skl_plane_wm *wm,
+ int plane_id)
{
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_plane *plane = intel_pstate->base.plane;
@@ -4657,15 +4668,19 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int level, max_level = ilk_wm_max_level(dev_priv);
+ enum plane_id intel_plane_id = intel_plane->id;
int ret;
if (WARN_ON(!intel_pstate->base.fb))
return -EINVAL;
- ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][intel_plane->id]);
+ ddb_blocks = plane_id ?
+skl_ddb_entry_size(&ddb->uv_plane[pipe][intel_plane_id]) :
+skl_ddb_entry_size(&ddb->plane[pipe][intel_plane_id]);
for (level = 0; level <= max_level; level++) {
- struct sk
[Intel-gfx] [PATCH v13 06/17] drm/i915/skl+: pass skl_wm_level struct to wm compute func
From: Mahesh Kumar
This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.
v2: Addressed review comments by Shashank Sharma
v3: Adding reviewed by tag from Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_pm.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8c612ae..90bf446 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,9 +4529,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
- uint16_t *out_blocks, /* out */
- uint8_t *out_lines, /* out */
- bool *enabled /* out */)
+ struct skl_wm_level *result /* out */)
{
const struct drm_plane_state *pstate = &intel_pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
@@ -4545,7 +4543,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
- *enabled = false;
+ result->plane_en = false;
return 0;
}
@@ -4626,7 +4624,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if ((level > 0 && res_lines > 31) ||
res_blocks >= ddb_allocation ||
min_disp_buf_needed >= ddb_allocation) {
- *enabled = false;
+ result->plane_en = false;
/*
* If there are no valid level 0 watermarks, then we can't
@@ -4646,9 +4644,9 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
}
/* The number of lines are ignored for the level 0 watermark. */
- *out_lines = level ? res_lines : 0;
- *out_blocks = res_blocks;
- *enabled = true;
+ result->plane_res_b = res_blocks;
+ result->plane_res_l = res_lines;
+ result->plane_en = true;
return 0;
}
@@ -4688,9 +4686,7 @@ skl_compute_wm_levels(const struct drm_i915_private
*dev_priv,
ddb_blocks,
level,
wm_params,
- &result->plane_res_b,
- &result->plane_res_l,
- &result->plane_en);
+ result);
if (ret)
return ret;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 10/17] drm/i915: Set scaler mode for NV12
From: Chandra Konduru
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3: Rebased (me)
v4: Rebased (me)
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.
v9: Rebased (me)
v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.
v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.
v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr
Tested-by: Clinton Taylor
Reviewed-by: Shashank Sharma
Reviewed-by: Clinton Taylor
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_atomic.c | 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86e..8e61b68 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6764,6 +6764,8 @@ enum {
#define PS_SCALER_MODE_MASK (3 << 28)
#define PS_SCALER_MODE_DYN (0 << 28)
#define PS_SCALER_MODE_HQ (1 << 28)
+#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
#define PS_PLANE_SEL_MASK (7 << 25)
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index e9fb6920..bb8c168 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -328,8 +328,18 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
}
/* set scaler mode */
- if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
- scaler_state->scalers[*scaler_id].mode = 0;
+ if ((INTEL_GEN(dev_priv) >= 9) &&
+ plane_state && plane_state->base.fb &&
+ plane_state->base.fb->format->format ==
+ DRM_FORMAT_NV12) {
+ if (INTEL_GEN(dev_priv) == 9 &&
+ !IS_GEMINILAKE(dev_priv) &&
+ !IS_SKYLAKE(dev_priv))
+ scaler_state->scalers[*scaler_id].mode =
+ SKL_PS_SCALER_MODE_NV12;
+ else
+ scaler_state->scalers[*scaler_id].mode =
+ PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C)
{
/*
* when only 1 scaler is in use on either pipe A or B,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 17/17] drm/i915: Display WA 827
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.
Signed-off-by: Chandra Konduru
Signed-off-by: Nabendu Maiti
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 31 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e61b68..dd8ee98 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3939,6 +3939,9 @@ enum {
#define _CLKGATE_DIS_PSL_A 0x46520
#define _CLKGATE_DIS_PSL_B 0x46524
#define _CLKGATE_DIS_PSL_C 0x46528
+#define DUPS1_GATING_DIS (1 << 15)
+#define DUPS2_GATING_DIS (1 << 19)
+#define DUPS3_GATING_DIS (1 << 23)
#define DPF_GATING_DIS (1 << 10)
#define DPF_RAM_GATING_DIS (1 << 9)
#define DPFR_GATING_DIS (1 << 8)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 941f00d..f5fdf8a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -504,6 +504,21 @@ static const struct intel_limit intel_limits_bxt = {
.p2 = { .p2_slow = 1, .p2_fast = 20 },
};
+static void
+skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+ if (IS_SKYLAKE(dev_priv))
+ return;
+
+ if (enable)
+ I915_WRITE(CLKGATE_DIS_PSL(pipe),
+ DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+ else
+ I915_WRITE(CLKGATE_DIS_PSL(pipe),
+ I915_READ(CLKGATE_DIS_PSL(pipe)) &
+ ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS));
+}
+
static bool
needs_modeset(const struct drm_crtc_state *state)
{
@@ -3151,6 +3166,9 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
int ret;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv =
+ to_i915(plane_state->base.plane->dev);
if (rotation & DRM_MODE_REFLECT_X &&
fb->modifier == DRM_FORMAT_MOD_LINEAR) {
@@ -3175,6 +3193,13 @@ int skl_check_plane_surface(const struct
intel_crtc_state *crtc_state,
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
+
+ /* Display WA 827 */
+ if (INTEL_GEN(dev_priv) == 9 || IS_CANNONLAKE(dev_priv)) {
+ if (!IS_GEMINILAKE(dev_priv))
+ skl_wa_clkgate(dev_priv,
+ intel_crtc->pipe, true);
+ }
} else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
ret = skl_check_ccs_aux_surface(plane_state);
@@ -5746,6 +5771,12 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_ddi_disable_pipe_clock(intel_crtc->config);
intel_encoders_post_disable(crtc, old_crtc_state, old_state);
+
+ if (INTEL_GEN(dev_priv) == 9 || IS_CANNONLAKE(dev_priv)) {
+ if (!IS_GEMINILAKE(dev_priv))
+ skl_wa_clkgate(dev_priv,
+ intel_crtc->pipe, false);
+ }
}
static void i9xx_pfit_enable(struct intel_crtc *crtc)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v13 16/17] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.
v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h
v3: Adding Reviewed By from Shashank Sharma
v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.
Reviewed-by: Shashank Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 763ae1f..941f00d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3631,6 +3631,11 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
if (intel_format_is_yuv(fb->format->format)) {
+ if (fb->format->format == DRM_FORMAT_NV12) {
+ plane_color_ctl |=
+ PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+ goto out;
+ }
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -3638,8 +3643,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
- }
+ }
+out:
return plane_color_ctl;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add NV12 support
== Series Details == Series: Add NV12 support URL : https://patchwork.freedesktop.org/series/39670/ State : failure == Summary == Series 39670v1 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/ Possible new issues: Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-kbl-7500u) Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:429s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:424s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s 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:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:495s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:495s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:483s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:473s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:402s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:409s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:517s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:456s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:419s fi-kbl-7500u total:288 pass:262 dwarn:1 dfail:0 fail:1 skip:24 time:468s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:505s 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:432s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:522s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:497s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:486s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:420s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:521s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 1339f9a5a27c drm/i915: Display WA 827 e2512797e0e9 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg e7310fb54287 drm/i915: Add NV12 support to intel_framebuffer_init e2876f568d26 drm/i915: Add NV12 as supported format for sprite plane d24eaa7f1235 drm/i915: Add NV12 as supported format for primary plane c468bf338a68 drm/i915: Upscale scaler max scale for NV12 14093696ac0f drm/i915: Update format_is_yuv() to include NV12 b06a83b7a3e7 drm/i915: Set scaler mode for NV12 1a0fc9903d7b drm/i915/skl: split skl_compute_ddb function a7269aacf906 drm/i915/skl+: nv12 workaround disable WM level 1-7 127974044799 drm/i915/skl+: make sure higher latency level has higher wm value 388a36b819e4 drm/i915/skl+: pass skl_wm_level struct to wm compute func 4fe6ee60c595 drm/i915/skl+: NV12 related changes for WM febfc56105e3 drm/i915/skl+: support verification of DDB HW state for NV12 1e1f431f9e41 drm/i915/skl+: add NV12 in skl_format_to_fourcc edc2fd014ea1 drm/i915/skl+: refactor WM calculation for NV12 c1e45b5d1766 drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8287/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove support for legacy debugfs crc interface (rev2)
== Series Details == Series: drm/i915: Remove support for legacy debugfs crc interface (rev2) URL : https://patchwork.freedesktop.org/series/33053/ State : failure == Summary == Possible new issues: Test kms_pipe_crc_basic: Subgroup bad-nb-words-1: pass -> SKIP (shard-apl) pass -> SKIP (shard-hsw) pass -> SKIP (shard-snb) Subgroup bad-nb-words-3: pass -> SKIP (shard-apl) pass -> SKIP (shard-hsw) pass -> SKIP (shard-snb) Subgroup bad-pipe: pass -> SKIP (shard-apl) pass -> SKIP (shard-hsw) pass -> SKIP (shard-snb) Test perf_pmu: Subgroup multi-client-vcs0: pass -> FAIL (shard-snb) Known issues: Test drv_selftest: Subgroup live_gtt: pass -> INCOMPLETE (shard-apl) fdo#103927 Test kms_cursor_legacy: Subgroup flip-vs-cursor-toggle: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: fail -> PASS (shard-hsw) fdo#100368 Test perf_pmu: Subgroup busy-start-vcs0: fail -> PASS (shard-snb) fdo#105106 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#105106 https://bugs.freedesktop.org/show_bug.cgi?id=105106 shard-apltotal:3445 pass:1798 dwarn:1 dfail:0 fail:9 skip:1635 time:11698s shard-hswtotal:3467 pass:1768 dwarn:1 dfail:0 fail:3 skip:1694 time:11638s shard-snbtotal:3467 pass:1359 dwarn:1 dfail:0 fail:3 skip:2104 time:6893s Blacklisted hosts: shard-kbltotal:3381 pass:1895 dwarn:1 dfail:0 fail:9 skip:1475 time:9040s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8276/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/42] drm/i915: Implement HDCP2.2
On Thu, Mar 08, 2018 at 06:03:32PM +0530, Ramalingam C wrote: > On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote: > > > > > -Original Message- > > > From: C, Ramalingam > > > Sent: Thursday, March 08, 2018 13:58 > > > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > > > seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas > > > ; jani.nik...@linux.intel.com > > > Cc: Vivi, Rodrigo ; Sharma, Shashank > > > ; Shankar, Uma ; C, > > > Ramalingam > > > Subject: [PATCH v2 00/42] drm/i915: Implement HDCP2.2 > > > > > > Based on HDCP1.4 framework introduced by Sean Paul, this series > > > implements the HDCP2.2 in I915. > > I didn't see HDCP 1.4 framework being merged upstream? What tree is this > > based on? > > This is based on drm-tip branch of https://cgit.freedesktop.org/drm-tip/ All the code also should be in linux-next. If it's not, then something went wrong somewhere with the scripting. -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 07/15] drm/i915/guc: Flush directly in log unregister
On 3/8/2018 9:16 PM, Michał Winiarski wrote:
Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.
v2: s/dev_priv/i915 (Sagar)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc_log.c | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index ee0981f5a208..5ff4b510569a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc)
intel_runtime_pm_put(dev_priv);
}
-static void guc_flush_logs(struct intel_guc *guc)
-{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
- /*
-* Before initiating the forceful flush, wait for any pending/ongoing
-* flush to complete otherwise forceful flush may not actually happen.
-*/
- flush_work(&guc->log.runtime.flush_work);
-
- /* Ask GuC to update the log buffer state */
- intel_runtime_pm_get(dev_priv);
- guc_log_flush(guc);
- intel_runtime_pm_put(dev_priv);
-
- /* GuC would have updated log buffer by now, so capture it */
- guc_log_capture_logs(guc);
-}
-
int intel_guc_log_create(struct intel_guc *guc)
{
struct i915_vma *vma;
@@ -630,15 +611,28 @@ int intel_guc_log_register(struct intel_guc *guc)
void intel_guc_log_unregister(struct intel_guc *guc)
{
+ struct drm_i915_private *i915 = guc_to_i915(guc);
+
guc_log_flush_irq_disable(guc);
+ /*
+* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not actually happen.
+*/
+ flush_work(&guc->log.runtime.flush_work);
+
/*
* Once logging is disabled, GuC won't generate logs & send an
* interrupt. But there could be some data in the log buffer
* which is yet to be captured. So request GuC to update the log
* buffer state and then collect the left over logs.
*/
- guc_flush_logs(guc);
+ intel_runtime_pm_get(i915);
+ guc_log_flush(guc);
+ intel_runtime_pm_put(i915);
+
+ /* GuC would have updated log buffer by now, so capture it */
+ guc_log_capture_logs(guc);
mutex_lock(&guc->log.runtime.lock);
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines
On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:
On 08/03/18 01:31, Tvrtko Ursulin wrote:
On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:
The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_engine_cs.c | 77
+
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 -
2 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info
intel_engine_classes[] = {
},
};
+#define MAX_MMIO_BASES 3
struct engine_info {
unsigned int hw_id;
unsigned int uabi_id;
u8 class;
u8 instance;
- u32 mmio_base;
+ struct engine_mmio_base {
+ u32 gen : 8;
+ u32 base : 24;
+ } mmio_bases[MAX_MMIO_BASES];
unsigned irq_shift;
};
It's not bad, but I am just wondering if it is too complicated versus
simply duplicating the tables.
Duplicated tables would certainly be much less code and complexity,
but what about the size of pure data?
In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES *
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times
NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme.
we remove a u32 (the old mmio base) so we only grow 8 per engine, but
the compiler rounds up to a multiple of u32 so 28 per engine, for a
total of 224.
Separate tables per gens would be:
sizeof(struct engine_info) is 18 bytes.
For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
>= gen11 = 8 engines * 18 = 144
54 + 90 + 144 = 288 bytes
So a little bit bigger. Hm. Plus we would need to refactor so
intel_engines[] is not indexed by engine->id but is contiguous array
with engine->id in the elements. Code to lookup the compact array
should be simpler than combined new code from this patch, especially
if you add the test as Chris suggested. So separate engine info arrays
would win I think overall - when considering size of text + size of
data + size of source code.
Not sure. I would exclude the selftest, which is usually not compiled
for released kernels, which leads to:
Yes, but we cannot exclude its source since selftests for separate
tables wouldn't be needed.
add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new delta
intel_engines 160 224 +64
__func__ 13891 13910 +19
intel_engines_init_mmio 1247 1264 +17
intel_init_bsd_ring_buffer 142 135 -7
Total: Before=1479626, After=1479719, chg +0.01%
Total growth is 93, which is less then your estimation for the growth
introduced by replicating the table.
But on the other hand your solution might be more future proof. So I
don't know. Use the crystal ball to decide? :)
I think we should expect that the total engine count could grow with
future gens. In this case to me adding a new entry to a unified table
seems much cleaner (and uses less data) than adding a completely new
table each time.
Okay I was off in my estimates. But in general I was coming from the
angle of thinking that every new mmio base difference in this scheme
grows the size for all engines. So if just VCS grows one new base,
impact is multiplied by NUM_ENGINES. But maybe separate tables are also
not a solution. Perhaps pulling out mmio_base arrays to outside struct
engine_info in another set of static tables, so they could be null
terminated would be best of both worlds?
struct engine_mmio_base {
u32 gen : 8;
u32 base : 24;
};
static const struct engine_mmio_base vcs0_mmio_bases[] = {
{ .gen = 11, .base = GEN11_BSD_RING_BASE },
{ .gen = 6, .base = GEN6_BSD_RING_BASE },
{ .gen = 4, .base = BSD_RING_BASE },
{ },
};
And then in intel_engines array, for BSD:
{
...
.mmio_bases = &vcs0_mmio_bases;
...
},
This way we limit data growth only to engines which change their mmio
bases frequently.
Just an idea.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show GEM_TRACE when detecting a failed GPU idle
If we timeout waiting for the GPU to idle, something went seriously
wrong. We currently dump the engine state, but we can also dump the
ftrace buffer showing our last operations (when available).
In passing, note that since commit 559e040f1f08 ("drm/i915: Show the GPU
state when declaring wedged", we now show the engine state twice, once
in detecting the failed idle and then again on declaring wedged.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 11 +--
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca53c9a0..8bd8cb7c198e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3657,16 +3657,7 @@ static int wait_for_engines(struct drm_i915_private
*i915)
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
dev_err(i915->drm.dev,
"Failed to idle engines, declaring wedged!\n");
- if (drm_debug & DRM_UT_DRIVER) {
- struct drm_printer p = drm_debug_printer(__func__);
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- for_each_engine(engine, i915, id)
- intel_engine_dump(engine, &p,
- "%s\n", engine->name);
- }
-
+ GEM_TRACE_DUMP();
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index f54c4ff74ded..8fdaa08e7bfb 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -53,8 +53,10 @@
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
+#define GEM_TRACE_DUMP() ftrace_dump()
#else
#define GEM_TRACE(...) do { } while (0)
+#define GEM_TRACE_DUMP() do { } while (0)
#endif
#define I915_NUM_ENGINES 8
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler
On 09/03/2018 01:38, Chris Wilson wrote:
Quoting Chris Wilson (2018-03-09 01:33:08)
gen11_gt_engine_intr(struct drm_i915_private * const i915,
const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
gen11_gt_irq_handler(struct drm_i915_private * const i915,
const u32 master_ctl)
{
+ static const u8 bank0_map[] = {
+ [GEN11_RCS0] = RCS,
+ [GEN11_BCS] = BCS,
Is there a reason why its RCS0 but BCS? And the multi-instance classes
actually use VCS(x)?
I am pretty sure that naming came from the spec.
Side note - one thing I dislike a bit about the current code and this
patch is that all engines have to be enumerated explicitly in the
interrupt handler. I kind of thought it was handy to handle the
multi-class engines from a loop, and so have one place less to remember
to update after adding a new engine instance.
And in general I think too many bike-sheds on this area of code before
we are even running it on real hw. :(
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Show GEM_TRACE when detecting a failed GPU idle
If we timeout waiting for the GPU to idle, something went seriously
wrong. We currently dump the engine state, but we can also dump the
ftrace buffer showing our last operations (when available).
In passing, note that since commit 559e040f1f08 ("drm/i915: Show the GPU
state when declaring wedged", we now show the engine state twice, once
in detecting the failed idle and then again on declaring wedged.
v2: ftrace_dump() takes a parameter specifying whether to dump all cpu
buffers or the local cpu's.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 11 +--
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca53c9a0..8bd8cb7c198e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3657,16 +3657,7 @@ static int wait_for_engines(struct drm_i915_private
*i915)
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
dev_err(i915->drm.dev,
"Failed to idle engines, declaring wedged!\n");
- if (drm_debug & DRM_UT_DRIVER) {
- struct drm_printer p = drm_debug_printer(__func__);
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- for_each_engine(engine, i915, id)
- intel_engine_dump(engine, &p,
- "%s\n", engine->name);
- }
-
+ GEM_TRACE_DUMP();
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index f54c4ff74ded..8922344fc21b 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -53,8 +53,10 @@
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
+#define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
#else
#define GEM_TRACE(...) do { } while (0)
+#define GEM_TRACE_DUMP() do { } while (0)
#endif
#define I915_NUM_ENGINES 8
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler
Quoting Tvrtko Ursulin (2018-03-09 10:06:48) > > On 09/03/2018 01:38, Chris Wilson wrote: > And in general I think too many bike-sheds on this area of code before > we are even running it on real hw. :( Come on now, it's not a proper bikeshed if the discussion is meaningful! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max
On Thu, 08 Mar 2018, Manasi Navare wrote:
> The panels are generally designed to support only a single
> clock and lane configuration, and typically these values
> correspond to the native resolution of the panel. But some
> panels advertise the MAX_LINK_RATE in DPCD higher than what
> is required to support the native resolution.
> So optimize and set the link rate and lane count to the
> least values required by the panel to support the native
> resolution. This will also be an effective power saving
> for such eDP panels.
I'm afraid this will lead to flickering on plenty of laptops. It will
just get reverted when it hits end users. We've been down this path
before. If we decide to try to do this again, we need to figure out how
*not* to regress those machines. We can't just talk our way out of this.
As a tip, it's often useful to have a look at git blame and git log when
you're considering changes to code that seems odd or contentious or
something. In this case that leads to commit 344c5bbcb7a2
("drm/i915/edp: use lane count and link rate from DPCD for eDP"), which
in turn leads to commit 56071a207602 ("drm/i915: use lane count and link
rate from VBT as minimums for eDP") and a bunch of bugzilla links.
That stuff was done by yours truly years ago, so I'd rather not repeat
my mistakes now. ;)
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Matt Atwood
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8d1d7af..ba1114b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1812,15 +1812,14 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> bpp = dev_priv->vbt.edp.bpp;
> }
>
> - /*
> - * Use the maximum clock and number of lanes the eDP panel
> - * advertizes being capable of. The panels are generally
> - * designed to support only a single clock and lane
> - * configuration, and typically these values correspond to the
> - * native resolution of the panel.
> + /* The panels are generally designed to support only a single
> + * clock and lane configuration, and typically these values
> + * correspond to the native resolution of the panel. But some
> + * panels advertise higher link rates that might not be required
> + * for the native resolution of the panel. So use the least
> + * required link rate/lane count for the panel's native
> + * resolution.
>*/
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;
> }
>
> for (; bpp >= 6*3; bpp -= 2*3) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max
Quoting Jani Nikula (2018-03-09 10:20:37)
> On Thu, 08 Mar 2018, Manasi Navare wrote:
> > The panels are generally designed to support only a single
> > clock and lane configuration, and typically these values
> > correspond to the native resolution of the panel. But some
> > panels advertise the MAX_LINK_RATE in DPCD higher than what
> > is required to support the native resolution.
> > So optimize and set the link rate and lane count to the
> > least values required by the panel to support the native
> > resolution. This will also be an effective power saving
> > for such eDP panels.
>
> I'm afraid this will lead to flickering on plenty of laptops. It will
> just get reverted when it hits end users. We've been down this path
> before. If we decide to try to do this again, we need to figure out how
> *not* to regress those machines. We can't just talk our way out of this.
>
> As a tip, it's often useful to have a look at git blame and git log when
> you're considering changes to code that seems odd or contentious or
> something. In this case that leads to commit 344c5bbcb7a2
> ("drm/i915/edp: use lane count and link rate from DPCD for eDP"), which
> in turn leads to commit 56071a207602 ("drm/i915: use lane count and link
> rate from VBT as minimums for eDP") and a bunch of bugzilla links.
Also include a bit of rationale in the comment about what happens if we
don't have that block.
* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The panels are generally
* designed to support only a single clock and lane
* configuration, and typically these values correspond to the
* native resolution of the panel.
+ On some? many? panels, failure to force the maximum bandwidth results
+ in flickering, hence we unconditionally apply this w/a.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next for 4.17
Joonas, so did this miss the deadline for v4.17? You're not making
another pull request?
BR,
Jani.
On Thu, 08 Mar 2018, Joonas Lahtinen wrote:
> Pulled.
>
> Regards, Joonas
>
> Quoting Zhenyu Wang (2018-03-08 04:31:52)
>>
>> Hi,
>>
>> Here's gvt-next update for 4.17. Biggest update is for huge code
>> refactor of shadow ppgtt from Changbin which is the most obscured
>> part, and with KBL context save/restore improvement from Weinan,
>> with other fixes.
>>
>> Thanks.
>> --
>> The following changes since commit 1f267a572b573b0b155022750cba93001f4367a8:
>>
>> drm/i915: Update DRIVER_DATE to 20180305 (2018-03-05 11:56:15 +0200)
>>
>> are available in the Git repository at:
>>
>> https://github.com/intel/gvt-linux.git tags/gvt-next-2018-03-08
>>
>> for you to fetch changes up to 991ecefbdd4b81719597d6c406df8d26ef5c1546:
>>
>> drm/i915/gvt: Return error at the failure of finding page_track
>> (2018-03-06 14:49:38 +0800)
>>
>>
>> gvt-next-2018-03-08
>>
>> - big refactor for shadow ppgtt (Changbin)
>> - KBL context save/restore via LRI cmd (Weinan)
>> - misc smatch fixes (Zhenyu)
>> - Properly unmap dma for guest page (Changbin)
>> - other misc fixes (Xiong, etc.)
>>
>>
>> Changbin Du (18):
>> drm/i915/gvt: Rework shadow graphic memory management code
>> drm/i915/gvt: Refine the intel_vgpu_mm reference management
>> drm/i915/gvt: Refine ggtt and ppgtt root entry ops
>> drm/i915/gvt: Refine ggtt_set_shadow_entry
>> drm/i915/gvt: Add verbose gtt shadow logs
>> drm/i915/gvt: Rename ggtt related functions to be more specific
>> drm/i915/gvt: Factor out intel_vgpu_{get, put}_ppgtt_mm interface
>> drm/i915/gvt: Use standard pte bit definition
>> drm/i915/gvt: Refine pte shadowing process
>> drm/i915/gvt: Rework shadow page management code
>> drm/i915/gvt: Rename shadow_page to short name spt
>> drm/i915/gvt: Rename mpt api {set, unset}_wp_page to {enable,
>> disable}_page_track
>> drm/i915/gvt: Don't extend page_track to mpt layer
>> drm/i915/gvt: Provide generic page_track infrastructure for
>> write-protected page
>> drm/i915/gvt: Manage shadow pages with radix tree
>> drm/i915/gvt: Define PTE addr mask with GENMASK_ULL
>> drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup
>> overhead
>> drm/i915/kvmgt: Add kvmgt debugfs entry nr_cache_entries under vgpu
>>
>> Weinan Li (3):
>> drm/i915/gvt: add define GEN9_MOCS_SIZE
>> drm/i915/gvt: add interface to check if context is inhibit
>> drm/i915/gvt: init mmio by lri command in vgpu inhibit context
>>
>> Xiong Zhang (2):
>> drm/i915/gvt: Release gvt->lock at the failure of finding page track
>> drm/i915/gvt: Return error at the failure of finding page_track
>>
>> Zhenyu Wang (7):
>> drm/i915/gvt: Fix one gvt_vgpu_error() use in dmabuf.c
>> drm/i915/gvt: remove gvt max port definition
>> drm/i915/gvt: Fix vGPU sched timeslice calculation warning
>> drm/i915/gvt: Fix check error of vgpu create failure message
>> drm/i915/gvt: Fix check error on fence mmio handler
>> drm/i915/gvt: Fix one indent error
>> drm/i915/gvt: Fix check error on hws_pga_write() fail message
>>
>> drivers/gpu/drm/i915/gvt/Makefile |2 +-
>> drivers/gpu/drm/i915/gvt/dmabuf.c |2 +-
>> drivers/gpu/drm/i915/gvt/gtt.c | 1457
>> ++-
>> drivers/gpu/drm/i915/gvt/gtt.h | 189 ++--
>> drivers/gpu/drm/i915/gvt/gvt.c |2 +-
>> drivers/gpu/drm/i915/gvt/gvt.h | 21 +-
>> drivers/gpu/drm/i915/gvt/handlers.c | 38 +-
>> drivers/gpu/drm/i915/gvt/hypercall.h|9 +-
>> drivers/gpu/drm/i915/gvt/kvmgt.c| 313 ---
>> drivers/gpu/drm/i915/gvt/mmio.c |9 +-
>> drivers/gpu/drm/i915/gvt/mmio_context.c | 210 -
>> drivers/gpu/drm/i915/gvt/mmio_context.h |5 +
>> drivers/gpu/drm/i915/gvt/mpt.h | 67 +-
>> drivers/gpu/drm/i915/gvt/page_track.c | 184
>> drivers/gpu/drm/i915/gvt/page_track.h | 56 ++
>> drivers/gpu/drm/i915/gvt/sched_policy.c |5 +-
>> drivers/gpu/drm/i915/gvt/scheduler.c| 44 +-
>> drivers/gpu/drm/i915/gvt/trace.h| 10 +-
>> drivers/gpu/drm/i915/gvt/vgpu.c |1 +
>> 19 files changed, 1468 insertions(+), 1156 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/gvt/page_track.c
>> create mode 100644 drivers/gpu/drm/i915/gvt/page_track.h
>>
>>
>> --
>> Open Source Technology Center, Intel ltd.
>>
>> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL
On Tue, 06 Mar 2018, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 12:41:55PM +0200, Jani Nikula wrote:
>> We don't want to preserve the DDI A 4 lane bit on ICL.
>>
>> Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing
>> limitation.")
>> Cc: Mahesh Kumar
>> Cc: Paulo Zanoni
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Pushed, thanks for the review.
The one CI warning is unrelated.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index bfdaa5d86861..66417dd24bfc 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2932,9 +2932,12 @@ void intel_ddi_init(struct drm_i915_private
>> *dev_priv, enum port port)
>> intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>> intel_encoder->cloneable = 0;
>>
>> -intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> - (DDI_BUF_PORT_REVERSAL |
>> - DDI_A_4_LANES);
>> +if (INTEL_GEN(dev_priv) >= 11)
>> +intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> +DDI_BUF_PORT_REVERSAL;
>> +else
>> +intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> +(DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
>> intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
>> intel_dig_port->max_lanes = intel_ddi_max_lanes(intel_dig_port);
>>
>> --
>> 2.11.0
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
Quoting Chris Wilson (2018-03-09 01:08:08) > Originally we were inlining gen8_cs_irq_handler() and so expected the > compiler to constant-fold away the irq_shift (so we had hardcoded it as > opposed to use engine->irq_shift). However, we dropped the inline given > the proliferation of gen8_cs_irq_handler()s. If we pull the shifting > of the iir into the caller, we can shrink the code still further: > > add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) > Function old new delta > gen8_cs_irq_handler 123 118 -5 > gen8_gt_irq_handler 261 248 -13 > gen11_irq_handler722 706 -16 > > v2: Drop gen11_cs_irq_handler now that it is a simple > stub around gen8_cs_irq_handler (Daniele) > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Tvrtko Ursulin > Cc: Daniele Ceraolo Spurio > Reviewed-by: Daniele Ceraolo Spurio Pushed, thanks for the review and prompting. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
== Series Details == Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2) URL : https://patchwork.freedesktop.org/series/39674/ State : success == Summary == Series 39674v2 drm/i915: Show GEM_TRACE when detecting a failed GPU idle https://patchwork.freedesktop.org/api/1.0/series/39674/revisions/2/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-skl-6700k2) fdo#104108 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s 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:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:486s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:478s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:471s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:578s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:578s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:414s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:290s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:468s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:419s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:467s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:458s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:584s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:519s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:532s fi-skl-6700k2total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:498s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:421s 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:395s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:520s 7e7b29286da55ce67130fb58e370542181f91ade drm-tip: 2018y-03m-09d-09h-43m-23s UTC integration manifest 352ba8c6113d drm/i915: Show GEM_TRACE when detecting a failed GPU idle == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
On 3/8/2018 9:17 PM, Michał Winiarski wrote:
Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.
v2: Don't touch guc_log_level on relay creation error, adjust locking
after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
Use struct_mutex rather than runtime.lock for set_log_level
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h
b/drivers/gpu/drm/i915/intel_guc_log.h
index 8c26cce77a98..df91f12a36ed 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -61,9 +61,10 @@ struct intel_guc_log {
int intel_guc_log_create(struct intel_guc *guc);
void intel_guc_log_destroy(struct intel_guc *guc);
void intel_guc_log_init_early(struct intel_guc *guc);
-int intel_guc_log_control_get(struct intel_guc *guc);
-int intel_guc_log_control_set(struct intel_guc *guc, u64 control_val);
-int intel_guc_log_register(struct intel_guc *guc);
-void intel_guc_log_unregister(struct intel_guc *guc);
+int intel_guc_log_level_get(struct intel_guc *guc);
+int intel_guc_log_level_set(struct intel_guc *guc, u64 control_val);
+int intel_guc_log_relay_open(struct intel_guc *guc);
+void intel_guc_log_relay_close(struct intel_guc *guc);
+void intel_guc_log_relay_flush(struct intel_guc *guc);
Need to maintain order of definition. init_early is also not in order.
With that:
Reviewed-by: Sagar Arun Kamble
#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 90d2f38e22c9..abce0e38528a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc *guc)
i915_gem_object_put(guc->load_err_log);
}
-int intel_uc_register(struct drm_i915_private *i915)
-{
- int ret = 0;
-
- if (!USES_GUC(i915))
- return 0;
-
- if (i915_modparams.guc_log_level)
- ret = intel_guc_log_register(&i915->guc);
-
- return ret;
-}
-
-void intel_uc_unregister(struct drm_i915_private *i915)
-{
- if (!USES_GUC(i915))
- return;
-
- if (i915_modparams.guc_log_level)
- intel_guc_log_unregister(&i915->guc);
-}
-
static int guc_enable_communication(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d6af984cd789..f76d51d1ce70 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -31,8 +31,6 @@
void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
void intel_uc_init_early(struct drm_i915_private *dev_priv);
void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
-int intel_uc_register(struct drm_i915_private *dev_priv);
-void intel_uc_unregister(struct drm_i915_private *dev_priv);
void intel_uc_init_fw(struct drm_i915_private *dev_priv);
void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
int intel_uc_init_misc(struct drm_i915_private *dev_priv);
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling
On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart
within our desired interval. Improve the likelihood of the inspection
passing by idling the GPU and waiting for 2 Evaluation Intervals before
we start polling of RC6 residency.
Signed-off-by: Chris Wilson
---
tests/gem_mocs_settings.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index 9705fbfd..85fd637a 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -336,12 +336,15 @@ static uint32_t rc6_residency(int dir)
static void rc6_wait(int fd)
{
- int sysfs;
uint32_t residency;
+ int sysfs;
sysfs = igt_sysfs_open(fd, NULL);
igt_assert_lte(0, sysfs);
+ gem_quiescent_gpu(fd);
+ usleep(320e3); /* Wait for 2 EIs before polling; should now be active */
+
residency = rc6_residency(sysfs);
igt_require(igt_wait(rc6_residency(sysfs) != residency, 1, 2));
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/15] drm/i915/guc: Get rid of GuC log runtime
On 3/8/2018 9:17 PM, Michał Winiarski wrote:
Runtime is not a very good name. Let's also move counting relay
overflows inside relay struct.
v2: Rename things rather than remove the struct (Chris)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
Some might want other stats too as part of relay since we print them
when relay is enabled.
But this is not a big issue. w/ or w/o that change:
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +--
drivers/gpu/drm/i915/intel_guc.c | 12 +++
drivers/gpu/drm/i915/intel_guc_log.c | 66 ++--
drivers/gpu/drm/i915/intel_guc_log.h | 7 ++--
4 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f99fe9910634..d7c0bf6facf6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2348,8 +2348,8 @@ static void i915_guc_log_info(struct seq_file *m,
seq_printf(m, "\tTotal flush interrupt count: %u\n",
guc->log.flush_interrupt_count);
- seq_printf(m, "\tCapture miss count: %u\n",
- guc->log.capture_miss_count);
+ seq_printf(m, "\tRelay full count: %u\n",
+ guc->log.relay.full_count);
}
static void i915_guc_client_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0d92caf6a83f..cab158e42577 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -87,9 +87,9 @@ int intel_guc_init_wq(struct intel_guc *guc)
* or scheduled later on resume. This way the handling of work
* item can be kept same between system suspend & rpm suspend.
*/
- guc->log.runtime.flush_wq = alloc_ordered_workqueue("i915-guc_log",
+ guc->log.relay.flush_wq = alloc_ordered_workqueue("i915-guc_log",
WQ_HIGHPRI | WQ_FREEZABLE);
- if (!guc->log.runtime.flush_wq) {
+ if (!guc->log.relay.flush_wq) {
DRM_ERROR("Couldn't allocate workqueue for GuC log\n");
return -ENOMEM;
}
@@ -112,7 +112,7 @@ int intel_guc_init_wq(struct intel_guc *guc)
guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
WQ_HIGHPRI);
if (!guc->preempt_wq) {
- destroy_workqueue(guc->log.runtime.flush_wq);
+ destroy_workqueue(guc->log.relay.flush_wq);
DRM_ERROR("Couldn't allocate workqueue for GuC "
"preemption\n");
return -ENOMEM;
@@ -130,7 +130,7 @@ void intel_guc_fini_wq(struct intel_guc *guc)
USES_GUC_SUBMISSION(dev_priv))
destroy_workqueue(guc->preempt_wq);
- destroy_workqueue(guc->log.runtime.flush_wq);
+ destroy_workqueue(guc->log.relay.flush_wq);
}
static int guc_shared_data_create(struct intel_guc *guc)
@@ -389,8 +389,8 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
- queue_work(guc->log.runtime.flush_wq,
- &guc->log.runtime.flush_work);
+ queue_work(guc->log.relay.flush_wq,
+ &guc->log.relay.flush_work);
guc->log.flush_interrupt_count++;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 92a7bf0fd729..7c4339dae534 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -151,10 +151,10 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
smp_wmb();
/* All data has been written, so now move the offset of sub buffer. */
- relay_reserve(guc->log.runtime.relay_chan,
guc->log.vma->obj->base.size);
+ relay_reserve(guc->log.relay.channel, guc->log.vma->obj->base.size);
/* Switch to the next sub buffer */
- relay_flush(guc->log.runtime.relay_chan);
+ relay_flush(guc->log.relay.channel);
}
static void *guc_get_write_buffer(struct intel_guc *guc)
@@ -168,7 +168,7 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
* done without using relay_reserve() along with relay_write(). So its
* better to use relay_reserve() alone.
*/
- return relay_reserve(guc->log.runtime.relay_chan, 0);
+ return relay_reserve(guc->log.relay.channel, 0);
}
static bool guc_check_log_buf_overflow(struct intel_guc *guc,
@@ -219,13 +219,13 @@ static void guc_read_update_log_buffer(struct intel_guc
*guc)
void *src_data, *dst_data;
bool new_overflow;
- mutex_lock(&guc->log.runtime.lock);
+
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski
wrote:
Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.
v2: Don't touch guc_log_level on relay creation error, adjust locking
after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
Use struct_mutex rather than runtime.lock for set_log_level
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
---
/snip/
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 90d2f38e22c9..abce0e38528a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc
*guc)
i915_gem_object_put(guc->load_err_log);
}
-int intel_uc_register(struct drm_i915_private *i915)
-{
- int ret = 0;
-
- if (!USES_GUC(i915))
- return 0;
-
- if (i915_modparams.guc_log_level)
- ret = intel_guc_log_register(&i915->guc);
-
- return ret;
-}
-
-void intel_uc_unregister(struct drm_i915_private *i915)
-{
- if (!USES_GUC(i915))
- return;
-
- if (i915_modparams.guc_log_level)
- intel_guc_log_unregister(&i915->guc);
-}
-
static int guc_enable_communication(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h
b/drivers/gpu/drm/i915/intel_uc.h
index d6af984cd789..f76d51d1ce70 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -31,8 +31,6 @@
void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
void intel_uc_init_early(struct drm_i915_private *dev_priv);
void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
-int intel_uc_register(struct drm_i915_private *dev_priv);
-void intel_uc_unregister(struct drm_i915_private *dev_priv);
hmm, it looks that timelines of these two functions were very short
(from patch 2 till patch 8) - so maybe by doing some patch re-order
can we fully skip them ?
void intel_uc_init_fw(struct drm_i915_private *dev_priv);
void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
int intel_uc_init_misc(struct drm_i915_private *dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled
On 3/8/2018 9:17 PM, Michał Winiarski wrote:
If nobody has enabled the relay, we're not comunicating with GuC, which
means that the stats don't have any meaning. Let's also remove interrupt
counter and tidy the debugfs formatting.
v2: Correct stats accounting (Sagar)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_debugfs.c | 45
drivers/gpu/drm/i915/intel_guc.c | 5 +---
drivers/gpu/drm/i915/intel_guc_log.c | 22 +-
drivers/gpu/drm/i915/intel_guc_log.h | 10
4 files changed, 48 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d29bacb1f308..94516ab4eaed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2326,30 +2326,45 @@ static int i915_guc_load_status_info(struct seq_file
*m, void *data)
return 0;
}
+static const char *
+stringify_guc_log_type(enum guc_log_buffer_type type)
+{
+ switch (type) {
+ case GUC_ISR_LOG_BUFFER:
+ return "ISR";
+ case GUC_DPC_LOG_BUFFER:
+ return "DPC";
+ case GUC_CRASH_DUMP_LOG_BUFFER:
+ return "CRASH";
+ default:
+ MISSING_CASE(type);
+ }
+
+ return "";
+}
+
static void i915_guc_log_info(struct seq_file *m,
struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
+ enum guc_log_buffer_type type;
- seq_puts(m, "GuC logging stats:\n");
-
- seq_printf(m, "\tISR: flush count %10u, overflow count %10u\n",
- guc->log.flush_count[GUC_ISR_LOG_BUFFER],
- guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
-
- seq_printf(m, "\tDPC: flush count %10u, overflow count %10u\n",
- guc->log.flush_count[GUC_DPC_LOG_BUFFER],
- guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
-
- seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n",
- guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
- guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+ if (!intel_guc_log_relay_enabled(guc)) {
+ seq_puts(m, "GuC log relay disabled\n");
+ return;
+ }
- seq_printf(m, "\tTotal flush interrupt count: %u\n",
- guc->log.flush_interrupt_count);
+ seq_puts(m, "GuC logging stats:\n");
seq_printf(m, "\tRelay full count: %u\n",
guc->log.relay.full_count);
+
+ for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ seq_printf(m, "\t%s:\tflush count %10u, overflow count %10u\n",
+ stringify_guc_log_type(type),
+ guc->log.stats[type].flush,
+ guc->log.stats[type].overflow);
Didn't see this earlier. Should be sampled_overflow.
And ordering of intel_guc_log_relay_enabled() declaration w.r.t other
declarations needs to be fixed.
With that:
Reviewed-by: Sagar Arun Kamble
+ }
}
static void i915_guc_client_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index cab158e42577..3e2f0f8503ed 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -388,12 +388,9 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
spin_unlock(&guc->irq_lock);
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
- INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
+ INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
queue_work(guc->log.relay.flush_wq,
&guc->log.relay.flush_work);
-
- guc->log.flush_interrupt_count++;
- }
}
int intel_guc_sample_forcewake(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7c4339dae534..a72fe4a369f4 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -171,22 +171,22 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
return relay_reserve(guc->log.relay.channel, 0);
}
-static bool guc_check_log_buf_overflow(struct intel_guc *guc,
+static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
enum guc_log_buffer_type type,
unsigned int full_cnt)
{
- unsigned int prev_full_cnt = guc->log.prev_overflow_count[type];
+ unsigned int prev_full_cnt = log->stats[type].sampled_overflow;
bool overflow = false;
if (full_cnt != prev_full_cnt) {
overflow = true;
- guc->log.prev_overflow_count[type] = full_cnt;
- guc->log.total_over
Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Default to non-verbose GuC logging
On 3/8/2018 9:17 PM, Michał Winiarski wrote:
Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing with non-verbose logging being disabled.
v2: Bring back the "auto" guc_log_level, now that we fixed the log
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble (v1)
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..c96360398072 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,7 +48,7 @@ struct drm_printer;
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
param(int, enable_guc, 0) \
- param(int, guc_log_level, 0) \
+ param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 3fb5f75aa7c9..2f579fff58cd 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -69,7 +69,7 @@ static int __get_platform_enable_guc(struct drm_i915_private
*dev_priv)
static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
{
- int guc_log_level = 0; /* disabled */
+ int guc_log_level = 1; /* non-verbose */
/* Enable if we're running on platform with GuC and debug config */
if (HAS_GUC(dev_priv) && intel_uc_is_using_guc() &&
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests
From: Tvrtko Ursulin
We need to use absolute tolerance when asserting on percentages. Relative
tolerance in this case is unfair and inaccurate since it's strictness
varies with relative target busyness.
v2:
* Do not include spin batch edit and submit into measured time.
* Open PMU before child is in test PWM phase.
* No need to emit test PWM for twice as long with the new explicit
synchroniazation via pipe.
* Log test duration in ms for better readability.
* Drop inverse assert. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Chris Wilson # v1
---
tests/perf_pmu.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 9ebffc64d1f1..ff9f71540ee4 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1459,7 +1459,15 @@ static void __rearm_spin_batch(igt_spin_t *spin)
__sync_synchronize();
}
-#define div_round_up(a, b) (((a) + (b) - 1) / (b))
+#define __assert_within(x, ref, tol_up, tol_down) \
+ igt_assert_f((double)(x) <= ((double)(ref) + (tol_up)) && \
+(double)(x) >= ((double)(ref) - (tol_down)), \
+"%f not within +%f/-%f of %f! ('%s' vs '%s')\n", \
+(double)(x), (double)(tol_up), (double)(tol_down), \
+(double)(ref), #x, #ref)
+
+#define assert_within(x, ref, tolerance) \
+ __assert_within(x, ref, tolerance, tolerance)
static void
accuracy(int gem_fd, const struct intel_execution_engine2 *e,
@@ -1493,8 +1501,8 @@ accuracy(int gem_fd, const struct intel_execution_engine2
*e,
while (test_us < min_test_us)
test_us += busy_us + idle_us;
- igt_info("calibration=%luus, test=%luus; ratio=%.2f%% (%luus/%luus)\n",
-pwm_calibration_us, test_us,
+ igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n",
+pwm_calibration_us / 1000, test_us / 1000,
(double)busy_us / (busy_us + idle_us) * 100.0,
busy_us, idle_us);
@@ -1507,7 +1515,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2
*e,
igt_fork(child, 1) {
struct sched_param rt = { .sched_priority = 99 };
const unsigned long timeout[] = {
- pwm_calibration_us * 1000, test_us * 2 * 1000
+ pwm_calibration_us * 1000, test_us * 1000
};
struct drm_i915_gem_exec_object2 obj = {};
uint64_t total_busy_ns = 0, total_idle_ns = 0;
@@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct
intel_execution_engine2 *e,
igt_nsec_elapsed(&test_start);
do {
- struct timespec t_busy = { };
- unsigned int target_idle_us;
-
- igt_nsec_elapsed(&t_busy);
+ unsigned int target_idle_us, t_busy;
/* Restart the spinbatch. */
__rearm_spin_batch(spin);
__submit_spin_batch(gem_fd, &obj, e);
- measured_usleep(busy_us);
+ t_busy = measured_usleep(busy_us);
igt_spin_batch_end(spin);
gem_sync(gem_fd, obj.handle);
- total_busy_ns += igt_nsec_elapsed(&t_busy);
+ total_busy_ns += t_busy;
target_idle_us =
(100 * total_busy_ns / target_busy_pct
- (total_busy_ns + total_idle_ns)) / 1000;
@@ -1569,12 +1574,13 @@ accuracy(int gem_fd, const struct
intel_execution_engine2 *e,
igt_spin_batch_free(gem_fd, spin);
}
+ fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
+
/* Let the child run. */
read(link[0], &expected, sizeof(expected));
- assert_within_epsilon(expected, target_busy_pct/100., 0.05);
+ assert_within(100.0 * expected, target_busy_pct, 5);
/* Collect engine busyness for an interesting part of child runtime. */
- fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
val[0] = __pmu_read_single(fd, &ts[0]);
read(link[0], &expected, sizeof(expected));
val[1] = __pmu_read_single(fd, &ts[1]);
@@ -1590,8 +1596,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2
*e,
igt_info("error=%.2f%% (%.2f%% vs %.2f%%)\n",
__error(busy_r, expected), 100 * busy_r, 100 * expected);
- assert_within_epsilon(busy_r, expected, 0.15);
- assert_within_epsilon(1 - busy_r, 1 - expected, 0.15);
+ assert_within(100.0 * busy_r, 100.0 * expected, 2);
}
igt_main
--
2.14.1
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM
On 3/9/2018 2:30 AM, Michal Wajdeczko wrote:
Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c| 2 ++
drivers/gpu/drm/i915/intel_guc.h | 6 ++
drivers/gpu/drm/i915/intel_huc.h | 6 ++
drivers/gpu/drm/i915/intel_uc.c| 18 ++
drivers/gpu/drm/i915/intel_uc.h| 1 +
drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++
6 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca5..49c81ae 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
*/
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
above intel_gpu_reset also resets uC. Should we just let it reset only
real engines with this change then?
+
+ intel_uc_sanitize(i915);
}
int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
+static inline int intel_guc_sanitize(struct intel_guc *guc)
+{
+ intel_uc_fw_sanitize(&guc->fw);
+ return 0;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+static inline int intel_huc_sanitize(struct intel_huc *huc)
+{
+ intel_uc_fw_sanitize(&huc->fw);
+ return 0;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
}
+void intel_uc_sanitize(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
+
+ if (!USES_GUC(i915))
+ return;
+
+ GEM_BUG_ON(!HAS_GUC(i915));
+
+ guc_disable_communication(guc);
+
+ intel_huc_sanitize(huc);
+ intel_guc_sanitize(guc);
+
+ __intel_uc_reset_hw(i915);
+}
+
int intel_uc_init_hw(struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
int intel_uc_init_misc(struct drm_i915_private *dev_priv);
void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
int intel_uc_init_hw(struct drm_i915_private *dev_priv);
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
}
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)
+{
+ if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+ uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
struct intel_uc_fw *uc_fw);
int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.
Op 06-03-18 om 16:57 schreef Maxime Ripard: > Hi, > > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote: >> Only try to set those values if the properties are supported. >> This fixes the kms_chameium tests to run on vc4 again. >> >> Reported-by: Maxime Ripard >> Cc: Paul Kocialkowski >> Cc: Eric Anholt >> Cc: Boris Brezillon >> Signed-off-by: Maarten Lankhorst > This works like a charm now, thanks! > Tested-by: Maxime Ripard > > Maxime > Can you upgrade this to a reviewed-by so I can apply this change? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL
No significant changes from either context offsets, nor report
formats, nor register whitelist.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_oa_icl.c | 118 +
drivers/gpu/drm/i915/i915_oa_icl.h | 34 +++
drivers/gpu/drm/i915/i915_perf.c | 5 +-
4 files changed, 158 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4eee91a3a236..ead1e4ff1575 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -171,7 +171,8 @@ i915-y += i915_perf.o \
i915_oa_glk.o \
i915_oa_cflgt2.o \
i915_oa_cflgt3.o \
- i915_oa_cnl.o
+ i915_oa_cnl.o \
+ i915_oa_icl.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_icl.c
b/drivers/gpu/drm/i915/i915_oa_icl.c
new file mode 100644
index ..a5667926e3de
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_icl.c
@@ -0,0 +1,118 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 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 "i915_drv.h"
+#include "i915_oa_icl.h"
+
+static const struct i915_oa_reg b_counter_config_test_oa[] = {
+ { _MMIO(0x2740), 0x },
+ { _MMIO(0x2710), 0x },
+ { _MMIO(0x2714), 0xf080 },
+ { _MMIO(0x2720), 0x },
+ { _MMIO(0x2724), 0xf080 },
+ { _MMIO(0x2770), 0x0004 },
+ { _MMIO(0x2774), 0x },
+ { _MMIO(0x2778), 0x0003 },
+ { _MMIO(0x277c), 0x },
+ { _MMIO(0x2780), 0x0007 },
+ { _MMIO(0x2784), 0x },
+ { _MMIO(0x2788), 0x0012 },
+ { _MMIO(0x278c), 0xfff7 },
+ { _MMIO(0x2790), 0x0012 },
+ { _MMIO(0x2794), 0xffcf },
+ { _MMIO(0x2798), 0x00100082 },
+ { _MMIO(0x279c), 0xffef },
+ { _MMIO(0x27a0), 0x001000c2 },
+ { _MMIO(0x27a4), 0xffe7 },
+ { _MMIO(0x27a8), 0x0011 },
+ { _MMIO(0x27ac), 0xffe7 },
+};
+
+static const struct i915_oa_reg flex_eu_config_test_oa[] = {
+};
+
+static const struct i915_oa_reg mux_config_test_oa[] = {
+ { _MMIO(0xd04), 0x0200 },
+ { _MMIO(0x9840), 0x },
+ { _MMIO(0x9884), 0x },
+ { _MMIO(0x9888), 0x1006 },
+ { _MMIO(0x9888), 0x2206 },
+ { _MMIO(0x9888), 0x1606 },
+ { _MMIO(0x9888), 0x2406 },
+ { _MMIO(0x9888), 0x1806 },
+ { _MMIO(0x9888), 0x1a06 },
+ { _MMIO(0x9888), 0x1206 },
+ { _MMIO(0x9888), 0x1406 },
+ { _MMIO(0x9888), 0x1006 },
+ { _MMIO(0x9888), 0x2206 },
+ { _MMIO(0x9884), 0x0003 },
+ { _MMIO(0x9888), 0x1613 },
+ { _MMIO(0x9888), 0x2401 },
+ { _MMIO(0x9888), 0x0e130056 },
+ { _MMIO(0x9888), 0x1013 },
+ { _MMIO(0x9888), 0x1a13 },
+ { _MMIO(0x9888), 0x541f0001 },
+ { _MMIO(0x9888), 0x181f },
+ { _MMIO(0x9888), 0x4c1f },
+ { _MMIO(0x9888), 0x301f },
+};
+
+static ssize_t
+show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "1\n");
+}
+
+void
+i915_perf_load_test_config_icl(struct drm_i915_private *dev_priv)
+{
+ strlcpy(dev_priv->perf.oa.test_config.uuid,
+ "a291665e-244b-4b76-9b9a-01de9d3c8068",
+ sizeof(dev_priv->perf.oa.test_config.uuid));
+ dev_priv->perf.oa.test_config.id = 1;
+
+ dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
+ dev_priv->perf.oa.test_config.mux_regs_le
Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config
On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> Previously it was assumed that eDP panels would advertise the lowest link
> rate required for their singular mode to function. With the introduction
> of more advanced features there are advantages to a panel advertising a
> higher rate then it needs for a its given mode. For panels that did, the
> driver previously used a higher rate then necessary for that mode.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a2eeede..aa6d77d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> dev_priv->vbt.edp.bpp);
> bpp = dev_priv->vbt.edp.bpp;
> }
> -
> - /*
> - * Use the maximum clock and number of lanes the eDP panel
> - * advertizes being capable of. The panels are generally
> - * designed to support only a single clock and lane
> - * configuration, and typically these values correspond to the
> - * native resolution of the panel.
> - */
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;
Please see my reply to Manasi's identical patch [1]. If we apply this
as-is, it will regress and will be reverted.
BR,
Jani.
[1]
http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-git-send-email-manasi.d.nav...@intel.com
> }
>
> for (; bpp >= 6*3; bpp -= 2*3) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
== Series Details == Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2) URL : https://patchwork.freedesktop.org/series/39674/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup cursorb-vs-flipb-atomic-transitions-varying-size: pass -> DMESG-WARN (shard-hsw) Test kms_frontbuffer_tracking: Subgroup fbc-1p-indfb-fliptrack: pass -> FAIL (shard-apl) Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite: fail -> PASS (shard-apl) Subgroup fbc-1p-primscrn-shrfb-msflip-blt: dmesg-fail -> PASS (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_atomic_transition: Subgroup 1x-modeset-transitions: pass -> FAIL (shard-apl) fdo#103207 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: fail -> PASS (shard-snb) fdo#103167 +1 Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3467 pass:1822 dwarn:1 dfail:0 fail:11 skip:1632 time:12231s shard-hswtotal:3467 pass:1769 dwarn:2 dfail:0 fail:4 skip:1691 time:11689s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6891s Blacklisted hosts: shard-kbltotal:3381 pass:1899 dwarn:1 dfail:0 fail:9 skip:1471 time:9138s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: enable perf support on ICL
== Series Details == Series: drm/i915/perf: enable perf support on ICL URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Series 39689v1 drm/i915/perf: enable perf support on ICL https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/1/mbox/ Known issues: Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-cnl-y3) fdo#103167 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k2) fdo#103191 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:425s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:374s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:507s 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:493s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:492s 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:473s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:579s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:410s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:291s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:465s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:512s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:586s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:533s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:423s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:531s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:392s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:509s 074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC integration manifest 07c313f0dad2 drm/i915/perf: enable perf support on ICL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro
This patch replaces use of remaining _MMIO_PORT6 macro and removes the
macro.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_reg.h | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7987a3f85d04..37742d774ba0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
#define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
#define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
-#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e,
f))
-#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f)
\
- _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
@@ -1948,20 +1945,21 @@ enum i915_power_well_id {
#define _CNL_PORT_PCS_DW1_LN0_C0x162C04
#define _CNL_PORT_PCS_DW1_LN0_D0x162E04
#define _CNL_PORT_PCS_DW1_LN0_F0x162804
-#define CNL_PORT_PCS_DW1_GRP(port) _MMIO_PORT6(port, \
+#define CNL_PORT_PCS_DW1_GRP(port) _MMIO(_PICK(port, \
_CNL_PORT_PCS_DW1_GRP_AE, \
_CNL_PORT_PCS_DW1_GRP_B, \
_CNL_PORT_PCS_DW1_GRP_C, \
_CNL_PORT_PCS_DW1_GRP_D, \
_CNL_PORT_PCS_DW1_GRP_AE, \
- _CNL_PORT_PCS_DW1_GRP_F)
-#define CNL_PORT_PCS_DW1_LN0(port) _MMIO_PORT6(port, \
+ _CNL_PORT_PCS_DW1_GRP_F))
+
+#define CNL_PORT_PCS_DW1_LN0(port) _MMIO(_PICK(port, \
_CNL_PORT_PCS_DW1_LN0_AE, \
_CNL_PORT_PCS_DW1_LN0_B, \
_CNL_PORT_PCS_DW1_LN0_C, \
_CNL_PORT_PCS_DW1_LN0_D, \
_CNL_PORT_PCS_DW1_LN0_AE, \
- _CNL_PORT_PCS_DW1_LN0_F)
+ _CNL_PORT_PCS_DW1_LN0_F))
#define COMMON_KEEPER_EN (1 << 26)
/* CNL Port TX registers */
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register
This patch creates a new macro to get PORT_TX register for any given DW.
This will remove the need of defining register address for each port & DW.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_reg.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..30ef3513dc6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1964,6 +1964,34 @@ enum i915_power_well_id {
_CNL_PORT_PCS_DW1_LN0_F)
#define COMMON_KEEPER_EN (1 << 26)
+/* CNL Port TX registers */
+#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
+#define _CNL_PORT_TX_B_GRP_OFFSET 0x1623C0
+#define _CNL_PORT_TX_C_GRP_OFFSET 0x162B40
+#define _CNL_PORT_TX_D_GRP_OFFSET 0x162BC0
+#define _CNL_PORT_TX_F_GRP_OFFSET 0x162A40
+#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440
+#define _CNL_PORT_TX_B_LN0_OFFSET 0x162640
+#define _CNL_PORT_TX_C_LN0_OFFSET 0x162C40
+#define _CNL_PORT_TX_D_LN0_OFFSET 0x162E40
+#define _CNL_PORT_TX_F_LN0_OFFSET 0x162840
+#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \
+ _CNL_PORT_TX_AE_GRP_OFFSET, \
+ _CNL_PORT_TX_B_GRP_OFFSET, \
+ _CNL_PORT_TX_B_GRP_OFFSET, \
+ _CNL_PORT_TX_D_GRP_OFFSET, \
+ _CNL_PORT_TX_AE_GRP_OFFSET, \
+ _CNL_PORT_TX_F_GRP_OFFSET) + \
+ 4*(dw))
+#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \
+ _CNL_PORT_TX_AE_LN0_OFFSET, \
+ _CNL_PORT_TX_B_LN0_OFFSET, \
+ _CNL_PORT_TX_B_LN0_OFFSET, \
+ _CNL_PORT_TX_D_LN0_OFFSET, \
+ _CNL_PORT_TX_AE_LN0_OFFSET, \
+ _CNL_PORT_TX_F_LN0_OFFSET) + \
+ 4*(dw))
+
#define _CNL_PORT_TX_DW2_GRP_AE0x162348
#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
#define _CNL_PORT_TX_DW2_GRP_C 0x162B48
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] CNL port refactoring
This series fixes CNL PORT_TX_DW5/7_LNO_D register address. This series also introduces macros to get register address of CNL_PORT_TX registers instead of defining for each DW instance. changes since V1: completely kill _MMIO_PORT6 macro Mahesh Kumar (3): drm/i915/cnl; Add macro to get PORT_TX register drm/i915/cnl: Replace PORT_TX register macros with new ones drm/i915/cnl: Kill _MMIO_PORT6 macro drivers/gpu/drm/i915/i915_reg.h | 147 1 file changed, 44 insertions(+), 103 deletions(-) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/cnl: Replace PORT_TX register macros with new ones
This patch replaces CNL_PORT_TX register macros with new macros defined
in previous patch.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_reg.h | 107 +---
1 file changed, 11 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 30ef3513dc6f..7987a3f85d04 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1992,30 +1992,8 @@ enum i915_power_well_id {
_CNL_PORT_TX_F_LN0_OFFSET) + \
4*(dw))
-#define _CNL_PORT_TX_DW2_GRP_AE0x162348
-#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
-#define _CNL_PORT_TX_DW2_GRP_C 0x162B48
-#define _CNL_PORT_TX_DW2_GRP_D 0x162BC8
-#define _CNL_PORT_TX_DW2_GRP_F 0x162A48
-#define _CNL_PORT_TX_DW2_LN0_AE0x162448
-#define _CNL_PORT_TX_DW2_LN0_B 0x162648
-#define _CNL_PORT_TX_DW2_LN0_C 0x162C48
-#define _CNL_PORT_TX_DW2_LN0_D 0x162E48
-#define _CNL_PORT_TX_DW2_LN0_F 0x162848
-#define CNL_PORT_TX_DW2_GRP(port) _MMIO_PORT6(port, \
- _CNL_PORT_TX_DW2_GRP_AE, \
- _CNL_PORT_TX_DW2_GRP_B, \
- _CNL_PORT_TX_DW2_GRP_C, \
- _CNL_PORT_TX_DW2_GRP_D, \
- _CNL_PORT_TX_DW2_GRP_AE, \
- _CNL_PORT_TX_DW2_GRP_F)
-#define CNL_PORT_TX_DW2_LN0(port) _MMIO_PORT6(port, \
- _CNL_PORT_TX_DW2_LN0_AE, \
- _CNL_PORT_TX_DW2_LN0_B, \
- _CNL_PORT_TX_DW2_LN0_C, \
- _CNL_PORT_TX_DW2_LN0_D, \
- _CNL_PORT_TX_DW2_LN0_AE, \
- _CNL_PORT_TX_DW2_LN0_F)
+#define CNL_PORT_TX_DW2_GRP(port) _MMIO(CNL_PORT_TX_DW_GRP((port), 2))
+#define CNL_PORT_TX_DW2_LN0(port) _MMIO(CNL_PORT_TX_DW_LN0((port), 2))
#define SWING_SEL_UPPER(x) ((x >> 3) << 15)
#define SWING_SEL_UPPER_MASK (1 << 15)
#define SWING_SEL_LOWER(x) ((x & 0x7) << 11)
@@ -2023,32 +2001,13 @@ enum i915_power_well_id {
#define RCOMP_SCALAR(x) ((x) << 0)
#define RCOMP_SCALAR_MASK(0xFF << 0)
-#define _CNL_PORT_TX_DW4_GRP_AE0x162350
-#define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
-#define _CNL_PORT_TX_DW4_GRP_C 0x162B50
-#define _CNL_PORT_TX_DW4_GRP_D 0x162BD0
-#define _CNL_PORT_TX_DW4_GRP_F 0x162A50
#define _CNL_PORT_TX_DW4_LN0_AE0x162450
#define _CNL_PORT_TX_DW4_LN1_AE0x1624D0
-#define _CNL_PORT_TX_DW4_LN0_B 0x162650
-#define _CNL_PORT_TX_DW4_LN0_C 0x162C50
-#define _CNL_PORT_TX_DW4_LN0_D 0x162E50
-#define _CNL_PORT_TX_DW4_LN0_F 0x162850
-#define CNL_PORT_TX_DW4_GRP(port) _MMIO_PORT6(port, \
- _CNL_PORT_TX_DW4_GRP_AE, \
- _CNL_PORT_TX_DW4_GRP_B, \
- _CNL_PORT_TX_DW4_GRP_C, \
- _CNL_PORT_TX_DW4_GRP_D, \
- _CNL_PORT_TX_DW4_GRP_AE, \
- _CNL_PORT_TX_DW4_GRP_F)
-#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO_PORT6_LN(port, ln,\
- _CNL_PORT_TX_DW4_LN0_AE, \
- _CNL_PORT_TX_DW4_LN1_AE, \
- _CNL_PORT_TX_DW4_LN0_B, \
- _CNL_PORT_TX_DW4_LN0_C, \
- _CNL_PORT_TX_DW4_LN0_D, \
- _CNL_PORT_TX_DW4_LN0_AE, \
- _CNL_PORT_TX_DW4_LN0_F)
+#define CNL_PORT_TX_DW4_GRP(port) _MMIO(CNL_PORT_TX_DW_GRP((port), 4))
+#define CNL_PORT_TX_DW4_LN0(port) _MMIO(CNL_PORT_TX_DW_LN0((port), 4))
+#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(CNL_PORT_TX_DW_LN0((port), 4) + \
+(ln * (_CNL_PORT_TX_DW4_LN1_AE - \
+ _CNL_PORT_TX_DW4_LN0_AE)))
#define LOADGEN_SELECT (1 << 31)
#define POST_CURSOR_1(x) ((x) << 12)
#define POST_CURSOR_1_MASK (0x3F << 12)
@@ -2057,30 +2016,8 @@ enum i915_power_well_id {
#define CURSOR
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests
Chris Wilson writes: > Before we reset the GPU after marking the device as wedged, we wait for > all the remaining requests to be completed (and marked as EIO). > Afterwards, we should flush the request lists so the next batch start > with the driver in an idle start. s/start/state? > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index a5bd07338b46..30cd07ebcb8e 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3273,7 +3273,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > if (!test_bit(I915_WEDGED, &i915->gpu_error.flags)) > return true; > > - /* Before unwedging, make sure that all pending operations > + /* > + * Before unwedging, make sure that all pending operations >* are flushed and errored out - we may have requests waiting upon >* third party fences. We marked all inflight requests as EIO, and >* every execbuf since returned EIO, for consistency we want all > @@ -3291,7 +3292,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > if (!rq) > continue; > > - /* We can't use our normal waiter as we want to > + /* > + * We can't use our normal waiter as we want to >* avoid recursively trying to handle the current >* reset. The basic dma_fence_default_wait() installs >* a callback for dma_fence_signal(), which is > @@ -3306,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > return false; > } > } > + i915_retire_requests(i915); > + GEM_BUG_ON(i915->gt.active_requests); > > - /* Undo nop_submit_request. We prevent all new i915 requests from > + /* > + * Undo nop_submit_request. We prevent all new i915 requests from >* being queued (by disallowing execbuf whilst wedged) so having >* waited for all active requests above, we know the system is idle >* and do not have to worry about a thread being inside > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.
On Fri, Mar 09, 2018 at 12:55:24PM +0100, Maarten Lankhorst wrote: > Op 06-03-18 om 16:57 schreef Maxime Ripard: > > Hi, > > > > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote: > >> Only try to set those values if the properties are supported. > >> This fixes the kms_chameium tests to run on vc4 again. > >> > >> Reported-by: Maxime Ripard > >> Cc: Paul Kocialkowski > >> Cc: Eric Anholt > >> Cc: Boris Brezillon > >> Signed-off-by: Maarten Lankhorst > > This works like a charm now, thanks! > > Tested-by: Maxime Ripard > > > > Maxime > > > Can you upgrade this to a reviewed-by so I can apply this change? Yep, of course: Reviewed-by: Maxime Ripard -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Quoting Chris Wilson (2018-03-07 13:42:22) > With a series of unusual events (a sequence of interrupted request > allocations), we could gradually leak the ring->space estimate by > unwinding the ring back to the start of the request, but not return the > used space back to the ring. Eventually and with great misfortune, it > would be possible to trigger ring->space exhaustion with no requests on > the ring. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_request.c | 1 + > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index d437beac3969..efa9ee557f31 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct > i915_gem_context *ctx) > > err_unwind: > rq->ring->emit = rq->head; > + intel_ring_update_space(rq->ring); Ok, skip this one as we will correct ourselves next time we wait_for_space. It's just the next one where we weren't maintaining ring->tail that was the issue. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Chris Wilson writes:
> With a series of unusual events (a sequence of interrupted request
> allocations), we could gradually leak the ring->space estimate by
> unwinding the ring back to the start of the request, but not return the
> used space back to the ring. Eventually and with great misfortune, it
> would be possible to trigger ring->space exhaustion with no requests on
> the ring.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_request.c | 1 +
> drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index d437beac3969..efa9ee557f31 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
> i915_gem_context *ctx)
>
> err_unwind:
> rq->ring->emit = rq->head;
> + intel_ring_update_space(rq->ring);
>
> /* Make sure we didn't add ourselves to external state before freeing */
> GEM_BUG_ON(!list_empty(&rq->active_list));
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1d599524a759..88eeb64041ae 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring
> *ring, unsigned int bytes)
> if (intel_ring_update_space(ring) >= bytes)
> return 0;
>
> + GEM_BUG_ON(list_empty(&ring->request_list));
At some point, after long series of misfortunate events, we
will add a first request and need actually wait a space for this
and then we kaboom in here?
-Mika
> list_for_each_entry(target, &ring->request_list, ring_link) {
> /* Would completion of this request free enough space? */
> if (bytes <= __intel_ring_space(target->postfix,
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Quoting Mika Kuoppala (2018-03-09 13:17:09) > Chris Wilson writes: > > > With a series of unusual events (a sequence of interrupted request > > allocations), we could gradually leak the ring->space estimate by > > unwinding the ring back to the start of the request, but not return the > > used space back to the ring. Eventually and with great misfortune, it > > would be possible to trigger ring->space exhaustion with no requests on > > the ring. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_request.c | 1 + > > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index d437beac3969..efa9ee557f31 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, > > struct i915_gem_context *ctx) > > > > err_unwind: > > rq->ring->emit = rq->head; > > + intel_ring_update_space(rq->ring); > > > > /* Make sure we didn't add ourselves to external state before freeing > > */ > > GEM_BUG_ON(!list_empty(&rq->active_list)); > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > > b/drivers/gpu/drm/i915/intel_ringbuffer.c > > index 1d599524a759..88eeb64041ae 100644 > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > > @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring > > *ring, unsigned int bytes) > > if (intel_ring_update_space(ring) >= bytes) > > return 0; > > > > + GEM_BUG_ON(list_empty(&ring->request_list)); > > At some point, after long series of misfortunate events, we > will add a first request and need actually wait a space for this > and then we kaboom in here? That's the experience. However, I don't think this patch helps because we do the intel_ring_update_space() here inside wait_for_space anyway, so it should come out in the wash so long as we aren't corrupting the ring space calculation. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring
Chris Wilson writes:
> When wedged, we do not update the ring->tail as we submit the requests
> causing us to leak the ring->space upon cleaning up the wedged driver.
> We can just use the value stored in rq->tail, and keep the submission
> backend details away from set-wedge.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_request.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index efa9ee557f31..69b378a323fc 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request)
>* is just about to be. Either works, if we miss the last two
>* noops - they are safe to be replayed on a reset.
>*/
> - tail = READ_ONCE(request->ring->tail);
> + tail = READ_ONCE(request->tail);
I tried to think if we need the READ_ONCE here anymore.
But as this is the safest version,
Reviewed-by: Mika Kuoppala
Noticed that request->tail is not cleared on i915_request_alloc.
If we would set rq->head = rq->tail = rq->ring->emit
we could use rq->head == rq->tail to assert that
we screw up something major during the request lifetime.
-Mika
> } else {
> tail = request->postfix;
> }
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Include ring->emit in debugging
Chris Wilson writes:
> Include ring->emit and ring->space alongside ring->(head,tail) when
> printing debug information.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
> drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e838c765b251..4de0a52f14a9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1923,8 +1923,8 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
>
> static void describe_ctx_ring(struct seq_file *m, struct intel_ring *ring)
> {
> - seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u)",
> -ring->space, ring->head, ring->tail);
> + seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, emit: %u)",
> +ring->space, ring->head, ring->tail, ring->emit);
> }
>
> static int i915_context_status(struct seq_file *m, void *unused)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4ba139c27fba..e71bd6951d9b 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1929,12 +1929,16 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> rq->head, rq->postfix, rq->tail,
> rq->batch ? upper_32_bits(rq->batch->node.start) :
> ~0u,
> rq->batch ? lower_32_bits(rq->batch->node.start) :
> ~0u);
> - drm_printf(m, "\t\tring->start: 0x%08x\n",
> + drm_printf(m, "\t\tring->start : 0x%08x\n",
Please check the space before ':', seems unintentional.
Reviewed-by: Mika Kuoppala
> i915_ggtt_offset(rq->ring->vma));
> - drm_printf(m, "\t\tring->head: 0x%08x\n",
> + drm_printf(m, "\t\tring->head: 0x%08x\n",
> rq->ring->head);
> - drm_printf(m, "\t\tring->tail: 0x%08x\n",
> + drm_printf(m, "\t\tring->tail: 0x%08x\n",
> rq->ring->tail);
> + drm_printf(m, "\t\tring->emit: 0x%08x\n",
> +rq->ring->emit);
> + drm_printf(m, "\t\tring->space: 0x%08x\n",
> +rq->ring->space);
> }
>
> rcu_read_unlock();
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL
On 9 March 2018 at 11:58, Lionel Landwerlin wrote: > No significant changes from either context offsets, nor report > formats, nor register whitelist. > > Signed-off-by: Lionel Landwerlin > --- The usual spiel about disabling clock-ratio-change reports, do we need it? So this will need the timestamp frequency stuff for gen11, should that go in before this, or don't we care? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection
Chris Wilson writes:
> Similar to the staging around handling of engine->submit_request, we
> need to stop adding to the execlists->queue prior to calling
> engine->cancel_requests. cancel_requests will move requests from the
> queue onto the timeline, so if we add a request onto the queue after that
> point, it will be lost.
>
> Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in
> set_wedged")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 13 +++--
> drivers/gpu/drm/i915/i915_request.c | 2 ++
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 30cd07ebcb8e..3b44952e089f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence
> *fence, int prio)
>
> rq = to_request(fence);
> engine = rq->engine;
> - if (!engine->schedule)
> - return;
>
> - engine->schedule(rq, prio);
> + rcu_read_lock();
> + if (engine->schedule)
> + engine->schedule(rq, prio);
> + rcu_read_unlock();
> }
>
> static void fence_set_priority(struct dma_fence *fence, int prio)
> @@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>*/
> for_each_engine(engine, i915, id) {
> i915_gem_reset_prepare_engine(engine);
> +
> engine->submit_request = nop_submit_request;
> + engine->schedule = NULL;
> }
> + i915->caps.scheduler = 0;
>
> /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3233,11 +3237,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* start to complete all requests.
>*/
> engine->submit_request = nop_complete_submit_request;
> - engine->schedule = NULL;
> }
>
> - i915->caps.scheduler = 0;
> -
> /*
>* Make sure no request can slip through without getting completed by
>* either this call here to intel_engine_init_global_seqno, or the one
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 69b378a323fc..0258449579f8 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1082,8 +1082,10 @@ void __i915_request_add(struct i915_request *request,
> bool flush_caches)
>* decide whether to preempt the entire chain so that it is ready to
>* run at the earliest possible convenience.
>*/
> + rcu_read_lock();
> if (engine->schedule)
> engine->schedule(request, request->ctx->priority);
> + rcu_read_unlock();
>
> local_bh_disable();
> i915_sw_fence_commit(&request->submit);
> --
> 2.16.2
>
> ___
> 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 3/6] drm/i915: Update ring position from request on retiring
Quoting Mika Kuoppala (2018-03-09 13:38:37) > Chris Wilson writes: > > > When wedged, we do not update the ring->tail as we submit the requests > > causing us to leak the ring->space upon cleaning up the wedged driver. > > We can just use the value stored in rq->tail, and keep the submission > > backend details away from set-wedge. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index efa9ee557f31..69b378a323fc 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request) > >* is just about to be. Either works, if we miss the last two > >* noops - they are safe to be replayed on a reset. > >*/ > > - tail = READ_ONCE(request->ring->tail); > > + tail = READ_ONCE(request->tail); > > I tried to think if we need the READ_ONCE here anymore. I tried as well to see if the comment was still correct. It still is due to that we can retire before we see the context-switch interrupt. > But as this is the safest version, > Reviewed-by: Mika Kuoppala > > Noticed that request->tail is not cleared on i915_request_alloc. > > If we would set rq->head = rq->tail = rq->ring->emit > we could use rq->head == rq->tail to assert that > we screw up something major during the request lifetime. Heh, if we get a stray write here, we're going to get stray writes everywhere :) -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 CNL port refactoring (rev2)
== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Series 38334v2 CNL port refactoring https://patchwork.freedesktop.org/api/1.0/series/38334/revisions/2/mbox/ Known issues: Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-cnl-y3) fdo#103167 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k2) fdo#103191 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:509s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:489s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:500s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:487s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:475s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:407s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:291s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:514s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:453s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:423s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:590s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:497s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:420s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:514s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:519s 074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC integration manifest d271c009a148 drm/i915/cnl: Kill _MMIO_PORT6 macro 5a42fe815c97 drm/i915/cnl: Replace PORT_TX register macros with new ones 08448452816c drm/i915/cnl; Add macro to get PORT_TX register == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.
v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request
Signed-off-by: Chris Wilson
Cc: Paneri, Praveen
Cc: Kamble, Sagar A
Cc: Antonio Argenziano
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/gem_ctx_freq.c | 648 +
tests/meson.build | 1 +
4 files changed, 651 insertions(+)
create mode 100644 tests/gem_ctx_freq.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
drm_import_export_LDADD = $(LDADD) -lpthread
gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_ctx_thrash_LDADD = $(LDADD) -lpthread
gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+ gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..f3cee838
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 7
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx,
+ .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+ .value = (uint64_t)max << 32 | min,
+ };
+
+ return __gem_context_set_param(fd, ¶m);
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+ igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx,
+ .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+ };
+
+ gem_context_get_param(fd, ¶m);
+
+ *min = param.value & 0x;
+ *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+ uint64_t data[2];
+ uint64_t d_t, d_v;
+
+ igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+ d_v = -data[0];
+ d_t = -data[1];
+
+ usleep(period_us);
+
+ igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+ d_v += data[0];
+ d_t += data[1];
+
+ return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+#define N_STEPS 10
+ const unsigned int engine = e->exec_id | e->flags;
+ uint32_t ctx = gem_context_create(fd);
+ uint32_t min, max;
+ double measured;
+ igt_spin_t *spin;
+ int pmu;
+
+ get_freq(fd, ctx, &min, &max);
+ igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+ pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+ igt_require(pmu >= 0);
+
+ for (int step = 0; step <= 2*N_STEPS; step++) {
+ int frac = step > N_
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Chris Wilson writes:
> tasklet_kill() will spin waiting for the current tasklet to be executed.
> However, if tasklet_disable() has been called, then the tasklet is never
> executed but permanently put back onto the runlist until
> tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> disable/enable pair. This is the case when we call set-wedge from inside
> i915_reset(), and another request was submitted to us concurrent to the
> reset.
>
> Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3b44952e089f..e75af06904b7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> *engine)
>* Turning off the execlists->tasklet until the reset is over
>* prevents the race.
>*/
> - tasklet_kill(&engine->execlists.tasklet);
> + if (!atomic_read(&engine->execlists.tasklet.count))
> + tasklet_kill(&engine->execlists.tasklet);
As discussed in irc, this might warrant comment that it is
our tasklet of which count we are racily investigating here,
so the race does not matter in the path we avoid killing.
Reviewed-by: Mika Kuoppala
> tasklet_disable(&engine->execlists.tasklet);
>
> /*
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Quoting Chris Wilson (2018-03-07 13:42:26)
> tasklet_kill() will spin waiting for the current tasklet to be executed.
> However, if tasklet_disable() has been called, then the tasklet is never
> executed but permanently put back onto the runlist until
> tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> disable/enable pair. This is the case when we call set-wedge from inside
> i915_reset(), and another request was submitted to us concurrent to the
> reset.
>
> Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3b44952e089f..e75af06904b7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> *engine)
> * Turning off the execlists->tasklet until the reset is over
> * prevents the race.
> */
> - tasklet_kill(&engine->execlists.tasklet);
> + if (!atomic_read(&engine->execlists.tasklet.count))
> + tasklet_kill(&engine->execlists.tasklet);
Note this is racy; two separate atomic operations. The only race we have
is with set-wedge vs reset, which is a rare and already contentious
issue. The upside of preventing the lockup is that we don't lose the
machine.
+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to prevent
+* a race between reset and set-wedged. It is not, so we do the best
+* we can atm and make sure we don't lock the machine up in the more
+* common case of recursing calling set-wedged from inside i915_reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL
On 09/03/18 13:49, Matthew Auld wrote: On 9 March 2018 at 11:58, Lionel Landwerlin wrote: No significant changes from either context offsets, nor report formats, nor register whitelist. Signed-off-by: Lionel Landwerlin --- The usual spiel about disabling clock-ratio-change reports, do we need it? Dammit :) So this will need the timestamp frequency stuff for gen11, should that go in before this, or don't we care? I'll wait for that to land indeed. Thanks a lot! Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Quoting Chris Wilson (2018-03-09 14:10:34)
> Quoting Chris Wilson (2018-03-07 13:42:26)
> > tasklet_kill() will spin waiting for the current tasklet to be executed.
> > However, if tasklet_disable() has been called, then the tasklet is never
> > executed but permanently put back onto the runlist until
> > tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> > disable/enable pair. This is the case when we call set-wedge from inside
> > i915_reset(), and another request was submitted to us concurrent to the
> > reset.
> >
> > Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3b44952e089f..e75af06904b7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> > *engine)
> > * Turning off the execlists->tasklet until the reset is over
> > * prevents the race.
> > */
> > - tasklet_kill(&engine->execlists.tasklet);
> > + if (!atomic_read(&engine->execlists.tasklet.count))
> > + tasklet_kill(&engine->execlists.tasklet);
>
> Note this is racy; two separate atomic operations. The only race we have
> is with set-wedge vs reset, which is a rare and already contentious
> issue. The upside of preventing the lockup is that we don't lose the
> machine.
>
> +* Note that this needs to be a single atomic operation on the
> +* tasklet (flush existing tasks, prevent new tasks) to prevent
> +* a race between reset and set-wedged. It is not, so we do the best
> +* we can atm and make sure we don't lock the machine up in the more
> +* common case of recursing calling set-wedged from inside i915_reset.
The alternative is to not try and do tasklet_kill() here. But that has
the side-effect of leaving it spinning if it was running at the same
time as the suspend. Hmm, for the moment I'll go with the comment and
see how inspired we are once gem_eio stops dieing.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling
On Fri, Mar 09, 2018 at 10:42:40AM +, Chris Wilson wrote:
> On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart
> within our desired interval. Improve the likelihood of the inspection
> passing by idling the GPU and waiting for 2 Evaluation Intervals before
> we start polling of RC6 residency.
I'd stick with pure gem_quiescent_gpu() since we're already polling for waay
longer than that.
Either way:
Reviewed-by: Michał Winiarski
-Michał
>
> Signed-off-by: Chris Wilson
> ---
> tests/gem_mocs_settings.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
> index 9705fbfd..85fd637a 100644
> --- a/tests/gem_mocs_settings.c
> +++ b/tests/gem_mocs_settings.c
> @@ -336,12 +336,15 @@ static uint32_t rc6_residency(int dir)
>
> static void rc6_wait(int fd)
> {
> - int sysfs;
> uint32_t residency;
> + int sysfs;
>
> sysfs = igt_sysfs_open(fd, NULL);
> igt_assert_lte(0, sysfs);
>
> + gem_quiescent_gpu(fd);
> + usleep(320e3); /* Wait for 2 EIs before polling; should now be active */
> +
> residency = rc6_residency(sysfs);
> igt_require(igt_wait(rc6_residency(sysfs) != residency, 1, 2));
>
> --
> 2.16.2
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/4] drm: Add drm_any_plane_has_format()
From: Ville Syrjälä
Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().
v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both
v3: Don't do the check in the core since we may not know the
modifier yet, instead export the function and let drivers
call it themselves
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 23 +++
include/drm/drm_mode_config.h | 6 ++
include/drm/drm_plane.h | 2 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7e8a37..3b2d6f8d889d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -578,6 +578,29 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
return 0;
}
+/**
+ * drm_any_plane_has_format - Check whether any plane supports this format and
modifier combination
+ * @dev: DRM device
+ * @format: pixel format (DRM_FORMAT_*)
+ * @modifier: data layout modifier
+ *
+ * Returns:
+ * Whether at least one plane supports the specified format and modifier
combination.
+ */
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier)
+{
+ struct drm_plane *plane;
+
+ drm_for_each_plane(plane, dev) {
+ if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_any_plane_has_format);
+
/*
* __setplane_internal - setplane handler for internal callers
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..9b894de9a75d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -52,6 +52,12 @@ struct drm_mode_config_funcs {
* requested metadata, but most of that is left to the driver. See
* &struct drm_mode_fb_cmd2 for details.
*
+* To validate the pixel format and modifier drivers can use
+* drm_any_plane_has_format() to make sure at least one plane supports
+* the requested values. Note that the driver must first determine the
+* actual modifier used if the request doesn't have it specified,
+* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+*
* If the parameters are deemed valid and the backing storage objects in
* the underlying memory manager all exist, then the driver allocates
* a new &drm_framebuffer structure, subclassed to contain
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..930e8fdd90f8 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -683,5 +683,7 @@ static inline struct drm_plane *drm_plane_find(struct
drm_device *dev,
#define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier);
#endif
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] drm/i915: Eliminate the horrendous format check code
From: Ville Syrjälä
Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.
v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 90
1 file changed, 8 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..7f06fa83d894 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13989,7 +13989,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = &intel_fb->base;
- struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14020,33 +14019,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
}
}
- /* Passed in modifier sanity checking. */
- switch (mode_cmd->modifier[0]) {
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- default:
- DRM_DEBUG_KMS("RC supported only with RGB
formats\n");
- goto err;
- }
- /* fall through */
- case I915_FORMAT_MOD_Y_TILED:
- case I915_FORMAT_MOD_Yf_TILED:
- if (INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
- goto err;
- }
- case DRM_FORMAT_MOD_LINEAR:
- case I915_FORMAT_MOD_X_TILED:
- break;
- default:
- DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+ if (!drm_any_plane_has_format(&dev_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ &format_name),
mode_cmd->modifier[0]);
goto err;
}
@@ -14081,60 +14061,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
- /* Reject formats not supported by any plane early. */
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_C8:
- case DRM_FORMAT_RGB565:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- case DRM_FORMAT_XRGB1555:
- if (INTEL_GEN(dev_priv) > 3) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
- INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_XRGB2101010:
- case DRM_FORMAT_XBGR2101010:
- if (INTEL_GEN(dev_priv) < 4) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR2101010:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_YUYV:
- case DRM_FORMAT_UYVY:
- case DRM_FORMAT_YVYU:
- case DRM_FORMAT_VYUY:
- if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_pri
[Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier
From: Ville Syrjälä
Only create framebuffers with supported format/modifier combinations by
checking that at least one plane supports the requested combination.
Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
the planes have (mostly) uniform capabilities. But I was lazy and
didn't feel like exporting drm_plane_format_check() and hand rolling
anything better. Also I really just wanted to come up with another
user for drm_any_plane_has_format() ;)
Compile tested only.
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..b6f15102dda0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -184,6 +184,17 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ &format_name),
+ mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm: Fix some coding style issues
From: Ville Syrjälä
Put an empty line between the variable declarations and the code, and
use tabs for alignment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..7df025669067 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -162,9 +162,10 @@ static int framebuffer_check(struct drm_device *dev,
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- &format_name));
+ drm_get_format_name(r->pixel_format,
+ &format_name));
return -EINVAL;
}
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
== Series Details == Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format() URL : https://patchwork.freedesktop.org/series/39700/ State : success == Summary == Series 39700v1 series starting with [v3,1/4] drm: Add drm_any_plane_has_format() https://patchwork.freedesktop.org/api/1.0/series/39700/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:429s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:500s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:479s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:404s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:571s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:419s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:466s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:504s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:578s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:431s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:495s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:505s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:513s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest d866fde8c9bc drm/vc4: Validate framebuffer pixel format/modifier 95156651bb61 drm: Fix some coding style issues e82cc7382b48 drm/i915: Eliminate the horrendous format check code 06e78ca5ab60 drm: Add drm_any_plane_has_format() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/issues.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/perf: enable perf support on ICL
== Series Details == Series: drm/i915/perf: enable perf support on ICL URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: incomplete -> PASS (shard-hsw) fdo#103375 Test kms_vblank: Subgroup pipe-a-ts-continuation-dpms-suspend: incomplete -> PASS (shard-hsw) fdo#103540 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3467 pass:1825 dwarn:1 dfail:0 fail:8 skip:1632 time:12305s shard-hswtotal:3467 pass:1772 dwarn:1 dfail:0 fail:2 skip:1691 time:11713s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6906s Blacklisted hosts: shard-kbltotal:3381 pass:1882 dwarn:14 dfail:1 fail:10 skip:1473 time:8809s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
On Apollolake, with stress test warm reboot, audio card was not getting enumerated after reboot. This was a spurious issue happening on Apollolake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for BXT. Extending this fix to BXT as well. Bspec: 21829 Tested on apollolake chromebook by stress test warm reboot with 2500 iterations. v2: * Mention Bspec Index in commit message(Dhinakaran Pandiyan) Signed-off-by: Gaurav K Singh Reviewed-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 709d6ca68074..656f6c931341 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv)) + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) return; i915_audio_component_get_power(kdev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] drm/i915/uc: Sanitize uC
Attempt to sanitize uC for better alignment with rest of GEM driver. v2: cover reset path and sanitize uc before gem Michal Wajdeczko (3): drm/i915/uc: Sanitize uC options early drm/i915/uc: Sanitize uC together with GEM HAX: Enable GuC for CI drivers/gpu/drm/i915/i915_drv.c| 2 -- drivers/gpu/drm/i915/i915_gem.c| 2 ++ drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_guc.h | 6 ++ drivers/gpu/drm/i915/intel_huc.h | 6 ++ drivers/gpu/drm/i915/intel_uc.c| 26 -- drivers/gpu/drm/i915/intel_uc.h| 2 +- drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++ 8 files changed, 46 insertions(+), 6 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915/uc: Sanitize uC options early
We are sanitizing uC related modparams together with other driver
modparams in intel_sanitize_options called from i915_driver_init_hw,
but this is too late for us as we will want to use USES_GUC/USES_HUC
macros at earlier stage. Since our sanitizing does not require any
MMIO access, we can do it in intel_uc_init_early right after we resolve
firmware names.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/intel_uc.c | 6 --
drivers/gpu/drm/i915/intel_uc.h | 1 -
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de4..5ba6d6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1074,8 +1074,6 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
i915_modparams.enable_ppgtt);
DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
- intel_uc_sanitize_options(dev_priv);
-
intel_gvt_sanitize_options(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e5bf0d3..a45171c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -83,7 +83,7 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
}
/**
- * intel_uc_sanitize_options - sanitize uC related modparam options
+ * sanitize_options_early - sanitize uC related modparam options
* @dev_priv: device private
*
* In case of "enable_guc" option this function will attempt to modify
@@ -99,7 +99,7 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
* unless GuC is enabled on given platform and the driver is compiled with
* debug config when this modparam will default to "enable(1..4)".
*/
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *dev_priv)
{
struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
@@ -163,6 +163,8 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
{
intel_guc_init_early(&dev_priv->guc);
intel_huc_init_early(&dev_priv->huc);
+
+ sanitize_options_early(dev_priv);
}
void intel_uc_init_fw(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f76d51d..dce4813 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -28,7 +28,6 @@
#include "intel_huc.h"
#include "i915_params.h"
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
void intel_uc_init_early(struct drm_i915_private *dev_priv);
void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
void intel_uc_init_fw(struct drm_i915_private *dev_priv);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM
Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.
v2: don't forget about reset path (Daniele)
sanitize uc before gem initiated full reset (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c| 2 ++
drivers/gpu/drm/i915/intel_guc.h | 6 ++
drivers/gpu/drm/i915/intel_huc.h | 6 ++
drivers/gpu/drm/i915/intel_uc.c| 18 ++
drivers/gpu/drm/i915/intel_uc.h| 1 +
drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++
6 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e58b741..05b0724 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2998,6 +2998,7 @@ int i915_gem_reset_prepare(struct drm_i915_private
*dev_priv)
}
i915_gem_revoke_fences(dev_priv);
+ intel_uc_sanitize(dev_priv);
return err;
}
@@ -4978,6 +4979,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
* machines is a good idea, we don't - just in case it leaves the
* machine in an unusable condition.
*/
+ intel_uc_sanitize(dev_priv);
i915_gem_sanitize(dev_priv);
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
+static inline int intel_guc_sanitize(struct intel_guc *guc)
+{
+ intel_uc_fw_sanitize(&guc->fw);
+ return 0;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+static inline int intel_huc_sanitize(struct intel_huc *huc)
+{
+ intel_uc_fw_sanitize(&huc->fw);
+ return 0;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
}
+void intel_uc_sanitize(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
+
+ if (!USES_GUC(i915))
+ return;
+
+ GEM_BUG_ON(!HAS_GUC(i915));
+
+ guc_disable_communication(guc);
+
+ intel_huc_sanitize(huc);
+ intel_guc_sanitize(guc);
+
+ __intel_uc_reset_hw(i915);
+}
+
int intel_uc_init_hw(struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
int intel_uc_init_misc(struct drm_i915_private *dev_priv);
void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
int intel_uc_init_hw(struct drm_i915_private *dev_priv);
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
}
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)
+{
+ if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+ uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
struct intel_uc_fw *uc_fw);
int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9..3deae1e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index abd1f7b..cb77b0e 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: misc fixes in headers (RESEND)
On Thu, Mar 08, 2018 at 04:22:55PM +0100, Michal Wajdeczko wrote: > On Thu, 08 Mar 2018 13:58:48 +0100, Petri Latvala > wrote: > > > On Thu, Mar 08, 2018 at 02:20:41PM +0200, Jani Nikula wrote: > > > On Thu, 08 Mar 2018, Chris Wilson wrote: > > > > Quoting Michal Wajdeczko (2018-03-08 09:50:33) > > > >> This is a resend, to make patchwork happy. > > > >> All patches already been reviewed. > > > > > > > > It's still being ignored. :( > > > > > > At least patchwork detected this as a series [1], often that's the > > > problem. > > > > > > Patchwork is not seeing patch 4/4, and due to its weird logic, it's > > still waiting for it instead of considering the series "incomplete". > > > > Looking at the series page, it doesn't even have a revision number. > > > > This causes the pw REST api to show the series as one with 0 patches > > when listing series, there's no series-new-revision event (CI is > > watching that), and it also causes the below: > > > > > I tried to start testing manually from patchwork, it gives me "failed!". > > > > > > Arek checked the logs and patch 4/4 hasn't been received by pw at > > all. Maybe it's still on the way, who knows. > > > > I'm not sure if this is related, but list archive decided to assign > patch 1/4 [1] to old series [2] instead new one [3] > > [1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158080.html > [2] > https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#157974 > [3] > https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#158081 > > ps. patch 4/4 is already in archive [4] > > [4] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158082.html The patch got lost in time and space and has never reached patchwork's mail server. I feed the patchwork with a copy of the mail manually. Expect results soon. -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Fix audio issue on BXT (rev2)
== Series Details == Series: drm: i915: Fix audio issue on BXT (rev2) URL : https://patchwork.freedesktop.org/series/35955/ State : failure == Summary == Series 35955v2 drm: i915: Fix audio issue on BXT https://patchwork.freedesktop.org/api/1.0/series/35955/revisions/2/mbox/ Possible new issues: Test kms_frontbuffer_tracking: Subgroup basic: pass -> INCOMPLETE (fi-bsw-n3050) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-hsw-4770) Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 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:425s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:424s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:224 pass:194 dwarn:0 dfail:0 fail:0 skip:29 fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:501s 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:473s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:245 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:422s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:524s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:537s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:498s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:516s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:518s fi-bxt-dsi failed to collect. IGT log at Patchwork_8292/fi-bxt-dsi/run0.log 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest c90b8bf68afb drm: i915: Fix audio issue on BXT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8292/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote:
> On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski
> wrote:
>
> > Those two concepts are really separate. Since GuC is writing data into
> > its own buffer and we even provide a way for userspace to read directly
> > from it using i915_guc_log_dump debugfs, there's no real reason to tie
> > log level with relay creation.
> > Let's create a separate debugfs, giving userspace a way to create a
> > relay on demand, when it wants to read a continuous log rather than a
> > snapshot.
> >
> > v2: Don't touch guc_log_level on relay creation error, adjust locking
> > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
> > Use struct_mutex rather than runtime.lock for set_log_level
> >
> > Signed-off-by: Michał Winiarski
> > Cc: Chris Wilson
> > Cc: Daniele Ceraolo Spurio
> > Cc: Sagar Arun Kamble
> > Cc: Michal Wajdeczko
> > ---
>
> /snip/
>
> > diff --git a/drivers/gpu/drm/i915/intel_uc.c
> > b/drivers/gpu/drm/i915/intel_uc.c
> > index 90d2f38e22c9..abce0e38528a 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/intel_uc.c
> > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc
> > *guc)
> > i915_gem_object_put(guc->load_err_log);
> > }
> > -int intel_uc_register(struct drm_i915_private *i915)
> > -{
> > - int ret = 0;
> > -
> > - if (!USES_GUC(i915))
> > - return 0;
> > -
> > - if (i915_modparams.guc_log_level)
> > - ret = intel_guc_log_register(&i915->guc);
> > -
> > - return ret;
> > -}
> > -
> > -void intel_uc_unregister(struct drm_i915_private *i915)
> > -{
> > - if (!USES_GUC(i915))
> > - return;
> > -
> > - if (i915_modparams.guc_log_level)
> > - intel_guc_log_unregister(&i915->guc);
> > -}
> > -
> > static int guc_enable_communication(struct intel_guc *guc)
> > {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > diff --git a/drivers/gpu/drm/i915/intel_uc.h
> > b/drivers/gpu/drm/i915/intel_uc.h
> > index d6af984cd789..f76d51d1ce70 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.h
> > +++ b/drivers/gpu/drm/i915/intel_uc.h
> > @@ -31,8 +31,6 @@
> > void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
> > void intel_uc_init_early(struct drm_i915_private *dev_priv);
> > void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
> > -int intel_uc_register(struct drm_i915_private *dev_priv);
> > -void intel_uc_unregister(struct drm_i915_private *dev_priv);
>
> hmm, it looks that timelines of these two functions were very short
> (from patch 2 till patch 8) - so maybe by doing some patch re-order
> can we fully skip them ?
I could drop patch 2 entirely and go straight to the decoupling - but that means
more code movement overall and way more content in this one.
I don't really see a better split (but since I'm the author I'm biased :) ).
I'm open for suggestions.
-Michał
>
> > void intel_uc_init_fw(struct drm_i915_private *dev_priv);
> > void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
> > int intel_uc_init_misc(struct drm_i915_private *dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC (rev2)
== Series Details == Series: drm/i915/uc: Sanitize uC (rev2) URL : https://patchwork.freedesktop.org/series/39634/ State : success == Summary == Series 39634v2 drm/i915/uc: Sanitize uC https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/2/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> FAIL (fi-skl-guc) fdo#103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:498s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:494s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:495s 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:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:417s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:287s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:452s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:419s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:587s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:433s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:518s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:538s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:288 pass:259 dwarn:0 dfail:0 fail:1 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:425s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:524s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest ae3a1d7d7e62 HAX: Enable GuC for CI 11f207630fb0 drm/i915/uc: Sanitize uC together with GEM 70549b8cf2c8 drm/i915/uc: Sanitize uC options early == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
Quoting Michał Winiarski (2018-03-09 16:30:42)
> On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote:
> > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski
> > wrote:
> >
> > > Those two concepts are really separate. Since GuC is writing data into
> > > its own buffer and we even provide a way for userspace to read directly
> > > from it using i915_guc_log_dump debugfs, there's no real reason to tie
> > > log level with relay creation.
> > > Let's create a separate debugfs, giving userspace a way to create a
> > > relay on demand, when it wants to read a continuous log rather than a
> > > snapshot.
> > >
> > > v2: Don't touch guc_log_level on relay creation error, adjust locking
> > > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
> > > Use struct_mutex rather than runtime.lock for set_log_level
> > >
> > > Signed-off-by: Michał Winiarski
> > > Cc: Chris Wilson
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Sagar Arun Kamble
> > > Cc: Michal Wajdeczko
> > > ---
> >
> > /snip/
> >
> > > diff --git a/drivers/gpu/drm/i915/intel_uc.c
> > > b/drivers/gpu/drm/i915/intel_uc.c
> > > index 90d2f38e22c9..abce0e38528a 100644
> > > --- a/drivers/gpu/drm/i915/intel_uc.c
> > > +++ b/drivers/gpu/drm/i915/intel_uc.c
> > > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc
> > > *guc)
> > > i915_gem_object_put(guc->load_err_log);
> > > }
> > > -int intel_uc_register(struct drm_i915_private *i915)
> > > -{
> > > - int ret = 0;
> > > -
> > > - if (!USES_GUC(i915))
> > > - return 0;
> > > -
> > > - if (i915_modparams.guc_log_level)
> > > - ret = intel_guc_log_register(&i915->guc);
> > > -
> > > - return ret;
> > > -}
> > > -
> > > -void intel_uc_unregister(struct drm_i915_private *i915)
> > > -{
> > > - if (!USES_GUC(i915))
> > > - return;
> > > -
> > > - if (i915_modparams.guc_log_level)
> > > - intel_guc_log_unregister(&i915->guc);
> > > -}
> > > -
> > > static int guc_enable_communication(struct intel_guc *guc)
> > > {
> > > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > > diff --git a/drivers/gpu/drm/i915/intel_uc.h
> > > b/drivers/gpu/drm/i915/intel_uc.h
> > > index d6af984cd789..f76d51d1ce70 100644
> > > --- a/drivers/gpu/drm/i915/intel_uc.h
> > > +++ b/drivers/gpu/drm/i915/intel_uc.h
> > > @@ -31,8 +31,6 @@
> > > void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
> > > void intel_uc_init_early(struct drm_i915_private *dev_priv);
> > > void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
> > > -int intel_uc_register(struct drm_i915_private *dev_priv);
> > > -void intel_uc_unregister(struct drm_i915_private *dev_priv);
> >
> > hmm, it looks that timelines of these two functions were very short
> > (from patch 2 till patch 8) - so maybe by doing some patch re-order
> > can we fully skip them ?
>
> I could drop patch 2 entirely and go straight to the decoupling - but that
> means
> more code movement overall and way more content in this one.
>
> I don't really see a better split (but since I'm the author I'm biased :) ).
> I'm open for suggestions.
I can settle the argument by grabbing the first 3 patches as code
movement, before we get into the details. Ok?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] HAX: Enable GuC for CI
From: Michal Wajdeczko v2: except running with HYPERVISOR --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9d0ff4..3deae1e22974 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1c1a00df010b..cfa21f6058a5 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915/guc: Move GuC notification handling to separate function
From: Michal Wajdeczko
To allow future code reuse. While here, fix comment style.
v2: Notifications are a separate thing - rename the handler (Sagar)
Suggested-by: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Sagar Arun Kamble
Reviewed-by: Sagar Arun Kamble
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-3-michal.winiar...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 33 ++---
drivers/gpu/drm/i915/intel_guc.c | 37 +
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..828f3104488c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1766,37 +1766,8 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir)
{
- if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
- /* Sample the log buffer flush related bits & clear them out now
-* itself from the message identity register to minimize the
-* probability of losing a flush interrupt, when there are back
-* to back flush interrupts.
-* There can be a new flush interrupt, for different log buffer
-* type (like for ISR), whilst Host is handling one (for DPC).
-* Since same bit is used in message register for ISR & DPC, it
-* could happen that GuC sets the bit for 2nd interrupt but Host
-* clears out the bit on handling the 1st interrupt.
-*/
- u32 msg, flush;
-
- msg = I915_READ(SOFT_SCRATCH(15));
- flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
- INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
- if (flush) {
- /* Clear the message bits that are handled */
- I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
-
- /* Handle flush interrupt in bottom half */
- queue_work(dev_priv->guc.log.runtime.flush_wq,
- &dev_priv->guc.log.runtime.flush_work);
-
- dev_priv->guc.log.flush_interrupt_count++;
- } else {
- /* Not clearing of unhandled event bits won't result in
-* re-triggering of the interrupt.
-*/
- }
- }
+ if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT)
+ intel_guc_to_host_event_handler(&dev_priv->guc);
}
static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..25f92291fd40 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -364,6 +364,43 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len)
return ret;
}
+void intel_guc_to_host_event_handler(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 msg, flush;
+
+ /*
+* Sample the log buffer flush related bits & clear them out now
+* itself from the message identity register to minimize the
+* probability of losing a flush interrupt, when there are back
+* to back flush interrupts.
+* There can be a new flush interrupt, for different log buffer
+* type (like for ISR), whilst Host is handling one (for DPC).
+* Since same bit is used in message register for ISR & DPC, it
+* could happen that GuC sets the bit for 2nd interrupt but Host
+* clears out the bit on handling the 1st interrupt.
+*/
+
+ msg = I915_READ(SOFT_SCRATCH(15));
+ flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
+ INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
+ if (flush) {
+ /* Clear the message bits that are handled */
+ I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
+
+ /* Handle flush interrupt in bottom half */
+ queue_work(guc->log.runtime.flush_wq,
+ &guc->log.runtime.flush_work);
+
+ guc->log.flush_interrupt_count++;
+ } else {
+ /*
+* Not clearing of unhandled event bits won't result in
+* re-triggering of the interrupt.
+*/
+ }
+}
+
int intel_guc_sample_forcewake(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424
[Intel-gfx] [CI 1/4] drm/i915/guc: Tidy guc_log_control
From: Michał Winiarski
We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.
v2: Tidy macros, keep debug messages, use helper var for enable,
correct typo (Michał)
Fix incorrect input validaction (Sagar)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Reviewed-by: Sagar Arun Kamble
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-1-michal.winiar...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++---
drivers/gpu/drm/i915/intel_guc_log.c | 80 +---
drivers/gpu/drm/i915/intel_guc_log.h | 3 +-
3 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 34d12522a1da..c4cc8fef11a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2499,13 +2499,10 @@ static int i915_guc_log_control_get(void *data, u64
*val)
{
struct drm_i915_private *dev_priv = data;
- if (!HAS_GUC(dev_priv))
+ if (!USES_GUC(dev_priv))
return -ENODEV;
- if (!dev_priv->guc.log.vma)
- return -EINVAL;
-
- *val = i915_modparams.guc_log_level;
+ *val = intel_guc_log_control_get(&dev_priv->guc);
return 0;
}
@@ -2514,10 +2511,10 @@ static int i915_guc_log_control_set(void *data, u64 val)
{
struct drm_i915_private *dev_priv = data;
- if (!HAS_GUC(dev_priv))
+ if (!USES_GUC(dev_priv))
return -ENODEV;
- return intel_guc_log_control(&dev_priv->guc, val);
+ return intel_guc_log_control_set(&dev_priv->guc, val);
}
DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index c0c2e7d1c7d7..7e59fb07b06b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -659,51 +659,63 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(&guc->log.vma);
}
-int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
+int intel_guc_log_control_get(struct intel_guc *guc)
+{
+ GEM_BUG_ON(!guc->log.vma);
+ GEM_BUG_ON(i915_modparams.guc_log_level < 0);
+
+ return i915_modparams.guc_log_level;
+}
+
+#define GUC_LOG_LEVEL_DISABLED 0
+#define LOG_LEVEL_TO_ENABLED(x)((x) > 0)
+#define LOG_LEVEL_TO_VERBOSITY(x) ({ \
+ typeof(x) _x = (x); \
+ LOG_LEVEL_TO_ENABLED(_x) ? _x - 1 : 0; \
+})
+#define VERBOSITY_TO_LOG_LEVEL(x) ((x) + 1)
+int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
- bool enable_logging = control_val > 0;
- u32 verbosity;
+ bool enabled = LOG_LEVEL_TO_ENABLED(val);
int ret;
- if (!guc->log.vma)
- return -ENODEV;
+ BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
+ GEM_BUG_ON(!guc->log.vma);
+ GEM_BUG_ON(i915_modparams.guc_log_level < 0);
- BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
- if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
+ /*
+* GuC is recognizing log levels starting from 0 to max, we're using 0
+* as indication that logging should be disabled.
+*/
+ if (val < GUC_LOG_LEVEL_DISABLED ||
+ val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX))
return -EINVAL;
- /* This combination doesn't make sense & won't have any effect */
- if (!enable_logging && !i915_modparams.guc_log_level)
- return 0;
+ mutex_lock(&dev_priv->drm.struct_mutex);
- verbosity = enable_logging ? control_val - 1 : 0;
+ if (i915_modparams.guc_log_level == val) {
+ ret = 0;
+ goto out_unlock;
+ }
- ret = mutex_lock_interruptible(&dev_priv->drm.struct_mutex);
- if (ret)
- return ret;
intel_runtime_pm_get(dev_priv);
- ret = guc_log_control(guc, enable_logging, verbosity);
+ ret = guc_log_control(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
- mutex_unlock(&dev_priv->drm.struct_mutex);
-
- if (ret < 0) {
- DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
- return ret;
+ if (ret) {
+ DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret);
+ goto out_unlock;
}
- if (enable_logging) {
- i915_modparams.guc_log_level = 1 + verbosity;
+ i915_modparams.guc_log_level = val;
- /*
-* If log was disabled at boot time, then the relay channel file
-* wouldn't have been created by n
[Intel-gfx] [CI 2/4] drm/i915/guc: Create common entry points for log register/unregister
From: Michał Winiarski
We have many functions responsible for allocating different parts of
GuC log runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.
v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał)
s/dev_priv/i915 (Sagar)
Make guc_log_relay_* static (sparse)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Reviewed-by: Sagar Arun Kamble
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-2-michal.winiar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/intel_guc_log.c | 156 ++-
drivers/gpu/drm/i915/intel_guc_log.h | 6 +-
drivers/gpu/drm/i915/intel_uc.c | 41 +
drivers/gpu/drm/i915/intel_uc.h | 2 +
5 files changed, 95 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de45644d..987c6770d1a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1238,9 +1238,11 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
- i915_guc_log_register(dev_priv);
i915_setup_sysfs(dev_priv);
+ /* Depends on debugfs having been initialized */
+ intel_uc_register(dev_priv);
+
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
} else
@@ -1298,7 +1300,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
- i915_guc_log_unregister(dev_priv);
+ intel_uc_unregister(dev_priv);
drm_dev_unregister(&dev_priv->drm);
i915_gem_shrinker_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7e59fb07b06b..90b395f34808 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,7 +443,7 @@ void intel_guc_log_init_early(struct intel_guc *guc)
INIT_WORK(&guc->log.runtime.flush_work, capture_logs_work);
}
-int intel_guc_log_relay_create(struct intel_guc *guc)
+static int guc_log_relay_create(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
@@ -496,7 +496,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc)
return ret;
}
-void intel_guc_log_relay_destroy(struct intel_guc *guc)
+static void guc_log_relay_destroy(struct intel_guc *guc)
{
mutex_lock(&guc->log.runtime.relay_lock);
@@ -514,49 +514,6 @@ void intel_guc_log_relay_destroy(struct intel_guc *guc)
mutex_unlock(&guc->log.runtime.relay_lock);
}
-static int guc_log_late_setup(struct intel_guc *guc)
-{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
- int ret;
-
- if (!guc_log_has_runtime(guc)) {
- /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/
- ret = intel_guc_log_relay_create(guc);
- if (ret)
- goto err;
-
- mutex_lock(&dev_priv->drm.struct_mutex);
- intel_runtime_pm_get(dev_priv);
- ret = guc_log_runtime_create(guc);
- intel_runtime_pm_put(dev_priv);
- mutex_unlock(&dev_priv->drm.struct_mutex);
-
- if (ret)
- goto err_relay;
- }
-
- ret = guc_log_relay_file_create(guc);
- if (ret)
- goto err_runtime;
-
- return 0;
-
-err_runtime:
- mutex_lock(&dev_priv->drm.struct_mutex);
- guc_log_runtime_destroy(guc);
- mutex_unlock(&dev_priv->drm.struct_mutex);
-err_relay:
- intel_guc_log_relay_destroy(guc);
-err:
- /* logging will remain off */
- i915_modparams.guc_log_level = 0;
- return ret;
-}
-
static void guc_log_capture_logs(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,16 +533,6 @@ static void guc_flush_logs(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
- if (!USES_GUC_SUBMISSION(dev_priv) || !i915_modparams.guc_log_level)
- return;
-
- /* First disable the interrupts, will be renabled afterwards */
- mutex_lock(&dev_priv->drm.struct_mutex);
- intel_runtime_pm_get(dev_priv);
- gen9_disable_guc_interrupts(dev_priv);
- intel_runtime_pm_put(dev_priv);
- mutex_unlo
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
On 09/03/2018 13:46, Chris Wilson wrote:
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.
v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request
Signed-off-by: Chris Wilson
Cc: Paneri, Praveen
Cc: Kamble, Sagar A
Cc: Antonio Argenziano
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/gem_ctx_freq.c | 648 +
tests/meson.build | 1 +
4 files changed, 651 insertions(+)
create mode 100644 tests/gem_ctx_freq.c
[snip]
+static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+ const struct test {
+ uint32_t min, max;
+ } tests[] = {
+ { min - 50, max - 50 },
+ { min - 50, max },
+ { min - 50, max + 50 },
+ { min, max + 50 },
+ { min + 50, max + 50 },
+
+ { min - 50, min - 50 },
+
+ { min - 50, min },
+ { min + 50, min },
+ { min, min - 50 },
+
+ { max + 50, max },
+ { max, max + 50 },
+ { max, max - 50 },
+
+ { max + 50, max + 50 },
Is unprivileged "{ max, max }" allowed? In other words pin to max
frequency by anyone? If so, what happens when all userspace learns about
this and wants to use it just so to be lower latency than the other guy?
Or even on our integrated graphics, such userspace would unwisely take
away power budget from the CPU. Or could it even harm itself by
triggering too much thermal throttling and run slower than if it let the
balance be controlled by the system?
Or will this be tied with the cgroup work to allow only clients allowed
by sysadmin to do this?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: misc fixes in headers (RESEND)
== Series Details == Series: drm/i915: misc fixes in headers (RESEND) URL : https://patchwork.freedesktop.org/series/39589/ State : success == Summary == Series 39589v1 drm/i915: misc fixes in headers (RESEND) https://patchwork.freedesktop.org/api/1.0/series/39589/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:424s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:509s 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:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:481s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:469s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:405s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:584s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:592s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:422s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:290s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:520s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:457s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:422s fi-kbl-7500u total:288 pass:262 dwarn:1 dfail:0 fail:1 skip:24 time:467s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:506s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:584s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:525s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:535s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:514s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:511s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 2b518e87976b drm/i915: Move i915_gpu_error into its own header f2969e101bac drm/i915: Make header i915_pmu.h more robust 87481ecfb862 drm/i915: Change parameters order in i915_gem_batch_pool_init c055bfc9c223 drm/i915: Include i915_reg.h in intel_ringbuffer.h == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling
On 08/03/2018 14:07, Chris Wilson wrote:
There is some redundancy between dma_fence->ops->enable_signaling (via
i915_fence_enable_signaling) and our backend,
intel_engine_enable_signaling() in that both levels recheck the fence
status multiple times. If we convert intel_engine_enable_signaling() to
return the information desired by dma_fence->ops->enable_signaling, we
can reduce i915_fence_enable_signaling to a simple stub and avoid
trying to reinterpret the same information.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/i915_request.c | 6 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d437beac3969..2a841800d4cf 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence)
static bool i915_fence_enable_signaling(struct dma_fence *fence)
{
- if (i915_fence_signaled(fence))
- return false;
This was based on hws seqno check...
-
- intel_engine_enable_signaling(to_request(fence), true);
- return !i915_fence_signaled(fence);
+ return intel_engine_enable_signaling(to_request(fence), true);
}
static signed long i915_fence_wait(struct dma_fence *fence,
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 1f79e7a47433..671a6d61e29d 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -730,10 +730,11 @@ static void insert_signal(struct intel_breadcrumbs *b,
list_add(&request->signaling.link, &iter->signaling.link);
}
-void intel_engine_enable_signaling(struct i915_request *request, bool wakeup)
+bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup)
{
struct intel_engine_cs *engine = request->engine;
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct intel_wait *wait = &request->signaling.wait;
u32 seqno;
/*
@@ -750,12 +751,12 @@ void intel_engine_enable_signaling(struct i915_request
*request, bool wakeup)
seqno = i915_request_global_seqno(request);
if (!seqno) /* will be enabled later upon execution */
- return;
+ return true;
- GEM_BUG_ON(request->signaling.wait.seqno);
- request->signaling.wait.tsk = b->signaler;
- request->signaling.wait.request = request;
- request->signaling.wait.seqno = seqno;
+ GEM_BUG_ON(wait->seqno);
+ wait->tsk = b->signaler;
+ wait->request = request;
+ wait->seqno = seqno;
/*
* Add ourselves into the list of waiters, but registering our
@@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct i915_request
*request, bool wakeup)
*/
spin_lock(&b->rb_lock);
insert_signal(b, request, seqno);
- wakeup &= __intel_engine_add_wait(engine, &request->signaling.wait);
+ wakeup &= __intel_engine_add_wait(engine, wait);
spin_unlock(&b->rb_lock);
- if (wakeup)
+ if (wakeup) {
wake_up_process(b->signaler);
+ return !intel_wait_complete(wait);
... and would now be based on breadcrumb waiter waking up and removing
itself from the tree.
So some potential latency where it wasn't before, well, enable-disable
signalling cycles actually.
If I got it right.. breadcrumbs code confuses me massively these days.
Regards,
Tvrtko
+ }
+
+ return true;
}
void intel_engine_cancel_signaling(struct i915_request *request)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0320c2c4cfba..aa34b2ff04bc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -939,7 +939,7 @@ bool intel_engine_add_wait(struct intel_engine_cs *engine,
struct intel_wait *wait);
void intel_engine_remove_wait(struct intel_engine_cs *engine,
struct intel_wait *wait);
-void intel_engine_enable_signaling(struct i915_request *request, bool wakeup);
+bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup);
void intel_engine_cancel_signaling(struct i915_request *request);
static inline bool intel_engine_has_waiter(const struct intel_engine_cs *engine)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Quoting Tvrtko Ursulin (2018-03-09 17:06:45)
>
> On 09/03/2018 13:46, Chris Wilson wrote:
> > Exercise some new API that allows applications to request that
> > individual contexts are executed within a desired frequency range.
> >
> > v2: Split single/continuous set_freq subtests
> > v3: Do an up/down ramp for individual freq request, check nothing
> > changes after each invalid request
> >
> > Signed-off-by: Chris Wilson
> > Cc: Paneri, Praveen
> > Cc: Kamble, Sagar A
> > Cc: Antonio Argenziano
> > ---
> > tests/Makefile.am | 1 +
> > tests/Makefile.sources | 1 +
> > tests/gem_ctx_freq.c | 648
> > +
> > tests/meson.build | 1 +
> > 4 files changed, 651 insertions(+)
> > create mode 100644 tests/gem_ctx_freq.c
> >
>
> [snip]
>
> > +static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
> > +{
> > + const struct test {
> > + uint32_t min, max;
> > + } tests[] = {
> > + { min - 50, max - 50 },
> > + { min - 50, max },
> > + { min - 50, max + 50 },
> > + { min, max + 50 },
> > + { min + 50, max + 50 },
> > +
> > + { min - 50, min - 50 },
> > +
> > + { min - 50, min },
> > + { min + 50, min },
> > + { min, min - 50 },
> > +
> > + { max + 50, max },
> > + { max, max + 50 },
> > + { max, max - 50 },
> > +
> > + { max + 50, max + 50 },
>
> Is unprivileged "{ max, max }" allowed? In other words pin to max
> frequency by anyone? If so, what happens when all userspace learns about
> this and wants to use it just so to be lower latency than the other guy?
I've gone with allow, since (a) it's always constrained by the global
user imposed limit and (b) userspace can already keep the gpu at max
frequency by load. At the start I opined that only CAP_SYS_NICE would be
allowed to raise the frequency bounds, but realised that in practice it
is immaterial as they were already running at max frequency anyway.
/*
* As we constrain the frequency request from the
* context (application) by the sysadmin imposed limits,
* it is reasonable to allow the application to
* specify its preferred range within those limits.
* That is we do not need to restrict requesting
* a higher frequency to privileged (CAP_SYS_NICE)
* processes.
*/
> Or even on our integrated graphics, such userspace would unwisely take
> away power budget from the CPU. Or could it even harm itself by
> triggering too much thermal throttling and run slower than if it let the
> balance be controlled by the system?
It will indeed. Running at max frequency is not a sensible idea for
anything but a few applications (dare we say miners? ;). I thought
compositors might benefit from reduced latency by starting at max,
https://bugs.freedesktop.org/show_bug.cgi?id=102199
but realistically they care more about power consumption and gain most of
the latency reduction from priority sorting and preemption.
On the bright side, we give them a loaded gun with which they can shoot
both feet off. They have to be confident that they do know their
behaviour better than the hw (which for a few will be true). We give
them the means to do so, we do not say it is wise.
> Or will this be tied with the cgroup work to allow only clients allowed
> by sysadmin to do this?
That's what I think as well. I think we will end up with everything that
can be adjusted via CONTEXT_SETPARAM will be constrained by cgroup.
Once again, we can only look at the integration of schedfreq and CFS as
being the direction the GPUs will also eventually take.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for CNL port refactoring (rev2)
== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: incomplete -> PASS (shard-hsw) fdo#103375 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_vblank: Subgroup pipe-a-ts-continuation-dpms-suspend: incomplete -> PASS (shard-hsw) fdo#103540 Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3381 pass:1778 dwarn:1 dfail:0 fail:9 skip:1591 time:11749s shard-hswtotal:3467 pass:1773 dwarn:1 dfail:0 fail:1 skip:1691 time:11736s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6959s Blacklisted hosts: shard-kbltotal:3390 pass:1905 dwarn:1 dfail:0 fail:9 skip:1473 time:8543s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/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: Remove the impedance mismatch around intel_engine_enable_signaling
Quoting Tvrtko Ursulin (2018-03-09 17:24:33)
>
> On 08/03/2018 14:07, Chris Wilson wrote:
> > There is some redundancy between dma_fence->ops->enable_signaling (via
> > i915_fence_enable_signaling) and our backend,
> > intel_engine_enable_signaling() in that both levels recheck the fence
> > status multiple times. If we convert intel_engine_enable_signaling() to
> > return the information desired by dma_fence->ops->enable_signaling, we
> > can reduce i915_fence_enable_signaling to a simple stub and avoid
> > trying to reinterpret the same information.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > Cc: Michal Winiarski
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 6 +-
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 +
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
> > 3 files changed, 15 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index d437beac3969..2a841800d4cf 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence)
> >
> > static bool i915_fence_enable_signaling(struct dma_fence *fence)
> > {
> > - if (i915_fence_signaled(fence))
> > - return false;
>
> This was based on hws seqno check...
>
> > -
> > - intel_engine_enable_signaling(to_request(fence), true);
> > - return !i915_fence_signaled(fence);
> > + return intel_engine_enable_signaling(to_request(fence), true);
> > }
> > @@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct
> > i915_request *request, bool wakeup)
> >*/
> > spin_lock(&b->rb_lock);
> > insert_signal(b, request, seqno);
> > - wakeup &= __intel_engine_add_wait(engine, &request->signaling.wait);
> > + wakeup &= __intel_engine_add_wait(engine, wait);
> > spin_unlock(&b->rb_lock);
> >
> > - if (wakeup)
> > + if (wakeup) {
> > wake_up_process(b->signaler);
> > + return !intel_wait_complete(wait);
>
> ... and would now be based on breadcrumb waiter waking up and removing
> itself from the tree.
And don't forget the same HWS check before the waiter is inserted. So we
have the same guards as before, just inside yet another spinlock.
> So some potential latency where it wasn't before, well, enable-disable
> signalling cycles actually.
The extra steps would be the insert_signal(). Fwiw, we could reorder the
insert_signal() but frankly this, dma_fence enable signaling of an
inflight request, is not a fast path. More commonly we will be enabling
signaling on the request as it is submitted (where wakeup is false and
we know that the HWS cannot be complete).
-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 [CI,1/4] drm/i915/guc: Tidy guc_log_control
== Series Details == Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39710/ State : success == Summary == Series 39710v1 series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control https://patchwork.freedesktop.org/api/1.0/series/39710/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:421s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:501s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:482s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:468s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:403s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-cnl-y3total:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:409s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:290s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:517s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:414s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:454s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:417s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:466s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:582s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:496s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:519s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:391s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:512s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 59dcd0fe0c8f HAX: Enable GuC for CI d4bc41a8a9d6 drm/i915/guc: Move GuC notification handling to separate function 9ab68c44f5e7 drm/i915/guc: Create common entry points for log register/unregister e0ff1976b21c drm/i915/guc: Tidy guc_log_control == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support
== Series Details == Series: Add NV12 support URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Series 39670v1 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 +1 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:426s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:496s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:487s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:488s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:477s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:405s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:408s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:286s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:519s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:457s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:424s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s 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:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:522s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:532s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:499s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:427s 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:390s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:503s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:520s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 749e844cfff1 drm/i915: Display WA 827 e6555c173591 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg 8ca8611bf6b0 drm/i915: Add NV12 support to intel_framebuffer_init 7531f149aa78 drm/i915: Add NV12 as supported format for sprite plane 0534f14fde9e drm/i915: Add NV12 as supported format for primary plane 614617ba6b50 drm/i915: Upscale scaler max scale for NV12 5f5596d38394 drm/i915: Update format_is_yuv() to include NV12 3ff123d5f468 drm/i915: Set scaler mode for NV12 42e536b29b4c drm/i915/skl: split skl_compute_ddb function 593a17e31721 drm/i915/skl+: nv12 workaround disable WM level 1-7 e007283a4b5a drm/i915/skl+: make sure higher latency level has higher wm value 02129257ecd5 drm/i915/skl+: pass skl_wm_level struct to wm compute func 7cd21a2a8f90 drm/i915/skl+: NV12 related changes for WM 883e1369e215 drm/i915/skl+: support verification of DDB HW state for NV12 0992f20891ee drm/i915/skl+: add NV12 in skl_format_to_fourcc 5453c9d856f6 drm/i915/skl+: refactor WM calculation for NV12 48faccbb411f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up last week. drm-misc-next-2018-03-09-3: drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Cheers, Sean The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e: drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-09-3 for you to fetch changes up to 60beeccc72cabefcb8874fec542b3142e262b6c2: drm/rockchip: Don't use atomic constructs for psr (2018-03-08 23:28:53 +0100) drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Arnd Bergmann (2): drm: fix drm_get_max_iomem type mismatch tinydrm: add backlight dependency Baruch Siach (1): drm: of: simplify component probe code Benjamin Gaignard (1): drm/stm: check pitch and size calculations even if !CONFIG_MMU Chris Wilson (1): drm/mm: Fix caching of leftmost node in the interval tree Christian König (2): drm/prime: fix potential race in drm_gem_map_detach drm/prime: make the pages array optional for drm_prime_sg_to_page_addr_arrays Daniel Stone (1): drm/vc4: Advertise supported modifiers for planes Jeffy Chen (10): drm/rockchip: Add device links for master and components drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale() drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector and encoder cleanup drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register() drm/rockchip: analogix_dp: reorder psr_unregister call in unbind drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup. drm/rockchip: inno_hdmi: Fix error handling path. drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind() Jernej Skrabec (8): dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline drm/sun4i: Add support for H3 display engine drm/sun4i: Add support for H3 mixer 0 drm/sun4i: Fix polarity configuration for DW HDMI PHY drm/sun4i: Add support for variants to DW HDMI PHY drm/sun4i: Move and expand DW HDMI PHY register macros drm/sun4i: Add support for H3 HDMI PHY variant drm/sun4i: Allow building on arm64 Joe Moriarty (2): drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem Jyri Sarha (1): drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane Linus Walleij (7): drm/panel: Fix ARM Versatile panel clocks bridge: Elaborate a bit on dumb VGA bridges in Kconfig drm: simple_kms_helper: Fix .mode_valid() documentation drm/pl111: Make the default BPP a per-variant variable drm/pl111: Handle the RealView variant separately drm/bridge: sii902x: Retry status read after DDI I2C drm/pl111: Use max memory bandwidth for resolution Maarten Lankhorst (1): drm/atomic: Call ww_acquire_done after drm_modeset_lock_all Marek Szyprowski (2): drm/bridge: analogix_dp: Postpone enabling runtime power management drm/bridge: analogix_dp: Don't create useless connectors Maxime Ripard (4): drm/sun4i: backend: Assign the pipes automatically drm/sun4i: Remove the plane description structure drm/sun4i: backend: Make zpos configurable drm/sun4i: backend: Remove ARGB spoofing Neil Armstrong (1): drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs Oleksandr Andrushchenko (5): drm/simple_kms_helper: Fix NU
[Intel-gfx] [RFC v3 1/8] drm: Add Enhanced Gamma LUT precision structure
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 19 +++
include/uapi/drm/drm_mode.h | 15 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7..e706da6 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -426,6 +426,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_force_disable);
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (32 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract_ext);
+
/**
* drm_mode_plane_set_obj_prop - set the value of a property
* @plane: drm plane object to set property value for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b5d7d9e..5f3ed88 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -615,6 +615,21 @@ struct drm_color_lut {
__u16 reserved;
};
+/*
+ * Creating 32 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+* Data is U0.32 fixed point format.
+*/
+ __u32 red;
+ __u32 green;
+ __u32 blue;
+ __u32 reserved;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 0/8] Add Plane Color Properties
This patch series adds properties for plane color features. It adds properties for degamma used to linearize data, CSC used for gamut conversion, and gamma used to again non-linearize data as per panel supported color space. These can be utilize by user space to convert planes from one format to another, one color space to another etc. Usersapce can take smart blending decisions and utilize these hardware supported plane color features to get accurate color profile. The same can help in consistent color quality from source to panel taking advantage of advanced color features in hardware. These patches just add the property interfaces and enable helper functions. This series adds Intel Gen9 specific plane gamma feature. We can build up and add other platform/hardware specific implementation on top of this series Note: This is just to get a design feedback whether these interfaces look ok. Based on community feedback on interfaces, we will implement IGT tests to validate plane color features. This is un-tested currently. Also, userspace implementation to use these properties is currently not available. v2: Dropped legacy gamma table for plane as suggested by Maarten. Added Gen9/BDW plane gamma feature and rebase on tot. v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul comments and moved plane color properties to drm_plane instead of mode_config. Added property documentation as suggested by Daniel, Vetter. Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. Uma Shankar (8): drm: Add Enhanced Gamma LUT precision structure drm: Add Plane Degamma properties drm: Add Plane CTM property drm: Add Plane Gamma properties drm: Define helper function for plane color enabling drm/i915: Enable plane color features drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms drm/i915: Load plane color luts from atomic flip Documentation/gpu/drm-kms.rst | 18 drivers/gpu/drm/drm_atomic.c | 30 +++ drivers/gpu/drm/drm_atomic_helper.c | 12 +++ drivers/gpu/drm/drm_plane.c | 131 ++ drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_pci.c | 5 +- drivers/gpu/drm/i915/i915_reg.h | 24 ++ drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + drivers/gpu/drm/i915/intel_color.c| 80 ++ drivers/gpu/drm/i915/intel_device_info.h | 5 ++ drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_drv.h | 10 +++ drivers/gpu/drm/i915/intel_sprite.c | 4 + include/drm/drm_color_mgmt.h | 5 ++ include/drm/drm_plane.h | 66 +++ include/uapi/drm/drm_mode.h | 15 16 files changed, 417 insertions(+), 1 deletion(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
