[Intel-gfx] [PATCH v3 5/5] drm/i915: squash lines for simple wrapper functions

2016-09-15 Thread Masahiro Yamada
Remove unneeded variables and assignments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Keep the wrapper function.
Cleanup of variables and assignments only.
  - Fix intel_engine_init_common() as well.

 drivers/gpu/drm/i915/i915_drv.c| 8 +---
 drivers/gpu/drm/i915/intel_engine_cs.c | 8 +---
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..1503c88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1324,13 +1324,7 @@ void i915_driver_unload(struct drm_device *dev)
 
 static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
 {
-   int ret;
-
-   ret = i915_gem_open(dev, file);
-   if (ret)
-   return ret;
-
-   return 0;
+   return i915_gem_open(dev, file);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e405f10..ebb4bf8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -298,13 +298,7 @@ static void intel_engine_cleanup_scratch(struct 
intel_engine_cs *engine)
  */
 int intel_engine_init_common(struct intel_engine_cs *engine)
 {
-   int ret;
-
-   ret = intel_engine_init_breadcrumbs(engine);
-   if (ret)
-   return ret;
-
-   return 0;
+   return intel_engine_init_breadcrumbs(engine);
 }
 
 void intel_engine_reset_irq(struct intel_engine_cs *engine)
-- 
1.9.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 [v6,1/6] drm/i915: Fallback to lower link rate and lane count during link training

2016-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [v6,1/6] drm/i915: Fallback to lower link rate and 
lane count during link training
URL   : https://patchwork.freedesktop.org/series/12534/
State : success

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6770hq failed to collect. IGT log at Patchwork_2541/fi-skl-6770hq/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2541/

a6259b0355d72540204077883a71796ac89e7603 drm-intel-nightly: 
2016y-09m-15d-14h-43m-41s UTC integration manifest
d7c15e7 drm/i915/dp/mst: Add support for upfront link training for DP MST
e16692c drm/i915/dp: Enable Upfront link training on DDI platforms
8a987ec drm/i915: Code cleanup to use dev_priv and INTEL_GEN
a47436b drm/i915: Change the placement of some static functions in intel_dp.c
1b8ba32 drm/i915: Remove the link rate and lane count loop in compute config
1a67daa drm/i915: Fallback to lower link rate and lane count during link 
training

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


[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

2016-09-15 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_pm.c

between commit:

  f403372658fc ("drm/i915/skl: Add support for the SAGV, fix underrun hangs")
(which is also in the drm-intel tree)

from Linus' tree and commit:

  6f3fff602e81 ("drm/i915: Add ddb size field to device info structure")

from the drm-intel tree.

I fixed it up (I just used the drm-intel version) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t v5 07/13] tests/sw_sync: Add subtest test_sync_merge

2016-09-15 Thread Robert Foss



On 2016-09-15 04:41 PM, Chris Wilson wrote:

On Thu, Sep 15, 2016 at 02:40:12PM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3061279..26226bd 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -116,6 +116,70 @@ static void test_sync_wait(void)
close(timeline);
 }

+static void test_sync_merge(void)
+{
+   int in_fence[3];
+   int fence_merge;
+   int timeline;
+   int active, signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_fence_create(timeline, 2);
+   in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+   fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sw_sync_merge(in_fence[2], fence_merge);


sw_sync_merge() really does need the negative tests:

invalid fd (-1),
device fd (/dev/dri/card0),
file fd.


Open other descriptors sounds like a good idea, but for device and file 
fds, which ones will always be available and open-able on any system?




should cover the most common errors (fuzz testing will hit the rest!)


+
+   /* confirm all fences have one active point (even d) */
+   active = sw_sync_fence_count_status(in_fence[0],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[1],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[2],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+   /* confirm that fence_merge is not signaled until the max of fence 
0,1,2 */
+   sw_sync_timeline_inc(timeline, 1);



+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);


This is missing from the earlier test_sync_busy().


+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+   signaled = sw_sync_fence_count_status(fence_merge,
+  SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");


Hmm, counting STATUS_SIGNALED / STATUS_ACTIVE is not behaving how I
would intuitively expect.

At this point, timeline.seqno = 3, I would expect count_signaled(merge)
== 3 (and count_fences(merge) == 3 => merge is now signaled).
But that's just my expectations


I'll have a look into this.


Rob.

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


[Intel-gfx] [PATCH v3 2/6] drm/i915: Remove the link rate and lane count loop in compute config

2016-09-15 Thread Manasi Navare
While configuring the pipe during modeset, it should use
max clock and max lane count and reduce the bpp until
the requested mode rate is less than or equal to
available link BW.
This is required to pass DP Compliance.

v3:
* Add Debug print if requested mode cannot be supported
during modeset (Dhinakaran Pandiyan)
v2:
* Removed the loop since we use max values of clock
and lane count (Dhinakaran Pandiyan)

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d81c67cb..65b4559 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1644,23 +1644,17 @@ intel_dp_compute_config(struct intel_encoder *encoder,
for (; bpp >= 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
   bpp);
+   clock = max_clock;
+   lane_count = max_lane_count;
+   link_clock = common_rates[clock];
+   link_avail = intel_dp_max_data_rate(link_clock,
+   lane_count);
 
-   for (clock = min_clock; clock <= max_clock; clock++) {
-   for (lane_count = min_lane_count;
-   lane_count <= max_lane_count;
-   lane_count <<= 1) {
-
-   link_clock = common_rates[clock];
-   link_avail = intel_dp_max_data_rate(link_clock,
-   lane_count);
-
-   if (mode_rate <= link_avail) {
-   goto found;
-   }
-   }
-   }
+   if (mode_rate <= link_avail)
+   goto found;
}
 
+   DRM_DEBUG_KMS("Requested Mode Rate not supported\n");
return false;
 
 found:
-- 
1.9.1

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


[Intel-gfx] [PATCH v17 5/6] drm/i915/dp: Enable Upfront link training on DDI platforms

2016-09-15 Thread Manasi Navare
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes. To address these scenarios we need to train the link before
modeset. This upfront link training caches the values of max link rate
and max lane count that get used later during modeset. Upfront link
training does not change any HW state, the link is disabled and PLL
values are reset to previous values after upfront link tarining so
that subsequent modeset is not aware of these changes.

This patch is based on prior work done by
R,Durgadoss 

Changes since v16:
* Use HAS_DDI macro for enabling this feature (Rodrigo Vivi)
* Fix some unnecessary removals/changes due to rebase (Rodrigo Vivi)

Changes since v15:
* Split this patch into two patches - one with functional
changes to enable upfront and other with moving the existing
functions around so that they can be used for upfront (Jani Nikula)
* Cleaned up the commit message

Signed-off-by: Durgadoss R 
Signed-off-by: Jim Bride 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  21 ++-
 drivers/gpu/drm/i915/intel_dp.c   | 190 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |   1 -
 drivers/gpu/drm/i915/intel_drv.h  |  14 +-
 4 files changed, 218 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 826d9f7..3168bcf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1676,7 +1676,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
pll->config.crtc_mask = 0;
 
/* If Link Training fails, send a uevent to generate a hotplug */
-   if (!intel_ddi_link_train(intel_dp, link_rate, lane_count, link_mst))
+   if (!intel_ddi_link_train(intel_dp, link_rate, lane_count, link_mst,
+ false))
drm_kms_helper_hotplug_event(encoder->base.dev);
pll->config = tmp_pll_config;
 }
@@ -2464,7 +2465,7 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int 
clock)
 
 bool
 intel_ddi_link_train(struct intel_dp *intel_dp, int max_link_rate,
-uint8_t max_lane_count, bool link_mst)
+uint8_t max_lane_count, bool link_mst, bool is_upfront)
 {
struct intel_connector *connector = intel_dp->attached_connector;
struct intel_encoder *encoder = connector->encoder;
@@ -2512,6 +2513,7 @@ intel_ddi_link_train(struct intel_dp *intel_dp, int 
max_link_rate,
pll->funcs.disable(dev_priv, pll);
pll->config = tmp_pll_config;
}
+
if (ret) {
DRM_DEBUG_KMS("Link Training successful at link rate: 
%d lane: %d\n",
  link_rate, lane_count);
@@ -2520,6 +2522,21 @@ intel_ddi_link_train(struct intel_dp *intel_dp, int 
max_link_rate,
}
intel_dp_stop_link_train(intel_dp);
 
+   if (is_upfront) {
+   DRM_DEBUG_KMS("Upfront link train %s: link_clock:%d lanes:%d\n",
+ ret ? "Passed" : "Failed",
+ link_rate, lane_count);
+   /* Disable port followed by PLL for next retry/clean up */
+   intel_ddi_post_disable(encoder, NULL, NULL);
+   pll->funcs.disable(dev_priv, pll);
+   pll->config = tmp_pll_config;
+   if (ret) {
+   /* Save the upfront values */
+   intel_dp->max_lanes_upfront = lane_count;
+   intel_dp->max_link_rate_upfront = link_rate;
+   }
+   }
+
if (!lane_count)
DRM_ERROR("Link Training Failed\n");
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8061e32..30b41ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -153,12 +153,21 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
 static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
-   u8 source_max, sink_max;
+   u8 temp, source_max, sink_max;
 
source_max = intel_dig_port->max_lanes;
sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
 
-   return min(source_max, sink_max);
+   temp = min(source_max, sink_max);
+
+   /*
+* Limit max lanes w.r.t to the max value found
+* using Upfront link training also.
+*/
+   if (intel_dp->max_lanes_upfront)
+   return min(temp, intel_dp->max_lanes_upfront);
+   else
+   return temp;

[Intel-gfx] [PATCH v3 6/6] drm/i915/dp/mst: Add support for upfront link training for DP MST

2016-09-15 Thread Manasi Navare
From: Jim Bride 

Add upfront link training to intel_dp_mst_mode_valid() so that we know
topology constraints before we validate the legality of modes to be
checked. These upfront values get used in mst_compute_config instead
of using max link rate and lane count values.

Train the link during modeset using the function intel_ddi_link_train()
that starts training fast and wide and falls back to lower link rate/
lane count in each iteration until link training succeeds.

v3:
* Reset the upfront values but dont unset the EDID for MST. (Manasi)
v2:
* Rebased on new revision of link training patch. (Manasi)

Signed-off-by: Manasi Navare 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c | 15 
 drivers/gpu/drm/i915/intel_dp_mst.c | 72 ++---
 drivers/gpu/drm/i915/intel_drv.h|  3 ++
 3 files changed, 62 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 30b41ad..d1b247e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct drm_device 
*dev,
  enum pipe pipe);
 static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 
-static int
+int
 intel_dp_max_link_bw(struct intel_dp  *intel_dp)
 {
int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
@@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
return max_link_bw;
 }
 
-static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
+u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
u8 temp, source_max, sink_max;
@@ -319,8 +319,7 @@ static int intersect_rates(const int *source_rates, int 
source_len,
return k;
 }
 
-static int intel_dp_common_rates(struct intel_dp *intel_dp,
-int *common_rates)
+int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
 {
const int *source_rates, *sink_rates;
int source_len, sink_len;
@@ -344,7 +343,7 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
-static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
+bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = _dig_port->base;
@@ -4624,12 +4623,12 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
}
 
 out:
-   if ((status != connector_status_connected) &&
-   (intel_dp->is_mst == false)) {
-   intel_dp_unset_edid(intel_dp);
+   if (status != connector_status_connected) {
intel_dp->upfront_done = false;
intel_dp->max_lanes_upfront = 0;
intel_dp->max_link_rate_upfront = 0;
+   if (intel_dp->is_mst == false)
+   intel_dp_unset_edid(intel_dp);
}
 
intel_display_power_put(to_i915(dev), power_domain);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 54a9d76..f57c672 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
int bpp;
int lane_count, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
-   int mst_pbn;
+   int mst_pbn, common_len;
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
 
pipe_config->dp_encoder_is_mst = true;
pipe_config->has_pch_encoder = false;
-   bpp = 24;
+
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* For MST we always configure for the maximum trainable link bw -
+* the spec doesn't seem to suggest we should do otherwise.  The
+* calls to intel_dp_max_lane_count() and intel_dp_common_rates()
+* both take successful upfront link training into account, and
+* return the DisplayPort max supported values in the event that
+* upfront link training was not done.
 */
-   lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+   lane_count = intel_dp_max_lane_count(intel_dp);
 
pipe_config->lane_count = lane_count;
 
-   pipe_config->pipe_bpp = 24;
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+   pipe_config->pipe_bpp = bpp = 24;
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   pipe_config->port_clock = common_rates[common_len - 1];
+
+   DRM_DEBUG_KMS("DP MST link configured for %d lanes @ %d.\n",
+ 

[Intel-gfx] [PATCH 4/6] drm/i915: Code cleanup to use dev_priv and INTEL_GEN

2016-09-15 Thread Manasi Navare
Replace dev with dev_priv and INTEL_INFO with INTEL_GEN

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 61d71fa..8061e32 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -230,13 +230,13 @@ static int
 intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
int size;
 
-   if (IS_BROXTON(dev)) {
+   if (IS_BROXTON(dev_priv)) {
*source_rates = bxt_rates;
size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
+   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
*source_rates = skl_rates;
size = ARRAY_SIZE(skl_rates);
} else {
@@ -1359,14 +1359,14 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
 
/* WaDisableHBR2:skl */
-   if (IS_SKL_REVID(dev, 0, SKL_REVID_B0))
+   if (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0))
return false;
 
-   if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)->gen >= 9))
+   if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
+   IS_BROADWELL(dev_priv) || (INTEL_GEN(dev_priv) >= 9))
return true;
else
return false;
-- 
1.9.1

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


[Intel-gfx] [PATCH 0/6] Remaining patches for upfront link training on DDI platforms

2016-09-15 Thread Manasi Navare
This patch series includes some of the remaining patches to enable
upfront link training on DDI platforms for DP SST and MST.
They are based on some of the patches submitted earlier by
Ander and Durgadoss.

The upfront link training had to be factored out of long pulse
hanlder because of deadlock issues seen on DP MST cases.
Now the upfront link training takes place in intel_dp_mode_valid()
to find the maximum lane count and link rate at which the DP link
can be successfully trained. These values are used to prune the
invalid modes before modeset. Modeset makes use the upfront lane
count and link train values.

These patches have been validated for DP SST and DP MST on DDI
platforms.

The existing implementation of link training does not implement fallback
for link rate/lane count as per the DP spec.
This patch series implements fallback loop to lower link rate
and lane count on CR and/or Channel EQ failures during link training.

Jim Bride (1):
  drm/i915/dp/mst: Add support for upfront link training for DP MST

Manasi Navare (5):
  drm/i915: Fallback to lower link rate and lane count during link
training
  drm/i915: Remove the link rate and lane count loop in compute config
  drm/i915: Change the placement of some static functions in intel_dp.c
  drm/i915: Code cleanup to use dev_priv and INTEL_GEN
  drm/i915/dp: Enable Upfront link training on DDI platforms

 drivers/gpu/drm/i915/intel_ddi.c  | 128 -
 drivers/gpu/drm/i915/intel_dp.c   | 388 +++---
 drivers/gpu/drm/i915/intel_dp_link_training.c |  13 +-
 drivers/gpu/drm/i915/intel_dp_mst.c   |  72 +++--
 drivers/gpu/drm/i915/intel_drv.h  |  21 +-
 5 files changed, 488 insertions(+), 134 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v6 1/6] drm/i915: Fallback to lower link rate and lane count during link training

2016-09-15 Thread Manasi Navare
According to the DisplayPort Spec, in case of Clock Recovery failure
the link training sequence should fall back to the lower link rate
followed by lower lane count until CR succeeds.
On CR success, the sequence proceeds with Channel EQ.
In case of Channel EQ failures, it should fallback to
lower link rate and lane count and start the CR phase again.

v6:
* Do not split quoted string across line (Mika Kahola)
v5:
* Reset the link rate index to the max link rate index
before lowering the lane count (Jani Nikula)
* Use the paradigm for loop in intel_dp_link_rate_index
v4:
* Fixed the link rate fallback loop (Manasi Navare)
v3:
* Fixed some rebase issues (Mika Kahola)
v2:
* Add a helper function to return index of requested link rate
into common_rates array
* Changed the link rate fallback loop to make use
of common_rates array (Mika Kahola)
* Changed INTEL_INFO to INTEL_GEN (David Weinehall)

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 111 +++---
 drivers/gpu/drm/i915/intel_dp.c   |  15 
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 4 files changed, 130 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8065a5f..826d9f7 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1637,19 +1637,18 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
}
 }
 
-static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
+static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
int link_rate, uint32_t lane_count,
-   struct intel_shared_dpll *pll,
-   bool link_mst)
+   struct intel_shared_dpll *pll)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
 
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
-link_mst);
-   if (encoder->type == INTEL_OUTPUT_EDP)
-   intel_edp_panel_on(intel_dp);
+false);
+
+   intel_edp_panel_on(intel_dp);
 
intel_ddi_clk_select(encoder, pll);
intel_prepare_dp_ddi_buffers(encoder);
@@ -1660,6 +1659,28 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_dp_stop_link_train(intel_dp);
 }
 
+static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
+   int link_rate, uint32_t lane_count,
+   struct intel_shared_dpll *pll,
+   bool link_mst)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_shared_dpll_config tmp_pll_config;
+
+   /* Disable the PLL and obtain the PLL for Link Training
+* that starts with highest link rate and lane count.
+*/
+   tmp_pll_config = pll->config;
+   pll->funcs.disable(dev_priv, pll);
+   pll->config.crtc_mask = 0;
+
+   /* If Link Training fails, send a uevent to generate a hotplug */
+   if (!intel_ddi_link_train(intel_dp, link_rate, lane_count, link_mst))
+   drm_kms_helper_hotplug_event(encoder->base.dev);
+   pll->config = tmp_pll_config;
+}
+
 static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
  bool has_hdmi_sink,
  struct drm_display_mode *adjusted_mode,
@@ -1693,20 +1714,26 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder,
struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
int type = intel_encoder->type;
 
-   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
+   if (type == INTEL_OUTPUT_EDP)
+   intel_ddi_pre_enable_edp(intel_encoder,
+   crtc->config->port_clock,
+   crtc->config->lane_count,
+   crtc->config->shared_dpll);
+
+   if (type == INTEL_OUTPUT_DP)
intel_ddi_pre_enable_dp(intel_encoder,
crtc->config->port_clock,
crtc->config->lane_count,
crtc->config->shared_dpll,
intel_crtc_has_type(crtc->config,

INTEL_OUTPUT_DP_MST));
-   }
-   if (type == INTEL_OUTPUT_HDMI) {
+
+   if (type == INTEL_OUTPUT_HDMI)

[Intel-gfx] [PATCH v3 3/6] drm/i915: Change the placement of some static functions in intel_dp.c

2016-09-15 Thread Manasi Navare
These static helper functions are required to be used within upfront
link training related functions so they need to be placed at the top
of the file. It also changes macro dev to dev_priv.

v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 150 
 1 file changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 65b4559..61d71fa 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -213,6 +213,81 @@ intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
return max_dotclk;
 }
 
+static int
+intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
+{
+   if (intel_dp->num_sink_rates) {
+   *sink_rates = intel_dp->sink_rates;
+   return intel_dp->num_sink_rates;
+   }
+
+   *sink_rates = default_rates;
+
+   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
+}
+
+static int
+intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   int size;
+
+   if (IS_BROXTON(dev)) {
+   *source_rates = bxt_rates;
+   size = ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
+   *source_rates = skl_rates;
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
+   }
+
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (!intel_dp_source_supports_hbr2(intel_dp))
+   size--;
+
+   return size;
+}
+
+static int intersect_rates(const int *source_rates, int source_len,
+  const int *sink_rates, int sink_len,
+  int *common_rates)
+{
+   int i = 0, j = 0, k = 0;
+
+   while (i < source_len && j < sink_len) {
+   if (source_rates[i] == sink_rates[j]) {
+   if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
+   return k;
+   common_rates[k] = source_rates[i];
+   ++k;
+   ++i;
+   ++j;
+   } else if (source_rates[i] < sink_rates[j]) {
+   ++i;
+   } else {
+   ++j;
+   }
+   }
+   return k;
+}
+
+static int intel_dp_common_rates(struct intel_dp *intel_dp,
+int *common_rates)
+{
+   const int *source_rates, *sink_rates;
+   int source_len, sink_len;
+
+   sink_len = intel_dp_sink_rates(intel_dp, _rates);
+   source_len = intel_dp_source_rates(intel_dp, _rates);
+
+   return intersect_rates(source_rates, source_len,
+  sink_rates, sink_len,
+  common_rates);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1281,19 +1356,6 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
intel_dp->aux.transfer = intel_dp_aux_transfer;
 }
 
-static int
-intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
-{
-   if (intel_dp->num_sink_rates) {
-   *sink_rates = intel_dp->sink_rates;
-   return intel_dp->num_sink_rates;
-   }
-
-   *sink_rates = default_rates;
-
-   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
-}
-
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -1310,31 +1372,6 @@ bool intel_dp_source_supports_hbr2(struct intel_dp 
*intel_dp)
return false;
 }
 
-static int
-intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
-{
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_device *dev = dig_port->base.base.dev;
-   int size;
-
-   if (IS_BROXTON(dev)) {
-   *source_rates = bxt_rates;
-   size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
-   *source_rates = skl_rates;
-   size = ARRAY_SIZE(skl_rates);
-   } else {
-   *source_rates = default_rates;
-   size = ARRAY_SIZE(default_rates);
-   }
-
-   /* This depends on the fact that 5.4 is last value in the array */
-   if (!intel_dp_source_supports_hbr2(intel_dp))
-   size--;
-
-   return size;
-}
-
 static void
 intel_dp_set_clock(struct intel_encoder *encoder,
   struct intel_crtc_state 

Re: [Intel-gfx] [PATCH i-g-t v5 06/13] tests/sw_sync: Add subtest test_sync_wait

2016-09-15 Thread Robert Foss



On 2016-09-15 04:32 PM, Chris Wilson wrote:

On Thu, Sep 15, 2016 at 02:40:11PM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

This subtest verifies that waiting on fences works properly.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index fcb2f57..3061279 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
 }

+static void test_sync_wait(void)


These are not testing waits but busy queries.


test_sync_wait refers to sw_sync_wait, which may or may not be 
meaningful to refer to.

Do you still prefer test_sync_busy?



static void test_sync_busy(void)

+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 5);
+
+   /* Wait on fence until timeout */


Misleading comment


Agreed.




+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");


igt_assert_f(ret == 0, "Fence created in an unexpectedly signaled state\n");


Agreed.




+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+
+   /* Wait on fence until timeout */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");


igt_assert_f(ret == 0, "Fence signaled earlier (timeline value 1, fence seqno 
5)\n");


Agreed.




+
+   /* Signal the fence */


/* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/


Agreed.


+   sw_sync_timeline_inc(timeline, 4);



+
+   /* Wait successfully */


Usless comment


Agreed.




+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting on fence\n");


igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence seqno 
5)\n");

If we have a timeline info, we could use %d to say the current value.

Another test would be to then

seqno = 0;
for (i = 0; i < n_primes; i++) {
seqno += primes[i];
sw_sync_timeline_inc(timeline, primes[i]);
igt_assert_eq(sw_sync_timeline_get_seqno(timeline), seqno);
}



This looks like a good addition, but primes has not previously been 
defined. Do you have preference for primes or would any increment, like 
random be ok?



+
+   /* Go even further, and confirm wait still succeeds */
+   sw_sync_timeline_inc(timeline, 10);
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting ahead\n");


igt_assert_f(ret == 0, "Fence now not signaled! (timeline value 10, fence seqno 
5)\n");


Agreed.
Thanks for the thorough review!


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


Re: [Intel-gfx] [PATCH i-g-t v5 02/13] tests/sw_sync: Add sw_sync test

2016-09-15 Thread Robert Foss



On 2016-09-15 04:22 PM, Chris Wilson wrote:

On Thu, Sep 15, 2016 at 02:40:07PM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

Add initial tests for sw_sync.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
---
 tests/Makefile.sources |  1 +
 tests/sw_sync.c| 52 ++
 2 files changed, 53 insertions(+)
 create mode 100644 tests/sw_sync.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 72a58ad..0ba769f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -125,6 +125,7 @@ TESTS_progs_M = \
prime_mmap_kms \
prime_self_import \
prime_vgem \
+   sw_sync \
template \
vgem_basic \
vgem_slow \
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
new file mode 100644
index 000..47e2dfa
--- /dev/null
+++ b/tests/sw_sync.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "igt.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+
+static void test_alloc_timeline(void)
+{
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   close(timeline);
+}
+
+igt_main
+{


If I were to run this on a kernel without sw_sync support, it would
fail. We want it to skip instead!

in lib/sw_sync.c:

static bool kernel_has_sw_sync(void)
{
bool err;

igt_ignore_warn(system("/sbin/modprobe -s r sw_sync"));

err = false;
if (access("/dev/sw_sync", R_OK | W_OK) < 0) {
char buf[128];

snprintf(buf, sizeof(buf), "%s/sw_sync", igt_debugfs_mount());
err = access("/sys/kernel//sw_sync", R_OK | W_OK) < 0;
}

return !err;
}

void igt_require_sw_sync(void)
{
igt_require(kernel_has_sw_sync());

}

then here:

igt_main
{

igt_fixture {
igt_require_sw_sync();
}


+   igt_subtest("alloc_timeline")
+   test_alloc_timeline();
+}


}



This is a solid improvement, igt_debugfs_mount() does not however seem 
to be available on upstream/master.
I've found your patch that includes it amongst other things, would you 
like me to extract it and include it into this series?


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


Re: [Intel-gfx] [PATCH i-g-t v5 06/13] tests/sw_sync: Add subtest test_sync_wait

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 02:40:11PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> This subtest verifies that waiting on fences works properly.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/sw_sync.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index fcb2f57..3061279 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
>   close(timeline[1]);
>  }
>  
> +static void test_sync_wait(void)
> +{

Ah, you don't have a real test_sync_wait()

Nor do you check that fences are inherited across fork() or can be sent
over unix sockets.

For test_sync_wait(), some along the lines of create timeline in parent,
fork + create fence in child (wakeup parent) wait(fence), .timeout =
10s), in parent sleep another 1s, increment timeline. Usual assertions.

If the fence was created in the parent and forked to the child, the
parent can assert the fence was signaled to ensure that we expect the
wait to succeed.
-Chris

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


Re: [Intel-gfx] [PATCH i-g-t v5 07/13] tests/sw_sync: Add subtest test_sync_merge

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 02:40:12PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Add subtest test_sync_merge that tests merging fences and the validity of the
> resulting merged fence.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/sw_sync.c | 67 
> +
>  1 file changed, 67 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 3061279..26226bd 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -116,6 +116,70 @@ static void test_sync_wait(void)
>   close(timeline);
>  }
>  
> +static void test_sync_merge(void)
> +{
> + int in_fence[3];
> + int fence_merge;
> + int timeline;
> + int active, signaled;
> +
> + timeline = sw_sync_timeline_create();
> + in_fence[0] = sw_sync_fence_create(timeline, 1);
> + in_fence[1] = sw_sync_fence_create(timeline, 2);
> + in_fence[2] = sw_sync_fence_create(timeline, 3);
> +
> + fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
> + fence_merge = sw_sync_merge(in_fence[2], fence_merge);

sw_sync_merge() really does need the negative tests:

invalid fd (-1),
device fd (/dev/dri/card0),
file fd.

should cover the most common errors (fuzz testing will hit the rest!)

> +
> + /* confirm all fences have one active point (even d) */
> + active = sw_sync_fence_count_status(in_fence[0],
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
> + active = sw_sync_fence_count_status(in_fence[1],
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
> + active = sw_sync_fence_count_status(in_fence[2],
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
> + active = sw_sync_fence_count_status(fence_merge,
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(active == 1, "fence_merge has too many active fences\n");
> +
> + /* confirm that fence_merge is not signaled until the max of fence 
> 0,1,2 */
> + sw_sync_timeline_inc(timeline, 1);

> + signaled = sw_sync_fence_count_status(in_fence[0],
> +   SW_SYNC_FENCE_STATUS_SIGNALED);

This is missing from the earlier test_sync_busy().

> + active = sw_sync_fence_count_status(fence_merge,
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
> + igt_assert_f(active == 1, "fence_merge signaled too early\n");
> +
> + sw_sync_timeline_inc(timeline, 1);
> + signaled = sw_sync_fence_count_status(in_fence[1],
> +   SW_SYNC_FENCE_STATUS_SIGNALED);
> + active = sw_sync_fence_count_status(fence_merge,
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
> + igt_assert_f(active == 1, "fence_merge signaled too early\n");
> +
> + sw_sync_timeline_inc(timeline, 1);
> + signaled = sw_sync_fence_count_status(in_fence[2],
> +   SW_SYNC_FENCE_STATUS_SIGNALED);
> + igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
> + signaled = sw_sync_fence_count_status(fence_merge,
> +SW_SYNC_FENCE_STATUS_SIGNALED);
> + active = sw_sync_fence_count_status(fence_merge,
> + SW_SYNC_FENCE_STATUS_ACTIVE);
> + igt_assert_f(active == 0 && signaled == 1,
> +  "fence_merge did not signal\n");

Hmm, counting STATUS_SIGNALED / STATUS_ACTIVE is not behaving how I
would intuitively expect.

At this point, timeline.seqno = 3, I would expect count_signaled(merge)
== 3 (and count_fences(merge) == 3 => merge is now signaled).
But that's just my expectations
-Chris

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


Re: [Intel-gfx] [PATCH i-g-t v5 06/13] tests/sw_sync: Add subtest test_sync_wait

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 02:40:11PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> This subtest verifies that waiting on fences works properly.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/sw_sync.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index fcb2f57..3061279 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
>   close(timeline[1]);
>  }
>  
> +static void test_sync_wait(void)

These are not testing waits but busy queries.

static void test_sync_busy(void)
> +{
> + int fence, ret;
> + int timeline;
> +
> + timeline = sw_sync_timeline_create();
> + fence = sw_sync_fence_create(timeline, 5);
> +
> + /* Wait on fence until timeout */

Misleading comment

> + ret = sw_sync_wait(fence, 0);
> + igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");

igt_assert_f(ret == 0, "Fence created in an unexpectedly signaled state\n");

> +
> + /* Advance timeline from 0 -> 1 */
> + sw_sync_timeline_inc(timeline, 1);
> +
> + /* Wait on fence until timeout */
> + ret = sw_sync_wait(fence, 0);
> + igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");

igt_assert_f(ret == 0, "Fence signaled earlier (timeline value 1, fence seqno 
5)\n");

> +
> + /* Signal the fence */

/* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/
> + sw_sync_timeline_inc(timeline, 4);

> +
> + /* Wait successfully */

Usless comment

> + ret = sw_sync_wait(fence, 0);
> + igt_assert_f(ret > 0, "Failure waiting on fence\n");

igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence seqno 
5)\n");

If we have a timeline info, we could use %d to say the current value.

Another test would be to then

seqno = 0;
for (i = 0; i < n_primes; i++) {
seqno += primes[i];
sw_sync_timeline_inc(timeline, primes[i]);
igt_assert_eq(sw_sync_timeline_get_seqno(timeline), seqno);
}

> +
> + /* Go even further, and confirm wait still succeeds */
> + sw_sync_timeline_inc(timeline, 10);
> + ret = sw_sync_wait(fence, 0);
> + igt_assert_f(ret > 0, "Failure waiting ahead\n");

igt_assert_f(ret == 0, "Fence now not signaled! (timeline value 10, fence seqno 
5)\n");

> +
> + close(fence);
> + close(timeline);
> +}

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


Re: [Intel-gfx] [PATCH i-g-t v5 02/13] tests/sw_sync: Add sw_sync test

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 02:40:07PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Add initial tests for sw_sync.
> 
> Signed-off-by: Robert Foss 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/Makefile.sources |  1 +
>  tests/sw_sync.c| 52 
> ++
>  2 files changed, 53 insertions(+)
>  create mode 100644 tests/sw_sync.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 72a58ad..0ba769f 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -125,6 +125,7 @@ TESTS_progs_M = \
>   prime_mmap_kms \
>   prime_self_import \
>   prime_vgem \
> + sw_sync \
>   template \
>   vgem_basic \
>   vgem_slow \
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> new file mode 100644
> index 000..47e2dfa
> --- /dev/null
> +++ b/tests/sw_sync.c
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright 2012 Google, Inc
> + * Copyright © 2016 Collabora, Ltd.
> + *
> + * Based on the implementation from the Android Open Source Project
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Robert Foss 
> + */
> +
> +#include 
> +#include 
> +
> +#include "sw_sync.h"
> +#include "igt.h"
> +#include "igt_aux.h"
> +
> +IGT_TEST_DESCRIPTION("Test SW Sync Framework");
> +
> +static void test_alloc_timeline(void)
> +{
> + int timeline;
> +
> + timeline = sw_sync_timeline_create();
> + close(timeline);
> +}
> +
> +igt_main
> +{

If I were to run this on a kernel without sw_sync support, it would
fail. We want it to skip instead!

in lib/sw_sync.c:

static bool kernel_has_sw_sync(void)
{
bool err;

igt_ignore_warn(system("/sbin/modprobe -s r sw_sync"));

err = false;
if (access("/dev/sw_sync", R_OK | W_OK) < 0) {
char buf[128];

snprintf(buf, sizeof(buf), "%s/sw_sync", igt_debugfs_mount());
err = access("/sys/kernel//sw_sync", R_OK | W_OK) < 0;
}

return !err;
}

void igt_require_sw_sync(void)
{
igt_require(kernel_has_sw_sync());

}

then here:

igt_main
{

igt_fixture {
igt_require_sw_sync();
}

> + igt_subtest("alloc_timeline")
> + test_alloc_timeline();
> +}

}

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


Re: [Intel-gfx] [PATCH i-g-t v5 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 02:40:06PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Base functions to help testing the Sync File Framework (explicit fencing
> mechanism ported from Android).
> These functions allow you to create, use and destroy timelines and fences.
> 
> Signed-off-by: Robert Foss 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Eric Engestrom 

Some minor cosmetics remain but well below the level of caring,
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Fallback to lower link rate and lane count during link training

2016-09-15 Thread Manasi Navare
On Wed, Sep 14, 2016 at 11:15:13AM +0300, Mika Kahola wrote:
> On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > According to the DisplayPort Spec, in case of Clock Recovery failure
> > the link training sequence should fall back to the lower link rate
> > followed by lower lane count until CR succeeds.
> > On CR success, the sequence proceeds with Channel EQ.
> > In case of Channel EQ failures, it should fallback to
> > lower link rate and lane count and start the CR phase again.
> > 
> > v5:
> > * Reset the link rate index to the max link rate index
> > before lowering the lane count (Jani Nikula)
> > * Use the paradigm for loop in intel_dp_link_rate_index
> > v4:
> > * Fixed the link rate fallback loop (Manasi Navare)
> > v3:
> > * Fixed some rebase issues (Mika Kahola)
> > v2:
> > * Add a helper function to return index of requested link rate
> > into common_rates array
> > * Changed the link rate fallback loop to make use
> > of common_rates array (Mika Kahola)
> > * Changed INTEL_INFO to INTEL_GEN (David Weinehall)
> > 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 112
> > +++---
> >  drivers/gpu/drm/i915/intel_dp.c   |  15 
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
> >  4 files changed, 131 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 8065a5f..4d3a931 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1637,19 +1637,18 @@ void intel_ddi_clk_select(struct
> > intel_encoder *encoder,
> >     }
> >  }
> >  
> > -static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> > +static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
> >     int link_rate, uint32_t
> > lane_count,
> > -   struct intel_shared_dpll *pll,
> > -   bool link_mst)
> > +   struct intel_shared_dpll *pll)
> >  {
> >     struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> >     struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> >     enum port port = intel_ddi_get_encoder_port(encoder);
> >  
> >     intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > -    link_mst);
> > -   if (encoder->type == INTEL_OUTPUT_EDP)
> > -   intel_edp_panel_on(intel_dp);
> > +    false);
> > +
> > +   intel_edp_panel_on(intel_dp);
> >  
> >     intel_ddi_clk_select(encoder, pll);
> >     intel_prepare_dp_ddi_buffers(encoder);
> > @@ -1660,6 +1659,28 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> >     intel_dp_stop_link_train(intel_dp);
> >  }
> >  
> > +static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> > +   int link_rate, uint32_t
> > lane_count,
> > +   struct intel_shared_dpll *pll,
> > +   bool link_mst)
> > +{
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> > +   struct intel_shared_dpll_config tmp_pll_config;
> > +
> > +   /* Disable the PLL and obtain the PLL for Link Training
> > +    * that starts with highest link rate and lane count.
> > +    */
> > +   tmp_pll_config = pll->config;
> > +   pll->funcs.disable(dev_priv, pll);
> > +   pll->config.crtc_mask = 0;
> > +
> > +   /* If Link Training fails, send a uevent to generate a
> > hotplug */
> > +   if (!intel_ddi_link_train(intel_dp, link_rate, lane_count,
> > link_mst))
> > +   drm_kms_helper_hotplug_event(encoder->base.dev);
> > +   pll->config = tmp_pll_config;
> > +}
> > +
> >  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> >       bool has_hdmi_sink,
> >       struct drm_display_mode
> > *adjusted_mode,
> > @@ -1693,20 +1714,26 @@ static void intel_ddi_pre_enable(struct
> > intel_encoder *intel_encoder,
> >     struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> >     int type = intel_encoder->type;
> >  
> > -   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > +   if (type == INTEL_OUTPUT_EDP)
> > +   intel_ddi_pre_enable_edp(intel_encoder,
> > +   crtc->config->port_clock,
> > +   crtc->config->lane_count,
> > +   crtc->config->shared_dpll);
> > +
> > +   if (type == INTEL_OUTPUT_DP)
> >     intel_ddi_pre_enable_dp(intel_encoder,
> >     crtc->config->port_clock,
> >     crtc->config->lane_count,
> >  

Re: [Intel-gfx] [PATCH i-g-t v4 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

2016-09-15 Thread Gustavo Padovan
2016-09-15 Robert Foss :

> 
> 
> On 2016-09-15 02:35 PM, Robert Foss wrote:
> > 
> > 
> > On 2016-09-15 02:46 AM, Chris Wilson wrote:
> > > On Wed, Sep 14, 2016 at 11:04:30AM -0400, robert.f...@collabora.com
> > > wrote:
> > > > +void sw_sync_timeline_inc(int fd, uint32_t count)
> > > > +{
> > > > +uint32_t arg = count;
> > > > +
> > > > +if (fd == 0)
> > > > +return;
> > > 
> > > But fd = 0 is a valid fd, and might be a timeline somewhere.
> > > 
> > > Did you mean count == 0 ?
> > > 
> > > And even then (unless it is defined as an error condition in the kernel
> > > ABI, and it should not be...) we should pass it through to the kernel.
> > 
> > You're right, I'll change it in v5.
> > 
> > > 
> > > > +do_ioctl(fd, SW_SYNC_IOC_INC, );
> > > > +}
> > > > +
> > > 
> > > > +int sw_sync_wait(int fence, int timeout)
> > > > +{
> > > > +struct pollfd fds;
> > > > +int ret;
> > > > +
> > > > +fds.fd = fence;
> > > > +fds.events = POLLIN | POLLERR;
> > > 
> > > POLLERR is always implied and doesn't need to be specified (it is
> > > meaningless in .events).
> > > 
> > > int sw_sync_wait(int fence, int timeout)
> > > {
> > > #if BEING_FANCY
> > > return poll(&(struct pollfd){fd, POLLIN}, 1, timeout);
> > > #else
> > > struct pollfd pfd = { fd, POLLIN };
> > > return poll(, 1, timeout);
> > > #endif
> > > }
> > > 
> > > Indentation has gone wrong, double check the whitespace.
> > 
> > That is definitely nicer looking. I'll drop it in for v5.
> > 
> > > 
> > > 
> > > How do fences operate after their timeline is closed? (Are they
> > > automatically signaled, or do they persist and are signaled normally?) Is
> > > there a test for using fences from a closed timeline (I was looking but
> > > didn't notice one).
> > 
> > I did some quick tests just to confirm, closing the timeline signals all
> > of its fences.
> 
> Actually, my quick test was wrong. A fence is _not_ signaled on when its
> timeline has been closed.
> 
> So you would like to see a test that confirms that a fence on closed
> timeline is not signaled?

Yes, please. Add this test and maybe another the signals the fence
before closing the timeline and the check if the fence is indeed
signaled.

Gustavo

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


Re: [Intel-gfx] [PATCH i-g-t v4 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

2016-09-15 Thread Robert Foss



On 2016-09-15 02:35 PM, Robert Foss wrote:



On 2016-09-15 02:46 AM, Chris Wilson wrote:

On Wed, Sep 14, 2016 at 11:04:30AM -0400, robert.f...@collabora.com
wrote:

+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+uint32_t arg = count;
+
+if (fd == 0)
+return;


But fd = 0 is a valid fd, and might be a timeline somewhere.

Did you mean count == 0 ?

And even then (unless it is defined as an error condition in the kernel
ABI, and it should not be...) we should pass it through to the kernel.


You're right, I'll change it in v5.




+do_ioctl(fd, SW_SYNC_IOC_INC, );
+}
+



+int sw_sync_wait(int fence, int timeout)
+{
+struct pollfd fds;
+int ret;
+
+fds.fd = fence;
+fds.events = POLLIN | POLLERR;


POLLERR is always implied and doesn't need to be specified (it is
meaningless in .events).

int sw_sync_wait(int fence, int timeout)
{
#if BEING_FANCY
return poll(&(struct pollfd){fd, POLLIN}, 1, timeout);
#else
struct pollfd pfd = { fd, POLLIN };
return poll(, 1, timeout);
#endif
}

Indentation has gone wrong, double check the whitespace.


That is definitely nicer looking. I'll drop it in for v5.




How do fences operate after their timeline is closed? (Are they
automatically signaled, or do they persist and are signaled normally?) Is
there a test for using fences from a closed timeline (I was looking but
didn't notice one).


I did some quick tests just to confirm, closing the timeline signals all
of its fences.


Actually, my quick test was wrong. A fence is _not_ signaled on when its 
timeline has been closed.


So you would like to see a test that confirms that a fence on closed 
timeline is not signaled?



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


Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

2016-09-15 Thread Manasi Navare
On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote:
> On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > From: Jim Bride 
> > 
> > Add upfront link training to intel_dp_mst_mode_valid() so that we know
> > topology constraints before we validate the legality of modes to be
> > checked.
> > 
> 
> The patch seems to do a lot more things than just what is described
> here. I guess, it would be better to split this into multiple patches or
> at least provide adequate description here.
> 

I think the only other thing its doing is making some functions
non static so they can be used for MST upfront enabling.
But I think that can be in the same patch since it is done in order
to enable upfront for MST.
Jim, any thoughts?


> > v3:
> > * Reset the upfront values but dont unset the EDID for MST. (Manasi)
> > v2:
> > * Rebased on new revision of link training patch. (Manasi)
> > 
> > Signed-off-by: Manasi Navare 
> > Signed-off-by: Jim Bride 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 15 
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 74 
> > +++--
> >  drivers/gpu/drm/i915/intel_drv.h|  3 ++
> >  3 files changed, 64 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 9042d28..635830e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct drm_device 
> > *dev,
> >   enum pipe pipe);
> >  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> >  
> > -static int
> > +int
> >  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> >  {
> > int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> > @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> > return max_link_bw;
> >  }
> >  
> > -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> >  {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > u8 temp, source_max, sink_max;
> > @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, int 
> > source_len,
> > return k;
> >  }
> >  
> > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > -int *common_rates)
> > +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
> >  {
> > const int *source_rates, *sink_rates;
> > int source_len, sink_len;
> > @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp 
> > *intel_dp,
> >common_rates);
> >  }
> >  
> > -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> > +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> >  {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > struct intel_encoder *intel_encoder = _dig_port->base;
> > @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> > }
> >  
> >  out:
> > -   if ((status != connector_status_connected) &&
> > -   (intel_dp->is_mst == false)) {
> > -   intel_dp_unset_edid(intel_dp);
> > +   if (status != connector_status_connected) {
> > intel_dp->upfront_done = false;
> > intel_dp->max_lanes_upfront = 0;
> > intel_dp->max_link_rate_upfront = 0;
> > +   if (intel_dp->is_mst == false)
> > +   intel_dp_unset_edid(intel_dp);
> > }
> >  
> > intel_display_power_put(to_i915(dev), power_domain);
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 54a9d76..98d45a4 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > int bpp;
> > int lane_count, slots;
> > const struct drm_display_mode *adjusted_mode = 
> > _config->base.adjusted_mode;
> > -   int mst_pbn;
> > +   int mst_pbn, common_len;
> > +   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> >  
> > pipe_config->dp_encoder_is_mst = true;
> > pipe_config->has_pch_encoder = false;
> > -   bpp = 24;
> > +
> > /*
> > -* for MST we always configure max link bw - the spec doesn't
> > -* seem to suggest we should do otherwise.
> > +* For MST we always configure for the maximum trainable link bw -
> > +* the spec doesn't seem to suggest we should do otherwise.  The
> > +* calls to intel_dp_max_lane_count() and intel_dp_common_rates()
> > +* both take successful upfront link training into account, and
> > +* return the DisplayPort max supported values in the event that
> > +* upfront link training was not done.
> >  */
> > -   

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Change the placement of some static functions in intel_dp.c

2016-09-15 Thread Manasi Navare
On Thu, Sep 15, 2016 at 10:41:23AM +0300, Mika Kahola wrote:
> On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > These static helper functions are required to be used within upfront
> > link training related functions so they need to be placed at the top
> > of the file. It also changes macro dev to dev_priv.
> > 
> We could split this patch into two parts. One being moving around the
> helper functions and the other one cleanup patch to change dev in favor
> of dev_priv.
>

It was just one place for changing dev to dev_priv. But sure I can
add a separate patch for that.

Manasi 
> > v2:
> > * Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
> > 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 158 
> > 
> >  1 file changed, 79 insertions(+), 79 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 07f9a49..a319102 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -190,6 +190,81 @@ intel_dp_max_data_rate(int max_link_clock, int
> > max_lanes)
> >     return (max_link_clock * max_lanes * 8) / 10;
> >  }
> >  
> > +static int
> > +intel_dp_sink_rates(struct intel_dp *intel_dp, const int
> > **sink_rates)
> > +{
> > +   if (intel_dp->num_sink_rates) {
> > +   *sink_rates = intel_dp->sink_rates;
> > +   return intel_dp->num_sink_rates;
> > +   }
> > +
> > +   *sink_rates = default_rates;
> > +
> > +   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> > +}
> > +
> > +static int
> > +intel_dp_source_rates(struct intel_dp *intel_dp, const int
> > **source_rates)
> > +{
> > +   struct intel_digital_port *dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv = to_i915(dig_port-
> > >base.base.dev);
> > +   int size;
> > +
> > +   if (IS_BROXTON(dev_priv)) {
> > +   *source_rates = bxt_rates;
> > +   size = ARRAY_SIZE(bxt_rates);
> > +   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> > +   *source_rates = skl_rates;
> > +   size = ARRAY_SIZE(skl_rates);
> > +   } else {
> > +   *source_rates = default_rates;
> > +   size = ARRAY_SIZE(default_rates);
> > +   }
> > +
> > +   /* This depends on the fact that 5.4 is last value in the
> > array */
> > +   if (!intel_dp_source_supports_hbr2(intel_dp))
> > +   size--;
> > +
> > +   return size;
> > +}
> > +
> > +static int intersect_rates(const int *source_rates, int source_len,
> > +      const int *sink_rates, int sink_len,
> > +      int *common_rates)
> > +{
> > +   int i = 0, j = 0, k = 0;
> > +
> > +   while (i < source_len && j < sink_len) {
> > +   if (source_rates[i] == sink_rates[j]) {
> > +   if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
> > +   return k;
> > +   common_rates[k] = source_rates[i];
> > +   ++k;
> > +   ++i;
> > +   ++j;
> > +   } else if (source_rates[i] < sink_rates[j]) {
> > +   ++i;
> > +   } else {
> > +   ++j;
> > +   }
> > +   }
> > +   return k;
> > +}
> > +
> > +static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > +    int *common_rates)
> > +{
> > +   const int *source_rates, *sink_rates;
> > +   int source_len, sink_len;
> > +
> > +   sink_len = intel_dp_sink_rates(intel_dp, _rates);
> > +   source_len = intel_dp_source_rates(intel_dp, _rates);
> > +
> > +   return intersect_rates(source_rates, source_len,
> > +      sink_rates, sink_len,
> > +      common_rates);
> > +}
> > +
> >  static enum drm_mode_status
> >  intel_dp_mode_valid(struct drm_connector *connector,
> >     struct drm_display_mode *mode)
> > @@ -1256,60 +1331,22 @@ intel_dp_aux_init(struct intel_dp *intel_dp,
> > struct intel_connector *connector)
> >     intel_dp->aux.transfer = intel_dp_aux_transfer;
> >  }
> >  
> > -static int
> > -intel_dp_sink_rates(struct intel_dp *intel_dp, const int
> > **sink_rates)
> > -{
> > -   if (intel_dp->num_sink_rates) {
> > -   *sink_rates = intel_dp->sink_rates;
> > -   return intel_dp->num_sink_rates;
> > -   }
> > -
> > -   *sink_rates = default_rates;
> > -
> > -   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> > -}
> > -
> >  bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
> >  {
> >     struct intel_digital_port *dig_port =
> > dp_to_dig_port(intel_dp);
> > -   struct drm_device *dev = dig_port->base.base.dev;
> > +   struct drm_i915_private *dev_priv = to_i915(dig_port-
> > >base.base.dev);
> >  
> >     /* WaDisableHBR2:skl */
> > -   if (IS_SKL_REVID(dev, 0, SKL_REVID_B0))
> > +   if (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0))
> >     return false;
> >  
> > -  

[Intel-gfx] [PATCH i-g-t v5 09/13] tests/sw_sync: Add subtest test_sync_multi_consumer

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies the access ordering of multiple consumer threads.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ff87cfe..e607b75 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
  *Robert Foss 
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -36,6 +38,15 @@
 
 IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 
+typedef struct {
+   int timeline;
+   uint32_t thread_id;
+   uint32_t nbr_threads;
+   uint32_t nbr_iterations;
+   volatile uint32_t * volatile counter;
+   sem_t *sem;
+} data_t;
+
 static void test_alloc_timeline(void)
 {
int timeline;
@@ -204,6 +215,95 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int nbr_threads = data->nbr_threads;
+   int timeline = data->timeline;
+   int iterations = data->nbr_iterations;
+   int ret, i;
+
+   for (i = 0; i < iterations; i++) {
+   int next_point = i * nbr_threads + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sw_sync_wait(fence, 1000);
+   if (ret <= 0)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   sem_post(data->sem);
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+   const uint32_t nbr_threads = 8;
+   const uint32_t nbr_iterations = 1 << 14;
+   data_t data_arr[nbr_threads];
+   pthread_t thread_arr[nbr_threads];
+   sem_t sem;
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   sem_init(, 0, 0);
+   timeline = sw_sync_timeline_create();
+
+   data.nbr_iterations = nbr_iterations;
+   data.nbr_threads = nbr_threads;
+   data.counter = 
+   data.timeline = timeline;
+   data.sem = 
+
+   /* Start sync threads. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Produce 'content'. */
+   for (i = 0; i < nbr_threads * nbr_iterations; i++)
+   {
+   sem_wait();
+
+   counter++;
+   sw_sync_timeline_inc(timeline, 1);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+   sem_destroy();
+
+   igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -226,5 +326,8 @@ igt_main
 
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+   igt_subtest("sync_multi_consumer")
+   test_sync_multi_consumer();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 08/13] tests/sw_sync: Add subtest test_sync_merge_same

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies merging a fence with itself does not fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 26226bd..ff87cfe 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -173,11 +173,35 @@ static void test_sync_merge(void)
igt_assert_f(active == 0 && signaled == 1,
 "fence_merge did not signal\n");
 
-   sw_sync_fence_destroy(in_fence[0]);
-   sw_sync_fence_destroy(in_fence[1]);
-   sw_sync_fence_destroy(in_fence[2]);
-   sw_sync_fence_destroy(fence_merge);
-   sw_sync_timeline_destroy(timeline);
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline);
+}
+
+static void test_sync_merge_same(void)
+{
+   int in_fence[2];
+   int timeline;
+   int signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_merge(in_fence[0], in_fence[0]);
+
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 0, "fence signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "fence did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(timeline);
 }
 
 igt_main
@@ -199,5 +223,8 @@ igt_main
 
igt_subtest("sync_merge")
test_sync_merge();
+
+   igt_subtest("sync_merge_same")
+   test_sync_merge_same();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 12/13] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index bd86111..9ec2dc2 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -215,6 +215,69 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void test_sync_multi_timeline_wait(void)
+{
+   int timeline[3];
+   int in_fence[3];
+   int fence_merge;
+   int active, signaled, ret;
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+   timeline[2] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+   in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+   fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+   /* Confirm fence isn't signaled */
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 3, "Fence signaled too early\n");
+
+   ret = sw_sync_wait(fence_merge, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   sw_sync_timeline_inc(timeline[0], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 2 && signaled == 1,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[1], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 1 && signaled == 2,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[2], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+   /* confirm you can successfully wait */
+   ret = sw_sync_wait(fence_merge, 100);
+   igt_assert_f(ret > 0, "Failure waiting on signaled fence\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+   close(timeline[2]);
+}
+
 static void * test_sync_multi_consumer_thread(void *arg)
 {
data_t *data = arg;
@@ -477,6 +540,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
 
+   igt_subtest("sync_multi_timeline_wait")
+   test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 07/13] tests/sw_sync: Add subtest test_sync_merge

2016-09-15 Thread robert . foss
From: Robert Foss 

Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3061279..26226bd 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -116,6 +116,70 @@ static void test_sync_wait(void)
close(timeline);
 }
 
+static void test_sync_merge(void)
+{
+   int in_fence[3];
+   int fence_merge;
+   int timeline;
+   int active, signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_fence_create(timeline, 2);
+   in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+   fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+   /* confirm all fences have one active point (even d) */
+   active = sw_sync_fence_count_status(in_fence[0],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[1],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[2],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+   /* confirm that fence_merge is not signaled until the max of fence 
0,1,2 */
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+   signaled = sw_sync_fence_count_status(fence_merge,
+  SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+   sw_sync_fence_destroy(in_fence[0]);
+   sw_sync_fence_destroy(in_fence[1]);
+   sw_sync_fence_destroy(in_fence[2]);
+   sw_sync_fence_destroy(fence_merge);
+   sw_sync_timeline_destroy(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -132,5 +196,8 @@ igt_main
 
igt_subtest("sync_wait")
test_sync_wait();
+
+   igt_subtest("sync_merge")
+   test_sync_merge();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 13/13] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 139 
 1 file changed, 139 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 9ec2dc2..1af9a6b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -447,6 +447,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static int test_mspc_wait_on_fence(int fence)
+{
+   int error, active;
+
+   do {
+   error = sw_sync_fence_count_status(fence,
+  SW_SYNC_FENCE_STATUS_ERROR);
+   igt_assert_f(error == 0, "Error occurred on fence\n");
+   active = sw_sync_fence_count_status(fence,
+   
SW_SYNC_FENCE_STATUS_ACTIVE);
+   } while (active);
+
+   return 0;
+}
+
+static struct {
+   int iterations;
+   int threads;
+   int counter;
+   int cons_timeline;
+   int *prod_timeline;
+   pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+   int id = (long)d;
+   int fence, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+
+   for (i = 0; i < iterations; i++) {
+   fence = sw_sync_fence_create(cons_timeline, i);
+
+   /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+   if ((iterations + id) % 8 != 0) {
+   igt_assert_f(sw_sync_wait(fence, -1) > 0,
+"Failure waiting on fence\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+   pthread_mutex_lock(_mpsc_data.lock);
+   test_mpsc_data.counter++;
+   pthread_mutex_unlock(_mpsc_data.lock);
+
+   sw_sync_timeline_inc(prod_timeline[id], 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+   int fence, merged, tmp, it, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+   int n = test_mpsc_data.threads;
+
+   for (it = 1; it <= iterations; it++) {
+   fence = sw_sync_fence_create(prod_timeline[0], it);
+   for (i = 1; i < n; i++) {
+   tmp = sw_sync_fence_create(prod_timeline[i], it);
+   merged = sw_sync_merge(tmp, fence);
+   close(tmp);
+   close(fence);
+   fence = merged;
+   }
+
+   /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+   if (iterations % 8 != 0) {
+   igt_assert_f(sw_sync_wait(fence, -1) == 0,
+   "Producers did not increment as 
expected\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+   /* Release the producer threads */
+   sw_sync_timeline_inc(cons_timeline, 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+   int iterations = 1 << 12;
+   int n = 5;
+   int prod_timeline[n];
+   int cons_timeline;
+   pthread_t threads[n];
+   long i;
+
+   cons_timeline = sw_sync_timeline_create();
+   for (i = 0; i < n; i++)
+   prod_timeline[i] = sw_sync_timeline_create();
+
+   test_mpsc_data.prod_timeline = prod_timeline;
+   test_mpsc_data.cons_timeline = cons_timeline;
+   test_mpsc_data.iterations = iterations;
+   test_mpsc_data.threads = n;
+   test_mpsc_data.counter = 0;
+   

[Intel-gfx] [PATCH i-g-t v5 11/13] tests/sw_sync: Add subtest test_sync_random_merge

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 73 +
 1 file changed, 73 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 13a5643..bd86111 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -384,6 +384,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void test_sync_random_merge(void)
+{
+   int i, size, ret;
+   const int nbr_timeline = 32;
+   const int nbr_merge = 1024;
+   int fence_map[nbr_timeline];
+   int timeline_arr[nbr_timeline];
+   int fence, tmpfence, merged;
+   int timeline, timeline_offset, sync_pt;
+
+   srand(time(NULL));
+
+   for (i = 0; i < nbr_timeline; i++) {
+   timeline_arr[i] = sw_sync_timeline_create();
+   fence_map[i] = -1;
+   }
+
+   sync_pt = rand();
+   fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+   fence_map[0] = sync_pt;
+
+   /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+   for (i = 0; i < nbr_merge; i++) {
+   /* Generate syncpoint. */
+   timeline_offset = rand() % nbr_timeline;
+   timeline = timeline_arr[timeline_offset];
+   sync_pt = rand();
+
+   /* Keep track of the latest sync_pt in each timeline. */
+   if (fence_map[timeline_offset] == -1)
+   fence_map[timeline_offset] = sync_pt;
+   else if (fence_map[timeline_offset] < sync_pt)
+   fence_map[timeline_offset] = sync_pt;
+
+   /* Merge. */
+   tmpfence = sw_sync_fence_create(timeline, sync_pt);
+   merged = sw_sync_merge(tmpfence, fence);
+   close(tmpfence);
+   close(fence);
+   fence = merged;
+   }
+
+   size = 0;
+   for (i = 0; i < nbr_timeline; i++)
+   if (fence_map[i] != -1)
+   size++;
+
+   /* Trigger the merged fence. */
+   for (i = 0; i < nbr_timeline; i++) {
+   if (fence_map[i] != -1) {
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0,
+   "Failure waiting on fence until timeout\n");
+   /* Increment the timeline to the last sync_pt */
+   sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+   }
+   }
+
+   /* Check that the fence is triggered. */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure triggering fence\n");
+
+   close(fence);
+   for (i = 0; i < nbr_timeline; i++)
+   close(timeline_arr[i]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -412,5 +482,8 @@ igt_main
 
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+   igt_subtest("sync_random_merge")
+   test_sync_random_merge();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 02/13] tests/sw_sync: Add sw_sync test

2016-09-15 Thread robert . foss
From: Robert Foss 

Add initial tests for sw_sync.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
---
 tests/Makefile.sources |  1 +
 tests/sw_sync.c| 52 ++
 2 files changed, 53 insertions(+)
 create mode 100644 tests/sw_sync.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 72a58ad..0ba769f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -125,6 +125,7 @@ TESTS_progs_M = \
prime_mmap_kms \
prime_self_import \
prime_vgem \
+   sw_sync \
template \
vgem_basic \
vgem_slow \
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
new file mode 100644
index 000..47e2dfa
--- /dev/null
+++ b/tests/sw_sync.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "igt.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+
+static void test_alloc_timeline(void)
+{
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   close(timeline);
+}
+
+igt_main
+{
+   igt_subtest("alloc_timeline")
+   test_alloc_timeline();
+}
+
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 10/13] tests/sw_sync: Add subtest test_sync_multi_consumer_producer

2016-09-15 Thread robert . foss
From: Robert Foss 

This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index e607b75..13a5643 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -304,6 +304,86 @@ static void test_sync_multi_consumer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void * test_sync_multi_consumer_producer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int nbr_threads = data->nbr_threads;
+   int timeline = data->timeline;
+   int iterations = data->nbr_iterations;
+   int ret, i;
+
+   for (i = 0; i < iterations; i++) {
+   int next_point = i * nbr_threads + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sw_sync_wait(fence, 1000);
+   if (ret <= 0)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   (*data->counter)++;
+
+   /* Kick off the next thread. */
+   sw_sync_timeline_inc(timeline, 1);
+
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer_producer(void)
+{
+   const uint32_t nbr_threads = 8;
+   const uint32_t nbr_iterations = 1 << 14;
+   data_t data_arr[nbr_threads];
+   pthread_t thread_arr[nbr_threads];
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   timeline = sw_sync_timeline_create();
+
+   data.nbr_iterations = nbr_iterations;
+   data.nbr_threads = nbr_threads;
+   data.counter = 
+   data.timeline = timeline;
+
+   /* Start consumer threads. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_producer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+
+   igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -329,5 +409,8 @@ igt_main
 
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
+
+   igt_subtest("sync_multi_consumer_producer")
+   test_sync_multi_consumer_producer();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 05/13] tests/sw_sync: Add subtest test_alloc_merge_fence

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies that merging two fences works in the simples possible
case.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 75bd471..fcb2f57 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -61,6 +61,26 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
 }
 
+static void test_alloc_merge_fence(void)
+{
+   int in_fence[2];
+   int fence_merge;
+   int timeline[2];
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+   fence_merge = sw_sync_merge(in_fence[1], in_fence[0]);
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -71,5 +91,8 @@ igt_main
 
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+   igt_subtest("alloc_merge_fence")
+   test_alloc_merge_fence();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 00/13] Implement sw_sync test

2016-09-15 Thread robert . foss
From: Robert Foss 

This series implements the sw_sync test and the lib/sw_sync helper functions 
for said test.

Gustavo Padovans sw_sync series was just de-staged in 
gregkh-staging/staging-next [1], and this test is targeted at verifying the 
functionality implemented in that series. 

The sw_sync subtests range from very basic tests of the sw_sync functionality, 
to stress testing and randomized tests.

[1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/

Changes since v1:
Added "Reviewed-by: Eric Engestrom " tag

  lib/sw_sync:
  - Fixed fd value checking
  - Fixed fd validity check in sw_sync_fd_close()
  - Moved sw_sync related paths to define
  - Switched from malloc+memset to calloc in sync_file_info()
  - Switched sizeof to dereferenced ptr

  tests/sw_sync:
  - Moved lib/sw_sync related code to lib/sw_sync commit
  - Replaced memset with assignment in loop


Changes since v2:

  lib/sw_sync:
  - Replaced fd validity check in sw_sync_timeline_create()
  - Replace sw_sync_XXX_destroy() functions with close()
  - Simplified sw_sync_timeline_inc() comparison
  - Changed sw_sync_merge() return value to -errno
  - Changed name of sw_sync_fence_size() to sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count_status()

  tests/sw_sync:
  - Replace sw_sync_XXX_destroy() functions with close()


Changes since v3:

  lib/sw_sync:
  - Changed sw_sync_fence_create() to take uint32_t seqno
  - Added raw __sw_sync_fence_create() and failure check sw_sync_fence_create()

  tests/sw_sync:
  - Switch to using __sw_sync_fence_create() for failure cases


Changes since v4:

  lib/sw_sync:
  - Fixed whitespace in sw_sync_fence_count()
  - Fixed whitespace and style of sw_sync_wait()
  - Fixed whitespace in __sw_sync_fence_count_status()

Robert Foss (13):
  lib/sw_sync: Add helper functions for managing synchronization
primitives
  tests/sw_sync: Add sw_sync test
  tests/sw_sync: Add subtest test_alloc_fence
  tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline
  tests/sw_sync: Add subtest test_alloc_merge_fence
  tests/sw_sync: Add subtest test_sync_wait
  tests/sw_sync: Add subtest test_sync_merge
  tests/sw_sync: Add subtest test_sync_merge_same
  tests/sw_sync: Add subtest test_sync_multi_consumer
  tests/sw_sync: Add subtest test_sync_multi_consumer_producer
  tests/sw_sync: Add subtest test_sync_random_merge
  tests/sw_sync: Add subtest test_sync_multi_timeline_wait
  tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

 lib/Makefile.sources   |   2 +
 lib/sw_sync.c  | 181 +
 lib/sw_sync.h  |  48 
 tests/Makefile.sources |   1 +
 tests/sw_sync.c| 694 +
 5 files changed, 926 insertions(+)
 create mode 100644 lib/sw_sync.c
 create mode 100644 lib/sw_sync.h
 create mode 100644 tests/sw_sync.c

-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

2016-09-15 Thread robert . foss
From: Robert Foss 

Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
---
 lib/Makefile.sources |   2 +
 lib/sw_sync.c| 181 +++
 lib/sw_sync.h|  48 ++
 3 files changed, 231 insertions(+)
 create mode 100644 lib/sw_sync.c
 create mode 100644 lib/sw_sync.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index bac9a7f..3dc7c3c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -61,6 +61,8 @@ lib_source_list = \
rendercopy_gen8.c   \
rendercopy_gen9.c   \
rendercopy.h\
+   sw_sync.c   \
+   sw_sync.h   \
intel_reg_map.c \
intel_iosf.c\
igt_kms.c   \
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
new file mode 100644
index 000..85d9226
--- /dev/null
+++ b/lib/sw_sync.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#ifndef ANDROID
+#define _GNU_SOURCE
+#else
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "drmtest.h"
+#include "ioctl_wrappers.h"
+
+#ifndef SW_SYNC_IOC_INC
+struct sw_sync_create_fence_data {
+   __u32   value;
+   charname[32];
+   __s32   fence;
+};
+
+#define SW_SYNC_IOC_MAGIC  'W'
+#define SW_SYNC_IOC_CREATE_FENCE   _IOWR(SW_SYNC_IOC_MAGIC, 0,\
+   struct 
sw_sync_create_fence_data)
+#define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1, 
__u32)
+#endif
+
+#define DEVFS_SW_SYNC   "/dev/sw_sync"
+#define DEBUGFS_SW_SYNC "/sys/kernel/debug/sync/sw_sync"
+
+
+int sw_sync_fd_is_valid(int fd)
+{
+   int status;
+
+   if (fd < 0)
+   return 0;
+
+   status = fcntl(fd, F_GETFD, 0);
+   return status >= 0;
+}
+
+int sw_sync_timeline_create(void)
+{
+   int fd = open(DEVFS_SW_SYNC, O_RDWR);
+
+   if (fd < 0)
+   fd = open(DEBUGFS_SW_SYNC, O_RDWR);
+
+   igt_assert(sw_sync_fd_is_valid(fd));
+
+   return fd;
+}
+
+int __sw_sync_fence_create(int fd, uint32_t seqno)
+{
+
+   struct sw_sync_create_fence_data data;
+
+   memset(, 0, sizeof(data));
+   data.value = seqno;
+
+   if (igt_ioctl(fd, SW_SYNC_IOC_CREATE_FENCE, ))
+   return -errno;
+
+   return data.fence;
+}
+
+int sw_sync_fence_create(int fd, uint32_t seqno)
+{
+   int fence = __sw_sync_fence_create(fd, seqno);
+   igt_assert(fence >= 0);
+   return fence;
+}
+
+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+   uint32_t arg = count;
+
+   do_ioctl(fd, SW_SYNC_IOC_INC, );
+}
+
+int sw_sync_merge(int fd1, int fd2)
+{
+   struct sync_merge_data data = {};
+   int err;
+
+   data.fd2 = fd2;
+
+   err = ioctl(fd1, SYNC_IOC_MERGE, );
+   if (err < 0)
+   return -errno;
+
+   sw_sync_fd_is_valid(data.fence);
+
+   return data.fence;
+}
+
+int sw_sync_wait(int fence, int timeout)
+{
+   struct pollfd pfd = { fence, POLLIN };
+
+   return poll(, 1, timeout);
+}
+
+int sw_sync_fence_count(int fd)
+{
+   struct sync_file_info info;
+
+   memset(, 0, sizeof(info));
+   if (ioctl(fd, SYNC_IOC_FILE_INFO, ))
+   return -errno;
+
+   return info.num_fences;
+}
+
+static 

[Intel-gfx] [PATCH i-g-t v5 04/13] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtests tests that creating fences on negative timelines fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 8f6208b..75bd471 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -56,6 +56,10 @@ static void test_alloc_fence(void)
close(timeline);
 }
 
+static void test_alloc_fence_invalid_timeline(void)
+{
+   igt_assert(__sw_sync_fence_create(-1, 0) < 0);
+}
 
 igt_main
 {
@@ -64,5 +68,8 @@ igt_main
 
igt_subtest("alloc_fence")
test_alloc_fence();
+
+   igt_subtest("alloc_fence_invalid_timeline")
+   test_alloc_fence_invalid_timeline();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 06/13] tests/sw_sync: Add subtest test_sync_wait

2016-09-15 Thread robert . foss
From: Robert Foss 

This subtest verifies that waiting on fences works properly.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index fcb2f57..3061279 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
 }
 
+static void test_sync_wait(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 5);
+
+   /* Wait on fence until timeout */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+
+   /* Wait on fence until timeout */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   /* Signal the fence */
+   sw_sync_timeline_inc(timeline, 4);
+
+   /* Wait successfully */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting on fence\n");
+
+   /* Go even further, and confirm wait still succeeds */
+   sw_sync_timeline_inc(timeline, 10);
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting ahead\n");
+
+   close(fence);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -94,5 +129,8 @@ igt_main
 
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+   igt_subtest("sync_wait")
+   test_sync_wait();
 }
 
-- 
2.9.3

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


[Intel-gfx] [PATCH i-g-t v5 03/13] tests/sw_sync: Add subtest test_alloc_fence

2016-09-15 Thread robert . foss
From: Robert Foss 

Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 47e2dfa..8f6208b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -44,9 +44,25 @@ static void test_alloc_timeline(void)
close(timeline);
 }
 
+static void test_alloc_fence(void)
+{
+   int in_fence;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   in_fence = sw_sync_fence_create(timeline, 0);
+
+   close(in_fence);
+   close(timeline);
+}
+
+
 igt_main
 {
igt_subtest("alloc_timeline")
test_alloc_timeline();
+
+   igt_subtest("alloc_fence")
+   test_alloc_fence();
 }
 
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH i-g-t v4 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

2016-09-15 Thread Robert Foss



On 2016-09-15 02:46 AM, Chris Wilson wrote:

On Wed, Sep 14, 2016 at 11:04:30AM -0400, robert.f...@collabora.com wrote:

+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+   uint32_t arg = count;
+
+   if (fd == 0)
+   return;


But fd = 0 is a valid fd, and might be a timeline somewhere.

Did you mean count == 0 ?

And even then (unless it is defined as an error condition in the kernel
ABI, and it should not be...) we should pass it through to the kernel.


You're right, I'll change it in v5.




+   do_ioctl(fd, SW_SYNC_IOC_INC, );
+}
+



+int sw_sync_wait(int fence, int timeout)
+{
+   struct pollfd fds;
+   int ret;
+
+   fds.fd = fence;
+   fds.events = POLLIN | POLLERR;


POLLERR is always implied and doesn't need to be specified (it is
meaningless in .events).

int sw_sync_wait(int fence, int timeout)
{
#if BEING_FANCY
return poll(&(struct pollfd){fd, POLLIN}, 1, timeout);
#else
struct pollfd pfd = { fd, POLLIN };
return poll(, 1, timeout);
#endif
}

Indentation has gone wrong, double check the whitespace.


That is definitely nicer looking. I'll drop it in for v5.




How do fences operate after their timeline is closed? (Are they
automatically signaled, or do they persist and are signaled normally?) Is
there a test for using fences from a closed timeline (I was looking but
didn't notice one).


I did some quick tests just to confirm, closing the timeline signals all 
of its fences.

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


Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

2016-09-15 Thread Pandiyan, Dhinakaran
On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> From: Jim Bride 
> 
> Add upfront link training to intel_dp_mst_mode_valid() so that we know
> topology constraints before we validate the legality of modes to be
> checked.
> 

The patch seems to do a lot more things than just what is described
here. I guess, it would be better to split this into multiple patches or
at least provide adequate description here.

> v3:
> * Reset the upfront values but dont unset the EDID for MST. (Manasi)
> v2:
> * Rebased on new revision of link training patch. (Manasi)
> 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 
>  drivers/gpu/drm/i915/intel_dp_mst.c | 74 
> +++--
>  drivers/gpu/drm/i915/intel_drv.h|  3 ++
>  3 files changed, 64 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9042d28..635830e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct drm_device 
> *dev,
> enum pipe pipe);
>  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
>  
> -static int
> +int
>  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
>  {
>   int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
>   return max_link_bw;
>  }
>  
> -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   u8 temp, source_max, sink_max;
> @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, int 
> source_len,
>   return k;
>  }
>  
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> -  int *common_rates)
> +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
>  {
>   const int *source_rates, *sink_rates;
>   int source_len, sink_len;
> @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>  common_rates);
>  }
>  
> -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct intel_encoder *intel_encoder = _dig_port->base;
> @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>   }
>  
>  out:
> - if ((status != connector_status_connected) &&
> - (intel_dp->is_mst == false)) {
> - intel_dp_unset_edid(intel_dp);
> + if (status != connector_status_connected) {
>   intel_dp->upfront_done = false;
>   intel_dp->max_lanes_upfront = 0;
>   intel_dp->max_link_rate_upfront = 0;
> + if (intel_dp->is_mst == false)
> + intel_dp_unset_edid(intel_dp);
>   }
>  
>   intel_display_power_put(to_i915(dev), power_domain);
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 54a9d76..98d45a4 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   int bpp;
>   int lane_count, slots;
>   const struct drm_display_mode *adjusted_mode = 
> _config->base.adjusted_mode;
> - int mst_pbn;
> + int mst_pbn, common_len;
> + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
>  
>   pipe_config->dp_encoder_is_mst = true;
>   pipe_config->has_pch_encoder = false;
> - bpp = 24;
> +
>   /*
> -  * for MST we always configure max link bw - the spec doesn't
> -  * seem to suggest we should do otherwise.
> +  * For MST we always configure for the maximum trainable link bw -
> +  * the spec doesn't seem to suggest we should do otherwise.  The
> +  * calls to intel_dp_max_lane_count() and intel_dp_common_rates()
> +  * both take successful upfront link training into account, and
> +  * return the DisplayPort max supported values in the event that
> +  * upfront link training was not done.
>*/
> - lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> + lane_count = intel_dp_max_lane_count(intel_dp);
>  
>   pipe_config->lane_count = lane_count;
>  
> - pipe_config->pipe_bpp = 24;
> - pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
> + pipe_config->pipe_bpp = bpp = 24;
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + pipe_config->port_clock = common_rates[common_len - 1];
> +
> + 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: do not use 'false' as a NULL pointer

2016-09-15 Thread Pandiyan, Dhinakaran
Reviewed-by: Dhinakaran Pandiyan 

On Thu, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fixes sparse warning:
> 
> drivers/gpu/drm/i915/intel_dpll_mgr.c:1712:24: warning: Using plain
> integer as NULL pointer
> 
> Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
> Cc: Manasi Navare 
> Cc: Ander Conselvan de Oliveira 
> Cc: Durgadoss R 
> Cc: Rodrigo Vivi 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 4b067accd5cd..c26d18a574b6 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1709,12 +1709,12 @@ bxt_get_dpll(struct intel_crtc *crtc,
>   if (encoder->type == INTEL_OUTPUT_HDMI
>   && !bxt_ddi_hdmi_pll_dividers(crtc, crtc_state,
> clock, _div))
> - return false;
> + return NULL;
>  
>   if ((encoder->type == INTEL_OUTPUT_DP ||
>encoder->type == INTEL_OUTPUT_EDP) &&
>   !bxt_ddi_dp_set_dpll_hw_state(clock, _hw_state))
> - return false;
> + return NULL;
>  
>   memset(_state->dpll_hw_state, 0,
>  sizeof(crtc_state->dpll_hw_state));

___
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: use NULL for NULL pointers

2016-09-15 Thread Pandiyan, Dhinakaran
Reviewed-by: Dhinakaran Pandiyan 

On Thu, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fix sparse warning:
> 
> drivers/gpu/drm/i915/i915_cmd_parser.c:987:72: warning: Using plain
> integer as NULL pointer
> 
> Fixes: 52a42cec4b70 ("drm/i915/cmdparser: Accelerate copies from WC memory")
> Cc: Chris Wilson 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 3c72b3b103e7..70980f82a15b 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -984,7 +984,7 @@ static u32 *copy_batch(struct drm_i915_gem_object 
> *dst_obj,
>  
>   src = ERR_PTR(-ENODEV);
>   if (src_needs_clflush &&
> - i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, 0, 0)) {
> + i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, NULL, 
> 0)) {
>   src = i915_gem_object_pin_map(src_obj, I915_MAP_WC);
>   if (!IS_ERR(src)) {
>   i915_memcpy_from_wc(dst,

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


[Intel-gfx] [drm-intel:for-linux-next 6/12] htmldocs: drivers/gpu/drm/drm_dp_helper.c:523: warning: No description found for parameter 'id[6]'

2016-09-15 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   80209e5f2c42c491ec5f4a63705b4377b407587c
commit: 266d783baaf5f34a5bea3b56489f091451a89767 [6/12] drm: Read DP branch 
device id
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/drm_modes.c:693: warning: No description found for parameter 
'bus_flags'
>> drivers/gpu/drm/drm_dp_helper.c:523: warning: No description found for 
>> parameter 'id[6]'
   drivers/gpu/drm/drm_dp_helper.c:524: warning: No description found for 
parameter 'id[6]'
   drivers/gpu/drm/drm_plane_helper.c:248: warning: No description found for 
parameter 'dst'
   drivers/gpu/drm/drm_plane_helper.c:248: warning: Excess function parameter 
'dest' description in 'drm_plane_helper_check_update'
   drivers/gpu/drm/drm_plane_helper.c:247: warning: No description found for 
parameter 'dst'
   drivers/gpu/drm/drm_plane_helper.c:247: warning: Excess function parameter 
'dest' description in 'drm_plane_helper_check_update'
   drivers/gpu/drm/drm_crtc.c:1270: WARNING: Inline literal start-string 
without end-string.
   drivers/gpu/drm/drm_crtc.c:1385: WARNING: Inline literal start-string 
without end-string.
   include/drm/drm_crtc.h:1202: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1255: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1268: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1272: WARNING: Inline literal start-string without 
end-string.
   drivers/gpu/drm/drm_irq.c:718: WARNING: Option list ends without a blank 
line; unexpected unindent.
   drivers/gpu/drm/drm_fb_helper.c:2195: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/drm_simple_kms_helper.c:141: WARNING: Inline literal 
start-string without end-string.
   include/drm/drm_gem.h:212: WARNING: Inline emphasis start-string without 
end-string.
   drivers/gpu/drm/i915/i915_vgpu.c:176: WARNING: Literal block ends without a 
blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_audio.c:54: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/i915/intel_audio.c:54: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/i915/intel_guc_fwif.h:159: WARNING: Block quote ends without 
a blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_guc_fwif.h:178: WARNING: Enumerated list ends 
without a blank line; unexpected unindent.
   Documentation/gpu/drm-kms.rst:13: WARNING: Could not lex literal_block as 
"C". Highlighting skipped.
   Documentation/gpu/drm-kms-helpers.rst:16: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.
   Documentation/gpu/i915.rst:57: WARNING: Could not lex literal_block as "C". 
Highlighting skipped.

vim +523 drivers/gpu/drm/drm_dp_helper.c

   507  case DP_DS_16BPC:
   508  return 16;
   509  }
   510  default:
   511  return 0;
   512  }
   513  }
   514  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
   515  
   516  /**
   517   * drm_dp_downstream_id() - identify branch device
   518   * @aux: DisplayPort AUX channel
   519   *
   520   * Returns branch device id on success or NULL on failure
   521   */
   522  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6])
 > 523  {
   524  return drm_dp_dpcd_read(aux, DP_BRANCH_ID, id, 6);
   525  }
   526  EXPORT_SYMBOL(drm_dp_downstream_id);
   527  
   528  /*
   529   * I2C-over-AUX implementation
   530   */
   531  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Try to print INSTDONE bits for all slice/subslice

2016-09-15 Thread Imre Deak
On Thu, 2016-09-15 at 17:30 +0300, Mika Kuoppala wrote:
> Imre Deak  writes:
> 
> > From: Ben Widawsky 
> > 
> > v2: (Imre)
> > - Access only subslices that are known to exist.
> > - Reset explictly the MCR selector to slice/sub-slice ID 0 after the
> >   readout.
> > - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck
> >   detection too.
> > - Take the uncore lock for the MCR-select/subslice-readout sequence.
> > 
> > Signed-off-by: Ben Widawsky 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 14 --
> >  drivers/gpu/drm/i915/i915_gpu_error.c   | 76 
> > ++---
> >  drivers/gpu/drm/i915/i915_irq.c | 25 ---
> >  drivers/gpu/drm/i915/i915_reg.h |  5 +++
> >  drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +-
> >  5 files changed, 125 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 45244f9..0f84165 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1281,6 +1281,9 @@ static void i915_instdone_info(struct 
> > drm_i915_private *dev_priv,
> >        struct seq_file *m,
> >        struct intel_instdone *instdone)
> >  {
> > +   int slice;
> > +   int subslice;
> > +
> >     seq_printf(m, "\t\tINSTDONE: 0x%08x\n",
> >        instdone->instdone);
> >  
> > @@ -1293,10 +1296,13 @@ static void i915_instdone_info(struct 
> > drm_i915_private *dev_priv,
> >     if (INTEL_GEN(dev_priv) <= 6)
> >     return;
> >  
> > -   seq_printf(m, "\t\tSAMPLER_INSTDONE: 0x%08x\n",
> > -      instdone->sampler);
> > -   seq_printf(m, "\t\tROW_INSTDONE: 0x%08x\n",
> > -      instdone->row);
> > +   for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> > +   seq_printf(m, "\t\tSAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
> > +      slice, subslice, instdone->sampler[slice][subslice]);
> > +
> > +   for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> > +   seq_printf(m, "\t\tROW_INSTDONE[%d][%d]: 0x%08x\n",
> > +      slice, subslice, instdone->row[slice][subslice]);
> >  }
> >  
> >  static int i915_hangcheck_info(struct seq_file *m, void *unused)
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 80fe101..06d4309 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -231,6 +231,9 @@ static const char *hangcheck_action_to_str(enum 
> > intel_engine_hangcheck_action a)
> >  static void error_print_instdone(struct drm_i915_error_state_buf *m,
> >      struct drm_i915_error_engine *ee)
> >  {
> > +   int slice;
> > +   int subslice;
> > +
> >     err_printf(m, "  INSTDONE: 0x%08x\n",
> >        ee->instdone.instdone);
> >  
> > @@ -243,10 +246,15 @@ static void error_print_instdone(struct 
> > drm_i915_error_state_buf *m,
> >     if (INTEL_GEN(m->i915) <= 6)
> >     return;
> >  
> > -   err_printf(m, "  SAMPLER_INSTDONE: 0x%08x\n",
> > -      ee->instdone.sampler);
> > -   err_printf(m, "  ROW_INSTDONE: 0x%08x\n",
> > -      ee->instdone.row);
> > +   for_each_instdone_slice_subslice(m->i915, slice, subslice)
> > +   err_printf(m, "  SAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
> > +      slice, subslice,
> > +      ee->instdone.sampler[slice][subslice]);
> > +
> > +   for_each_instdone_slice_subslice(m->i915, slice, subslice)
> > +   err_printf(m, "  ROW_INSTDONE[%d][%d]: 0x%08x\n",
> > +      slice, subslice,
> > +      ee->instdone.row[slice][subslice]);
> >  }
> >  
> >  static void error_print_engine(struct drm_i915_error_state_buf *m,
> > @@ -1534,12 +1542,52 @@ const char *i915_cache_level_str(struct 
> > drm_i915_private *i915, int type)
> >     }
> >  }
> >  
> > +static inline uint32_t
> > +read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> > +     int subslice, i915_reg_t reg)
> > +{
> > +   uint32_t mcr;
> > +   uint32_t ret;
> > +   enum forcewake_domains fw_domains;
> > +
> > +   fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg,
> > +   FW_REG_READ);
> > +   fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
> > +    GEN8_MCR_SELECTOR,
> > +    FW_REG_READ | 
> > FW_REG_WRITE);
> > +
> > +   spin_lock_irq(_priv->uncore.lock);
> > +   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
> > +
> > +   mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> > +   /*
> > +    * The HW expects the slice and sublice selectors to be reset to 0
> > +    * after 

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

2016-09-15 Thread Martin Steigerwald
Am Mittwoch, 14. September 2016, 14:14:35 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Jani Nikula  wrote:
> > On Wed, 14 Sep 2016, Pavel Machek  wrote:
> >> For the "sometimes need xrandr after resume": I don't think I can
> >> bisect that. It only happens sometimes :-(. But there's something
> >> helpful in the logs:
> >> 
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> > 
> > Pavel, Martin, do you always see this when the display fails to resume?
> > Is it HDMI/DVI for both of you?
> 
> Please try this patch, backported from our next.

Was busy up to now, and weekend also quite full already.

Thing is: I didn´t see this blank screen thing with 4.8-rc6 so far. And I did 
not have above EDID stuff in my log either. So I first wait whether I see 
blank screen again and if so, then know that a test would make sense. Maybe I 
see it before I complete a rc7 or rc8 (if there will be one), then I would 
include the patch of course.

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


Re: [Intel-gfx] [PATCH v6 0/5] Prep. for DP audio MST support

2016-09-15 Thread Lyude Paul
For the new patch, and any of the other patches in this series I haven't
reviewed yet, looks good to me:

Reviewed-by: Lyude 

On Wed, 2016-09-14 at 17:17 -0700, Dhinakaran Pandiyan wrote:
> This series lays the groundwork for more DP MST audio work that will
> follow.
> 
> v2:
> Different solution replacing the enc_to_dig_port() fix (Ville, Lyude).
> No changes to MST audio enabling and move audio_connector patches.
> Reordered the patches (Lyude)
> 
> v3:
> Different solution to get port from encoder (danvet).
> Removed locals that are not needed any more.
> Minor variable renaming clean up.
> Rebased on dinq.
> Retained r-b for "start adding dp mst audio" as it does not change.
> 
> v4:
> Fixed missing port initialization in intel_sdvo.c
> Renamed the port enum member from 'attached_port' to 'port'
> Fixed commit message typos.
> 
> v5:
> Really renamed the port enum member from 'attached_port' to 'port'
> Rebased on atomic changes.
> 
> v6:
> Modified the return type for a helper that returns port in intel_dvo.c
> 
> Dhinakaran Pandiyan (4):
>   drm/i915: Standardize port type for DVO encoders
>   drm/i915: Store port enum in intel_encoder
>   drm/i915: Switch to using port stored in intel_encoder
>   drm/i915: Move audio_connector to intel_encoder
> 
> Libin Yang (1):
>   drm/i915: start adding dp mst audio
> 
>  drivers/gpu/drm/i915/i915_debugfs.c | 19 +++-
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_audio.c  | 44 +++-
> -
>  drivers/gpu/drm/i915/intel_crt.c|  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c| 21 +-
>  drivers/gpu/drm/i915/intel_dp.c |  1 +
>  drivers/gpu/drm/i915/intel_dp_mst.c | 19 
>  drivers/gpu/drm/i915/intel_drv.h|  7 --
>  drivers/gpu/drm/i915/intel_dsi.c|  1 +
>  drivers/gpu/drm/i915/intel_dvo.c| 16 --
>  drivers/gpu/drm/i915/intel_hdmi.c   |  1 +
>  drivers/gpu/drm/i915/intel_lvds.c   |  3 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c   |  1 +
>  drivers/gpu/drm/i915/intel_tv.c |  2 ++
>  14 files changed, 96 insertions(+), 42 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/6] drm/i915: make intel_dp_compute_bpp static

2016-09-15 Thread Jim Bride
On Thu, Sep 15, 2016 at 04:28:52PM +0300, Jani Nikula wrote:
> Fix sparse warning:
> 
> drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: symbol
> 'intel_dp_compute_bpp' was not declared. Should it be static?
> 
> Fixes: f9bb705e65f6 ("drm/i915: Update bits per component for display info")
> Cc: Mika Kahola 
> Cc: Jim Bride 
> Signed-off-by: Jani Nikula 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 69cee9b0a08d..acd0c51f74d5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1524,8 +1524,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, 
> int port_clock,
>   }
>  }
>  
> -int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> -  struct intel_crtc_state *pipe_config)
> +static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config)
>  {
>   int bpp, bpc;
>  
> -- 
> 2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Try to print INSTDONE bits for all slice/subslice

2016-09-15 Thread Mika Kuoppala
Imre Deak  writes:

> From: Ben Widawsky 
>
> v2: (Imre)
> - Access only subslices that are known to exist.
> - Reset explictly the MCR selector to slice/sub-slice ID 0 after the
>   readout.
> - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck
>   detection too.
> - Take the uncore lock for the MCR-select/subslice-readout sequence.
>
> Signed-off-by: Ben Widawsky 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 --
>  drivers/gpu/drm/i915/i915_gpu_error.c   | 76 
> ++---
>  drivers/gpu/drm/i915/i915_irq.c | 25 ---
>  drivers/gpu/drm/i915/i915_reg.h |  5 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +-
>  5 files changed, 125 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 45244f9..0f84165 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1281,6 +1281,9 @@ static void i915_instdone_info(struct drm_i915_private 
> *dev_priv,
>  struct seq_file *m,
>  struct intel_instdone *instdone)
>  {
> + int slice;
> + int subslice;
> +
>   seq_printf(m, "\t\tINSTDONE: 0x%08x\n",
>  instdone->instdone);
>  
> @@ -1293,10 +1296,13 @@ static void i915_instdone_info(struct 
> drm_i915_private *dev_priv,
>   if (INTEL_GEN(dev_priv) <= 6)
>   return;
>  
> - seq_printf(m, "\t\tSAMPLER_INSTDONE: 0x%08x\n",
> -instdone->sampler);
> - seq_printf(m, "\t\tROW_INSTDONE: 0x%08x\n",
> -instdone->row);
> + for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> + seq_printf(m, "\t\tSAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
> +slice, subslice, instdone->sampler[slice][subslice]);
> +
> + for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> + seq_printf(m, "\t\tROW_INSTDONE[%d][%d]: 0x%08x\n",
> +slice, subslice, instdone->row[slice][subslice]);
>  }
>  
>  static int i915_hangcheck_info(struct seq_file *m, void *unused)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 80fe101..06d4309 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -231,6 +231,9 @@ static const char *hangcheck_action_to_str(enum 
> intel_engine_hangcheck_action a)
>  static void error_print_instdone(struct drm_i915_error_state_buf *m,
>struct drm_i915_error_engine *ee)
>  {
> + int slice;
> + int subslice;
> +
>   err_printf(m, "  INSTDONE: 0x%08x\n",
>  ee->instdone.instdone);
>  
> @@ -243,10 +246,15 @@ static void error_print_instdone(struct 
> drm_i915_error_state_buf *m,
>   if (INTEL_GEN(m->i915) <= 6)
>   return;
>  
> - err_printf(m, "  SAMPLER_INSTDONE: 0x%08x\n",
> -ee->instdone.sampler);
> - err_printf(m, "  ROW_INSTDONE: 0x%08x\n",
> -ee->instdone.row);
> + for_each_instdone_slice_subslice(m->i915, slice, subslice)
> + err_printf(m, "  SAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
> +slice, subslice,
> +ee->instdone.sampler[slice][subslice]);
> +
> + for_each_instdone_slice_subslice(m->i915, slice, subslice)
> + err_printf(m, "  ROW_INSTDONE[%d][%d]: 0x%08x\n",
> +slice, subslice,
> +ee->instdone.row[slice][subslice]);
>  }
>  
>  static void error_print_engine(struct drm_i915_error_state_buf *m,
> @@ -1534,12 +1542,52 @@ const char *i915_cache_level_str(struct 
> drm_i915_private *i915, int type)
>   }
>  }
>  
> +static inline uint32_t
> +read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> +   int subslice, i915_reg_t reg)
> +{
> + uint32_t mcr;
> + uint32_t ret;
> + enum forcewake_domains fw_domains;
> +
> + fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg,
> + FW_REG_READ);
> + fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
> +  GEN8_MCR_SELECTOR,
> +  FW_REG_READ | 
> FW_REG_WRITE);
> +
> + spin_lock_irq(_priv->uncore.lock);
> + intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
> +
> + mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> + /*
> +  * The HW expects the slice and sublice selectors to be reset to 0
> +  * after reading out the registers.
> +  */
> + WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK));
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/6] drm/i915: make intel_dp_compute_bpp static

2016-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915: make intel_dp_compute_bpp static
URL   : https://patchwork.freedesktop.org/series/12503/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6700hq)
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> SKIP   (fi-ivb-3770)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:0   skip:38 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:220  dwarn:0   dfail:0   fail:1   skip:23 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2540/

0ab36c7521bda5633d4d963a505014042b305346 drm-intel-nightly: 
2016y-09m-15d-11h-56m-55s UTC integration manifest
9da4ceb drm/i915: silence io mapping/unmapping sparse warnings on different 
address spaces
8875086 drm/i915: workaround sparse warning on variable length arrays
6dc2628e drm/i915: use NULL for NULL pointers
bf97cc2 drm/i915: keep declarations in i915_drv.h
46dd452 drm/i915: do not use 'false' as a NULL pointer
5bc5b51 drm/i915: make intel_dp_compute_bpp static

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


[Intel-gfx] [drm-intel:for-linux-next 12/12] drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of function 'seq_printf'

2016-09-15 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   80209e5f2c42c491ec5f4a63705b4377b407587c
commit: 80209e5f2c42c491ec5f4a63705b4377b407587c [12/12] drm: Add DP branch 
device info on debugfs
config: ia64-defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 80209e5f2c42c491ec5f4a63705b4377b407587c
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_downstream_debug':
>> drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of 
>> function 'seq_printf' [-Werror=implicit-function-declaration]
 seq_printf(m, "\tDP branch device present: %s\n",
 ^
>> drivers/gpu/drm/drm_dp_helper.c:559:3: error: implicit declaration of 
>> function 'seq_puts' [-Werror=implicit-function-declaration]
  seq_puts(m, "\t\tType: DisplayPort\n");
  ^
   cc1: some warnings being treated as errors

vim +/seq_printf +551 drivers/gpu/drm/drm_dp_helper.c

   545  int len;
   546  uint8_t rev[2];
   547  int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
   548  bool branch_device = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
   549   DP_DWN_STRM_PORT_PRESENT;
   550  
 > 551  seq_printf(m, "\tDP branch device present: %s\n",
   552 branch_device ? "yes" : "no");
   553  
   554  if (!branch_device)
   555  return;
   556  
   557  switch (type) {
   558  case DP_DS_PORT_TYPE_DP:
 > 559  seq_puts(m, "\t\tType: DisplayPort\n");
   560  break;
   561  case DP_DS_PORT_TYPE_VGA:
   562  seq_puts(m, "\t\tType: VGA\n");

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 4/6] drm/i915: use NULL for NULL pointers

2016-09-15 Thread Jani Nikula
Fix sparse warning:

drivers/gpu/drm/i915/i915_cmd_parser.c:987:72: warning: Using plain
integer as NULL pointer

Fixes: 52a42cec4b70 ("drm/i915/cmdparser: Accelerate copies from WC memory")
Cc: Chris Wilson 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 3c72b3b103e7..70980f82a15b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -984,7 +984,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dst_obj,
 
src = ERR_PTR(-ENODEV);
if (src_needs_clflush &&
-   i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, 0, 0)) {
+   i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, NULL, 
0)) {
src = i915_gem_object_pin_map(src_obj, I915_MAP_WC);
if (!IS_ERR(src)) {
i915_memcpy_from_wc(dst,
-- 
2.1.4

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


[Intel-gfx] [PATCH 3/6] drm/i915: keep declarations in i915_drv.h

2016-09-15 Thread Jani Nikula
Fix sparse warnings:

drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
'i915_driver_load' was not declared. Should it be static?

drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol
'i915_driver_unload' was not declared. Should it be static?

drivers/gpu/drm/i915/i915_drv.c:2444:25: warning: symbol 'i915_pm_ops'
was not declared. Should it be static?

Fixes: 42f5551d2769 ("drm/i915: Split out the PCI driver interface to 
i915_pci.c")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_pci.c | 7 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4bf10407cba..c0a7ea4dc2a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2885,6 +2885,11 @@ __i915_printk(struct drm_i915_private *dev_priv, const 
char *level,
 extern long i915_compat_ioctl(struct file *filp, unsigned int cmd,
  unsigned long arg);
 #endif
+extern const struct dev_pm_ops i915_pm_ops;
+
+extern int i915_driver_load(struct pci_dev *pdev,
+   const struct pci_device_id *ent);
+extern void i915_driver_unload(struct drm_device *dev);
 extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 687c768833b3..31e6edd08dd0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -431,9 +431,6 @@ static const struct pci_device_id pciidlist[] = {
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
 
-extern int i915_driver_load(struct pci_dev *pdev,
-   const struct pci_device_id *ent);
-
 static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
 {
struct intel_device_info *intel_info =
@@ -463,8 +460,6 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
return i915_driver_load(pdev, ent);
 }
 
-extern void i915_driver_unload(struct drm_device *dev);
-
 static void i915_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -473,8 +468,6 @@ static void i915_pci_remove(struct pci_dev *pdev)
drm_dev_unref(dev);
 }
 
-extern const struct dev_pm_ops i915_pm_ops;
-
 static struct pci_driver i915_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
-- 
2.1.4

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


[Intel-gfx] [PATCH 5/6] drm/i915: workaround sparse warning on variable length arrays

2016-09-15 Thread Jani Nikula
Fix sparse warning:

drivers/gpu/drm/i915/intel_device_info.c:195:31: warning: Variable
length array is used.

In truth the array does have constant length, but sparse is too dumb to
realize. This is a bit ugly, but silence the warning no matter what.

Fixes: 91bedd34abf0 ("drm/i915/bdw: Check for slice, subslice and EU count for 
BDW")
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 73b6858600ac..1b20e160bc1f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -192,7 +192,7 @@ static void broadwell_sseu_info_init(struct 
drm_i915_private *dev_priv)
struct sseu_dev_info *sseu = _device_info(dev_priv)->sseu;
const int s_max = 3, ss_max = 3, eu_max = 8;
int s, ss;
-   u32 fuse2, eu_disable[s_max];
+   u32 fuse2, eu_disable[3]; /* s_max */
 
fuse2 = I915_READ(GEN8_FUSE2);
sseu->slice_mask = (fuse2 & GEN8_F2_S_ENA_MASK) >> GEN8_F2_S_ENA_SHIFT;
-- 
2.1.4

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


[Intel-gfx] [PATCH 2/6] drm/i915: do not use 'false' as a NULL pointer

2016-09-15 Thread Jani Nikula
Fixes sparse warning:

drivers/gpu/drm/i915/intel_dpll_mgr.c:1712:24: warning: Using plain
integer as NULL pointer

Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
Cc: Manasi Navare 
Cc: Ander Conselvan de Oliveira 
Cc: Durgadoss R 
Cc: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b067accd5cd..c26d18a574b6 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1709,12 +1709,12 @@ bxt_get_dpll(struct intel_crtc *crtc,
if (encoder->type == INTEL_OUTPUT_HDMI
&& !bxt_ddi_hdmi_pll_dividers(crtc, crtc_state,
  clock, _div))
-   return false;
+   return NULL;
 
if ((encoder->type == INTEL_OUTPUT_DP ||
 encoder->type == INTEL_OUTPUT_EDP) &&
!bxt_ddi_dp_set_dpll_hw_state(clock, _hw_state))
-   return false;
+   return NULL;
 
memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));
-- 
2.1.4

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


[Intel-gfx] [PATCH 6/6] drm/i915: silence io mapping/unmapping sparse warnings on different address spaces

2016-09-15 Thread Jani Nikula
drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52: warning: incorrect type in 
argument 1 (different address spaces)
drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52:expected void [noderef] 
*vaddr
drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52:got void *
drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15: warning: incorrect type in 
assignment (different address spaces)
drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15:expected void *vaddr
drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15:got void [noderef] 
*

Cc: Chris Wilson 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 33c85227643d..e88786ea1219 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -429,7 +429,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
}
 
if (cache->vaddr) {
-   io_mapping_unmap_atomic(unmask_page(cache->vaddr));
+   io_mapping_unmap_atomic((void __force __iomem *) 
unmask_page(cache->vaddr));
} else {
struct i915_vma *vma;
int ret;
@@ -474,7 +474,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
offset += page << PAGE_SHIFT;
}
 
-   vaddr = io_mapping_map_atomic_wc(>i915->ggtt.mappable, offset);
+   vaddr = (void __force *) 
io_mapping_map_atomic_wc(>i915->ggtt.mappable, offset);
cache->page = page;
cache->vaddr = (unsigned long)vaddr;
 
-- 
2.1.4

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


[Intel-gfx] [PATCH 1/6] drm/i915: make intel_dp_compute_bpp static

2016-09-15 Thread Jani Nikula
Fix sparse warning:

drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: symbol
'intel_dp_compute_bpp' was not declared. Should it be static?

Fixes: f9bb705e65f6 ("drm/i915: Update bits per component for display info")
Cc: Mika Kahola 
Cc: Jim Bride 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 69cee9b0a08d..acd0c51f74d5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1524,8 +1524,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int 
port_clock,
}
 }
 
-int intel_dp_compute_bpp(struct intel_dp *intel_dp,
-struct intel_crtc_state *pipe_config)
+static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
+   struct intel_crtc_state *pipe_config)
 {
int bpp, bpc;
 
-- 
2.1.4

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


Re: [Intel-gfx] [PATCH] drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+

2016-09-15 Thread Ville Syrjälä
On Fri, Aug 19, 2016 at 07:03:23PM -0300, Paulo Zanoni wrote:
> We never remembered to set it (so it was zero), but this was not a
> problem in the past due to the way handled the hardware registers.
> Unfortunately we changed how we set the hardware and forgot to set
> intel_crtc->dspaddr_offset.
> 
> This started to reflect on a few kms_frontbuffer_tracking subtests
> that relied on page flips with CRTCs that don't point to the x:0,y:0
> coordinates of the frontbuffer. After the page flip the CRTC was
> showing the x:0,y:0 coordinate of the frontbuffer instead of
> x:500,y:500. This problem is present even if we don't enable FBC or
> PSR.
> 
> While trying to bisect it I realized that the first bad commit
> actually just gives me a black screen for the mentioned tests instead
> of showing the wrong x:0,y:0 offsets. A few commits later the black
> screen problem goes away and we get to the point where the code is
> today, but I'll consider the black screen as the first bad commit
> since it's the point where the IGT subtests start to fail.
> 
> Fixes: 6687c9062c46 ("drm/i915: Rewrite fb rotation GTT handling")
> Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt
> Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt
> Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack
> Cc: Ville Syrjälä 
> Cc: Sivakumar Thulasimani 
> Cc: drm-intel-fi...@lists.freedesktop.org
> 
> Signed-off-by: Paulo Zanoni 


> ---
>  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 f3e9ac5..1232b0e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3407,6 +3407,8 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   dst_w--;
>   dst_h--;
>  
> + intel_crtc->dspaddr_offset = surf_addr;
> +

Reviewed-by: Ville Syrjälä 

>   intel_crtc->adjusted_x = src_x;
>   intel_crtc->adjusted_y = src_y;
>  
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/9] drm/i915/gen9: minimum scanlines for Y tile is not always 4

2016-09-15 Thread Maarten Lankhorst
Op 14-09-16 om 02:38 schreef Paulo Zanoni:
> During watermarks calculations, this value is used in 3 different
> places. Only one of them was not using a hardcoded 4. Move the code up
> so everybody can benefit from the actual value.
>
> This should only help on situations with Y tiling + 90/270 rotation +
> 1 or 2 bpp or NV12.
>
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 56 
> +++--
>  1 file changed, 32 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fe43044..4d46315 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3504,7 +3504,8 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate, 
> uint8_t cpp, uint32_t latenc
>  
>  static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
>  uint32_t horiz_pixels, uint8_t cpp,
> -uint64_t tiling, uint32_t latency)
> +uint64_t tiling, uint32_t latency,
> +uint32_t y_min_scanlines)
>  {
>   uint32_t ret;
>   uint32_t plane_bytes_per_line, plane_blocks_per_line;
> @@ -3517,9 +3518,9 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate, 
> uint32_t pipe_htotal,
>  
>   if (tiling == I915_FORMAT_MOD_Y_TILED ||
>   tiling == I915_FORMAT_MOD_Yf_TILED) {
> - plane_bytes_per_line *= 4;
> + plane_bytes_per_line *= y_min_scanlines;
>   plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
> - plane_blocks_per_line /= 4;
> + plane_blocks_per_line /= y_min_scanlines;
>   } else if (tiling == DRM_FORMAT_MOD_NONE) {
>   plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512) 
> + 1;
>   } else {
> @@ -3576,6 +3577,7 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   uint8_t cpp;
>   uint32_t width = 0, height = 0;
>   uint32_t plane_pixel_rate;
> + uint32_t y_min_scanlines;
>  
>   if (latency == 0 || !cstate->base.active || 
> !intel_pstate->base.visible) {
>   *enabled = false;
> @@ -3591,38 +3593,44 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   cpp = drm_format_plane_cpp(fb->pixel_format, 0);
>   plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate, intel_pstate);
>  
> + if (intel_rotation_90_or_270(pstate->rotation)) {
> + int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
> + drm_format_plane_cpp(fb->pixel_format, 1) :
> + drm_format_plane_cpp(fb->pixel_format, 0);
> +
> + switch (cpp) {
> + case 1:
> + y_min_scanlines = 16;
> + break;
> + case 2:
> + y_min_scanlines = 8;
> + break;
> + default:
> + WARN(1, "Unsupported pixel depth for rotation");
I wanted to comment that MISSING_CASE was appropriate here, but seems ville 
beat me to it on patch 9. :-)

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


Re: [Intel-gfx] [PATCH 9/9] drm/i915/gen9: fail the modeset instead of WARNing on unsuported config

2016-09-15 Thread Ville Syrjälä
On Tue, Sep 13, 2016 at 09:38:22PM -0300, Paulo Zanoni wrote:
> Now that this code is part of the compute stage we can return -EINVAL
> to prevent the modeset instead of giving a WARN and trying anyway.
> 
> Reported-by: Lyude 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9edc8ce..6394db7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3589,11 +3589,11 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   case 2:
>   y_min_scanlines = 8;
>   break;
> - default:
> - WARN(1, "Unsupported pixel depth for rotation");
>   case 4:
>   y_min_scanlines = 4;
>   break;
> + default:
> + return -EINVAL;

Considering this should never happen, MISSING_CASE() would be the
appropriate choice here.

>   }
>   } else {
>   y_min_scanlines = 4;
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] drm/i915: Ignore OpRegion panel type except on select machines

2016-09-15 Thread Adrien Vergé
> Tested-by: Marco Krüger 
> Tested-by: Alexey Shumitsky 
> Tested-by: Sean Greenslade 
> Tested-by: Emil Andersen Lauridsen 
> Tested-by: Robin Müller 
> Tested-by: oceans...@gmail.com
> Signed-off-by: Ville Syrjälä 
> Acked-by: Jani Nikula 
> Tested-by: James Hogan 

That works for me too on Terra Mobile Ultrabook 1450 II.
Thanks!

Tested-by: Adrien Vergé 

> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262d591a..7acbbbf97833 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1047,6 +1047,23 @@ err_out:
>   return err;
>  }
>  
> +static int intel_use_opregion_panel_type_callback(const struct dmi_system_id 
> *id)
> +{
> + DRM_INFO("Using panel type from OpRegion on %s\n", id->ident);
> + return 1;
> +}
> +
> +static const struct dmi_system_id intel_use_opregion_panel_type[] = {
> + {
> + .callback = intel_use_opregion_panel_type_callback,
> + .ident = "Conrac GmbH IX45GM2",
> + .matches = {DMI_MATCH(DMI_SYS_VENDOR, "Conrac GmbH"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "IX45GM2"),
> + },
> + },
> + { }
> +};
> +
>  int
>  intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
>  {
> @@ -1073,6 +1090,16 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   /*
> +  * So far we know that some machined must use it, others must not use 
> it.
> +  * There doesn't seem to be any way to determine which way to go, except
> +  * via a quirk list :(
> +  */
> + if (!dmi_check_system(intel_use_opregion_panel_type)) {
> + DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> + return -ENODEV;
> + }
> +
> + /*
>* FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
>* low vswing for eDP, whereas the VBT panel type (2) gives us normal
>* vswing instead. Low vswing results in some display flickers, so
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 25/26] drm/i915: Add sysfs interface to know the HW requested frequency

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 04:14:22PM +0530, Kamble, Sagar A wrote:
> 
> 
> On 9/9/2016 10:13 PM, Chris Wilson wrote:
> >On Fri, Sep 09, 2016 at 06:21:44PM +0530, Sagar Arun Kamble wrote:
> >>With SLPC, user can read this value to know SLPC requested frequency.
> >Not SLPC specific, even elsewhere there may be a delay between the cur
> >value and the req (just means something more on SLPC).
> cur_freq is updated whenever RPNSWREQ is written so they should be
> same right?
> Where will delay come into picture?

RPNSWEQ is only updated from an irq worker. Plenty of scope for
breakage.
-Chris

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


Re: [Intel-gfx] [PATCH v4 11/26] drm/i915/slpc: Update sysfs/debugfs interfaces for frequency parameters

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 04:11:45PM +0530, Kamble, Sagar A wrote:
> 
> 
> On 9/9/2016 10:43 PM, Chris Wilson wrote:
> >On Fri, Sep 09, 2016 at 06:21:30PM +0530, Sagar Arun Kamble wrote:
> >>From: Tom O'Rourke 
> >>
> >>When SLPC is controlling requested frequency, the rps.cur_freq
> >>value is not used to make the frequency request.
> >>
> >>Requested frequency from register RPNSWREQ has the value
> >>most recently requested by SLPC firmware. Adding new sysfs
> >>interface gt_req_freq_mhz to know this value.
> >>SLPC requested value needs to be made available to i915 without
> >>reading RPNSWREQ.
> >>
> >>v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
> >> Avoid magic numbers (Nick)
> >> Use a function for repeated code (Jon)
> >>
> >>v2: Add "SLPC Active" to i915_frequency_info output and
> >> don't update cur_freq as it is driver internal request. (Chris)
> >>
> >>v3: Removing sysfs interface gt_req_freq_mhz out of this patch
> >> for proper division of functionality. (Sagar)
> >>
> >>v4: idle_freq, boost_freq are also not used with SLPC.
> >>
> >>Signed-off-by: Tom O'Rourke 
> >>Signed-off-by: Sagar Arun Kamble 
> >>---
> >>  drivers/gpu/drm/i915/i915_debugfs.c | 24 ++--
> >>  drivers/gpu/drm/i915/i915_sysfs.c   |  3 +++
> >>  2 files changed, 21 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >>b/drivers/gpu/drm/i915/i915_debugfs.c
> >>index 02b627e..71bce32 100644
> >>--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >>@@ -1083,6 +1083,9 @@ static int i915_frequency_info(struct seq_file *m, 
> >>void *unused)
> >>intel_runtime_pm_get(dev_priv);
> >>+   if (intel_slpc_active(dev_priv))
> >>+   seq_puts(m, "SLPC Active\n");
> >>+
> >>if (IS_GEN5(dev_priv)) {
> >>u16 rgvswctl = I915_READ16(MEMSWCTL);
> >>u16 rgvstat = I915_READ16(MEMSTAT_ILK);
> >>@@ -1250,15 +1253,21 @@ static int i915_frequency_info(struct seq_file *m, 
> >>void *unused)
> >>seq_printf(m, "Max overclocked frequency: %dMHz\n",
> >>   intel_gpu_freq(dev_priv, dev_priv->rps.max_freq));
> >>-   seq_printf(m, "Current freq: %d MHz\n",
> >>-  intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq));
> >>+   if (!intel_slpc_active(dev_priv)) {
> >Just keep printing them, we have the banner upfront, and being able to
> >track and compare internal values vs hw state is still important. (And
> >the ordering was fairly intentional.)
> cur_freq, idle_freq, boost_freq will not be applicable with SLPC.
> With SLPC we should rely on value from RPNSWREQ for cur_freq.

Hence the banner. We still want to be able to inspect our internal
values to see if anything is going wrong, whether SLPC is enabled or
not. E.g. if SLPC is and yet the bookkeeping is changing, something is
wrong.
-Chris

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


Re: [Intel-gfx] [PATCH v9 00/12] drm/i915: DP branch devices

2016-09-15 Thread Jani Nikula
On Fri, 09 Sep 2016, Mika Kahola  wrote:
> Prep work for DP branch device handling
>
> This series of patches reads DPCD register 0x80h for receiver
> capabilities for DP branch devices. The branch device types are
> converters for the following standards
>
>  - DP to VGA
>  - DP to DVI
>  - DP to HDMI
>  - DP++ dual mode
>  - Wireless WiGig
>  
> DPCD register defines max pixel rate for VGA dongles. This
> check is carried out during mode validation. 

Pushed all except the last patch to drm-intel-next-queued, with Dave's
IRC ack on queuing the drm patches through the Intel tree.

BR,
Jani.


-- 
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] [PULL] drm-intel-fixes

2016-09-15 Thread Jani Nikula

Hi Dave, more Intel fixes for v4.8.

BR,
Jani.

The following changes since commit fc2780b66b15092ac68272644a522c1624c48547:

  drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB 
(2016-09-07 17:40:43 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-09-15

for you to fetch changes up to ea54ff4008892b46c7a3e6bc8ab8aaec9d198639:

  drm/i915: Ignore OpRegion panel type except on select machines (2016-09-14 
11:25:05 +0300)


Chris Wilson (1):
  drm/i915: Restore lost "Initialized i915" welcome message

Rodrigo Vivi (1):
  Revert "drm/i915/psr: Make idle_frames sensible again"

Ville Syrjälä (1):
  drm/i915: Ignore OpRegion panel type except on select machines

 drivers/gpu/drm/i915/i915_drv.c   |  5 +
 drivers/gpu/drm/i915/intel_opregion.c | 27 +++
 drivers/gpu/drm/i915/intel_psr.c  | 14 +++---
 3 files changed, 39 insertions(+), 7 deletions(-)

-- 
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: Queue page flip work via a low latency, unbound workqueue

2016-09-15 Thread Imre Deak
On Thu, 2016-09-15 at 10:44 +0200, Maarten Lankhorst wrote:
> Op 14-09-16 om 19:07 schreef Imre Deak:
> > While user space has control over the scheduling priority of its
> > page
> > flipping thread, the corresponding work the driver schedules for
> > MMIO
> > flips always runs from the generic system workqueue which has some
> > scheduling overhead due it being CPU bound. This would hinder an
> > application that wants more stringent guarantees over flip timing
> > (to
> > avoid missing a flip at the next frame count).
> > 
> > Fix this by scheduling the work from a dedicated, unbound workqueue
> > which provides for minimal scheduling latency.
> I think it should use the same wq as intel_atomic_commit, either page
> flip should use
> system_unbound_wq, or atomic_commit should use this one.

Hm, I didn't notice system_unbound_wq, and I suppose there is no
advantage (smaller latency) in using a dedicated wq. So I can change
this to use system_unbound_wq.

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


Re: [Intel-gfx] [PATCH] drm/i915: Add ddb size field to device info structure

2016-09-15 Thread Jani Nikula
On Thu, 15 Sep 2016, Deepak M  wrote:
> Adding the ddb size into the devide info will avoid
> platform checks while computing wm.
>
> v2: Added comment and WARN_ON if ddb size is zero.(Jani)
> v3: Added WARN_ON at the right place.(Jani)
>
> Suggested-by: Ander Conselvan de Oliveira 
> 
> Signed-off-by: Deepak M 

Pushed to drm-intel-next-queued, thanks for the patch.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_pci.c |  5 +
>  drivers/gpu/drm/i915/intel_pm.c | 13 ++---
>  3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e2dda8..6014c3a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -710,6 +710,7 @@ struct intel_device_info {
>   u8 ring_mask; /* Rings supported by the HW */
>   u8 num_rings;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> + u16 ddb_size; /* in blocks */
>   /* Register offsets for the various display pipes and transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
>   int trans_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d771870d..687c768 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -328,6 +328,7 @@ static const struct intel_device_info intel_skylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
> @@ -336,6 +337,7 @@ static const struct intel_device_info 
> intel_skylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> @@ -358,6 +360,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_hw_contexts = 1,
>   .has_logical_ring_contexts = 1,
>   .has_guc = 1,
> + .ddb_size = 512,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> @@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> @@ -377,6 +381,7 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6af438f..2df06b7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2853,13 +2853,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
>   return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
>  }
>  
> -/*
> - * On gen9, we need to allocate Display Data Buffer (DDB) portions to the
> - * different active planes.
> - */
> -
> -#define SKL_DDB_SIZE 896 /* in blocks */
> -#define BXT_DDB_SIZE 512
>  #define SKL_SAGV_BLOCK_TIME  30 /* µs */
>  
>  /*
> @@ -3057,10 +3050,8 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   else
>   *num_active = hweight32(dev_priv->active_crtcs);
>  
> - if (IS_BROXTON(dev))
> - ddb_size = BXT_DDB_SIZE;
> - else
> - ddb_size = SKL_DDB_SIZE;
> + ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> + WARN_ON(ddb_size == 0);
>  
>   ddb_size -= 4; /* 4 blocks for bypass path allocation */

-- 
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 v4 25/26] drm/i915: Add sysfs interface to know the HW requested frequency

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:13 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:44PM +0530, Sagar Arun Kamble wrote:

With SLPC, user can read this value to know SLPC requested frequency.

Not SLPC specific, even elsewhere there may be a delay between the cur
value and the req (just means something more on SLPC).
cur_freq is updated whenever RPNSWREQ is written so they should be same 
right?

Where will delay come into picture?


Though I'm never keen on expanding the stable ABI, I can't object to
this given the existence of the others - but I will ask for a use case
other than debug.

For testing SLPC requests from Host side we have to rely on read of RPNSWREQ

-Chris



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


Re: [Intel-gfx] [PATCH v4 23/26] drm/i915/slpc: Keep RP SW Mode enabled while disabling rps

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:28 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:42PM +0530, Sagar Arun Kamble wrote:

With SLPC, only RP SW Mode control should be left enabled by i915.
Else, SLPC requests through through RPNSWREQ will not be granted.

Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 70e08d9..d06c9bb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5064,7 +5064,13 @@ static void gen9_disable_rc6(struct drm_i915_private 
*dev_priv)
  
  static void gen9_disable_rps(struct drm_i915_private *dev_priv)

  {
-   I915_WRITE(GEN6_RP_CONTROL, 0);
+   uint32_t rp_ctl = 0;

u32 rp_ctl = 0;


+
+   /* RP SW Mode Control will be needed for SLPC, Hence not clearing.*/

/* RP SW Mode Control will be needed for SLPC, so keep it enabled. */


+   if (i915.enable_slpc)

intel_slpc_enabled() ? (consistency!)

Will update this.



+   rp_ctl = I915_READ(GEN6_RP_CONTROL) & GEN6_RP_MEDIA_MODE_MASK;

Ok, so this is not doing what you describe. This is preserving state,
yes. But if we know that state is meant to be enabled for SLPC why are
we reading it back.

I am left with questions about what is happening behind our backs, and
what the code is trying to hide.
Will fix this. SLPC is going to request frequency hence we need to make 
sure host

does not tamper RP_CONTROL settings.

-Chris



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


Re: [Intel-gfx] [PATCH v4 24/26] drm/i915/slpc: Enable SLPC, where supported

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:15 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:43PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

This patch makes SLPC enabled by default on
platforms with hardware/firmware support.

v1: Removing warning "enable_slpc < 0" as it is
set to -1 with this patch now. This was caught by CI BAT.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_params.c | 4 ++--
  drivers/gpu/drm/i915/intel_guc.h   | 1 -
  2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 72b3097..7b3b3fd 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,7 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
-   .enable_slpc = 0,
+   .enable_slpc = -1,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -135,7 +135,7 @@ MODULE_PARM_DESC(enable_execlists,
  module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
  MODULE_PARM_DESC(enable_slpc,
"Override single-loop-power-controller (slpc) usage. "
-   "(-1=auto, 0=disabled [default], 1=enabled)");
+   "(-1=auto [default], 0=disabled, 1=enabled)");
  
  module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);

  MODULE_PARM_DESC(enable_psr, "Enable PSR "
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6e24e60..e9e1163 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -151,7 +151,6 @@ struct intel_guc {
  
  static inline int intel_slpc_enabled(void)

  {
-   WARN_ON(i915.enable_slpc < 0);

Remove this from the original path, and make it return a bool, since
i915.enable_slpc is always sanitized.

The this patch simply becomes flipping the switch.

Will update this.

-Chris



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


Re: [Intel-gfx] [PATCH v4 18/26] drm/i915/slpc: Add i915_slpc_info to debugfs

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:44 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:37PM +0530, Sagar Arun Kamble wrote:

+   if (!intel_slpc_active(dev_priv))
+   return -ENODEV;

Can we really say slpc is active without an slpc.vma?

No. Will remove this check.

-Chris



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


Re: [Intel-gfx] [PATCH v4 16/26] drm/i915/slpc: Add slpc support for max/min freq

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:19 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:35PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.

v1: Update for SLPC 2015.2.4 (params for both slice and unslice)
 Replace HAS_SLPC with intel_slpc_active() (Paulo)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 18 ++
  drivers/gpu/drm/i915/i915_sysfs.c   | 18 ++
  2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 71bce32..0956d1f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4873,6 +4873,15 @@ i915_max_freq_set(void *data, u64 val)
  
  	dev_priv->rps.max_freq_softlimit = val;
  
+	if (intel_slpc_active(dev_priv)) {

+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));

Hmm, there are a lot of these casts. Why?

Changing intel_gpu_freq(), intel_freq_opcode() to take and return
unsigned would help.

will fix this

-Chris



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


Re: [Intel-gfx] [PATCH v4 17/26] drm/i915/slpc: Add enable/disable debugfs for slpc

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:24 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:36PM +0530, Sagar Arun Kamble wrote:

+static ssize_t slpc_dcc_write(struct file *file, const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   int ret = 0;
+
+   ret = slpc_param_write(m, ubuf, len, SLPC_PARAM_TASK_ENABLE_DCC,
+  SLPC_PARAM_TASK_DISABLE_DCC);
+   if (ret)
+   return (size_t) ret;

What value is (ssize_t)(size_t)-1 as seen by userspace? Is it negative?

Will fix this. casting is not needed.

-Chris



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


Re: [Intel-gfx] [PATCH v4 11/26] drm/i915/slpc: Update sysfs/debugfs interfaces for frequency parameters

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:43 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:30PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.

Requested frequency from register RPNSWREQ has the value
most recently requested by SLPC firmware. Adding new sysfs
interface gt_req_freq_mhz to know this value.
SLPC requested value needs to be made available to i915 without
reading RPNSWREQ.

v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
 Avoid magic numbers (Nick)
 Use a function for repeated code (Jon)

v2: Add "SLPC Active" to i915_frequency_info output and
 don't update cur_freq as it is driver internal request. (Chris)

v3: Removing sysfs interface gt_req_freq_mhz out of this patch
 for proper division of functionality. (Sagar)

v4: idle_freq, boost_freq are also not used with SLPC.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 24 ++--
  drivers/gpu/drm/i915/i915_sysfs.c   |  3 +++
  2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..71bce32 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1083,6 +1083,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
  
  	intel_runtime_pm_get(dev_priv);
  
+	if (intel_slpc_active(dev_priv))

+   seq_puts(m, "SLPC Active\n");
+
if (IS_GEN5(dev_priv)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
u16 rgvstat = I915_READ16(MEMSTAT_ILK);
@@ -1250,15 +1253,21 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Max overclocked frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.max_freq));
  
-		seq_printf(m, "Current freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq));
+   if (!intel_slpc_active(dev_priv)) {

Just keep printing them, we have the banner upfront, and being able to
track and compare internal values vs hw state is still important. (And
the ordering was fairly intentional.)

cur_freq, idle_freq, boost_freq will not be applicable with SLPC.
With SLPC we should rely on value from RPNSWREQ for cur_freq.



+   seq_printf(m, "Current freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.cur_freq));
+   seq_printf(m, "Idle freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.idle_freq));
+   seq_printf(m, "Boost freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.boost_freq));
+   }
+
seq_printf(m, "Actual freq: %d MHz\n", cagf);
-   seq_printf(m, "Idle freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq));
seq_printf(m, "Min freq: %d MHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.min_freq));
-   seq_printf(m, "Boost freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, dev_priv->rps.boost_freq));
seq_printf(m, "Max freq: %d MHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.max_freq));
seq_printf(m,
@@ -2315,6 +2324,9 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
struct drm_device *dev = _priv->drm;
struct drm_file *file;
  
+	if (intel_slpc_active(dev_priv))

+   return -ENODEV;
+
seq_printf(m, "RPS enabled? %d\n", dev_priv->rps.enabled);
seq_printf(m, "GPU busy? %s [%x]\n",
   yesno(dev_priv->gt.awake), dev_priv->gt.active_engines);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 1012eee..020d64e 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -299,6 +299,9 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
  {
struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
  
+	if (intel_slpc_active(dev_priv))

+   return -ENODEV;

Ok, I had a thought that we allowed the user to directly set cur freq,
but we don't.
-Chris



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


Re: [Intel-gfx] [PATCH v4 10/26] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

2016-09-15 Thread Kamble, Sagar A


On 9/9/2016 10:38 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:29PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

SLPC shared data is used to pass information
to/from SLPC in GuC firmware.

For Skylake, platform sku type and slice count
are identified from device id and fuse values.

Support for other platforms needs to be added.

v1: Update for SLPC interface version 2015.2.4
 intel_slpc_active() returns 1 if slpc initialized (Paulo)
 change default host_os to "Windows"
 Spelling fixes (Sagar Kamble and Nick Hoath)
 Added WARN for checking if upper 32bits of GTT offset
 of shared object are zero. (ChrisW)
 Changed function call from gem_allocate/release_guc_obj to
 i915_guc_allocate/release_gem_obj. (Sagar)
 Updated commit message and moved POWER_PLAN and POWER_SOURCE
 definition from later patch. (Akash)
 Add struct_mutex locking while allocating/releasing slpc shared
 object. This was caught by CI BAT. Adding SLPC state variable
 to determine if it is active as it not just dependent on shared
 data setup.
 Rebase with guc_allocate_vma related changes.

v2: WARN_ON for platform_sku validity and space changes. (David)
 Checkpatch update.

v3: Fixing WARNING in igt@drv_module_reload_basic found in trybot BAT
 with SLPC Enabled.

v4: Updated support for GuC v9. s/slice_total/hweight8(slice_mask)/ (Dave).

Reviewed-by: David Weinehall 
Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_drv.h  |  7 ++-
  drivers/gpu/drm/i915/intel_guc.h  |  2 +
  drivers/gpu/drm/i915/intel_pm.c   |  6 ++-
  drivers/gpu/drm/i915/intel_slpc.c | 88 ++
  drivers/gpu/drm/i915/intel_slpc.h | 99 +++
  5 files changed, 199 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cf9aa24..796c52f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1707,7 +1707,12 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
  

I am going to need an idiot's guide here as to the difference between
enabled() and active().
Idea was to set active only when shared data is initialized. enabled was 
used to do initial/final setup.

Will change this and make consistent everywhere by keeping only one state.



  static inline int intel_slpc_active(struct drm_i915_private *dev_priv)

bool.

will update



  {
-   return 0;
+   int ret = 0;
+
+   if (dev_priv->guc.slpc.vma && dev_priv->guc.slpc.enabled)
+   ret = 1;
+
+   return ret;
  }
  
  /* intel_pm.c */

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 83dec66..6e24e60 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -145,6 +145,8 @@ struct intel_guc {
  
  	uint64_t submissions[I915_NUM_ENGINES];

uint32_t last_seqno[I915_NUM_ENGINES];
+
+   struct intel_slpc slpc;
  };
  
  static inline int intel_slpc_enabled(void)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d187066..2211f7b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6656,7 +6656,8 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
  
  void intel_cleanup_gt_powersave(struct drm_i915_private *dev_priv)

  {
-   if (intel_slpc_enabled())
+   if (intel_slpc_enabled() &&
+   dev_priv->guc.slpc.vma)
intel_slpc_cleanup(dev_priv);
else if (IS_VALLEYVIEW(dev_priv))
valleyview_cleanup_gt_powersave(dev_priv);
@@ -6746,7 +6747,8 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
  
  	mutex_lock(_priv->rps.hw_lock);
  
-	if (intel_slpc_enabled()) {

+   if (intel_slpc_enabled() &&
+   dev_priv->guc.slpc.vma) {
gen9_enable_rc6(dev_priv);
intel_slpc_enable(dev_priv);
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index be9e84c..972db18 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -22,15 +22,103 @@
   *
   */
  #include 
+#include 
  #include "i915_drv.h"
  #include "intel_guc.h"
  
+static unsigned int slpc_get_platform_sku(struct drm_i915_private *dev_priv)

+{
+   enum slpc_platform_sku platform_sku;
+
+   if (IS_SKL_ULX(dev_priv))
+   platform_sku = SLPC_PLATFORM_SKU_ULX;
+   else if (IS_SKL_ULT(dev_priv))
+   platform_sku = SLPC_PLATFORM_SKU_ULT;
+   else
+   platform_sku = SLPC_PLATFORM_SKU_DT;
+
+   WARN_ON(platform_sku > 0xFF);
+
+   return platform_sku;
+}
+
+static unsigned int 

Re: [Intel-gfx] [PATCH v4 07/26] drm/i915/slpc: Use intel_slpc_* functions if supported

2016-09-15 Thread Kamble, Sagar A

Thanks for the review.


On 9/9/2016 10:50 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:26PM +0530, Sagar Arun Kamble wrote:

@@ -6720,31 +6743,38 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
+   if (intel_slpc_enabled()) {
+   } else {
  
-	WARN_ON(dev_priv->rps.max_freq < dev_priv->rps.min_freq);

-   WARN_ON(dev_priv->rps.idle_freq > dev_priv->rps.max_freq);
+   WARN_ON(dev_priv->rps.max_freq < dev_priv->rps.min_freq);
+   WARN_ON(dev_priv->rps.idle_freq > dev_priv->rps.max_freq);
  
-	WARN_ON(dev_priv->rps.efficient_freq < dev_priv->rps.min_freq);

-   WARN_ON(dev_priv->rps.efficient_freq > dev_priv->rps.max_freq);
+   WARN_ON(dev_priv->rps.efficient_freq < dev_priv->rps.min_freq);
+   WARN_ON(dev_priv->rps.efficient_freq > dev_priv->rps.max_freq);

You seem to be chickening out of some sanity checks on values we present
to the user.
-Chris


Will restore these. idle_freq not applicable to SLPC hence will remove 
check for it with SLPC.






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


Re: [Intel-gfx] [PATCH v4 09/26] drm/i915/slpc: If using SLPC, do not set frequency

2016-09-15 Thread Kamble, Sagar A



On 9/9/2016 10:51 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:28PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

When frequency requests are made by SLPC, host driver
should not attempt to make frequency requests due to
potential conflicts.

Host-based turbo operations are already avoided when
SLPC is used.  This change covers other frequency
requests such as from sysfs or debugfs interfaces.

A later patch in this series updates sysfs/debugfs
interfaces for setting max/min frequencies with SLPC.

v1: Use intel_slpc_active instead of HAS_SLPC (Paulo)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index db5c4ef..d187066 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5047,6 +5047,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
  
  void intel_set_rps(struct drm_i915_private *dev_priv, u8 val)

  {
+   if (intel_slpc_active(dev_priv))
+   return;

active not enabled?

All of the other checks in rps are enabled, right?
-Chris


Will change this to make consistent.





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


Re: [Intel-gfx] [PATCH] drm/i915: Unlock PPS registers after GPU reset

2016-09-15 Thread Ville Syrjälä
On Wed, Sep 14, 2016 at 01:04:13PM +0300, Imre Deak wrote:
> Reapply the PPS register unlock workaround after GPU reset on platforms
> where the reset clobbers the display HW state. This at least gets rid of
> the related WARN during LVDS encoder enabling on PNV.
> 
> Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder 
> enabling")
> Reported-by: Ville Syrjälä 
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 48433e1..8bcffdd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3629,6 +3629,7 @@ void intel_finish_reset(struct drm_i915_private 
> *dev_priv)
>   intel_runtime_pm_disable_interrupts(dev_priv);
>   intel_runtime_pm_enable_interrupts(dev_priv);
>  
> + intel_pps_unlock_regs_wa(dev_priv);
>   intel_modeset_init_hw(dev);
>  
>   spin_lock_irq(_priv->irq_lock);
> -- 
> 2.5.0

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

2016-09-15 Thread Chris Wilson
On Thu, Sep 15, 2016 at 09:57:18AM +0100, Tvrtko Ursulin wrote:
> On 14/09/2016 18:00, Dave Gordon wrote:
> >On 14/09/16 16:22, Tvrtko Ursulin wrote:
> >>
> >>On 12/09/2016 21:19, Dave Gordon wrote:
> >>>Renaming to more consistent scheme, and updating comments, mostly
> >>>about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().
> >>>
> >>>Signed-off-by: Dave Gordon 
> Reviewed-by: Tvrtko Ursulin 

And pushed.
-Chris

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


Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

2016-09-15 Thread Jani Nikula
On Thu, 15 Sep 2016, Dave Gordon  wrote:
> On 14/09/16 18:35, Chris Wilson wrote:
>> On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote:
>>> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
 -static inline bool
 -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
 -int engine)
 -{
 -  return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
 +  return obj->active_count;
>>>
>>> our type is bool, so !!obj->active_count;
>>
>> That's the beauty of using bool, !! is implied on the (bool)integer
>> conversion.
>> -Chris
>
> It's a gcc extension, though, so does it work on clang?

It's in the standard.

"When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1."

BR,
Jani.


>
> .Dave.
> ___
> 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] drm/i915: Only expand COND once in wait_for()

2016-09-15 Thread Chris Wilson
On Wed, Sep 14, 2016 at 03:53:32PM -0300, Paulo Zanoni wrote:
> Em Qua, 2016-09-14 às 13:10 +0100, Dave Gordon escreveu:
> > Commentary from Chris Wilson's original version:
> > 
> > > 
> > > I was looking at some wait_for() timeouts on a slow system, with
> > > lots of
> > > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > > mishandling the timeout, I tried to ensure that we loop at least
> > > once
> > > after first testing COND. However, the double test of COND either
> > > side
> > > of the timeout check makes that unlikely. But we can do an
> > > equivalent
> > > loop, that keeps the COND check after testing for timeout (required
> > > so
> > > that we are not preempted between testing COND and then testing for
> > > a
> > > timeout) without expanding COND twice.
> > > 
> > > The advantage of only expanding COND once is a dramatic reduction
> > > in
> > > code size:
> > > 
> > >    text      data bss dec hex
> > >    1308733   5184    1152 1315069  141
> > > 0fd   before
> > >    1305341   5184    1152 1311677  140
> > > 3bd   after
> > 
> > but it turned out that due to a missing iniitialiser, gcc had "gone
> > wild trimming undefined code" :( This version acheives a rather more
> > modest (but still worthwhile) gain of ~550 bytes.
> > 
> > Signed-off-by: Dave Gordon 
> > Original-idea-by: Chris Wilson 
> > Cc: Chris Wilson 
> > Cc: Zanoni, Paulo R 
> 
> Reviewed-by: Paulo Zanoni 

Thanks for the improvement and review, pushed.
-Chris

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add ddb size field to device info structure (rev3)

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Add ddb size field to device info structure (rev3)
URL   : https://patchwork.freedesktop.org/series/12427/
State : success

== Summary ==

Series 12427v3 drm/i915: Add ddb size field to device info structure
https://patchwork.freedesktop.org/api/1.0/series/12427/revisions/3/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:210  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2539/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
a0f1e3e drm/i915: Add ddb size field to device info structure

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


Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

2016-09-15 Thread Masahiro Yamada
2016-09-15 18:46 GMT+09:00 Jani Nikula :
> On Wed, 14 Sep 2016, Masahiro Yamada  wrote:
>> i915_driver_open() is equivalent to i915_gem_open().  Replace the
>> i915_driver_open with the direct use of i915_gem_open().
>
> Sorry I know I asked for this, but there was opposition to doing
> this. Please just do the return i915_gem_open(dev, file) version like
> you had originally.

Sure.

(I was also wondering if it is the right thing to do.)

I will send v3.





-- 
Best Regards
Masahiro Yamada
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

2016-09-15 Thread Jani Nikula
On Wed, 14 Sep 2016, Masahiro Yamada  wrote:
> i915_driver_open() is equivalent to i915_gem_open().  Replace the
> i915_driver_open with the direct use of i915_gem_open().

Sorry I know I asked for this, but there was opposition to doing
this. Please just do the return i915_gem_open(dev, file) version like
you had originally.

Thanks,
Jani.


>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/gpu/drm/i915/i915_drv.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7f4e8ad..d3a33c4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1322,17 +1322,6 @@ void i915_driver_unload(struct drm_device *dev)
>   i915_driver_cleanup_early(dev_priv);
>  }
>  
> -static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
> -{
> - int ret;
> -
> - ret = i915_gem_open(dev, file);
> - if (ret)
> - return ret;
> -
> - return 0;
> -}
> -
>  /**
>   * i915_driver_lastclose - clean up after all DRM clients have exited
>   * @dev: DRM device
> @@ -2569,7 +2558,7 @@ static int intel_runtime_resume(struct device *kdev)
>   .driver_features =
>   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
>   DRIVER_RENDER | DRIVER_MODESET,
> - .open = i915_driver_open,
> + .open = i915_gem_open,
>   .lastclose = i915_driver_lastclose,
>   .preclose = i915_driver_preclose,
>   .postclose = i915_driver_postclose,

-- 
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 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

2016-09-15 Thread Dave Gordon

On 14/09/16 18:35, Chris Wilson wrote:

On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote:

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:

-static inline bool
-i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
- int engine)
-{
-   return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
+   return obj->active_count;


our type is bool, so !!obj->active_count;


That's the beauty of using bool, !! is implied on the (bool)integer
conversion.
-Chris


It's a gcc extension, though, so does it work on clang?

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


Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

2016-09-15 Thread Jani Nikula
On Wed, 14 Sep 2016, "Zanoni, Paulo R"  wrote:
> Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu:
>> On Wed, 14 Sep 2016, Paulo Zanoni  wrote:
>> > 
>> > Hi
>> > 
>> > Here's the series with the reviews implemented. There's a new
>> > patch,
>> > based on the additional issue spotted by Lyude.
>> 
>> There's a bunch of cc: stable patches mixed with non cc: stable
>> patches
>> in the series. Do the cc: stable fixes work and backport cleanly
>> without
>> the the other non cc: stable patches? If not, can you arrange the
>> series
>> to not depend on the other patches?
>
> Yeah, my bad. I was just pasting the output of "dim fixes" without
> considering this aspect. I think the best thing is probably to backport
> everything to stable and hope it works, considering the current
> complaints we're seeing about screen flickering on SKL. Agree?

The short answer, agreed.

This probably needs actual backporting, i.e. doesn't cherry-pick
cleanly, and it could probably use some testing too. What happens if the
stable folks manage to cherry-pick some but not all the patches cleanly?

BR,
Jani.



>
> I suppose I don't need to resend the series just for these new tags.
> I'll add them when it's time to merge.
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> > 
>> > 
>> > Thanks for all the reviews,
>> > Paulo
>> > 
>> > Paulo Zanoni (9):
>> >   drm/i915: SAGV is not SKL-only, so rename a few things
>> >   drm/i915: introduce intel_has_sagv()
>> >   drm/i915/kbl: KBL also needs to run the SAGV code
>> >   drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
>> >   drm/i915/gen9: minimum scanlines for Y tile is not always 4
>> >   drm/i915/gen9: fix plane_blocks_per_line on watermarks
>> > calculations
>> >   drm/i915/gen9: fix the watermark res_blocks value
>> >   drm/i915/gen9: implement missing case for SKL watermarks
>> > calculation
>> >   drm/i915/gen9: fail the modeset instead of WARNing on unsuported
>> > config
>> > 
>> >  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
>> >  drivers/gpu/drm/i915/intel_display.c |   9 +-
>> >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>> >  drivers/gpu/drm/i915/intel_pm.c  | 186 ---
>> > 
>> >  4 files changed, 118 insertions(+), 93 deletions(-)
>> 

-- 
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] [PATCH] drm/i915: Add ddb size field to device info structure

2016-09-15 Thread Deepak M
Adding the ddb size into the devide info will avoid
platform checks while computing wm.

v2: Added comment and WARN_ON if ddb size is zero.(Jani)
v3: Added WARN_ON at the right place.(Jani)

Suggested-by: Ander Conselvan de Oliveira 

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_pci.c |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 13 ++---
 3 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..6014c3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -710,6 +710,7 @@ struct intel_device_info {
u8 ring_mask; /* Rings supported by the HW */
u8 num_rings;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
+   u16 ddb_size; /* in blocks */
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
int trans_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d771870d..687c768 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -328,6 +328,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
@@ -336,6 +337,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
@@ -358,6 +360,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_hw_contexts = 1,
.has_logical_ring_contexts = 1,
.has_guc = 1,
+   .ddb_size = 512,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
@@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info = 
{
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
 };
 
 static const struct intel_device_info intel_kabylake_gt3_info = {
@@ -377,6 +381,7 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6af438f..2df06b7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2853,13 +2853,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
 }
 
-/*
- * On gen9, we need to allocate Display Data Buffer (DDB) portions to the
- * different active planes.
- */
-
-#define SKL_DDB_SIZE   896 /* in blocks */
-#define BXT_DDB_SIZE   512
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
 /*
@@ -3057,10 +3050,8 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
else
*num_active = hweight32(dev_priv->active_crtcs);
 
-   if (IS_BROXTON(dev))
-   ddb_size = BXT_DDB_SIZE;
-   else
-   ddb_size = SKL_DDB_SIZE;
+   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
+   WARN_ON(ddb_size == 0);
 
ddb_size -= 4; /* 4 blocks for bypass path allocation */
 
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

2016-09-15 Thread Tvrtko Ursulin


On 14/09/2016 18:33, Chris Wilson wrote:

On Wed, Sep 14, 2016 at 02:30:20PM +0100, Tvrtko Ursulin wrote:

On 14/09/2016 07:52, Chris Wilson wrote:

In the next patch, we will use deferred request emission. That requires
reserving sufficient space in the ringbuffer to emit the request, which
first requires us to know how large the request is.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_request.c |  1 +
  drivers/gpu/drm/i915/intel_lrc.c|  6 ++
  drivers/gpu/drm/i915/intel_ringbuffer.c | 29 +++--
  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
  4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index ebc2feba3e50..9a735e2d5aea 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -425,6 +425,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 * away, e.g. because a GPU scheduler has deferred it.
 */
req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
+   GEM_BUG_ON(req->reserved_space < engine->emit_request_sz);
if (i915.enable_execlists)
ret = intel_logical_ring_alloc_request_extras(req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 00fcf36ba919..7e944a0acc10 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct drm_i915_gem_request 
*request)
return intel_logical_ring_advance(request);
  }
+static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS;
+
  static int gen8_emit_request_render(struct drm_i915_gem_request *request)
  {
struct intel_ring *ring = request->ring;
@@ -1603,6 +1605,8 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
return intel_logical_ring_advance(request);
  }
+static const int gen8_emit_request_render_sz = 8 + WA_TAIL_DWORDS;
+
  static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
  {
int ret;
@@ -1677,6 +1681,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
engine->reset_hw = reset_common_ring;
engine->emit_flush = gen8_emit_flush;
engine->emit_request = gen8_emit_request;
+   engine->emit_request_sz = gen8_emit_request_sz;
engine->submit_request = execlists_submit_request;
engine->irq_enable = gen8_logical_ring_enable_irq;
@@ -1799,6 +1804,7 @@ int logical_render_ring_init(struct intel_engine_cs 
*engine)
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_request = gen8_emit_request_render;
+   engine->emit_request_sz = gen8_emit_request_render_sz;
ret = intel_engine_create_scratch(engine, 4096);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 597e35c9b699..c8c9ad40fd93 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1405,6 +1405,8 @@ static int i9xx_emit_request(struct drm_i915_gem_request 
*req)
return 0;
  }
+static const int i9xx_emit_request_sz = 4;
+
  /**
   * gen6_sema_emit_request - Update the semaphore mailbox registers
   *
@@ -1458,6 +1460,8 @@ static int gen8_render_emit_request(struct 
drm_i915_gem_request *req)
return 0;
  }
+static const int gen8_render_emit_request_sz = 8;
+
  /**
   * intel_ring_sync - sync the waiter to the signaller on seqno
   *
@@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct 
drm_i915_private *dev_priv,
engine->reset_hw = reset_ring_common;
engine->emit_request = i9xx_emit_request;
-   if (i915.semaphores)
+   engine->emit_request_sz = i9xx_emit_request_sz;
+   if (i915.semaphores) {
+   int num_rings;
+
engine->emit_request = gen6_sema_emit_request;
+
+   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;

You can use INTEL_INFO(dev_priv)->num_rings instead of hweight32.

I thought info->num_rings was set afterwards? (And num_rings may be an
overestimate here :(


You are correct, my oversight. Maybe it should have been num_rings and 
num_initialized_rings.


Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

2016-09-15 Thread Tvrtko Ursulin


On 14/09/2016 18:00, Dave Gordon wrote:

On 14/09/16 16:22, Tvrtko Ursulin wrote:


On 12/09/2016 21:19, Dave Gordon wrote:

Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 63
+++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
  3 files changed, 34 insertions(+), 33 deletions(-)



[snip]


  int i915_guc_submission_init(struct drm_i915_private *dev_priv)
  {
+const size_t ctxsize = sizeof(struct guc_context_desc);
+const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
+const size_t gemsize = round_up(poolsize, PAGE_SIZE);
  struct intel_guc *guc = _priv->guc;
  struct i915_vma *vma;
-u32 size;
/* Wipe bitmap & delete client in case of reinitialisation */
  bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
@@ -985,15 +987,14 @@ int i915_guc_submission_init(struct
drm_i915_private *dev_priv)
  if (guc->ctx_pool_vma)
  return 0; /* already allocated */
  -size = PAGE_ALIGN(GUC_MAX_GPU_CONTEXTS*sizeof(struct
guc_context_desc));
-vma = guc_allocate_vma(guc, size);
+vma = guc_allocate_vma(guc, gemsize);


PAGE_ALIGN lost - lower layers do that for us? I don't have easy access
to the tree at the moment to check and I kind of can't remember right 
now.


PAGE_ALIGN here is replaced by using round_up(..., PAGE_SIZE) at the 
point where the constant is defined a few lines above. I think 
round_up() is clearer, because "align" could equally well mean round 
down. Anyway "align" (up or down) is something you do to addresses or 
offsets, not sizes.


I failed to spot that line. :( Should really take a long holiday. :)

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH] DRM: i915: Fix random GPU hang, Bug 156851

2016-09-15 Thread Jani Nikula

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97814

On Thu, 15 Sep 2016, Cheng Cao  wrote:
> Signed-off-by: Cheng Cao 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  6 
>  drivers/gpu/drm/i915/i915_gem_stolen.c  | 61 
> -
>  drivers/gpu/drm/i915/i915_reg.h |  6 
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++-
>  4 files changed, 60 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 7a30af7..0b05dd9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2907,6 +2907,12 @@ static unsigned int gen8_get_total_gtt_size(u16 
> bdw_gmch_ctl)
>   if (bdw_gmch_ctl > 4)
>   bdw_gmch_ctl = 4;
>  #endif
> +#ifdef CONFIG_X86_64
> + /* Limit 64b platforms to a 4GB GGTT */
> + /* DMA 4GB protection */
> + if (bdw_gmch_ctl > 8)
> + bdw_gmch_ctl = 8;
> +#endif
>  
>   return bdw_gmch_ctl << 20;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 66be299a1..da272ae 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -352,47 +352,44 @@ static void gen8_get_stolen_reserved(struct 
> drm_i915_private *dev_priv,
>unsigned long *base, unsigned long *size)
>  {
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> + unsigned long stolen_top;
> + struct i915_ggtt *ggtt = _priv->ggtt;
>  
>   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
>   switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>   case GEN8_STOLEN_RESERVED_1M:
> - *size = 1024 * 1024;
> + *size = 1 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_2M:
> - *size = 2 * 1024 * 1024;
> + *size = 2 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_4M:
> - *size = 4 * 1024 * 1024;
> + *size = 4 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_8M:
> - *size = 8 * 1024 * 1024;
> + *size = 8 << 10 << 10;
>   break;
>   default:
> - *size = 8 * 1024 * 1024;
> - MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> - }
> -}
> -
> -static void bdw_get_stolen_reserved(struct drm_i915_private *dev_priv,
> - unsigned long *base, unsigned long *size)
> -{
> - struct i915_ggtt *ggtt = _priv->ggtt;
> - uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> - unsigned long stolen_top;
> + /* Whatever if it is a BDW device or SKL device
> +  * Or others devices..
> +  * This way is always going to work on 5th
> +  * generation Intel Processer
> +  */
> + stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
>  
> - stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
> + *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
> - *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> + /* MLIMIT - MBASE => PEG */
> + /*   -- mobile-5th-gen-core-family-datasheet-vol-2.pdf */
> + if (*base == 0) {
> + *size = 0;
> + MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> + } else
> + *size = stolen_top - *base;
>  
> - /* On these platforms, the register doesn't have a size field, so the
> -  * size is the distance between the base and the top of the stolen
> -  * memory. We also have the genuine case where base is zero and there's
> -  * nothing reserved. */
> - if (*base == 0)
> - *size = 0;
> - else
> - *size = stolen_top - *base;
> + break;
> + }
>  }
>  
>  int i915_gem_init_stolen(struct drm_device *dev)
> @@ -442,14 +439,14 @@ int i915_gem_init_stolen(struct drm_device *dev)
>   gen7_get_stolen_reserved(dev_priv, _base,
>_size);
>   break;
> + case 8:
> + gen8_get_stolen_reserved(dev_priv, _base,
> +  _size);
> + break;
>   default:
> - if (IS_BROADWELL(dev_priv) ||
> - IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev))
> - bdw_get_stolen_reserved(dev_priv, _base,
> - _size);
> - else
> - gen8_get_stolen_reserved(dev_priv, _base,
> -  _size);
> + // FIXME: This seemed like going to work
> + gen8_get_stolen_reserved(dev_priv, _base,
> +  _size);
>   break;

Re: [Intel-gfx] [PATCH v2] drm/i915: Queue page flip work via a low latency, unbound workqueue

2016-09-15 Thread Maarten Lankhorst
Op 14-09-16 om 19:07 schreef Imre Deak:
> While user space has control over the scheduling priority of its page
> flipping thread, the corresponding work the driver schedules for MMIO
> flips always runs from the generic system workqueue which has some
> scheduling overhead due it being CPU bound. This would hinder an
> application that wants more stringent guarantees over flip timing (to
> avoid missing a flip at the next frame count).
>
> Fix this by scheduling the work from a dedicated, unbound workqueue
> which provides for minimal scheduling latency.
I think it should use the same wq as intel_atomic_commit, either page flip 
should use
system_unbound_wq, or atomic_commit should use this one.

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


Re: [Intel-gfx] [PATCH] drm/i915: Add ddb size field to device info structure

2016-09-15 Thread Jani Nikula
On Wed, 14 Sep 2016, Deepak M  wrote:
> Adding the ddb size into the devide info will avoid
> platform checks while computing wm.
>
> v2: Added comment and WARN_ON if ddb size is zero.(Jani)
>
> Suggested-by: Ander Conselvan de Oliveira 
> 
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_pci.c |  5 +
>  drivers/gpu/drm/i915/intel_pm.c | 15 +++
>  3 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e2dda8..6014c3a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -710,6 +710,7 @@ struct intel_device_info {
>   u8 ring_mask; /* Rings supported by the HW */
>   u8 num_rings;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> + u16 ddb_size; /* in blocks */
>   /* Register offsets for the various display pipes and transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
>   int trans_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d771870d..687c768 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -328,6 +328,7 @@ static const struct intel_device_info intel_skylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
> @@ -336,6 +337,7 @@ static const struct intel_device_info 
> intel_skylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> @@ -358,6 +360,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_hw_contexts = 1,
>   .has_logical_ring_contexts = 1,
>   .has_guc = 1,
> + .ddb_size = 512,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> @@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> @@ -377,6 +381,7 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6af438f..9c5861e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2853,13 +2853,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
>   return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
>  }
>  
> -/*
> - * On gen9, we need to allocate Display Data Buffer (DDB) portions to the
> - * different active planes.
> - */
> -
> -#define SKL_DDB_SIZE 896 /* in blocks */
> -#define BXT_DDB_SIZE 512
>  #define SKL_SAGV_BLOCK_TIME  30 /* µs */
>  
>  /*
> @@ -3057,13 +3050,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   else
>   *num_active = hweight32(dev_priv->active_crtcs);
>  
> - if (IS_BROXTON(dev))
> - ddb_size = BXT_DDB_SIZE;
> - else
> - ddb_size = SKL_DDB_SIZE;
> -
> + ddb_size = INTEL_INFO(dev_priv)->ddb_size;
>   ddb_size -= 4; /* 4 blocks for bypass path allocation */
>  
> + WARN_ON(ddb_size == 0);

Please be careful. You have to stick the WARN_ON *before* you decrement
by 4.

BR,
Jani.


> +
>   /*
>* If the state doesn't change the active CRTC's, then there's
>* no need to recalculate; the existing pipe allocation limits

-- 
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: Fix random GPU hang, Bug 156851

2016-09-15 Thread Jani Nikula

You'll still need that commit message. See 'git log' on our driver for
examples of the level of commit messages we expect. You'll also see how
to reference bugs using the Bugzilla: tag. And please do file the bug
where I asked, not somewhere else.

BR,
Jani.


On Thu, 15 Sep 2016, Cheng Cao  wrote:
> Signed-off-by: Cheng Cao 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  6 
>  drivers/gpu/drm/i915/i915_gem_stolen.c  | 61 
> -
>  drivers/gpu/drm/i915/i915_reg.h |  6 
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++-
>  4 files changed, 60 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 7a30af7..0b05dd9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2907,6 +2907,12 @@ static unsigned int gen8_get_total_gtt_size(u16 
> bdw_gmch_ctl)
>   if (bdw_gmch_ctl > 4)
>   bdw_gmch_ctl = 4;
>  #endif
> +#ifdef CONFIG_X86_64
> + /* Limit 64b platforms to a 4GB GGTT */
> + /* DMA 4GB protection */
> + if (bdw_gmch_ctl > 8)
> + bdw_gmch_ctl = 8;
> +#endif
>  
>   return bdw_gmch_ctl << 20;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 66be299a1..da272ae 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -352,47 +352,44 @@ static void gen8_get_stolen_reserved(struct 
> drm_i915_private *dev_priv,
>unsigned long *base, unsigned long *size)
>  {
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> + unsigned long stolen_top;
> + struct i915_ggtt *ggtt = _priv->ggtt;
>  
>   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
>   switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>   case GEN8_STOLEN_RESERVED_1M:
> - *size = 1024 * 1024;
> + *size = 1 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_2M:
> - *size = 2 * 1024 * 1024;
> + *size = 2 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_4M:
> - *size = 4 * 1024 * 1024;
> + *size = 4 << 10 << 10;
>   break;
>   case GEN8_STOLEN_RESERVED_8M:
> - *size = 8 * 1024 * 1024;
> + *size = 8 << 10 << 10;
>   break;
>   default:
> - *size = 8 * 1024 * 1024;
> - MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> - }
> -}
> -
> -static void bdw_get_stolen_reserved(struct drm_i915_private *dev_priv,
> - unsigned long *base, unsigned long *size)
> -{
> - struct i915_ggtt *ggtt = _priv->ggtt;
> - uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> - unsigned long stolen_top;
> + /* Whatever if it is a BDW device or SKL device
> +  * Or others devices..
> +  * This way is always going to work on 5th
> +  * generation Intel Processer
> +  */
> + stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
>  
> - stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
> + *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
> - *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> + /* MLIMIT - MBASE => PEG */
> + /*   -- mobile-5th-gen-core-family-datasheet-vol-2.pdf */
> + if (*base == 0) {
> + *size = 0;
> + MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> + } else
> + *size = stolen_top - *base;
>  
> - /* On these platforms, the register doesn't have a size field, so the
> -  * size is the distance between the base and the top of the stolen
> -  * memory. We also have the genuine case where base is zero and there's
> -  * nothing reserved. */
> - if (*base == 0)
> - *size = 0;
> - else
> - *size = stolen_top - *base;
> + break;
> + }
>  }
>  
>  int i915_gem_init_stolen(struct drm_device *dev)
> @@ -442,14 +439,14 @@ int i915_gem_init_stolen(struct drm_device *dev)
>   gen7_get_stolen_reserved(dev_priv, _base,
>_size);
>   break;
> + case 8:
> + gen8_get_stolen_reserved(dev_priv, _base,
> +  _size);
> + break;
>   default:
> - if (IS_BROADWELL(dev_priv) ||
> - IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev))
> - bdw_get_stolen_reserved(dev_priv, _base,
> - _size);
> - else
> - gen8_get_stolen_reserved(dev_priv, _base,
> -   

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Change the placement of some static functions in intel_dp.c

2016-09-15 Thread Mika Kahola
On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> These static helper functions are required to be used within upfront
> link training related functions so they need to be placed at the top
> of the file. It also changes macro dev to dev_priv.
> 
We could split this patch into two parts. One being moving around the
helper functions and the other one cleanup patch to change dev in favor
of dev_priv.

> v2:
> * Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 158 
> 
>  1 file changed, 79 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 07f9a49..a319102 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -190,6 +190,81 @@ intel_dp_max_data_rate(int max_link_clock, int
> max_lanes)
>   return (max_link_clock * max_lanes * 8) / 10;
>  }
>  
> +static int
> +intel_dp_sink_rates(struct intel_dp *intel_dp, const int
> **sink_rates)
> +{
> + if (intel_dp->num_sink_rates) {
> + *sink_rates = intel_dp->sink_rates;
> + return intel_dp->num_sink_rates;
> + }
> +
> + *sink_rates = default_rates;
> +
> + return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> +}
> +
> +static int
> +intel_dp_source_rates(struct intel_dp *intel_dp, const int
> **source_rates)
> +{
> + struct intel_digital_port *dig_port =
> dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> + int size;
> +
> + if (IS_BROXTON(dev_priv)) {
> + *source_rates = bxt_rates;
> + size = ARRAY_SIZE(bxt_rates);
> + } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> + *source_rates = skl_rates;
> + size = ARRAY_SIZE(skl_rates);
> + } else {
> + *source_rates = default_rates;
> + size = ARRAY_SIZE(default_rates);
> + }
> +
> + /* This depends on the fact that 5.4 is last value in the
> array */
> + if (!intel_dp_source_supports_hbr2(intel_dp))
> + size--;
> +
> + return size;
> +}
> +
> +static int intersect_rates(const int *source_rates, int source_len,
> +    const int *sink_rates, int sink_len,
> +    int *common_rates)
> +{
> + int i = 0, j = 0, k = 0;
> +
> + while (i < source_len && j < sink_len) {
> + if (source_rates[i] == sink_rates[j]) {
> + if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
> + return k;
> + common_rates[k] = source_rates[i];
> + ++k;
> + ++i;
> + ++j;
> + } else if (source_rates[i] < sink_rates[j]) {
> + ++i;
> + } else {
> + ++j;
> + }
> + }
> + return k;
> +}
> +
> +static int intel_dp_common_rates(struct intel_dp *intel_dp,
> +  int *common_rates)
> +{
> + const int *source_rates, *sink_rates;
> + int source_len, sink_len;
> +
> + sink_len = intel_dp_sink_rates(intel_dp, _rates);
> + source_len = intel_dp_source_rates(intel_dp, _rates);
> +
> + return intersect_rates(source_rates, source_len,
> +    sink_rates, sink_len,
> +    common_rates);
> +}
> +
>  static enum drm_mode_status
>  intel_dp_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
> @@ -1256,60 +1331,22 @@ intel_dp_aux_init(struct intel_dp *intel_dp,
> struct intel_connector *connector)
>   intel_dp->aux.transfer = intel_dp_aux_transfer;
>  }
>  
> -static int
> -intel_dp_sink_rates(struct intel_dp *intel_dp, const int
> **sink_rates)
> -{
> - if (intel_dp->num_sink_rates) {
> - *sink_rates = intel_dp->sink_rates;
> - return intel_dp->num_sink_rates;
> - }
> -
> - *sink_rates = default_rates;
> -
> - return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> -}
> -
>  bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port =
> dp_to_dig_port(intel_dp);
> - struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
>  
>   /* WaDisableHBR2:skl */
> - if (IS_SKL_REVID(dev, 0, SKL_REVID_B0))
> + if (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0))
>   return false;
>  
> - if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) ||
> IS_BROADWELL(dev) ||
> - (INTEL_INFO(dev)->gen >= 9))
> + if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
> + IS_BROADWELL(dev_priv) || (INTEL_GEN(dev_priv) >= 9))
>   return true;
>   else
>   return false;
>  }
>  
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Standardize port type for DVO encoders (rev2)

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Standardize port type for DVO encoders (rev2)
URL   : https://patchwork.freedesktop.org/series/12418/
State : success

== Summary ==

Series 12418v2 drm/i915: Standardize port type for DVO encoders
https://patchwork.freedesktop.org/api/1.0/series/12418/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2537/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
7362ae9 drm/i915: Standardize port type for DVO encoders

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Queue page flip work with high priority (rev2)

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Queue page flip work with high priority (rev2)
URL   : https://patchwork.freedesktop.org/series/12336/
State : warning

== Summary ==

Series 12336v2 drm/i915: Queue page flip work with high priority
https://patchwork.freedesktop.org/api/1.0/series/12336/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-c:
pass   -> DMESG-WARN (fi-skl-6700k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (fi-hsw-4770r)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2536/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
c04762c drm/i915: Queue page flip work via a low latency, unbound workqueue

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev4)

2016-09-15 Thread Patchwork
== Series Details ==

Series: Enable i915 perf stream for Haswell OA unit (rev4)
URL   : https://patchwork.freedesktop.org/series/11295/
State : failure

== Summary ==

Series 11295v4 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/4/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6260u)
Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-hsw-4770k)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-byt-j1900)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:210  dwarn:1   dfail:0   fail:2   skip:31 
fi-hsw-4770k total:244  pass:225  dwarn:0   dfail:0   fail:1   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:218  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 
fi-skl-6260u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2535/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
ac3d501 drm/i915: Add a kerneldoc summary for i915_perf.c
9748144 drm/i915: Add more Haswell OA metric sets
695808f drm/i915: add oa_event_min_timer_exponent sysctl
b0c7ab1 drm/i915: Add dev.i915.perf_event_paranoid sysctl option
89749a7 drm/i915: advertise available metrics via sysfs
de45a10 drm/i915: Enable i915 perf stream for Haswell OA unit
af51dda drm/i915: Add 'render basic' Haswell OA unit config
4217060 drm/i915: don't whitelist oacontrol in cmd parser
1d86d19 drm/i915: return EACCES for check_cmd() failures
d9423dc drm/i915: rename OACONTROL GEN7_OACONTROL
de1d4ac drm/i915: Add i915 perf infrastructure

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() (rev2)

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() 
(rev2)
URL   : https://patchwork.freedesktop.org/series/12262/
State : warning

== Summary ==

Series 12262v2 drm/i915: introduce & use i915_gem_object_{set, clear, 
is}_dirty()
https://patchwork.freedesktop.org/api/1.0/series/12262/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:227  dwarn:2   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2534/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
4d942c8 drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only expand COND once in wait_for() (rev2)

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Only expand COND once in wait_for() (rev2)
URL   : https://patchwork.freedesktop.org/series/12403/
State : success

== Summary ==

Series 12403v2 drm/i915: Only expand COND once in wait_for()
https://patchwork.freedesktop.org/api/1.0/series/12403/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2532/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
bd562f9 drm/i915: Only expand COND once in wait_for()

___
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: Unlock PPS registers after GPU reset

2016-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Unlock PPS registers after GPU reset
URL   : https://patchwork.freedesktop.org/series/12446/
State : success

== Summary ==

Series 12446v1 drm/i915: Unlock PPS registers after GPU reset
https://patchwork.freedesktop.org/api/1.0/series/12446/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:212  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2530/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
424c774 drm/i915: Unlock PPS registers after GPU reset

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev3)

2016-09-15 Thread Patchwork
== Series Details ==

Series: Enable i915 perf stream for Haswell OA unit (rev3)
URL   : https://patchwork.freedesktop.org/series/11295/
State : failure

== Summary ==

Series 11295v3 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/3/mbox/

Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-hsw-4770k)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:209  dwarn:2   dfail:0   fail:2   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:0   dfail:0   fail:2   skip:35 
fi-hsw-4770k total:244  pass:225  dwarn:0   dfail:0   fail:1   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:218  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:226  dwarn:3   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2533/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
36985e3 drm/i915: Add a kerneldoc summary for i915_perf.c
9aab6b3 drm/i915: Add more Haswell OA metric sets
bdbb5e3 drm/i915: add oa_event_min_timer_exponent sysctl
bff8073 drm/i915: Add dev.i915.perf_event_paranoid sysctl option
c7d3b3b drm/i915: advertise available metrics via sysfs
c56f5bb drm/i915: Enable i915 perf stream for Haswell OA unit
182685f drm/i915: Add 'render basic' Haswell OA unit config
a48ac08 drm/i915: don't whitelist oacontrol in cmd parser
45f7ac0 drm/i915: return EACCES for check_cmd() failures
956313e drm/i915: rename OACONTROL GEN7_OACONTROL
db94420 drm/i915: Add i915 perf infrastructure

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Prep. for DP audio MST support (rev10)

2016-09-15 Thread Patchwork
== Series Details ==

Series: Prep. for DP audio MST support (rev10)
URL   : https://patchwork.freedesktop.org/series/11129/
State : failure

== Summary ==

Series 11129v10 Prep. for DP audio MST support
https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/10/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-FAIL (fi-skl-6700k)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:218  dwarn:1   dfail:1   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2538/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
22bf313 drm/i915: start adding dp mst audio
599d0bf drm/i915: Move audio_connector to intel_encoder
4173b55 drm/i915: Switch to using port stored in intel_encoder
9e37be7 drm/i915: Store port enum in intel_encoder
f176412 drm/i915: Standardize port type for DVO encoders

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


  1   2   >