[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.

[Patchwork]

== Series Details ==

Series: series starting with [1/9] drm/i915/psr: Do not activate PSR on 
frontbuffer flush from fbdev.
URL   : https://patchwork.freedesktop.org/series/37222/
State : failure

== Summary ==

Series 37222v1 series starting with [1/9] drm/i915/psr: Do not activate PSR on 
frontbuffer flush from fbdev.
https://patchwork.freedesktop.org/api/1.0/series/37222/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> FAIL   (fi-cnl-y2)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
pass   -> FAIL   (fi-cnl-y2)
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-cnl-y2)

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-cnl-y2total:288  pass:258  dwarn:0   dfail:0   fail:3   skip:27  
time:533s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:275s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
613153d13cc4 drm/i915/dp: Use the same aux retry interval as the core.
df3fbe824edd drm/dp: Export AUX_RETRY_INTERVAL
d478a7b9a4f2 drm/i915/dp: Move comment about hw timeout to the right place.
0a1e9441a39c drm/i915/dp: Remove redundant sleep after AUX transaction length 
check.
bd9979fae5cc drm/i915/psr: Inline psr2 caps checks.
46bad20dccd5 drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.
f171648ca84d drm/i915/psr: Extract PSR DPCD initialization and move it to 
intel_psr.c
000a9a7e6e7c drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with 
might_sleep()
8b7fcc9c09b2 drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7799/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev4)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev4)
URL   : https://patchwork.freedesktop.org/series/37134/
State : success

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +2
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> SKIP   (shard-snb) fdo#103880
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:2838 pass:1753 dwarn:1   dfail:0   fail:20  skip:1064 
time:12644s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:12023s
shard-snbtotal:2838 pass:1327 dwarn:1   dfail:0   fail:12  skip:1498 
time:6631s
Blacklisted hosts:
shard-kbltotal:2825 pass:1852 dwarn:8   dfail:0   fail:23  skip:941 
time:9455s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7798/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/9] drm/i915/dp: Remove redundant sleep after AUX transaction length check.

[Dhinakaran Pandiyan]

The core already takes care of the delay before retrying. The delay now
changes to (500, 600)us instead of (500 + 1000, 600 + 1500)us.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2454326690fb..97a4557053db 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1189,14 +1189,6 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
if (recv_bytes == 0 || recv_bytes > 20) {
DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n",
  recv_bytes);
-   /*
-* FIXME: This patch was created on top of a series that
-* organize the retries at drm level. There EBUSY should
-* also take care for 1ms wait before retrying.
-* That aux retries re-org is still needed and after that is
-* merged we remove this sleep from here.
-*/
-   usleep_range(1000, 1500);
ret = -EBUSY;
goto out;
}
-- 
2.14.1

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

[Intel-gfx] [PATCH 8/9] drm/dp: Export AUX_RETRY_INTERVAL

[Dhinakaran Pandiyan]

Drivers can use this in their retry loops too.

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_helper.c | 12 +---
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffe14ec3e7f2..0a7c8d6e7d8c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -169,8 +169,6 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
 }
 EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
 
-#define AUX_RETRY_INTERVAL 500 /* us */
-
 /**
  * DOC: dp helpers
  *
@@ -206,8 +204,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 */
for (retry = 0; retry < 32; retry++) {
if (ret != 0 && ret != -ETIMEDOUT) {
-   usleep_range(AUX_RETRY_INTERVAL,
-AUX_RETRY_INTERVAL + 100);
+   usleep_range(DP_AUX_RETRY_INTERVAL,
+DP_AUX_RETRY_INTERVAL + 100);
}
 
ret = aux->transfer(aux, );
@@ -718,7 +716,7 @@ static int drm_dp_i2c_retry_count(const struct 
drm_dp_aux_msg *msg,
drm_dp_aux_reply_duration(msg);
int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
 
-   return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
+   return DIV_ROUND_UP(i2c_time_us, aux_time_us + DP_AUX_RETRY_INTERVAL);
 }
 
 /*
@@ -795,7 +793,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * For now just defer for long enough to hopefully be
 * safe for all use-cases.
 */
-   usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
100);
+   usleep_range(DP_AUX_RETRY_INTERVAL, 
DP_AUX_RETRY_INTERVAL + 100);
continue;
 
default:
@@ -827,7 +825,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
aux->i2c_defer_count++;
if (defer_i2c < 7)
defer_i2c++;
-   usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
100);
+   usleep_range(DP_AUX_RETRY_INTERVAL, 
DP_AUX_RETRY_INTERVAL + 100);
drm_dp_i2c_msg_write_status_update(msg);
 
continue;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c239e6e24a10..2eae1aed2d26 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -61,6 +61,8 @@
 #define DP_AUX_I2C_REPLY_DEFER (0x2 << 2)
 #define DP_AUX_I2C_REPLY_MASK  (0x3 << 2)
 
+#define DP_AUX_RETRY_INTERVAL  500 /* us */
+
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
-- 
2.14.1

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

[Intel-gfx] [PATCH 9/9] drm/i915/dp: Use the same aux retry interval as the core.

[Dhinakaran Pandiyan]

Keeps the wait times consistent.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 06619998b5a3..3c64b2e92575 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1145,9 +1145,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
continue;
 
if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
-   usleep_range(400, 500);
+   usleep_range(DP_AUX_RETRY_INTERVAL,
+DP_AUX_RETRY_INTERVAL + 100);
continue;
}
+
if (status & DP_AUX_CH_CTL_DONE)
goto done;
}
-- 
2.14.1

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

[Intel-gfx] [PATCH 7/9] drm/i915/dp: Move comment about hw timeout to the right place.

[Dhinakaran Pandiyan]

No functional change.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 97a4557053db..06619998b5a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1136,14 +1136,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
   DP_AUX_CH_CTL_TIME_OUT_ERROR |
   DP_AUX_CH_CTL_RECEIVE_ERROR);
 
-   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
-   continue;
-
/* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
 *   400us delay required for errors and timeouts
 *   Timeout errors from the HW already meet this
 *   requirement so skip to next iteration
 */
+   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
+   continue;
+
if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
usleep_range(400, 500);
continue;
-- 
2.14.1

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

[Intel-gfx] [PATCH 5/9] drm/i915/psr: Inline psr2 caps checks.

[Dhinakaran Pandiyan]

Add a macro to check for a bit offset in a DPCD reg, use this macro to
eliminate three functions and a local.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 66 
 1 file changed, 19 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 83874bcd1142..9f83a7430e39 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,73 +56,45 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
-static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
-{
-   uint8_t psr_caps = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
-   return false;
-   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
-}
-
-static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
-{
-   uint8_t dprx = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
- ) != 1)
-   return false;
-   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
-}
-
-static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
-{
-   uint8_t alpm_caps = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
- _caps) != 1)
-   return false;
-   return alpm_caps & DP_ALPM_CAP;
-}
+#define DPCD_READB(_reg, _off) ({ u8 _buf;\
+   drm_dp_dpcd_readb(_dp->aux, _reg, &_buf) == 1 ? _buf & _off : 0; \
+})
 
 void intel_psr_init_dpcd(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
+   struct i915_psr *psr = _priv->psr;
 
drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
 sizeof(intel_dp->psr_dpcd));
 
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
-   dev_priv->psr.sink_support = true;
+   psr->sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
}
 
if (INTEL_GEN(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
-   uint8_t frame_sync_cap;
-
-   dev_priv->psr.sink_support = true;
-   if (drm_dp_dpcd_readb(_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- _sync_cap) != 1)
-   frame_sync_cap = 0;
-   dev_priv->psr.aux_frame_sync = frame_sync_cap & 
DP_AUX_FRAME_SYNC_CAP;
+   psr->sink_support = true;
+   psr->aux_frame_sync = 
DPCD_READB(DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+   DP_AUX_FRAME_SYNC_CAP);
/* PSR2 needs frame sync as well */
-   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
+   psr->psr2_support = psr->aux_frame_sync;
DRM_DEBUG_KMS("PSR2 %s on sink",
- dev_priv->psr.psr2_support ? "supported" : "not 
supported");
-
-   if (dev_priv->psr.psr2_support) {
-   dev_priv->psr.y_cord_support =
-   intel_dp_get_y_cord_status(intel_dp);
-   dev_priv->psr.colorimetry_support =
-   intel_dp_get_colorimetry_status(intel_dp);
-   dev_priv->psr.alpm =
-   intel_dp_get_alpm_status(intel_dp);
+ psr->psr2_support ? "supported" : "not 
supported");
+
+   if (psr->psr2_support) {
+   psr->y_cord_support = DPCD_READB(DP_PSR_CAPS,
+   
DP_PSR2_SU_Y_COORDINATE_REQUIRED);
+   psr->colorimetry_support = 
DPCD_READB(DP_DPRX_FEATURE_ENUMERATION_LIST,
+
DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED);
+   psr->alpm = DPCD_READB(DP_RECEIVER_ALPM_CAP,
+ DP_ALPM_CAP);
}
}
 }
+#undef DPCD_READB
 
 static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
 {
-- 
2.14.1

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

[Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.

[Dhinakaran Pandiyan]

There is no corresponding invalidate call before the buffer is written
to, this results in screen freezing sometime after switching to console
mode with PSR enabled. Invalidating the front buffer in the fbdev call
backs won't work either as some of them are called in atomic contexts and
{drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index e9feffdea899..c12af1118647 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
if (!CAN_PSR(dev_priv))
return;
 
+   if (origin == ORIGIN_DIRTYFB)
+   return;
+
mutex_lock(_priv->psr.lock);
if (!dev_priv->psr.enabled) {
mutex_unlock(_priv->psr.lock);
-- 
2.14.1

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

[Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c

[Dhinakaran Pandiyan]

intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and
intel_dp.c is huge.

No functional change intended.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c  | 64 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 68 
 3 files changed, 70 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2e88715..2454326690fb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, 
uint8_t link_status[DP_LINK_
DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
 }
 
-static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
-{
-   uint8_t psr_caps = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
-   return false;
-   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
-}
-
-static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
-{
-   uint8_t dprx = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
- ) != 1)
-   return false;
-   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
-}
-
-static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
-{
-   uint8_t alpm_caps = 0;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
- _caps) != 1)
-   return false;
-   return alpm_caps & DP_ALPM_CAP;
-}
-
 /* These are source-specific values. */
 uint8_t
 intel_dp_voltage_max(struct intel_dp *intel_dp)
@@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
 
-   /* Check if the panel supports PSR */
-   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
-intel_dp->psr_dpcd,
-sizeof(intel_dp->psr_dpcd));
-   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
-   dev_priv->psr.sink_support = true;
-   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
-   }
-
-   if (INTEL_GEN(dev_priv) >= 9 &&
-   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
-   uint8_t frame_sync_cap;
-
-   dev_priv->psr.sink_support = true;
-   if (drm_dp_dpcd_readb(_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- _sync_cap) != 1)
-   frame_sync_cap = 0;
-   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
-   /* PSR2 needs frame sync as well */
-   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
-   DRM_DEBUG_KMS("PSR2 %s on sink",
- dev_priv->psr.psr2_support ? "supported" : "not 
supported");
-
-   if (dev_priv->psr.psr2_support) {
-   dev_priv->psr.y_cord_support =
-   intel_dp_get_y_cord_status(intel_dp);
-   dev_priv->psr.colorimetry_support =
-   intel_dp_get_colorimetry_status(intel_dp);
-   dev_priv->psr.alpm =
-   intel_dp_get_alpm_status(intel_dp);
-   }
-
-   }
+   intel_psr_init_dpcd(intel_dp);
 
/*
 * Read the eDP display control registers.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3cee54bc0352..a340bc04dad8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port);
 
 /* intel_psr.c */
 #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
+void intel_psr_init_dpcd(struct intel_dp *intel_dp);
 void intel_psr_enable(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state);
 void intel_psr_disable(struct intel_dp *intel_dp,
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c12af1118647..a1b878449e83 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,6 +56,74 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
+static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+{
+   uint8_t psr_caps = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
+   return false;
+   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
+}
+
+static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+   uint8_t dprx = 0;
+
+   if 

[Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.

[Dhinakaran Pandiyan]

The cap check should be specifically for bit 0 instead of any bit.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index a1b878449e83..83874bcd1142 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -107,7 +107,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
  DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
  _sync_cap) != 1)
frame_sync_cap = 0;
-   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
+   dev_priv->psr.aux_frame_sync = frame_sync_cap & 
DP_AUX_FRAME_SYNC_CAP;
/* PSR2 needs frame sync as well */
dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
DRM_DEBUG_KMS("PSR2 %s on sink",
-- 
2.14.1

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

[Intel-gfx] [PATCH 2/9] drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with might_sleep()

[Dhinakaran Pandiyan]

Frontbuffer flush and invalidate call psr, fbc and drrs functions that use
mutexes but they can be called in atomic contexts in the fbdev path. The
point where the spinlocks are acquired is up in the call stack that is not
entirely easy to spot, so annotate with might_sleep().

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_frontbuffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index fcfc217e754e..3a8d3d06c26a 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -79,6 +79,7 @@ void __intel_fb_obj_invalidate(struct drm_i915_gem_object 
*obj,
spin_unlock(_priv->fb_tracking.lock);
}
 
+   might_sleep();
intel_psr_invalidate(dev_priv, frontbuffer_bits);
intel_edp_drrs_invalidate(dev_priv, frontbuffer_bits);
intel_fbc_invalidate(dev_priv, frontbuffer_bits, origin);
@@ -108,6 +109,7 @@ static void intel_frontbuffer_flush(struct drm_i915_private 
*dev_priv,
if (!frontbuffer_bits)
return;
 
+   might_sleep();
intel_edp_drrs_flush(dev_priv, frontbuffer_bits);
intel_psr_flush(dev_priv, frontbuffer_bits, origin);
intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
-- 
2.14.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 [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev4)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev4)
URL   : https://patchwork.freedesktop.org/series/37134/
State : success

== Summary ==

Series 37134v4 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/37134/revisions/4/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#103375

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:454s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:470s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
a1500d9c0a9f drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
dc2e020a119b drm/i915/cnl: Enable DDI-F on Cannonlake.
021a48f953d7 drm/i915/cnl: Add HPD support for Port F.
0feb0a231470 drm/i915: For HPD connected port use hpd_pin instead of port.
658d4aa3a9ab drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
ec5d7fff50f6 drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
702b9715 drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
7bb6cd4038f9 drm/i915/cnl: Extend Wa 1178 to Aux F.
58effcb14daf drm/i915/cnl: Add AUX-F support
b92f1fbcf174 drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7798/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev3)
URL   : https://patchwork.freedesktop.org/series/37134/
State : success

== Summary ==

Series 37134v3 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/37134/revisions/3/mbox/

Test kms_busy:
Subgroup basic-flip-a:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:484s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-elk-e7500 total:224  pass:169  dwarn:8   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
4bfc57fd4f6c drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
8725d90d7fb3 drm/i915/cnl: Enable DDI-F on Cannonlake.
dd5781af0a27 drm/i915/cnl: Add HPD support for Port F.
438fae9a572f drm/i915: For HPD connected port use hpd_pin instead of port.
7c3d8917c90d drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
e81384511e83 drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
baee668d4097 drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
8ce0475fa614 drm/i915/cnl: Extend Wa 1178 to Aux F.
9f50ca128541 drm/i915/cnl: Add AUX-F support
6d64380daef5 drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7797/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Rodrigo Vivi]

Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.

v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)

Cc: Dhinakaran Pandiyan 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_ddi.c|  4 
 drivers/gpu/drm/i915/intel_display.c|  6 +-
 drivers/gpu/drm/i915/intel_display.h|  2 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +---
 5 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 076a49107e02..8261fe4c4316 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1304,6 +1304,7 @@ enum i915_power_well_id {
SKL_DISP_PW_DDI_B,
SKL_DISP_PW_DDI_C,
SKL_DISP_PW_DDI_D,
+   CNL_DISP_PW_DDI_F = 6,
 
GLK_DISP_PW_AUX_A = 8,
GLK_DISP_PW_AUX_B,
@@ -8945,6 +8946,7 @@ enum skl_power_gate {
 #define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
+#define  SFUSE_STRAP_DDIF_DETECTED (1<<3)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
 #define  SFUSE_STRAP_DDIC_DETECTED (1<<1)
 #define  SFUSE_STRAP_DDID_DETECTED (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e51559be2e3b..cfcd9cb37d5d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2946,6 +2946,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_dig_port->ddi_io_power_domain =
POWER_DOMAIN_PORT_DDI_E_IO;
break;
+   case PORT_F:
+   intel_dig_port->ddi_io_power_domain =
+   POWER_DOMAIN_PORT_DDI_F_IO;
+   break;
default:
MISSING_CASE(port);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 83de43ce1f3b..fe3c09184c2e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5647,6 +5647,8 @@ enum intel_display_power_domain 
intel_port_to_power_domain(enum port port)
return POWER_DOMAIN_PORT_DDI_D_LANES;
case PORT_E:
return POWER_DOMAIN_PORT_DDI_E_LANES;
+   case PORT_F:
+   return POWER_DOMAIN_PORT_DDI_F_LANES;
default:
MISSING_CASE(port);
return POWER_DOMAIN_PORT_OTHER;
@@ -13619,7 +13621,7 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (found || IS_GEN9_BC(dev_priv))
intel_ddi_init(dev_priv, PORT_A);
 
-   /* DDI B, C and D detection is indicated by the SFUSE_STRAP
+   /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
 * register */
found = I915_READ(SFUSE_STRAP);
 
@@ -13629,6 +13631,8 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
intel_ddi_init(dev_priv, PORT_C);
if (found & SFUSE_STRAP_DDID_DETECTED)
intel_ddi_init(dev_priv, PORT_D);
+   if (found & SFUSE_STRAP_DDIF_DETECTED)
+   intel_ddi_init(dev_priv, PORT_F);
/*
 * On SKL we don't have a way to detect DDI-E so we rely on VBT.
 */
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index 30fa2041a45f..c4042e342f50 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -157,11 +157,13 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_C_LANES,
POWER_DOMAIN_PORT_DDI_D_LANES,
POWER_DOMAIN_PORT_DDI_E_LANES,
+   POWER_DOMAIN_PORT_DDI_F_LANES,
POWER_DOMAIN_PORT_DDI_A_IO,
POWER_DOMAIN_PORT_DDI_B_IO,
POWER_DOMAIN_PORT_DDI_C_IO,
POWER_DOMAIN_PORT_DDI_D_IO,
POWER_DOMAIN_PORT_DDI_E_IO,
+   POWER_DOMAIN_PORT_DDI_F_IO,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 294b85adc413..70e659772a7a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -94,6 +94,8 @@ intel_display_power_domain_str(enum 

[Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Rodrigo Vivi]

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
 warns as pointed by DK.
v11: Clean up squashed commit message. (David)
v12: Remove unnecessary handling for older platforms (DK)
 Adding AUX_F to PG2 following other existent ones. (DK)

Cc: David Weinehall 
Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  6 ++
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 drivers/gpu/drm/i915/intel_display.h|  1 +
 drivers/gpu/drm/i915/intel_dp.c |  6 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 ++
 6 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5702ebf17974..f89a1a0a25c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ enum modeset_restore {
 #define DP_AUX_B 0x10
 #define DP_AUX_C 0x20
 #define DP_AUX_D 0x30
+#define DP_AUX_F 0x60
 
 #define DDC_PIN_B  0x05
 #define DDC_PIN_C  0x04
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f643d5ad7ff7..4d84b1c41a94 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   tmp_mask |= CNL_AUX_CHANNEL_F;
+
if (iir & tmp_mask) {
dp_aux_irq_handler(dev_priv);
found = true;
@@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   de_port_masked |= CNL_AUX_CHANNEL_F;
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64933fd74cb6..44f46593172f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1312,6 +1312,7 @@ enum i915_power_well_id {
CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
CNL_DISP_PW_AUX_D,
+   CNL_DISP_PW_AUX_F,
 
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
@@ -5284,6 +5285,13 @@ enum {
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
 
+#define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
+#define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
+#define _DPF_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64518)
+#define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
+#define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
+#define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
@@ -6939,6 +6947,7 @@ enum {
 #define GEN8_DE_PORT_IMR _MMIO(0x4)
 #define GEN8_DE_PORT_IIR _MMIO(0x8)
 #define GEN8_DE_PORT_IER _MMIO(0xc)
+#define  CNL_AUX_CHANNEL_F (1 << 28)
 #define  GEN9_AUX_CHANNEL_D(1 << 27)
 #define  GEN9_AUX_CHANNEL_C(1 << 26)
 #define  GEN9_AUX_CHANNEL_B(1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index e47638931b51..30fa2041a45f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -172,6 +172,7 @@ enum 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev2)
URL   : https://patchwork.freedesktop.org/series/37148/
State : success

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:2678 pass:1668 dwarn:1   dfail:0   fail:20  skip:989 
time:11995s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:12054s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6658s
Blacklisted hosts:
shard-kbltotal:2825 pass:1854 dwarn:5   dfail:0   fail:22  skip:943 
time:9539s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7796/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/17] drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed

[James Ausmus]

On Tue, Jan 23, 2018 at 05:05:26PM -0200, Paulo Zanoni wrote:
> From: Mahesh Kumar 
> 
> ICL require DDB allocation of plane to be more than "minimum display
> buffer needed" for each level in order to enable WM level.
> 
> This patch implements and consider the same while allocating DDB
> and enabling WM.
> 
> Changes Since V1:
>  - rebase
> Changes Since V2:
>  - Remove extra parentheses
>  - Use FP16.16 only when absolutely necessary (Paulo)
> Changes Since V3:
>  - Rebase
> Changes since v4 (from Paulo)
>  - Coding style issue.
> 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Mahesh Kumar 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 44d952a3d9a6..c6d31a5075ad 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4510,6 +4510,7 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   struct intel_atomic_state *state =
>   to_intel_atomic_state(cstate->base.state);
>   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
> + uint32_t min_disp_buf_needed;
>  
>   if (latency == 0 ||
>   !intel_wm_plane_visible(cstate, intel_pstate)) {
> @@ -4568,7 +4569,34 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   }
>   }
>  
> - if (res_blocks >= ddb_allocation || res_lines > 31) {
> + if (INTEL_GEN(dev_priv) >= 11) {
> + if (wp->y_tiled) {
> + uint32_t extra_lines;
> + uint_fixed_16_16_t fp_min_disp_buf_needed;
> +
> + if (res_lines % wp->y_min_scanlines == 0)
> + extra_lines = wp->y_min_scanlines;
> + else
> + extra_lines = wp->y_min_scanlines * 2 -
> +   res_lines % wp->y_min_scanlines;
> +
> + fp_min_disp_buf_needed = mul_u32_fixed16(res_lines +
> + extra_lines,
> + wp->plane_blocks_per_line);
> + min_disp_buf_needed = fixed16_to_u32_round_up(
> + fp_min_disp_buf_needed);
> + } else {
> + min_disp_buf_needed = DIV_ROUND_UP(res_blocks * 11, 10);
> + }
> + } else {
> + /*
> +  * To enable a WM level ddb_allocation should be
> +  * greater than result blocks for GEN-9/10.
> +  */
> + min_disp_buf_needed = res_blocks + 1;
> + }
> +
> + if (min_disp_buf_needed > ddb_allocation || res_lines > 31) {
>   *enabled = false;
>  
>   /*
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Rafael Antognolli]

On Fri, Jan 26, 2018 at 11:17:01PM +, Chris Wilson wrote:
> Quoting Rafael Antognolli (2018-01-26 23:05:24)
> > This workaround should prevent a bug that can be hit on a context
> > restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall
> > (0x7a04 0x0010 0x 0x) followed by 12DW's of
> > NOOP(0x0) in the indirect context batch buffer, to ensure the engine is
> > idle prior to programming 3DSTATE_SAMPLE_PATTERN.
> > 
> > References: HSD#1939868
> > 
> >  v2:
> >- More descriptive changelog and comments.
> >- Fix math when counting dwords.
> > 
> > Signed-off-by: Rafael Antognolli 
> > Cc: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c | 34 +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 51e61b04a555..46c130d106d7 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1366,6 +1366,36 @@ static u32 *gen9_init_indirectctx_bb(struct 
> > intel_engine_cs *engine, u32 *batch)
> > return batch;
> >  }
> >  
> > +static u32 *gen10_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
> > *batch)
> > +{
> > +   int i;
> > +
> > +   /*
> > +* WaPipeControlBefore3DStateSamplePattern: cnl
> > +*
> > +* Ensure the engine is idle prior to programming a
> > +* 3DSTATE_SAMPLE_PATTERN during a context restore.
> > +*/
> > +   batch = gen8_emit_pipe_control(batch,
> > +  PIPE_CONTROL_CS_STALL,
> > +  0);
> > +   /*
> > +* WaPipeControlBefore3DStateSamplePattern says we need 4 dwords for
> > +* the PIPE_CONTROL followed by 12 dwords of 0x0, so 16 dwords in
> > +* total. Since gen8_emit_pipe_control() already advances the batch 
> > by
> > +* 6 dwords, we advance the other 10 here.
> > +*/
> > +   for (i = 0; i < 10; i++)
> > +   *batch++ = MI_NOOP;
> 
> If the spec says emit 12 nops, emit 12 nops. Otherwise if we add another
> w/a here it may break this magic.

So, in the bspec, there's the following text:

"The address above needs to be a GGTT address and contain a pipe control
with CS stall(0x7a04 0x0010 0x 0x)followed by
12DW’s of NOOP(0x)"

while on an internal ticket pointed by it, it is:

"The address above needs to be a GGTT address.. It would contain the
following value: 7A04 0010 followed by 14 DW’s of zero."

That's why I think it is really 16 DW's in total. And
gen8_emit_pipe_control() already emits 6 of them. How are we supposed to
emit 12 after that?

I don't know if they expect the pipe control to be cacheline aligned,
but I can ask and try to find out.

> I am not going to ask what the magic nops do, it just gives a 72 cycle
> delay in the CS parser. My guess is that they are trying to isolate a
> cacheline, in which case they are expecting the pipecontrol to be
> cacheline aligned. (I would get that clarified and add an assert to
> document such a requirement.) Or they just mean that the indirect ctx is
> cacheline aligned and the nops are just the normal padding and nothing
> to do with the w/a.
> 
> s/10/12/ here and tweak the comment to remove the assumed cacheline
> tail, but please see if someone can clarify if the nops are indeed part
> of the w/a or just the normal filler.
> With s/10/12/,
> Acked-by: Chris Wilson 
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev2)
URL   : https://patchwork.freedesktop.org/series/37148/
State : success

== Summary ==

Series 37148v2 drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern
https://patchwork.freedesktop.org/api/1.0/series/37148/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:490s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:294s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
7b8180832a9f drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7796/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/17] drm/i915/icl: implement the display init/uninit sequences

[James Ausmus]

On Tue, Jan 23, 2018 at 05:05:22PM -0200, Paulo Zanoni wrote:
> This code is similar enough to the CNL code that I considered just
> adding ICL support to the CNL function, but I think it's still
> different enough, and having a function specific to ICL allows us to
> more easily adapt code in case the spec changes more later.
> 
> We're still missing the power wells and the mbus code, so leave those
> pieces with a FIXME comment while they're not here yet.
> 
> v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits.
> 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 16 ++-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 82 
> -
>  2 files changed, 94 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ebf6261d30fd..979bc06a59f4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1904,6 +1904,11 @@ enum i915_power_well_id {
>  #define   CL_POWER_DOWN_ENABLE   (1 << 4)
>  #define   SUS_CLOCK_CONFIG   (3 << 0)
>  
> +#define _ICL_PORT_CL_DW5_A   0x162014
> +#define _ICL_PORT_CL_DW5_B   0x6C014
> +#define ICL_PORT_CL_DW5(port)_MMIO((port == PORT_A) ? \
> +   _ICL_PORT_CL_DW5_A : _ICL_PORT_CL_DW5_B)
> +
>  #define _PORT_CL1CM_DW9_A0x162024
>  #define _PORT_CL1CM_DW9_BC   0x6C024
>  #define   IREF0RC_OFFSET_SHIFT   8
> @@ -7126,8 +7131,9 @@ enum {
>  #define  RESET_PCH_HANDSHAKE_ENABLE  (1<<4)
>  
>  #define GEN8_CHICKEN_DCPR_1  _MMIO(0x46430)
> -#define   SKL_SELECT_ALTERNATE_DC_EXIT   (1<<30)
> -#define   MASK_WAKEMEM   (1<<13)
> +#define   SKL_SELECT_ALTERNATE_DC_EXIT   (1 << 30)
> +#define   MASK_WAKEMEM   (1 << 13)
> +#define   CNL_DDI_CLOCK_REG_ACCESS_ON(1 << 7)
>  
>  #define SKL_DFSM _MMIO(0x51000)
>  #define SKL_DFSM_CDCLK_LIMIT_MASK(3 << 23)
> @@ -9696,4 +9702,10 @@ enum skl_power_gate {
>  #define  MMCD_PCLA   (1 << 31)
>  #define  MMCD_HOTSPOT_EN (1 << 27)
>  
> +#define _ICL_PHY_MISC_A  0x64C00
> +#define _ICL_PHY_MISC_B  0x64C04
> +#define ICL_PHY_MISC(port)   _MMIO((port == PORT_A) ? \
> +   _ICL_PHY_MISC_A : _ICL_PHY_MISC_B)
> +#define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 73dd525d241a..2556db16c76a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2882,6 +2882,80 @@ static void cnl_display_core_uninit(struct 
> drm_i915_private *dev_priv)
>   I915_WRITE(CHICKEN_MISC_2, val);
>  }
>  
> +static void icl_display_core_init(struct drm_i915_private *dev_priv,
> +   bool resume)
> +{
> + enum port port;
> + u32 val;
> +
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
> + /* 1. Enable PCH reset handshake. */
> + val = I915_READ(HSW_NDE_RSTWRN_OPT);
> + val |= RESET_PCH_HANDSHAKE_ENABLE;
> + I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> +
> + for (port = PORT_A; port <= PORT_B; port++) {
> + /* 2. Enable DDI combo PHY comp. */
> + val = I915_READ(ICL_PHY_MISC(port));
> + val &= ~ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
> + I915_WRITE(ICL_PHY_MISC(port), val);
> +
> + cnl_set_procmon_ref_values(dev_priv, port);
> +
> + val = I915_READ(ICL_PORT_COMP_DW0(port));
> + val |= COMP_INIT;
> + I915_WRITE(ICL_PORT_COMP_DW0(port), val);
> +
> + /* 3. Set power down enable. */
> + val = I915_READ(ICL_PORT_CL_DW5(port));
> + val |= CL_POWER_DOWN_ENABLE;
> + I915_WRITE(ICL_PORT_CL_DW5(port), val);
> + }
> +
> + /* 4. Enable power well 1 (PG1) and aux IO power. */
> + /* FIXME: ICL power wells code not here yet. */
> +
> + /* 5. Enable CDCLK. */
> + icl_init_cdclk(dev_priv);
> +
> + /* 6. Enable DBUF. */
> + gen9_dbuf_enable(dev_priv);
> +
> + /* 7. Setup MBUS. */
> + /* FIXME: MBUS code not here yet. */
> +
> + /* 8. CHICKEN_DCPR_1 */
> + I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
> + CNL_DDI_CLOCK_REG_ACCESS_ON);
> +}
> +
> +static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
> +{
> + enum port port;
> + u32 val;
> +
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
> + /* 1. Disable all display engine functions -> aready done */
> +
> + /* 2. Disable DBUF */
> + gen9_dbuf_disable(dev_priv);
> +
> + /* 3. Disable CD clock */
> + 

Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Chris Wilson]

Quoting Rafael Antognolli (2018-01-26 23:05:24)
> This workaround should prevent a bug that can be hit on a context
> restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall
> (0x7a04 0x0010 0x 0x) followed by 12DW's of
> NOOP(0x0) in the indirect context batch buffer, to ensure the engine is
> idle prior to programming 3DSTATE_SAMPLE_PATTERN.
> 
> References: HSD#1939868
> 
>  v2:
>- More descriptive changelog and comments.
>- Fix math when counting dwords.
> 
> Signed-off-by: Rafael Antognolli 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 51e61b04a555..46c130d106d7 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1366,6 +1366,36 @@ static u32 *gen9_init_indirectctx_bb(struct 
> intel_engine_cs *engine, u32 *batch)
> return batch;
>  }
>  
> +static u32 *gen10_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
> *batch)
> +{
> +   int i;
> +
> +   /*
> +* WaPipeControlBefore3DStateSamplePattern: cnl
> +*
> +* Ensure the engine is idle prior to programming a
> +* 3DSTATE_SAMPLE_PATTERN during a context restore.
> +*/
> +   batch = gen8_emit_pipe_control(batch,
> +  PIPE_CONTROL_CS_STALL,
> +  0);
> +   /*
> +* WaPipeControlBefore3DStateSamplePattern says we need 4 dwords for
> +* the PIPE_CONTROL followed by 12 dwords of 0x0, so 16 dwords in
> +* total. Since gen8_emit_pipe_control() already advances the batch by
> +* 6 dwords, we advance the other 10 here.
> +*/
> +   for (i = 0; i < 10; i++)
> +   *batch++ = MI_NOOP;

If the spec says emit 12 nops, emit 12 nops. Otherwise if we add another
w/a here it may break this magic.

I am not going to ask what the magic nops do, it just gives a 72 cycle
delay in the CS parser. My guess is that they are trying to isolate a
cacheline, in which case they are expecting the pipecontrol to be
cacheline aligned. (I would get that clarified and add an assert to
document such a requirement.) Or they just mean that the indirect ctx is
cacheline aligned and the nops are just the normal padding and nothing
to do with the w/a.

s/10/12/ here and tweak the comment to remove the assumed cacheline
tail, but please see if someone can clarify if the nops are indeed part
of the w/a or just the normal filler.
With s/10/12/,
Acked-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

[James Ausmus]

On Tue, Jan 23, 2018 at 05:05:20PM -0200, Paulo Zanoni wrote:
> This commit adds the basic CDCLK functions, but it's still missing
> pieces of the display initialization sequence.
> 
> v2:
>  - Implement the voltage levels.
>  - Rebase.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  10 +-
>  drivers/gpu/drm/i915/intel_cdclk.c | 253 
> -
>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>  3 files changed, 261 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index abd9ee876186..d72e206b2b9f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7113,8 +7113,12 @@ enum {
>  #define SKL_DFSM_PIPE_B_DISABLE  (1 << 21)
>  #define SKL_DFSM_PIPE_C_DISABLE  (1 << 28)
>  
> -#define SKL_DSSM _MMIO(0x51004)
> -#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define SKL_DSSM _MMIO(0x51004)
> +#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK   (7 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz  (0 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz(1 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz(2 << 29)
>  
>  #define GEN7_FF_SLICE_CS_CHICKEN1_MMIO(0x20e0)
>  #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL  (1<<14)
> @@ -8760,6 +8764,8 @@ enum skl_power_gate {
>  #define  BXT_CDCLK_CD2X_PIPE_NONEBXT_CDCLK_CD2X_PIPE(3)
>  #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE  (1<<16)
>  #define  CDCLK_FREQ_DECIMAL_MASK (0x7ff)
> +#define  ICL_CDCLK_CD2X_PIPE(pipe)   ((pipe) << 19)

This isn't right - pipe A is (0 << 19), but pipe B is (2 << 19), and C
is (6 << 19).

> +#define  ICL_CDCLK_CD2X_PIPE_NONEICL_CDCLK_CD2X_PIPE(7)
>  
>  /* LCPLL_CTL */
>  #define LCPLL1_CTL   _MMIO(0x46010)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index c4392ea34a3d..d867956d5a9f 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1766,6 +1766,215 @@ static void cnl_sanitize_cdclk(struct 
> drm_i915_private *dev_priv)
>   dev_priv->cdclk.hw.vco = -1;
>  }
>  
> +static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> +{
> + int ranges_24[] = { 312000, 552000, 648000 };
> + int ranges_19_38[] = { 307200, 556800, 652800 };
> + int *ranges;
> +
> + switch (ref) {
> + default:
> + MISSING_CASE(ref);
> + case 24000:
> + ranges = ranges_24;
> + break;
> + case 19200:
> + case 38400:
> + ranges = ranges_19_38;
> + break;
> + }
> +
> + if (min_cdclk > ranges[1])
> + return ranges[2];
> + else if (min_cdclk > ranges[0])
> + return ranges[1];
> + else
> + return ranges[0];
> +}
> +
> +static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int 
> cdclk)
> +{
> + int ratio;
> +
> + /* 50MHz == CDCLK PLL disabled. */
> + if (cdclk == 5)
> + return 0;
> +
> + switch (cdclk) {
> + default:
> + MISSING_CASE(cdclk);
> + case 307200:
> + case 556800:
> + case 652800:
> + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> + dev_priv->cdclk.hw.ref != 38400);
> + break;
> + case 312000:
> + case 552000:
> + case 648000:
> + WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> + }
> +
> + ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> +
> + return dev_priv->cdclk.hw.ref * ratio;
> +}
> +
> +static void icl_set_cdclk(struct drm_i915_private *dev_priv,
> +   const struct intel_cdclk_state *cdclk_state)
> +{
> + unsigned int cdclk = cdclk_state->cdclk;
> + unsigned int vco = cdclk_state->vco;
> + int ret;
> + u32 voltage_level;
> +
> + mutex_lock(_priv->pcu_lock);
> + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE, 3);
> + mutex_unlock(_priv->pcu_lock);
> + if (ret) {
> + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> +   ret);
> + return;
> + }
> +
> + /* FIXME: We should also consider the DDI clock here. */
> + switch (cdclk) {
> + case 307200:
> + case 312000:
> + voltage_level = 0;
> + break;
> + case 556800:
> + case 552000:
> + voltage_level = 1;
> + break;
> + default:
> + MISSING_CASE(cdclk);
> + case 652800:
> + case 648000:
> + voltage_level = 2;
> + break;
> + }
> +
> 

[Intel-gfx] [PATCH v2] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Rafael Antognolli]

This workaround should prevent a bug that can be hit on a context
restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall
(0x7a04 0x0010 0x 0x) followed by 12DW's of
NOOP(0x0) in the indirect context batch buffer, to ensure the engine is
idle prior to programming 3DSTATE_SAMPLE_PATTERN.

References: HSD#1939868

 v2:
   - More descriptive changelog and comments.
   - Fix math when counting dwords.

Signed-off-by: Rafael Antognolli 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 51e61b04a555..46c130d106d7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1366,6 +1366,36 @@ static u32 *gen9_init_indirectctx_bb(struct 
intel_engine_cs *engine, u32 *batch)
return batch;
 }
 
+static u32 *gen10_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
*batch)
+{
+   int i;
+
+   /*
+* WaPipeControlBefore3DStateSamplePattern: cnl
+*
+* Ensure the engine is idle prior to programming a
+* 3DSTATE_SAMPLE_PATTERN during a context restore.
+*/
+   batch = gen8_emit_pipe_control(batch,
+  PIPE_CONTROL_CS_STALL,
+  0);
+   /*
+* WaPipeControlBefore3DStateSamplePattern says we need 4 dwords for
+* the PIPE_CONTROL followed by 12 dwords of 0x0, so 16 dwords in
+* total. Since gen8_emit_pipe_control() already advances the batch by
+* 6 dwords, we advance the other 10 here.
+*/
+   for (i = 0; i < 10; i++)
+   *batch++ = MI_NOOP;
+
+   /* Pad to end of cacheline */
+   while ((unsigned long)batch % CACHELINE_BYTES)
+   *batch++ = MI_NOOP;
+
+   return batch;
+}
+
+
 #define CTX_WA_BB_OBJ_SIZE (PAGE_SIZE)
 
 static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
@@ -1419,7 +1449,9 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 
switch (INTEL_GEN(engine->i915)) {
case 10:
-   return 0;
+   wa_bb_fn[0] = gen10_init_indirectctx_bb;
+   wa_bb_fn[1] = NULL;
+   break;
case 9:
wa_bb_fn[0] = gen9_init_indirectctx_bb;
wa_bb_fn[1] = NULL;
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Imre Deak]

On Fri, Jan 26, 2018 at 02:06:23PM -0800, Rodrigo Vivi wrote:
> On Fri, Jan 26, 2018 at 09:39:42PM +, Pandiyan, Dhinakaran wrote:
> > 
> > On Thu, 2018-01-25 at 14:03 -0800, Rodrigo Vivi wrote:
> > > Now let's finish the Port-F support by adding the
> > > proper port F detection, irq and power well support.
> > > 
> > > v2: Rebase
> > > v3: Use BIT_ULL
> > > v4: Cover missed case on ddi init.
> > > v5: Update commit message.
> > > v6: Rebase on top of display headers rework.
> > > v7: Squash power-well handling related to DDI F to this
> > > patch to avoid warns as pointed out by DK.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Manasi Navare 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h |  2 ++
> > >  drivers/gpu/drm/i915/intel_ddi.c|  4 
> > >  drivers/gpu/drm/i915/intel_display.c|  6 +-
> > >  drivers/gpu/drm/i915/intel_display.h|  2 ++
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
> > >  5 files changed, 29 insertions(+), 4 deletions(-)
> > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.h 
> > > b/drivers/gpu/drm/i915/intel_display.h
> > > index 30fa2041a45f..c4042e342f50 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > @@ -157,11 +157,13 @@ enum intel_display_power_domain {
> > >   POWER_DOMAIN_PORT_DDI_C_LANES,
> > >   POWER_DOMAIN_PORT_DDI_D_LANES,
> > >   POWER_DOMAIN_PORT_DDI_E_LANES,
> > > + POWER_DOMAIN_PORT_DDI_F_LANES,
> > 
> > What well does this need? {B,C,D}_LANES all enable/disable power well 2
> > from what I can tell. I don't see a
> > BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) in this patch.
> 
> indeed. They need to be added along with other *DDI_{B,C,D}_LANES on
> CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS.
> 
> > 
> > >   POWER_DOMAIN_PORT_DDI_A_IO,
> > >   POWER_DOMAIN_PORT_DDI_B_IO,
> > >   POWER_DOMAIN_PORT_DDI_C_IO,
> > >   POWER_DOMAIN_PORT_DDI_D_IO,
> > >   POWER_DOMAIN_PORT_DDI_E_IO,
> > > + POWER_DOMAIN_PORT_DDI_F_IO,
> > >   POWER_DOMAIN_PORT_DSI,
> > >   POWER_DOMAIN_PORT_CRT,
> > >   POWER_DOMAIN_PORT_OTHER,
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 3526b563b8ec..30e50ea16960 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -94,6 +94,8 @@ intel_display_power_domain_str(enum 
> > > intel_display_power_domain domain)
> > >   return "PORT_DDI_D_LANES";
> > >   case POWER_DOMAIN_PORT_DDI_E_LANES:
> > >   return "PORT_DDI_E_LANES";
> > > + case POWER_DOMAIN_PORT_DDI_F_LANES:
> > > + return "PORT_DDI_F_LANES";
> > >   case POWER_DOMAIN_PORT_DDI_A_IO:
> > >   return "PORT_DDI_A_IO";
> > >   case POWER_DOMAIN_PORT_DDI_B_IO:
> > > @@ -104,6 +106,8 @@ intel_display_power_domain_str(enum 
> > > intel_display_power_domain domain)
> > >   return "PORT_DDI_D_IO";
> > >   case POWER_DOMAIN_PORT_DDI_E_IO:
> > >   return "PORT_DDI_E_IO";
> > > + case POWER_DOMAIN_PORT_DDI_F_IO:
> > > + return "PORT_DDI_F_IO";
> > >   case POWER_DOMAIN_PORT_DSI:
> > >   return "PORT_DSI";
> > >   case POWER_DOMAIN_PORT_CRT:
> > > @@ -1860,6 +1864,9 @@ void intel_display_power_put(struct 
> > > drm_i915_private *dev_priv,
> > >  #define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
> > >   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> > >   BIT_ULL(POWER_DOMAIN_INIT))
> > > +#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS ( \
> > > + BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
> > > + BIT_ULL(POWER_DOMAIN_INIT))
> > >  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> > >   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > >   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > > @@ -2411,6 +2418,12 @@ static struct i915_power_well cnl_power_wells[] = {
> > >   .id = SKL_DISP_PW_DDI_D,
> > >   },
> > >   {
> > > + .name = "DDI F IO power well",
> > > + .domains = CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS,
> > > + .ops = _power_well_ops,
> > > + .id = CNL_DISP_PW_DDI_F,
> > > + },
> > 
> > Again same question about the enabling order, can this be enabled after
> > power well2? 
> 
> Ok, now I see your question from another angle.
> 
> I hope it works or the proposed solution for power well won't work at all.
> 
> I can't recall anywhere on the spec where this order should matter. Imre?

The order shouldn't matter. The BSpec AUX programming lists the
dependencies in the AUX->PW#2 order. OTOH PW#2 could be already enabled
due to any external port being active at the time we want to enable AUX.
So what matters is that both PWs are enabled before starting the AUX
transfer.

> 
> If the order matters somehow we will need to bring 

[Intel-gfx] ✗ Fi.CI.IGT: failure for include: Move ascii85 functions from i915 to linux/ascii85.h

[Patchwork]

== Series Details ==

Series: include: Move ascii85 functions from i915 to linux/ascii85.h
URL   : https://patchwork.freedesktop.org/series/37211/
State : failure

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:21  skip:1064 
time:12674s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:12105s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6663s
Blacklisted hosts:
shard-kbltotal:2807 pass:1841 dwarn:1   dfail:0   fail:21  skip:942 
time:9314s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7795/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Rodrigo Vivi]

On Fri, Jan 26, 2018 at 09:39:42PM +, Pandiyan, Dhinakaran wrote:
> 
> On Thu, 2018-01-25 at 14:03 -0800, Rodrigo Vivi wrote:
> > Now let's finish the Port-F support by adding the
> > proper port F detection, irq and power well support.
> > 
> > v2: Rebase
> > v3: Use BIT_ULL
> > v4: Cover missed case on ddi init.
> > v5: Update commit message.
> > v6: Rebase on top of display headers rework.
> > v7: Squash power-well handling related to DDI F to this
> > patch to avoid warns as pointed out by DK.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Manasi Navare 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h |  2 ++
> >  drivers/gpu/drm/i915/intel_ddi.c|  4 
> >  drivers/gpu/drm/i915/intel_display.c|  6 +-
> >  drivers/gpu/drm/i915/intel_display.h|  2 ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
> >  5 files changed, 29 insertions(+), 4 deletions(-)
> 
> > diff --git a/drivers/gpu/drm/i915/intel_display.h 
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 30fa2041a45f..c4042e342f50 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -157,11 +157,13 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_PORT_DDI_C_LANES,
> > POWER_DOMAIN_PORT_DDI_D_LANES,
> > POWER_DOMAIN_PORT_DDI_E_LANES,
> > +   POWER_DOMAIN_PORT_DDI_F_LANES,
> 
> What well does this need? {B,C,D}_LANES all enable/disable power well 2
> from what I can tell. I don't see a
> BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) in this patch.

indeed. They need to be added along with other *DDI_{B,C,D}_LANES on
CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS.

> 
> > POWER_DOMAIN_PORT_DDI_A_IO,
> > POWER_DOMAIN_PORT_DDI_B_IO,
> > POWER_DOMAIN_PORT_DDI_C_IO,
> > POWER_DOMAIN_PORT_DDI_D_IO,
> > POWER_DOMAIN_PORT_DDI_E_IO,
> > +   POWER_DOMAIN_PORT_DDI_F_IO,
> > POWER_DOMAIN_PORT_DSI,
> > POWER_DOMAIN_PORT_CRT,
> > POWER_DOMAIN_PORT_OTHER,
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 3526b563b8ec..30e50ea16960 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -94,6 +94,8 @@ intel_display_power_domain_str(enum 
> > intel_display_power_domain domain)
> > return "PORT_DDI_D_LANES";
> > case POWER_DOMAIN_PORT_DDI_E_LANES:
> > return "PORT_DDI_E_LANES";
> > +   case POWER_DOMAIN_PORT_DDI_F_LANES:
> > +   return "PORT_DDI_F_LANES";
> > case POWER_DOMAIN_PORT_DDI_A_IO:
> > return "PORT_DDI_A_IO";
> > case POWER_DOMAIN_PORT_DDI_B_IO:
> > @@ -104,6 +106,8 @@ intel_display_power_domain_str(enum 
> > intel_display_power_domain domain)
> > return "PORT_DDI_D_IO";
> > case POWER_DOMAIN_PORT_DDI_E_IO:
> > return "PORT_DDI_E_IO";
> > +   case POWER_DOMAIN_PORT_DDI_F_IO:
> > +   return "PORT_DDI_F_IO";
> > case POWER_DOMAIN_PORT_DSI:
> > return "PORT_DSI";
> > case POWER_DOMAIN_PORT_CRT:
> > @@ -1860,6 +1864,9 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> >  #define CNL_DISPLAY_AUX_F_POWER_DOMAINS (  \
> > BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > +#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS (   \
> > +   BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
> > +   BIT_ULL(POWER_DOMAIN_INIT))
> >  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > @@ -2411,6 +2418,12 @@ static struct i915_power_well cnl_power_wells[] = {
> > .id = SKL_DISP_PW_DDI_D,
> > },
> > {
> > +   .name = "DDI F IO power well",
> > +   .domains = CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS,
> > +   .ops = _power_well_ops,
> > +   .id = CNL_DISP_PW_DDI_F,
> > +   },
> 
> Again same question about the enabling order, can this be enabled after
> power well2? 

Ok, now I see your question from another angle.

I hope it works or the proposed solution for power well won't work at all.

I can't recall anywhere on the spec where this order should matter. Imre?

If the order matters somehow we will need to bring the old patches back to
add the full definition of wells. So I hope we don't need that.

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

Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

@@ -870,7 +895,8 @@ static void execlists_submission_tasklet(unsigned long data)
 GEM_BUG_ON(status & GEN8_CTX_STATUS_IDLE_ACTIVE);
  
 if (status & GEN8_CTX_STATUS_COMPLETE &&

-   buf[2*head + 1] == PREEMPT_ID) {
+   HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
+   buf[2*head + 1] == 
upper_32_bits(preempt_ce->lrc_desc)) {


buf[2*head + 1] == execlists->preempt_status_complete

No need for HAS_LOGICAL_RING_PREEMPTION as you can then set to an
impossible value. If you want to send that as a bug fix patch first...
-Chris



Unless I'm missing something this isn't a bug pre-gen11 since we always 
allocate the preempt context and thus we can't erroneously match 
PREEMPT_ID. lrc_desc is only created after pinning, so to use that the 
extra check was required. I'll add execlists->preempt_status_complete 
(and the other change for the commit_reg) to this patch.


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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Rodrigo Vivi]

On Fri, Jan 26, 2018 at 09:27:41PM +, Pandiyan, Dhinakaran wrote:
> 
> On Fri, 2018-01-26 at 09:15 -0800, Rodrigo Vivi wrote:
> > On some Cannonlake SKUs we have a dedicated Aux for port F,
> > that is only the full split between port A and port E.
> > 
> > There is still no Aux E for Port E, as in previous platforms,
> > because port_E still means shared lanes with port A.
> > 
> > v2: Rebase.
> > v3: Add couple missed PORT_F cases on intel_dp.
> > v4: Rebase and fix commit message.
> > v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> > v6: Rebase on top of display headers rework.
> > v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> > v8: Fix Aux bits for Port F (DK)
> > v9: Fix VBT definition of Port F (DK).
> > v10: Squash power well addition to this patch to avoid
> >  warns as pointed by DK.
> > v11: Clean up squashed commit message. (David)
> > 
> > Cc: David Weinehall 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Lucas De Marchi 
> > Cc: Imre Deak 
> > Cc: Manasi Navare 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Rodrigo Vivi 
> > Reviewed-by: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c |  6 ++
> >  drivers/gpu/drm/i915/i915_reg.h |  9 +
> >  drivers/gpu/drm/i915/intel_display.h|  1 +
> >  drivers/gpu/drm/i915/intel_dp.c |  8 
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +
> >  6 files changed, 46 insertions(+)
> 
> 
> 
> > @@ -1342,6 +1345,7 @@ static i915_reg_t g4x_aux_ctl_reg(struct 
> > drm_i915_private *dev_priv,
> > case PORT_B:
> > case PORT_C:
> > case PORT_D:
> > +   case PORT_F:
> > return DP_AUX_CH_CTL(port);
> > default:
> > MISSING_CASE(port);
> > @@ -1356,6 +1360,7 @@ static i915_reg_t g4x_aux_data_reg(struct 
> > drm_i915_private *dev_priv,
> > case PORT_B:
> > case PORT_C:
> > case PORT_D:
> > +   case PORT_F:
> > return DP_AUX_CH_DATA(port, index);
> 
> I pointed this out in the last review, but it must have got lost among
> other comments and code.
> Why are these hunks needed? skl_aux_data_reg and skl_aux_ctl_reg already
> have the necessary changes and the gfx_ variants won't get called for
> INTEL_GEN >= 9

I missed those, but you are right.
yet another v comming without this...

> 
> 
> 
> > @@ -1855,6 +1857,9 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> >  #define CNL_DISPLAY_AUX_D_POWER_DOMAINS (  \
> > BIT_ULL(POWER_DOMAIN_AUX_D) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > +#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (  \
> > +   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> > +   BIT_ULL(POWER_DOMAIN_INIT))
> >  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> 
> 
> Why is BIT_ULL(POWER_DOMAIN_AUX_F) not included in
> CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS, while POWER_DOMAIN_AUX_B,
> POWER_DOMAIN_AUX_C and POWER_DOMAIN_AUX_D are?
> 
> If I understand this correctly, power_get(AUX_B) would
> enable both AUX_B powerwell and powerwell 2. 
> 
> But, power_get(AUX_F) would just enable AUX_F.
> 
> I don't see anything in the spec justifies why AUX_F should be treated
> differently.

agree. Shouldn't be different.
I will fix.

> 
> 
> 
> > @@ -2405,6 +2410,12 @@ static struct i915_power_well cnl_power_wells[] = {
> > .ops = _power_well_ops,
> > .id = SKL_DISP_PW_DDI_D,
> > },
> > +   {
> > +   .name = "AUX F",
> > +   .domains = CNL_DISPLAY_AUX_F_POWER_DOMAINS,
> > +   .ops = _power_well_ops,
> > +   .id = CNL_DISP_PW_AUX_F,
> > +   },
> 
> I wonder if placing AUX_F after dc_off and power well 2 has any impact.
> Is there an expected order that the hardware requires us to power these
> wells? For e.g, is it okay to enable power well 2 before enabling
> AUX_F?

The other matters now. That's how we are removing from the list
for platforms without port_f... array_size - 1. (-2 on the next that adds ddi 
one)

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

Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/icl: Enhanced execution list support

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-01-26 18:31:25)
> From: Thomas Daniel 
> 
> Enhanced Execlists is an upgraded version of execlists which supports
> up to 8 ports. The lrcs to be submitted are written to a submit queue
> (the ExecLists Submission Queue - ELSQ), which is then loaded on the
> HW. When writing to the ELSP register, the lrcs are written cyclically
> in the queue from position 0 to position 7. Alternatively, it is
> possible to write directly in the individual positions of the queue
> using the ELSQC registers. To be able to re-use all the existing code
> we're using the latter method and we're currently limiting ourself to
> only using 2 elements.
> 
> v2: Rebase.
> v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
> v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
> v5: Reword commit, rename regs to be closer to specs, turn off
> preemption (Daniele), reuse engine->execlists.elsp (Chris)
> v6: use has_logical_ring_elsq to differentiate the new paths
> v7: add preemption support, rename els to submit_reg (Chris)
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/i915_pci.c  |  3 +-
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  drivers/gpu/drm/i915/intel_lrc.c | 52 
> +---
>  drivers/gpu/drm/i915/intel_lrc.h |  3 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 ++--
>  6 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f48a8ee..0493b4b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2743,6 +2743,8 @@ static inline unsigned int i915_sg_segment_size(void)
>  
>  #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
> ((dev_priv)->info.has_logical_ring_contexts)
> +#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
> +   ((dev_priv)->info.has_logical_ring_elsq)
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> ((dev_priv)->info.has_logical_ring_preemption)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f28c165..6c86cba 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -583,7 +583,8 @@
> GEN10_FEATURES, \
> .gen = 11, \
> .ddb_size = 2048, \
> -   .has_csr = 0
> +   .has_csr = 0, \
> +   .has_logical_ring_elsq = 1
>  
>  static const struct intel_device_info intel_icelake_11_info __initconst = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 9542018..dbf0f2d 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -96,6 +96,7 @@ enum intel_platform {
> func(has_l3_dpf); \
> func(has_llc); \
> func(has_logical_ring_contexts); \
> +   func(has_logical_ring_elsq); \
> func(has_logical_ring_preemption); \
> func(has_overlay); \
> func(has_pooled_eu); \
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ac78fc2..6c7b9c3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -400,17 +400,29 @@ static u64 execlists_update_context(struct 
> drm_i915_gem_request *rq)
> return ce->lrc_desc;
>  }
>  
> -static inline void elsp_write(u64 desc, u32 __iomem *elsp)
> +static inline void write_desc(struct intel_engine_cs *engine, u64 desc, u32 
> port)
>  {
> -   writel(upper_32_bits(desc), elsp);
> -   writel(lower_32_bits(desc), elsp);
> +   if (HAS_LOGICAL_RING_ELSQ(engine->i915)) {
> +   writel(lower_32_bits(desc), engine->execlists.submit_reg + 
> port * 2);
> +   writel(upper_32_bits(desc), engine->execlists.submit_reg + 
> port * 2 + 1);
> +   } else {
> +   writel(upper_32_bits(desc), engine->execlists.submit_reg);
> +   writel(lower_32_bits(desc), engine->execlists.submit_reg);
> +   }
>  }
>  
>  static void execlists_submit_ports(struct intel_engine_cs *engine)
>  {
> +   struct drm_i915_private *dev_priv = engine->i915;
> struct execlist_port *port = engine->execlists.port;
> unsigned int n;
>  
> +   /*
> +* ELSQ note: the submit queue is not cleared after being submitted
> +* to the HW so we need to make sure we always clean it up. This is
> +* currently ensured by the fact that we always write the same number
> +* of elsq entries, keep this in mind before changing the loop 

Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Pandiyan, Dhinakaran]

On Thu, 2018-01-25 at 14:03 -0800, Rodrigo Vivi wrote:
> Now let's finish the Port-F support by adding the
> proper port F detection, irq and power well support.
> 
> v2: Rebase
> v3: Use BIT_ULL
> v4: Cover missed case on ddi init.
> v5: Update commit message.
> v6: Rebase on top of display headers rework.
> v7: Squash power-well handling related to DDI F to this
> patch to avoid warns as pointed out by DK.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c|  4 
>  drivers/gpu/drm/i915/intel_display.c|  6 +-
>  drivers/gpu/drm/i915/intel_display.h|  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
>  5 files changed, 29 insertions(+), 4 deletions(-)

> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index 30fa2041a45f..c4042e342f50 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -157,11 +157,13 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_PORT_DDI_C_LANES,
>   POWER_DOMAIN_PORT_DDI_D_LANES,
>   POWER_DOMAIN_PORT_DDI_E_LANES,
> + POWER_DOMAIN_PORT_DDI_F_LANES,

What well does this need? {B,C,D}_LANES all enable/disable power well 2
from what I can tell. I don't see a
BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) in this patch.

>   POWER_DOMAIN_PORT_DDI_A_IO,
>   POWER_DOMAIN_PORT_DDI_B_IO,
>   POWER_DOMAIN_PORT_DDI_C_IO,
>   POWER_DOMAIN_PORT_DDI_D_IO,
>   POWER_DOMAIN_PORT_DDI_E_IO,
> + POWER_DOMAIN_PORT_DDI_F_IO,
>   POWER_DOMAIN_PORT_DSI,
>   POWER_DOMAIN_PORT_CRT,
>   POWER_DOMAIN_PORT_OTHER,
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 3526b563b8ec..30e50ea16960 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -94,6 +94,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "PORT_DDI_D_LANES";
>   case POWER_DOMAIN_PORT_DDI_E_LANES:
>   return "PORT_DDI_E_LANES";
> + case POWER_DOMAIN_PORT_DDI_F_LANES:
> + return "PORT_DDI_F_LANES";
>   case POWER_DOMAIN_PORT_DDI_A_IO:
>   return "PORT_DDI_A_IO";
>   case POWER_DOMAIN_PORT_DDI_B_IO:
> @@ -104,6 +106,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "PORT_DDI_D_IO";
>   case POWER_DOMAIN_PORT_DDI_E_IO:
>   return "PORT_DDI_E_IO";
> + case POWER_DOMAIN_PORT_DDI_F_IO:
> + return "PORT_DDI_F_IO";
>   case POWER_DOMAIN_PORT_DSI:
>   return "PORT_DSI";
>   case POWER_DOMAIN_PORT_CRT:
> @@ -1860,6 +1864,9 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  #define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
>   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> +#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
>  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
>   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> @@ -2411,6 +2418,12 @@ static struct i915_power_well cnl_power_wells[] = {
>   .id = SKL_DISP_PW_DDI_D,
>   },
>   {
> + .name = "DDI F IO power well",
> + .domains = CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS,
> + .ops = _power_well_ops,
> + .id = CNL_DISP_PW_DDI_F,
> + },

Again same question about the enabling order, can this be enabled after
power well2? 


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

Re: [Intel-gfx] [PATCH igt 2/2] igt/kms_frontbuffer_tracking: Bump the wait time for FBC

[Chris Wilson]

Quoting Chris Wilson (2018-01-25 21:28:49)
> It is taking longer than a couple of seconds for the FBC worker to be
> executed after scheduling; and then will take a minimum of a vblank
> interval for it activate. So wait longer to reduce the flip flops.
> 
> Signed-off-by: Chris Wilson 

Any acks?

> ---
>  tests/kms_frontbuffer_tracking.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c 
> b/tests/kms_frontbuffer_tracking.c
> index 79e4f5862..fb5627535 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -920,7 +920,7 @@ static bool fbc_stride_not_supported(void)
>  
>  static bool fbc_wait_until_enabled(void)
>  {
> -   return igt_wait(fbc_is_enabled(IGT_LOG_DEBUG), 2000, 1);
> +   return igt_wait(fbc_is_enabled(IGT_LOG_DEBUG), 5000, 8);
>  }
>  
>  static bool psr_wait_until_enabled(void)
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 1/2] lib: Refactor igt_wait() to use library timers

[Chris Wilson]

Quoting Antonio Argenziano (2018-01-26 16:50:15)
> 
> 
> On 25/01/18 13:28, Chris Wilson wrote:
> > Use the timer routines for computing elapsed time from igt_core for
> > smaller code.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   lib/igt_aux.h | 25 +++--
> >   1 file changed, 11 insertions(+), 14 deletions(-)
> > 
> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> > index 02e70126c..48ba7970f 100644
> > --- a/lib/igt_aux.h
> > +++ b/lib/igt_aux.h
> > @@ -29,6 +29,7 @@
> >   #define IGT_AUX_H
> >   
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -251,28 +252,24 @@ void igt_unlock_mem(void);
> >* True of COND evaluated to true, false otherwise.
> >*/
> >   #define igt_wait(COND, timeout_ms, interval_ms) ({  \
> > - struct timeval start_, end_, diff_; \
> > - int elapsed_ms_;\
> > - bool ret_ = false;  \
> > + struct timespec tv = {};\
> > + bool ret_;  \
> >   \
> > - igt_assert(gettimeofday(_, NULL) == 0);   \
> >   do {\
> > + uint64_t elapsed = igt_nsec_elapsed() >> 20; \
> 
> Maybe tv_ and elapsed_ just for consistency.
> 
> Reviewed-by: Antonio Argenziano 

Corrected and pushed, thanks!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: only assign dev_priv->pch_id on successful pch detection

[Chris Wilson]

Quoting David Weinehall (2018-01-26 15:53:53)
> On Fri, Jan 26, 2018 at 04:48:05PM +0200, Jani Nikula wrote:
> > Currently pch_id gets assigned also when there's no pch. It doesn't look
> > like it makes a difference, but do the right thing anyway.
> 
> Makes sense.
> 
> Reviewed-by: David Weinehall 

I suspect this is the one that upset gvt.
 
> > Signed-off-by: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 3e8664de025d..0332e315650c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -183,8 +183,6 @@ static void intel_detect_pch(struct drm_i915_private 
> > *dev_priv)
> >  
> >   id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >  
> > - dev_priv->pch_id = id;
> > -
> >   if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >   dev_priv->pch_type = PCH_IBX;
> >   DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> > @@ -272,6 +270,8 @@ static void intel_detect_pch(struct drm_i915_private 
> > *dev_priv)
> >   continue;
> >   }
> >  
> > + dev_priv->pch_id = id;
> > +
> >   break;
> >   }
> >   if (!pch)
> > -- 
> > 2.11.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Pandiyan, Dhinakaran]

On Fri, 2018-01-26 at 09:15 -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
> 
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
> 
> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> v8: Fix Aux bits for Port F (DK)
> v9: Fix VBT definition of Port F (DK).
> v10: Squash power well addition to this patch to avoid
>  warns as pointed by DK.
> v11: Clean up squashed commit message. (David)
> 
> Cc: David Weinehall 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c |  6 ++
>  drivers/gpu/drm/i915/i915_reg.h |  9 +
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_dp.c |  8 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +
>  6 files changed, 46 insertions(+)



> @@ -1342,6 +1345,7 @@ static i915_reg_t g4x_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_CTL(port);
>   default:
>   MISSING_CASE(port);
> @@ -1356,6 +1360,7 @@ static i915_reg_t g4x_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_DATA(port, index);

I pointed this out in the last review, but it must have got lost among
other comments and code.
Why are these hunks needed? skl_aux_data_reg and skl_aux_ctl_reg already
have the necessary changes and the gfx_ variants won't get called for
INTEL_GEN >= 9



> @@ -1855,6 +1857,9 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  #define CNL_DISPLAY_AUX_D_POWER_DOMAINS (\
>   BIT_ULL(POWER_DOMAIN_AUX_D) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> +#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
> + BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
>  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
>   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \


Why is BIT_ULL(POWER_DOMAIN_AUX_F) not included in
CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS, while POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C and POWER_DOMAIN_AUX_D are?

If I understand this correctly, power_get(AUX_B) would
enable both AUX_B powerwell and powerwell 2. 

But, power_get(AUX_F) would just enable AUX_F.

I don't see anything in the spec justifies why AUX_F should be treated
differently.



> @@ -2405,6 +2410,12 @@ static struct i915_power_well cnl_power_wells[] = {
>   .ops = _power_well_ops,
>   .id = SKL_DISP_PW_DDI_D,
>   },
> + {
> + .name = "AUX F",
> + .domains = CNL_DISPLAY_AUX_F_POWER_DOMAINS,
> + .ops = _power_well_ops,
> + .id = CNL_DISP_PW_AUX_F,
> + },

I wonder if placing AUX_F after dc_off and power well 2 has any impact.
Is there an expected order that the hardware requires us to power these
wells? For e.g, is it okay to enable power well 2 before enabling
AUX_F? 


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

[Intel-gfx] ✓ Fi.CI.BAT: success for include: Move ascii85 functions from i915 to linux/ascii85.h

[Patchwork]

== Series Details ==

Series: include: Move ascii85 functions from i915 to linux/ascii85.h
URL   : https://patchwork.freedesktop.org/series/37211/
State : success

== Summary ==

Series 37211v1 include: Move ascii85 functions from i915 to linux/ascii85.h
https://patchwork.freedesktop.org/api/1.0/series/37211/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:463s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:461s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:408s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
f8cd6a723439 include: Move ascii85 functions from i915 to linux/ascii85.h

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7795/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] include: Move ascii85 functions from i915 to linux/ascii85.h

[Chris Wilson]

Quoting Jordan Crouse (2018-01-26 20:59:22)
> The i915 DRM driver very cleverly used ascii85 encoding for their

All gfx drivers must eventually become PostScript.

> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
> 
> Signed-off-by: Jordan Crouse 
> ---
> diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
> new file mode 100644
> index 000..7ee39f9
> --- /dev/null
> +++ b/include/linux/ascii85.h
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright (c) 2008 Intel Corporation

Just cut this down to
/*
 * SPDX-License-Identifier: GPL-2.0
 *
 * Copyright (c) 2008 Intel Corporation
 * Copyright (c) 2018 My Name Here
 */

Fortunately ideas themselves are not copyrightable, otherwise Adobe has
a strong claim to ownership.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] include: Move ascii85 functions from i915 to linux/ascii85.h

[Chris Wilson]

Quoting Jordan Crouse (2018-01-26 20:59:22)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
> 
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/i915/i915_gpu_error.c | 24 +---
>  include/linux/ascii85.h   | 52 
> +++
>  2 files changed, 53 insertions(+), 23 deletions(-)
>  create mode 100644 include/linux/ascii85.h
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 48418fb..2588f37 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_drv.h"
>  
> @@ -501,29 +502,6 @@ void i915_error_printf(struct drm_i915_error_state_buf 
> *e, const char *f, ...)
> va_end(args);
>  }
>  
> -static int
> -ascii85_encode_len(int len)
> -{
> -   return DIV_ROUND_UP(len, 4);
> -}
> -
> -static bool
> -ascii85_encode(u32 in, char *out)
> -{
> -   int i;
> -
> -   if (in == 0)
> -   return false;
> -
> -   out[5] = '\0';
> -   for (i = 5; i--; ) {
> -   out[i] = '!' + in % 85;
> -   in /= 85;
> -   }
> -
> -   return true;
> -}
> -
>  static void print_error_obj(struct drm_i915_error_state_buf *m,
> struct intel_engine_cs *engine,
> const char *name,
> diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
> new file mode 100644
> index 000..7ee39f9
> --- /dev/null
> +++ b/include/linux/ascii85.h
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright (c) 2008 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef _ASCII85_H_
> +#define _ASCII85_H_
> +
> +#include 
> +
> +static inline int
> +ascii85_encode_len(int len)
> +{
> +   return DIV_ROUND_UP(len, 4);
> +}

Use longs for generic stuff.

> +
> +static inline bool
> +ascii85_encode(u32 in, char *out)
> +{
> +   int i;
> +
> +   if (in == 0)
> +   return false;
> +
> +   out[5] = '\0';
> +   for (i = 5; i--; ) {
> +   out[i] = '!' + in % 85;
> +   in /= 85;
> +   }
> +
> +   return true;
> +}

I think you'll want to capture the special case 0 == 'z' in the common
routines.

{
char buf[ASCII85_BUFSZ];
int i, len;

len = ascii85_encode_len(PAGE_SIZE);
for (i = 0; i < len; i++)
err_puts(m, ascii85_encode(obj->pages[page][i], buf));
}   

Looks reasonable for the caller, so

#define ASCII85_BUFSZ 6

static inline const char *
ascii85_encode(u32 in, char *out)
{
int i;

/* check whether out[0] = 'z'; out[1] = '\0'; generates better code */
if (in == 0)
return "z";

out[5] = '\0';
for (i = 5; i--; ) {
out[i] = '!' + in % 85;
in /= 85;
}

return out;
}

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

[Intel-gfx] [PATCH] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 24 +---
 include/linux/ascii85.h   | 52 +++
 2 files changed, 53 insertions(+), 23 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 48418fb..2588f37 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 
@@ -501,29 +502,6 @@ void i915_error_printf(struct drm_i915_error_state_buf *e, 
const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index 000..7ee39f9
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2008 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+static inline int
+ascii85_encode_len(int len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline bool
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return false;
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return true;
+}
+
+#endif
-- 
1.9.1

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

[Intel-gfx] [RFC] Move i915 ascii85 functions to linux/ascii85.h

[Jordan Crouse]

I've been working on a crash dump utility for the drm/msm GPU driver
to get the useful GPU information out after a hang. Taking inspiration
from the i915 driver I thought it was very smart to use ascii85 format
to encode the binary buffers and other bits.  This patch moves the two
very simple functions to encode binaries as ascii85 from the i915
driver to a linux header to be enjoyed by all.

I debated if it was better to move them to drm/ or go all the way and 
obviously I picked all the way, but if the owners and maintainers feel
like this is something we want to keep closer to home then by all means
lets do what feels best.

Suggestions and flames welcome. Coming immediately after will be the drm/msm
stack that uses this in anger.

Jordan Crouse (1):
  include: Move ascii85 functions from i915 to linux/ascii85.h

 drivers/gpu/drm/i915/i915_gpu_error.c | 24 +---
 include/linux/ascii85.h   | 52 +++
 2 files changed, 53 insertions(+), 23 deletions(-)
 create mode 100644 include/linux/ascii85.h

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 04/17] drm/i915/icl: Enable both DBuf slices during init

[Paulo Zanoni]

Em Ter, 2018-01-23 às 16:49 -0800, James Ausmus escreveu:
> On Tue, Jan 23, 2018 at 05:05:23PM -0200, Paulo Zanoni wrote:
> > From: Mahesh Kumar 
> > 
> > ICL has 2 slices of DBuf, enable both the slices during display
> > init.
> > 
> > Ideally we should only enable the second slice when needed in order
> > to
> > save power, but while we're not there yet, adopt the simpler
> > solution
> > to keep us bug-free.
> > 
> > v2 (from Paulo):
> >   - Add the TODO comment.
> >   - Reorganize where things are defined.
> >   - Fix indentation.
> >   - Remove unnecessary POSTING_READ() calls.
> >   - Improve the commit message.
> > 
> > Signed-off-by: Mahesh Kumar 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h |  2 ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 34
> > +++--
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 979bc06a59f4..1746df9a263d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7122,6 +7122,8 @@ enum {
> >  #define  DISP_DATA_PARTITION_5_6   (1<<6)
> >  #define  DISP_IPC_ENABLE   (1<<3)
> >  #define DBUF_CTL   _MMIO(0x45008)
> > +#define DBUF_CTL_S1_MMIO(0x45008)
> 
> Since it's the exact same register, is it really worth duplicating,
> or
> should we just use the existing DBUF_CTL instead of adding
> DBUF_CTL_S1?

I like it: it's just a single extra line on i915_reg.h and adds clarity
to the code that uses it. But I have nothing against removing it too.


> 
> 
> > +#define DBUF_CTL_S2_MMIO(0x44FE8)
> >  #define  DBUF_POWER_REQUEST(1<<31)
> >  #define  DBUF_POWER_STATE  (1<<30)
> >  #define GEN7_MSG_CTL   _MMIO(0x45010)
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 2556db16c76a..7801a425398f 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2610,6 +2610,36 @@ static void gen9_dbuf_disable(struct
> > drm_i915_private *dev_priv)
> > DRM_ERROR("DBuf power disable timeout!\n");
> >  }
> >  
> > +/*
> > + * TODO: we shouldn't always enable DBUF_CTL_S2, we should only
> > enable it when
> > + * needed and keep it disabled as much as possible.
> > + */
> > +static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
> > +{
> > +   I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) |
> > DBUF_POWER_REQUEST);
> > +   I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) |
> > DBUF_POWER_REQUEST);
> > +   POSTING_READ(DBUF_CTL_S2);
> > +
> > +   udelay(10);
> 
> BSpec says to poll, and timeout/fail after 10 uS, rather than
> unconditionally busy wait - worth making more complex to potentially
> save a few uS of busy wait?

Yeah, good points. We have intel_wait_for_register() to help avoid the
complexity here.


> 
> > +
> > +   if (!(I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
> > +   !(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
> > +   DRM_ERROR("DBuf power enable timeout\n");
> > +}
> > +
> > +static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
> > +{
> > +   I915_WRITE(DBUF_CTL_S1, I915_READ(DBUF_CTL_S1) &
> > ~DBUF_POWER_REQUEST);
> > +   I915_WRITE(DBUF_CTL_S2, I915_READ(DBUF_CTL_S2) &
> > ~DBUF_POWER_REQUEST);
> > +   POSTING_READ(DBUF_CTL_S2);
> > +
> > +   udelay(10);
> > +
> > +   if ((I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
> > +   (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
> > +   DRM_ERROR("DBuf power disable timeout!\n");
> > +}
> > +
> >  static void skl_display_core_init(struct drm_i915_private
> > *dev_priv,
> >bool resume)
> >  {
> > @@ -2920,7 +2950,7 @@ static void icl_display_core_init(struct
> > drm_i915_private *dev_priv,
> > icl_init_cdclk(dev_priv);
> >  
> > /* 6. Enable DBUF. */
> > -   gen9_dbuf_enable(dev_priv);
> > +   icl_dbuf_enable(dev_priv);
> >  
> > /* 7. Setup MBUS. */
> > /* FIXME: MBUS code not here yet. */
> > @@ -2940,7 +2970,7 @@ static void icl_display_core_uninit(struct
> > drm_i915_private *dev_priv)
> > /* 1. Disable all display engine functions -> aready done
> > */
> >  
> > /* 2. Disable DBUF */
> > -   gen9_dbuf_disable(dev_priv);
> > +   icl_dbuf_disable(dev_priv);
> >  
> > /* 3. Disable CD clock */
> > icl_uninit_cdclk(dev_priv);
> > -- 
> > 2.14.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[James Ausmus]

On Fri, Jan 26, 2018 at 06:24:32PM -0200, Paulo Zanoni wrote:
> Em Ter, 2018-01-23 às 16:32 -0800, James Ausmus escreveu:
> > On Tue, Jan 23, 2018 at 05:05:21PM -0200, Paulo Zanoni wrote:
> > > On ICL we have two sets of registers: one for port A and another
> > > for
> > > port B. The set of port A registers is the same as the CNL
> > > registers.
> > > 
> > > Since the procmon table on ICL is the same we want to reuse the CNL
> > > function. To do that we add a port argument and make CNL always
> > > call
> > > the function passing port A. This way, we'll be able to easily
> > > reuse
> > > the function on ICL when we add icl_display_core_init().
> > > 
> > > v2: Don't use _PICK() when you can use a ternary operator.
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h | 26
> > > ++
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 ++---
> > >  2 files changed, 40 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index d72e206b2b9f..ebf6261d30fd 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -2102,6 +2102,32 @@ enum i915_power_well_id {
> > >  #define CNL_PORT_COMP_DW9_MMIO(0x162124)
> > >  #define CNL_PORT_COMP_DW10   _MMIO(0x162128)
> > >  
> > > +#define _ICL_PORT_COMP_DW0_A 0x162100
> > > +#define _ICL_PORT_COMP_DW0_B 0x6C100
> > > +#define ICL_PORT_COMP_DW0(port)  _MMIO((port ==
> > > PORT_A) ? \
> > > +   _ICL_PORT_COMP_DW0_A
> > > : \
> > > +   _ICL_PORT_COMP_DW0_B
> > > )
> > > +#define _ICL_PORT_COMP_DW1_A 0x162104
> > > +#define _ICL_PORT_COMP_DW1_B 0x6C104
> > > +#define ICL_PORT_COMP_DW1(port)  _MMIO((port ==
> > > PORT_A) ? \
> > > +   _ICL_PORT_COMP_DW1_A
> > > : \
> > > +   _ICL_PORT_COMP_DW1_B
> > > )
> > > +#define _ICL_PORT_COMP_DW3_A 0x16210C
> > > +#define _ICL_PORT_COMP_DW3_B 0x6C10C
> > > +#define ICL_PORT_COMP_DW3(port)  _MMIO((port ==
> > > PORT_A) ? \
> > > +   _ICL_PORT_COMP_DW3_A
> > > : \
> > > +   _ICL_PORT_COMP_DW3_B
> > > )
> > > +#define _ICL_PORT_COMP_DW9_A 0x162124
> > > +#define _ICL_PORT_COMP_DW9_B 0x6C124
> > > +#define ICL_PORT_COMP_DW9(port)  _MMIO((port ==
> > > PORT_A) ? \
> > > +   _ICL_PORT_COMP_DW9_A
> > > : \
> > > +   _ICL_PORT_COMP_DW9_B
> > > )
> > > +#define _ICL_PORT_COMP_DW10_A0x162128
> > > +#define _ICL_PORT_COMP_DW10_B0x6C128
> > > +#define ICL_PORT_COMP_DW10(port) _MMIO((port == PORT_A) ?
> > > \
> > > +   _ICL_PORT_COMP_DW10_
> > > A :   \
> > > +   _ICL_PORT_COMP_DW10_
> > > B)
> > > +
> > >  /* BXT PHY Ref registers */
> > >  #define _PORT_REF_DW3_A  0x16218C
> > >  #define _PORT_REF_DW3_BC 0x6C18C
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 5b1aa4b9c72c..73dd525d241a 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -2758,12 +2758,19 @@ static const struct cnl_procmon {
> > >   { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 =
> > > 0x8AE38FF1, },
> > >  };
> > >  
> > > -static void cnl_set_procmon_ref_values(struct drm_i915_private
> > > *dev_priv)
> > > +/*
> > > + * CNL has just one set of registers, while ICL has two sets: one
> > > for port A and
> > > + * the other for port B. The CNL registers are equivalent to the
> > > ICL port A
> > > + * registers, that's why we call the ICL macros even though the
> > > function has CNL
> > > + * on its name.
> > > + */
> 
> My reply below refers to this comment here ^.
> 
> 
> 
> 
> > > +static void cnl_set_procmon_ref_values(struct drm_i915_private
> > > *dev_priv,
> > > +enum port port)
> > >  {
> > >   const struct cnl_procmon *procmon;
> > >   u32 val;
> > >  
> > > - val = I915_READ(CNL_PORT_COMP_DW3);
> > > + val = I915_READ(ICL_PORT_COMP_DW3(port));
> > >   switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
> > >   default:
> > >   MISSING_CASE(val);
> > > @@ -2784,13 +2791,13 @@ static void
> > > cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
> > >   break;
> > >   }
> > >  
> > > - val = I915_READ(CNL_PORT_COMP_DW1);
> > > + val = I915_READ(ICL_PORT_COMP_DW1(port));
> > >   val &= ~((0xff << 16) | 0xff);
> > >   val |= procmon->dw1;
> > > - 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Chris Wilson]

Quoting Rafael Antognolli (2018-01-26 17:58:29)
> On Fri, Jan 26, 2018 at 09:55:58AM -0800, Rafael Antognolli wrote:
> > On Fri, Jan 26, 2018 at 08:23:13AM +, Chris Wilson wrote:
> > > Quoting Rafael Antognolli (2018-01-26 01:26:34)
> > > > Write a PIPE_CONTROL with CS stall followed by 14 dwords of 0 in the
> > > > indirect context wa bb.
> > > 
> > > 14 MI_NOOPS following? That isn't what you wrote in the code, but the
> > 
> > Agreed, sorry. The workarounds says:
> > 
> > 0x7a04 0x0010 + 14 dwords of 0. I counted 6 dwords from
> > gen8_emit_pipe_control() and figured "just 8 more to 14". I think I had
> > it right on my first version of this patch, but...
> > 
> > > main thing you haven't explained is why. A normal batch will already
> > > have a flush in its setup, but more to the point would be the only
> > > reason this is required is because of an implicit 3DSTATE inside the
> > > context image on preemption. Right? Otherwise it seems to be a purely
> > > userspace problem.
> > 
> > This is the text from the workaround:
> > 
> > "This bug can be hit on a context restore.  To avoid the issue the
> > following must be programmed by SW to ensure the engine is idle prior to
> > programming 3DSTATE_SAMPLE_PATTERN:
> > 
> > With RS context enabled: 0x21c8 = 0x85c0
> > 
> > With RS context disabled:0x21c8 = 0x1ac0
> > 
> > The above program specifes the offset to insert driver programmed
> > commands
> > 
> > 0x21c4[31:6] = 0x
> > 
> > 0x21c4[5:0] = 0x
> > 
> > N=Size of CL needed to fit Workaround
> > 
> > The above programming is the GGTT address of the driver programmed
> > commands and the size(# of CL) to execute.
> > 
> > The address above needs to be a GGTT address and contain a pipe control
> > with CS stall(0x7a04 0x0010 0x 0x)followed by
> > 12DW’s of NOOP(0x)"
> > 
> > Since it needs to be in a GGTT address, and it's specifically talking
> > about the Indirect Context Pointer, we figured it should be in the
> > kernel. I can update the commit message with the above text if it helps.
> > 
> > I originally implemented this trying to fix my GPU hang, but it turns
> > out the issue was something else and this commit doesn't help at all.
> > Still, I see no reason to not have it there just in case it prevent any
> > future hangs...
> 
> Oh, and this workaround is actually a little longer, and there is a part
> that describe a similar PIPE_CONTROL before 3DSTATE_SAMPLE_PATTERN. That
> part is already implemented in userspace.

Cool, I really just wanted confirmation that it was indeed required
before the context switch. Hence justifying placement in the
indirect_ctx bb, and explaining why it's not just a regular pre-batch
flush. Please do try and distill as much as the workaround
note into the changelog and a reminder inside the code; especially the
rationale on why it's in the indirect ctx bb.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[Ville Syrjälä]

On Tue, Jan 23, 2018 at 05:05:21PM -0200, Paulo Zanoni wrote:
> On ICL we have two sets of registers: one for port A and another for
> port B. The set of port A registers is the same as the CNL registers.
> 
> Since the procmon table on ICL is the same we want to reuse the CNL
> function. To do that we add a port argument and make CNL always call
> the function passing port A. This way, we'll be able to easily reuse
> the function on ICL when we add icl_display_core_init().
> 
> v2: Don't use _PICK() when you can use a ternary operator.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 26 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 ++---
>  2 files changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d72e206b2b9f..ebf6261d30fd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2102,6 +2102,32 @@ enum i915_power_well_id {
>  #define CNL_PORT_COMP_DW9_MMIO(0x162124)
>  #define CNL_PORT_COMP_DW10   _MMIO(0x162128)
>  
> +#define _ICL_PORT_COMP_DW0_A 0x162100
> +#define _ICL_PORT_COMP_DW0_B 0x6C100
> +#define ICL_PORT_COMP_DW0(port)  _MMIO((port == PORT_A) ?
> \
> +   _ICL_PORT_COMP_DW0_A :\
> +   _ICL_PORT_COMP_DW0_B)

Why not just _MMIO_PORT() ?

> +#define _ICL_PORT_COMP_DW1_A 0x162104
> +#define _ICL_PORT_COMP_DW1_B 0x6C104
> +#define ICL_PORT_COMP_DW1(port)  _MMIO((port == PORT_A) ?
> \
> +   _ICL_PORT_COMP_DW1_A :\
> +   _ICL_PORT_COMP_DW1_B)
> +#define _ICL_PORT_COMP_DW3_A 0x16210C
> +#define _ICL_PORT_COMP_DW3_B 0x6C10C
> +#define ICL_PORT_COMP_DW3(port)  _MMIO((port == PORT_A) ?
> \
> +   _ICL_PORT_COMP_DW3_A :\
> +   _ICL_PORT_COMP_DW3_B)
> +#define _ICL_PORT_COMP_DW9_A 0x162124
> +#define _ICL_PORT_COMP_DW9_B 0x6C124
> +#define ICL_PORT_COMP_DW9(port)  _MMIO((port == PORT_A) ?
> \
> +   _ICL_PORT_COMP_DW9_A :\
> +   _ICL_PORT_COMP_DW9_B)
> +#define _ICL_PORT_COMP_DW10_A0x162128
> +#define _ICL_PORT_COMP_DW10_B0x6C128
> +#define ICL_PORT_COMP_DW10(port) _MMIO((port == PORT_A) ?\
> +   _ICL_PORT_COMP_DW10_A :   \
> +   _ICL_PORT_COMP_DW10_B)
> +
>  /* BXT PHY Ref registers */
>  #define _PORT_REF_DW3_A  0x16218C
>  #define _PORT_REF_DW3_BC 0x6C18C
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 5b1aa4b9c72c..73dd525d241a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2758,12 +2758,19 @@ static const struct cnl_procmon {
>   { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
>  };
>  
> -static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
> +/*
> + * CNL has just one set of registers, while ICL has two sets: one for port A 
> and
> + * the other for port B. The CNL registers are equivalent to the ICL port A
> + * registers, that's why we call the ICL macros even though the function has 
> CNL
> + * on its name.
> + */
> +static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv,
> +enum port port)
>  {
>   const struct cnl_procmon *procmon;
>   u32 val;
>  
> - val = I915_READ(CNL_PORT_COMP_DW3);
> + val = I915_READ(ICL_PORT_COMP_DW3(port));
>   switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
>   default:
>   MISSING_CASE(val);
> @@ -2784,13 +2791,13 @@ static void cnl_set_procmon_ref_values(struct 
> drm_i915_private *dev_priv)
>   break;
>   }
>  
> - val = I915_READ(CNL_PORT_COMP_DW1);
> + val = I915_READ(ICL_PORT_COMP_DW1(port));
>   val &= ~((0xff << 16) | 0xff);
>   val |= procmon->dw1;
> - I915_WRITE(CNL_PORT_COMP_DW1, val);
> + I915_WRITE(ICL_PORT_COMP_DW1(port), val);
>  
> - I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
> - I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
> + I915_WRITE(ICL_PORT_COMP_DW9(port), procmon->dw9);
> + I915_WRITE(ICL_PORT_COMP_DW10(port), procmon->dw10);
>  }
>  
>  static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
> resume)
> @@ -2811,7 +2818,7 @@ static void cnl_display_core_init(struct 
> drm_i915_private *dev_priv, bool resume
>   val &= 

Re: [Intel-gfx] [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[Paulo Zanoni]

Em Ter, 2018-01-23 às 16:32 -0800, James Ausmus escreveu:
> On Tue, Jan 23, 2018 at 05:05:21PM -0200, Paulo Zanoni wrote:
> > On ICL we have two sets of registers: one for port A and another
> > for
> > port B. The set of port A registers is the same as the CNL
> > registers.
> > 
> > Since the procmon table on ICL is the same we want to reuse the CNL
> > function. To do that we add a port argument and make CNL always
> > call
> > the function passing port A. This way, we'll be able to easily
> > reuse
> > the function on ICL when we add icl_display_core_init().
> > 
> > v2: Don't use _PICK() when you can use a ternary operator.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 26
> > ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 ++---
> >  2 files changed, 40 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index d72e206b2b9f..ebf6261d30fd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2102,6 +2102,32 @@ enum i915_power_well_id {
> >  #define CNL_PORT_COMP_DW9  _MMIO(0x162124)
> >  #define CNL_PORT_COMP_DW10 _MMIO(0x162128)
> >  
> > +#define _ICL_PORT_COMP_DW0_A   0x162100
> > +#define _ICL_PORT_COMP_DW0_B   0x6C100
> > +#define ICL_PORT_COMP_DW0(port)_MMIO((port ==
> > PORT_A) ?   \
> > + _ICL_PORT_COMP_DW0_A
> > :   \
> > + _ICL_PORT_COMP_DW0_B
> > )
> > +#define _ICL_PORT_COMP_DW1_A   0x162104
> > +#define _ICL_PORT_COMP_DW1_B   0x6C104
> > +#define ICL_PORT_COMP_DW1(port)_MMIO((port ==
> > PORT_A) ?   \
> > + _ICL_PORT_COMP_DW1_A
> > :   \
> > + _ICL_PORT_COMP_DW1_B
> > )
> > +#define _ICL_PORT_COMP_DW3_A   0x16210C
> > +#define _ICL_PORT_COMP_DW3_B   0x6C10C
> > +#define ICL_PORT_COMP_DW3(port)_MMIO((port ==
> > PORT_A) ?   \
> > + _ICL_PORT_COMP_DW3_A
> > :   \
> > + _ICL_PORT_COMP_DW3_B
> > )
> > +#define _ICL_PORT_COMP_DW9_A   0x162124
> > +#define _ICL_PORT_COMP_DW9_B   0x6C124
> > +#define ICL_PORT_COMP_DW9(port)_MMIO((port ==
> > PORT_A) ?   \
> > + _ICL_PORT_COMP_DW9_A
> > :   \
> > + _ICL_PORT_COMP_DW9_B
> > )
> > +#define _ICL_PORT_COMP_DW10_A  0x162128
> > +#define _ICL_PORT_COMP_DW10_B  0x6C128
> > +#define ICL_PORT_COMP_DW10(port)   _MMIO((port == PORT_A) ?
> > \
> > + _ICL_PORT_COMP_DW10_
> > A : \
> > + _ICL_PORT_COMP_DW10_
> > B)
> > +
> >  /* BXT PHY Ref registers */
> >  #define _PORT_REF_DW3_A0x16218C
> >  #define _PORT_REF_DW3_BC   0x6C18C
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 5b1aa4b9c72c..73dd525d241a 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2758,12 +2758,19 @@ static const struct cnl_procmon {
> > { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 =
> > 0x8AE38FF1, },
> >  };
> >  
> > -static void cnl_set_procmon_ref_values(struct drm_i915_private
> > *dev_priv)
> > +/*
> > + * CNL has just one set of registers, while ICL has two sets: one
> > for port A and
> > + * the other for port B. The CNL registers are equivalent to the
> > ICL port A
> > + * registers, that's why we call the ICL macros even though the
> > function has CNL
> > + * on its name.
> > + */

My reply below refers to this comment here ^.




> > +static void cnl_set_procmon_ref_values(struct drm_i915_private
> > *dev_priv,
> > +  enum port port)
> >  {
> > const struct cnl_procmon *procmon;
> > u32 val;
> >  
> > -   val = I915_READ(CNL_PORT_COMP_DW3);
> > +   val = I915_READ(ICL_PORT_COMP_DW3(port));
> > switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
> > default:
> > MISSING_CASE(val);
> > @@ -2784,13 +2791,13 @@ static void
> > cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
> > break;
> > }
> >  
> > -   val = I915_READ(CNL_PORT_COMP_DW1);
> > +   val = I915_READ(ICL_PORT_COMP_DW1(port));
> > val &= ~((0xff << 16) | 0xff);
> > val |= procmon->dw1;
> > -   I915_WRITE(CNL_PORT_COMP_DW1, val);
> > +   I915_WRITE(ICL_PORT_COMP_DW1(port), val);
> >  
> > -   I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
> > -   I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
> > +   I915_WRITE(ICL_PORT_COMP_DW9(port), 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add DPCD definitions for DP 1.4 FEC feature (rev3)

[Patchwork]

== Series Details ==

Series: drm: Add DPCD definitions for DP 1.4 FEC feature (rev3)
URL   : https://patchwork.freedesktop.org/series/34259/
State : success

== Summary ==

Series 34259v3 drm: Add DPCD definitions for DP 1.4 FEC feature
https://patchwork.freedesktop.org/api/1.0/series/34259/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:530s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:529s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
868a0e7ca036 drm: Add DPCD definitions for DP 1.4 FEC feature

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7794/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] drm/i915/icl: new context descriptor support

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] drm/i915/icl: new context descriptor 
support
URL   : https://patchwork.freedesktop.org/series/37204/
State : warning

== Summary ==

Series 37204v1 series starting with [v4,1/2] drm/i915/icl: new context 
descriptor support
https://patchwork.freedesktop.org/api/1.0/series/37204/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:527s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
59d31a7adb7a drm/i915/icl: Enhanced execution list support
8988ec90ecd0 drm/i915/icl: new context descriptor support

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7793/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove Firmware URL.

[Patchwork]

== Series Details ==

Series: drm/i915: Remove Firmware URL.
URL   : https://patchwork.freedesktop.org/series/37201/
State : failure

== Summary ==

Series 37201v1 drm/i915: Remove Firmware URL.
https://patchwork.freedesktop.org/api/1.0/series/37201/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-bxt-j4205)
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:526s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
4404c0e93938 drm/i915: Remove Firmware URL.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7792/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 2/2] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

From: Thomas Daniel 

Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue
(the ExecLists Submission Queue - ELSQ), which is then loaded on the
HW. When writing to the ELSP register, the lrcs are written cyclically
in the queue from position 0 to position 7. Alternatively, it is
possible to write directly in the individual positions of the queue
using the ELSQC registers. To be able to re-use all the existing code
we're using the latter method and we're currently limiting ourself to
only using 2 elements.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
preemption (Daniele), reuse engine->execlists.elsp (Chris)
v6: use has_logical_ring_elsq to differentiate the new paths
v7: add preemption support, rename els to submit_reg (Chris)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  |  3 +-
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 52 +---
 drivers/gpu/drm/i915/intel_lrc.h |  3 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 ++--
 6 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f48a8ee..0493b4b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2743,6 +2743,8 @@ static inline unsigned int i915_sg_segment_size(void)
 
 #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
((dev_priv)->info.has_logical_ring_contexts)
+#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
+   ((dev_priv)->info.has_logical_ring_elsq)
 #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f28c165..6c86cba 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -583,7 +583,8 @@
GEN10_FEATURES, \
.gen = 11, \
.ddb_size = 2048, \
-   .has_csr = 0
+   .has_csr = 0, \
+   .has_logical_ring_elsq = 1
 
 static const struct intel_device_info intel_icelake_11_info __initconst = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 9542018..dbf0f2d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -96,6 +96,7 @@ enum intel_platform {
func(has_l3_dpf); \
func(has_llc); \
func(has_logical_ring_contexts); \
+   func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
func(has_overlay); \
func(has_pooled_eu); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ac78fc2..6c7b9c3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -400,17 +400,29 @@ static u64 execlists_update_context(struct 
drm_i915_gem_request *rq)
return ce->lrc_desc;
 }
 
-static inline void elsp_write(u64 desc, u32 __iomem *elsp)
+static inline void write_desc(struct intel_engine_cs *engine, u64 desc, u32 
port)
 {
-   writel(upper_32_bits(desc), elsp);
-   writel(lower_32_bits(desc), elsp);
+   if (HAS_LOGICAL_RING_ELSQ(engine->i915)) {
+   writel(lower_32_bits(desc), engine->execlists.submit_reg + port 
* 2);
+   writel(upper_32_bits(desc), engine->execlists.submit_reg + port 
* 2 + 1);
+   } else {
+   writel(upper_32_bits(desc), engine->execlists.submit_reg);
+   writel(lower_32_bits(desc), engine->execlists.submit_reg);
+   }
 }
 
 static void execlists_submit_ports(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
struct execlist_port *port = engine->execlists.port;
unsigned int n;
 
+   /*
+* ELSQ note: the submit queue is not cleared after being submitted
+* to the HW so we need to make sure we always clean it up. This is
+* currently ensured by the fact that we always write the same number
+* of elsq entries, keep this in mind before changing the loop below.
+*/
for (n = execlists_num_ports(>execlists); n--; ) {
struct drm_i915_gem_request *rq;
unsigned int count;
@@ -434,8 +446,13 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc 

[Intel-gfx] [PATCH v4 1/2] drm/i915/icl: new context descriptor support

[Daniele Ceraolo Spurio]

From: "Ceraolo Spurio, Daniele" 

Starting from Gen11 the context descriptor format has been updated in
the HW. The hw_id field has been considerably reduced in size and engine
class and instance fields have been added.

There is a slight name clashing issue because the field that we call
hw_id is actually called SW Context ID in the specs for Gen11+.

With the current size of the hw_id field we can have a maximum of 2k
contexts at any time, but we could use the sw_counter field (which is sw
defined) to increase that because the HW requirement is that
engine_id + sw id + sw_counter is a unique number.
GuC uses a similar method to support more contexts but does its tracking
at lrc level. To avoid doing an implementation that will need to be
reworked once GuC support lands, defer it for now and mark it as TODO.

v2: rebased, add documentation, fix GEN11_ENGINE_INSTANCE_SHIFT
v3: rebased, bring back lost code from i915_gem_context.c
v4: make TODO comment more generic (Oscar)

Cc: Oscar Mateo 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 11 +--
 drivers/gpu/drm/i915/i915_reg.h |  4 
 drivers/gpu/drm/i915/intel_lrc.c| 28 +++-
 4 files changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f9..f48a8ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2083,6 +2083,7 @@ struct drm_i915_private {
 */
struct ida hw_ida;
 #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
} contexts;
 
u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e753..dbc50b9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -211,9 +211,15 @@ static void context_close(struct i915_gem_context *ctx)
 static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
 {
int ret;
+   unsigned int max;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   max = GEN11_MAX_CONTEXT_HW_ID;
+   else
+   max = MAX_CONTEXT_HW_ID;
 
ret = ida_simple_get(_priv->contexts.hw_ida,
-0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+0, max, GFP_KERNEL);
if (ret < 0) {
/* Contexts are only released when no longer active.
 * Flush any pending retires to hopefully release some
@@ -221,7 +227,7 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, 
unsigned *out)
 */
i915_gem_retire_requests(dev_priv);
ret = ida_simple_get(_priv->contexts.hw_ida,
-0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+0, max, GFP_KERNEL);
if (ret < 0)
return ret;
}
@@ -462,6 +468,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
 
/* Using the simple ida interface, the max is limited by sizeof(int) */
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
+   BUILD_BUG_ON(GEN11_MAX_CONTEXT_HW_ID > INT_MAX);
ida_init(_priv->contexts.hw_ida);
 
/* lowest priority; idle task */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64933fd..2e4e6c7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3840,6 +3840,10 @@ enum {
 
 #define GEN8_CTX_ID_SHIFT 32
 #define GEN8_CTX_ID_WIDTH 21
+#define GEN11_SW_CTX_ID_SHIFT 37
+#define GEN11_SW_CTX_ID_WIDTH 11
+#define GEN11_ENGINE_CLASS_SHIFT 61
+#define GEN11_ENGINE_INSTANCE_SHIFT 48
 
 #define CHV_CLK_CTL1   _MMIO(0x101100)
 #define VLV_CLK_CTL2   _MMIO(0x101104)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2fa328d..ac78fc2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -188,6 +188,18 @@ static void execlists_init_reg_state(u32 *reg_state,
  *  bits 32-52:ctx ID, a globally unique tag
  *  bits 53-54:mbz, reserved for use by hardware
  *  bits 55-63:group ID, currently unused and set to 0
+ *
+ * Starting from Gen11, the upper dword of the descriptor has a new format:
+ *
+ *  bits 32-36:reserved
+ *  bits 37-47:SW context ID
+ *  bits 48:53:engine instance
+ *  bit 54:mbz, reserved for use by hardware
+ *  bits 55-60:SW counter
+ *  bits 61-63:engine class
+ *
+ * engine info, SW context ID and SW counter need to form a unique number
+ * (Context ID) per lrc.
  */
 static void
 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev2)
URL   : https://patchwork.freedesktop.org/series/37134/
State : failure

== Summary ==

Warning: bzip CI_DRM_3686/shard-glkb6/results14.json.bz2 wasn't in correct JSON 
format
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Test kms_mmap_write_crc:
skip   -> PASS   (shard-apl)

fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2838 pass:1752 dwarn:1   dfail:0   fail:20  skip:1064 
time:12719s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:12054s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:12  skip:1497 
time:6669s
Blacklisted hosts:
shard-kbltotal:2825 pass:1855 dwarn:4   dfail:0   fail:22  skip:943 
time:9551s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7791/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.

[Rodrigo Vivi]

The right place for the firmware is linux-firmware.git.
We shouldn't advertise anywhere to users to start downloading
firmware blobs manually.

Also it seems that 01.org page is outdated and it doesn't
contain DMC 1.27 for SKL, for instance. Probably other
firmware releases are missing there, while they are part
of the official linux-firmware.git.

So, let's stop advertising that place here.
But also let's work in parallel to kill that page for
good and maybe with a message explaining to users
that they don't need to install manually, but rely
on their distros for getting linux-firmware package updates.

Cc: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_csr.c   | 2 --
 drivers/gpu/drm/i915/intel_uc_fw.c | 2 --
 drivers/gpu/drm/i915/intel_uc_fw.h | 3 ---
 3 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 41e6c75a7f3c..05761ffbf2ec 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -429,8 +429,6 @@ static void csr_load_work_fn(struct work_struct *work)
   "Failed to load DMC firmware %s."
   " Disabling runtime power management.\n",
   csr->fw_path);
-   dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
-  INTEL_UC_FIRMWARE_URL);
}
 
release_firmware(fw);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c 
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 784eff9cdfc8..f2c4ddb4b91d 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -189,8 +189,6 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
 
DRM_WARN("%s: Failed to fetch firmware %s (error %d)\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path, err);
-   DRM_INFO("%s: Firmware can be downloaded from %s\n",
-intel_uc_fw_type_repr(uc_fw->type), INTEL_UC_FIRMWARE_URL);
 
release_firmware(fw);   /* OK even if fw is NULL */
 }
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd4609c785..ee40852f2250 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -29,9 +29,6 @@ struct drm_printer;
 struct drm_i915_private;
 struct i915_vma;
 
-/* Home of GuC, HuC and DMC firmwares */
-#define INTEL_UC_FIRMWARE_URL "https://01.org/linuxgraphics/downloads/firmware;
-
 enum intel_uc_fw_status {
INTEL_UC_FIRMWARE_FAIL = -1,
INTEL_UC_FIRMWARE_NONE = 0,
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Rafael Antognolli]

On Fri, Jan 26, 2018 at 09:55:58AM -0800, Rafael Antognolli wrote:
> On Fri, Jan 26, 2018 at 08:23:13AM +, Chris Wilson wrote:
> > Quoting Rafael Antognolli (2018-01-26 01:26:34)
> > > Write a PIPE_CONTROL with CS stall followed by 14 dwords of 0 in the
> > > indirect context wa bb.
> > 
> > 14 MI_NOOPS following? That isn't what you wrote in the code, but the
> 
> Agreed, sorry. The workarounds says:
> 
> 0x7a04 0x0010 + 14 dwords of 0. I counted 6 dwords from
> gen8_emit_pipe_control() and figured "just 8 more to 14". I think I had
> it right on my first version of this patch, but...
> 
> > main thing you haven't explained is why. A normal batch will already
> > have a flush in its setup, but more to the point would be the only
> > reason this is required is because of an implicit 3DSTATE inside the
> > context image on preemption. Right? Otherwise it seems to be a purely
> > userspace problem.
> 
> This is the text from the workaround:
> 
> "This bug can be hit on a context restore.  To avoid the issue the
> following must be programmed by SW to ensure the engine is idle prior to
> programming 3DSTATE_SAMPLE_PATTERN:
> 
> With RS context enabled: 0x21c8 = 0x85c0
> 
> With RS context disabled:0x21c8 = 0x1ac0
> 
> The above program specifes the offset to insert driver programmed
> commands
> 
> 0x21c4[31:6] = 0x
> 
> 0x21c4[5:0] = 0x
> 
> N=Size of CL needed to fit Workaround
> 
> The above programming is the GGTT address of the driver programmed
> commands and the size(# of CL) to execute.
> 
> The address above needs to be a GGTT address and contain a pipe control
> with CS stall(0x7a04 0x0010 0x 0x)followed by
> 12DW’s of NOOP(0x)"
> 
> Since it needs to be in a GGTT address, and it's specifically talking
> about the Indirect Context Pointer, we figured it should be in the
> kernel. I can update the commit message with the above text if it helps.
> 
> I originally implemented this trying to fix my GPU hang, but it turns
> out the issue was something else and this commit doesn't help at all.
> Still, I see no reason to not have it there just in case it prevent any
> future hangs...

Oh, and this workaround is actually a little longer, and there is a part
that describe a similar PIPE_CONTROL before 3DSTATE_SAMPLE_PATTERN. That
part is already implemented in userspace.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH libdrm] tests: Add drm_set_cgrp_param

[Emil Velikov]

On 26 January 2018 at 17:27, Matt Roper  wrote:
> On Fri, Jan 26, 2018 at 05:08:48PM +, Emil Velikov wrote:
>> On 22 January 2018 at 15:44, Matt Roper  wrote:
>> > drm_set_cgrp_param is a simple tool to set DRM parameters associated with a
>> > cgroup.  It is intended to be called at system initialization time (e.g., 
>> > from
>> > a sysv-init script or systemd service) to configure graphics policy and
>> > resource management according to the wishes of the system integrator.
>> >
>> > Signed-off-by: Matt Roper 
>> > ---
>> >  configure.ac  |  1 +
>> >  tests/Makefile.am |  2 +-
>> >  tests/drm_set_cgrp_param/Makefile.am  | 18 ++
>> >  tests/drm_set_cgrp_param/drm_set_cgrp_param.c | 80 
>> > +++
>> >  4 files changed, 100 insertions(+), 1 deletion(-)
>> >  create mode 100644 tests/drm_set_cgrp_param/Makefile.am
>> >  create mode 100644 tests/drm_set_cgrp_param/drm_set_cgrp_param.c
>> >
>> Hi Matt,
>>
>> Adding a small test/demo in libdrm sounds good. Although I think we
>> need some IGT tests, if you haven't prepped them already.
>> After all we need to ensure the kernel correctly validates and errors
>> when we feed it the wrong info through the IOCTL.
>
> Yeah, agreed.  Writing real IGT's was in the TODO list of the
> cover-letter for my kernel patch series.  This kernel work is still a
> pretty early RFC just to gather feedback on the general approach of
> integrating cgroups with DRM; I figured I'd wait on writing real IGT's
> until we're more confident that this is the right approach in general.
>
> I'm working on a v2 right now that makes some pretty significant changes
> to the series, but I'm not sure yet whether the uapi will change in my
> next iteration or not.
>
Good call - have an agreement about the interface and usage first.
Then iron out all the fiddly bits.

>> There's a small suggestions about the IOCTL design.
>> s/reserved/flags/ to make future extension are possible - as mentioned in [2]
>
> Yeah, that's why I added the reserved field; we don't have any actual
> flags yet, but as soon as we do we'd rename the field to flags and
> document it accordingly.  I can rename the field immediately if you
> think that's easier.  I think the most important thing that's missing at
> the moment is that the kernel patches forgot to check that the reserved
> field is actually empty (i.e., we should reject calls with any garbage
> in there now so that we don't break ABI in the future when we start
> really using those bits for something).
>
Please rename it now. Otherwise we'll get a build break for new kernel
and old userspace.
And yes, validating (returning -EINVAL IIRC) the flags is a must.

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Rafael Antognolli]

On Fri, Jan 26, 2018 at 08:23:13AM +, Chris Wilson wrote:
> Quoting Rafael Antognolli (2018-01-26 01:26:34)
> > Write a PIPE_CONTROL with CS stall followed by 14 dwords of 0 in the
> > indirect context wa bb.
> 
> 14 MI_NOOPS following? That isn't what you wrote in the code, but the

Agreed, sorry. The workarounds says:

0x7a04 0x0010 + 14 dwords of 0. I counted 6 dwords from
gen8_emit_pipe_control() and figured "just 8 more to 14". I think I had
it right on my first version of this patch, but...

> main thing you haven't explained is why. A normal batch will already
> have a flush in its setup, but more to the point would be the only
> reason this is required is because of an implicit 3DSTATE inside the
> context image on preemption. Right? Otherwise it seems to be a purely
> userspace problem.

This is the text from the workaround:

"This bug can be hit on a context restore.  To avoid the issue the
following must be programmed by SW to ensure the engine is idle prior to
programming 3DSTATE_SAMPLE_PATTERN:

With RS context enabled: 0x21c8 = 0x85c0

With RS context disabled:0x21c8 = 0x1ac0

The above program specifes the offset to insert driver programmed
commands

0x21c4[31:6] = 0x

0x21c4[5:0] = 0x

N=Size of CL needed to fit Workaround

The above programming is the GGTT address of the driver programmed
commands and the size(# of CL) to execute.

The address above needs to be a GGTT address and contain a pipe control
with CS stall(0x7a04 0x0010 0x 0x)followed by
12DW’s of NOOP(0x)"

Since it needs to be in a GGTT address, and it's specifically talking
about the Indirect Context Pointer, we figured it should be in the
kernel. I can update the commit message with the above text if it helps.

I originally implemented this trying to fix my GPU hang, but it turns
out the issue was something else and this commit doesn't help at all.
Still, I see no reason to not have it there just in case it prevent any
future hangs...

Rafael
___
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 [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev2)
URL   : https://patchwork.freedesktop.org/series/37134/
State : success

== Summary ==

Series 37134v2 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/37134/revisions/2/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:526s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
265e406b3c4f drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
f6da6fcb6335 drm/i915/cnl: Enable DDI-F on Cannonlake.
1b15954685f8 drm/i915/cnl: Add HPD support for Port F.
99718773daa4 drm/i915: For HPD connected port use hpd_pin instead of port.
ca6d2bf7b795 drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
20d1bd5d551d drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
ac6516be379c drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
2d35bab78bea drm/i915/cnl: Extend Wa 1178 to Aux F.
7dbdf4cea549 drm/i915/cnl: Add AUX-F support
249c36c91dfd drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7791/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH libdrm] tests: Add drm_set_cgrp_param

[Matt Roper]

On Fri, Jan 26, 2018 at 05:08:48PM +, Emil Velikov wrote:
> On 22 January 2018 at 15:44, Matt Roper  wrote:
> > drm_set_cgrp_param is a simple tool to set DRM parameters associated with a
> > cgroup.  It is intended to be called at system initialization time (e.g., 
> > from
> > a sysv-init script or systemd service) to configure graphics policy and
> > resource management according to the wishes of the system integrator.
> >
> > Signed-off-by: Matt Roper 
> > ---
> >  configure.ac  |  1 +
> >  tests/Makefile.am |  2 +-
> >  tests/drm_set_cgrp_param/Makefile.am  | 18 ++
> >  tests/drm_set_cgrp_param/drm_set_cgrp_param.c | 80 
> > +++
> >  4 files changed, 100 insertions(+), 1 deletion(-)
> >  create mode 100644 tests/drm_set_cgrp_param/Makefile.am
> >  create mode 100644 tests/drm_set_cgrp_param/drm_set_cgrp_param.c
> >
> Hi Matt,
> 
> Adding a small test/demo in libdrm sounds good. Although I think we
> need some IGT tests, if you haven't prepped them already.
> After all we need to ensure the kernel correctly validates and errors
> when we feed it the wrong info through the IOCTL.

Yeah, agreed.  Writing real IGT's was in the TODO list of the
cover-letter for my kernel patch series.  This kernel work is still a
pretty early RFC just to gather feedback on the general approach of
integrating cgroups with DRM; I figured I'd wait on writing real IGT's
until we're more confident that this is the right approach in general.

I'm working on a v2 right now that makes some pretty significant changes
to the series, but I'm not sure yet whether the uapi will change in my
next iteration or not.

> There's a small suggestions about the IOCTL design.
> s/reserved/flags/ to make future extension are possible - as mentioned in [2]

Yeah, that's why I added the reserved field; we don't have any actual
flags yet, but as soon as we do we'd rename the field to flags and
document it accordingly.  I can rename the field immediately if you
think that's easier.  I think the most important thing that's missing at
the moment is that the kernel patches forgot to check that the reserved
field is actually empty (i.e., we should reject calls with any garbage
in there now so that we don't break ABI in the future when we start
really using those bits for something).

Thanks for the feedback!

Matt

> 
> Thanks
> Emil
> 
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt?h=v4.15-rc9#n64

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Rodrigo Vivi]

On Fri, Jan 26, 2018 at 10:12:00AM +, Jani Nikula wrote:
> On Thu, 25 Jan 2018, Rodrigo Vivi  wrote:
> > The only difference is that this SKUs has the full
> > Port A/E split named as Port F.
> >
> > But since SKUs differences don't matter on the platform
> > definition group and ids, let's merge all off them together.
> >
> > v2: Really include the PCI IDs to the picidlist[];
> > v3: Add the PCI Id for another SKU (Anusha).
> > v4: Update IDs, really include to pciidlists again.
> > v5: Unify all GT2 IDs.
> > v6: Unify in a way that we don't break early-quirks.c
> > v7: Remove GT reference since it doesn't matter here (Paulo)
> > Also move IS_CNL_WITH_PORT_F macro to this patch to
> > make it easier for review this part and also to get
> > used sooner.
> >
> > Cc: Dhinakaran Pandiyan 
> > Cc: Paulo Zanoni 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Rodrigo Vivi 
> > Reviewed-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
> >  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
> >  include/drm/i915_pciids.h   | 18 +++---
> >  3 files changed, 11 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 454d8f937fae..5702ebf17974 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2648,6 +2648,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  (dev_priv)->info.gt == 2)
> >  #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
> >  (dev_priv)->info.gt == 3)
> > +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> > +   (INTEL_DEVID(dev_priv) & 0x0004) == 
> > 0x0004)
> 
> I'd be happy if bit 2 in device id actually meant "port F", but I'm not
> so happy with coming up with rules like this for coincidental things.

the port F thing is just that we have no name for that SKU :(
but from the spec organization this bit seems to represent that
group. Although I fully agree with you that this is horrible.

> 
> More generally, I'm not all that happy about *any* of the INTEL_DEVID
> uses in i915_drv.h because it spreads out the device id information, so
> I'd rather not add more. I'd rather move towards single point of truth
> for device ids.

Yeah. I guess I agree with you.
There should be something inside the device info right?
even if we have to separate that in two groups.

If you agree with this approach I can follow up with a patch/series
that kill INTEL_DEVID in favor of device info structs.

Or do you have any other idea for solving this?

on this particular case here I considered that, but
since I had no good name and INTEL_DEVID was there I've
chosen the lazy path.

> 
> Okay, so this is late in the review cycles, and part of a more general
> problem, so we should probably just go with this for now and come back
> to this later.

It is never too late ;)

But in this case I'd prefer moving with this series as is
to avoid blocking Paulo with ICL enabling and minimize
the conflicts and rebase pain to only one area of the code.

Thanks for bringing it up,
Rodrigo.

> 
> 
> BR,
> Jani.
> 
> 
> 
> 
> >  
> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index f28c165fc49d..7eb3d5e4350e 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -571,7 +571,7 @@ static const struct intel_device_info 
> > intel_coffeelake_gt3_info __initconst = {
> > .ddb_size = 1024, \
> > GLK_COLORS
> >  
> > -static const struct intel_device_info intel_cannonlake_gt2_info 
> > __initconst = {
> > +static const struct intel_device_info intel_cannonlake_info __initconst = {
> > GEN10_FEATURES,
> > .is_alpha_support = 1,
> > .platform = INTEL_CANNONLAKE,
> > @@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
> > INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
> > INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
> > -   INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
> > -   INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
> > +   INTEL_CNL_IDS(_cannonlake_info),
> > {0, 0, 0}
> >  };
> >  MODULE_DEVICE_TABLE(pci, pciidlist);
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 5db0458dd832..9e1fe6634424 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -414,24 +414,20 @@
> > INTEL_CFL_U_GT2_IDS(info), \
> > INTEL_CFL_U_GT3_IDS(info)
> >  
> > -/* CNL U 2+2 */
> > -#define INTEL_CNL_U_GT2_IDS(info) \
> > +/* CNL 

[Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Rodrigo Vivi]

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
 warns as pointed by DK.
v11: Clean up squashed commit message. (David)

Cc: David Weinehall 
Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  6 ++
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 drivers/gpu/drm/i915/intel_display.h|  1 +
 drivers/gpu/drm/i915/intel_dp.c |  8 
 drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +
 6 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5702ebf17974..f89a1a0a25c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ enum modeset_restore {
 #define DP_AUX_B 0x10
 #define DP_AUX_C 0x20
 #define DP_AUX_D 0x30
+#define DP_AUX_F 0x60
 
 #define DDC_PIN_B  0x05
 #define DDC_PIN_C  0x04
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f643d5ad7ff7..4d84b1c41a94 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   tmp_mask |= CNL_AUX_CHANNEL_F;
+
if (iir & tmp_mask) {
dp_aux_irq_handler(dev_priv);
found = true;
@@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   de_port_masked |= CNL_AUX_CHANNEL_F;
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64933fd74cb6..44f46593172f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1312,6 +1312,7 @@ enum i915_power_well_id {
CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
CNL_DISP_PW_AUX_D,
+   CNL_DISP_PW_AUX_F,
 
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
@@ -5284,6 +5285,13 @@ enum {
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
 
+#define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
+#define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
+#define _DPF_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64518)
+#define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
+#define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
+#define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
@@ -6939,6 +6947,7 @@ enum {
 #define GEN8_DE_PORT_IMR _MMIO(0x4)
 #define GEN8_DE_PORT_IIR _MMIO(0x8)
 #define GEN8_DE_PORT_IER _MMIO(0xc)
+#define  CNL_AUX_CHANNEL_F (1 << 28)
 #define  GEN9_AUX_CHANNEL_D(1 << 27)
 #define  GEN9_AUX_CHANNEL_C(1 << 26)
 #define  GEN9_AUX_CHANNEL_B(1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index e47638931b51..30fa2041a45f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -172,6 +172,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
POWER_DOMAIN_AUX_D,
+   

Re: [Intel-gfx] [PATCH libdrm] tests: Add drm_set_cgrp_param

[Emil Velikov]

On 22 January 2018 at 15:44, Matt Roper  wrote:
> drm_set_cgrp_param is a simple tool to set DRM parameters associated with a
> cgroup.  It is intended to be called at system initialization time (e.g., from
> a sysv-init script or systemd service) to configure graphics policy and
> resource management according to the wishes of the system integrator.
>
> Signed-off-by: Matt Roper 
> ---
>  configure.ac  |  1 +
>  tests/Makefile.am |  2 +-
>  tests/drm_set_cgrp_param/Makefile.am  | 18 ++
>  tests/drm_set_cgrp_param/drm_set_cgrp_param.c | 80 
> +++
>  4 files changed, 100 insertions(+), 1 deletion(-)
>  create mode 100644 tests/drm_set_cgrp_param/Makefile.am
>  create mode 100644 tests/drm_set_cgrp_param/drm_set_cgrp_param.c
>
Hi Matt,

Adding a small test/demo in libdrm sounds good. Although I think we
need some IGT tests, if you haven't prepped them already.
After all we need to ensure the kernel correctly validates and errors
when we feed it the wrong info through the IOCTL.

There's a small suggestions about the IOCTL design.
s/reserved/flags/ to make future extension are possible - as mentioned in [2]

Thanks
Emil

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt?h=v4.15-rc9#n64
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 1/2] lib: Refactor igt_wait() to use library timers

[Antonio Argenziano]

On 25/01/18 13:28, Chris Wilson wrote:

Use the timer routines for computing elapsed time from igt_core for
smaller code.

Signed-off-by: Chris Wilson 
---
  lib/igt_aux.h | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 02e70126c..48ba7970f 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -29,6 +29,7 @@
  #define IGT_AUX_H
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -251,28 +252,24 @@ void igt_unlock_mem(void);
   * True of COND evaluated to true, false otherwise.
   */
  #define igt_wait(COND, timeout_ms, interval_ms) ({\
-   struct timeval start_, end_, diff_; \
-   int elapsed_ms_;\
-   bool ret_ = false;  \
+   struct timespec tv = {};\
+   bool ret_;  \
\
-   igt_assert(gettimeofday(_, NULL) == 0);   \
do {\
+   uint64_t elapsed = igt_nsec_elapsed() >> 20;   \


Maybe tv_ and elapsed_ just for consistency.

Reviewed-by: Antonio Argenziano 


+   \
if (COND) { \
+   igt_debug("%s took %"PRIu64"ms\n", #COND, elapsed); \
ret_ = true;\
break;  \
+   }   \
+   if (elapsed > timeout_ms) {  \
+   ret_ = false;   \
+   break;  \
}   \
\
usleep(interval_ms * 1000); \
-   \
-   igt_assert(gettimeofday(_, NULL) == 0); \
-   timersub(_, _, _);   \
-   \
-   elapsed_ms_ = diff_.tv_sec * 1000 + \
- diff_.tv_usec / 1000; \
-   } while (elapsed_ms_ < timeout_ms);  \
-   \
-   if (!ret_ && (COND))\
-   ret_ = true;\
+   } while (1);\
\
ret_;   \
  })


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

Re: [Intel-gfx] [PATCH v6] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

On 26/01/18 00:47, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-01-26 00:10:09)



On 24/01/18 09:46, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-01-24 17:30:07)

From: Thomas Daniel 

Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue
(the ExecLists Submission Queue - ELSQ), which is then loaded on the
HW. When writing to the ELSP register, the lrcs are written cyclically
in the queue from position 0 to position 7. Alternatively, it is
possible to write directly in the individual positions of the queue
using the ELSQC registers. To be able to re-use all the existing code
we're using the latter method and we're currently limiting ourself to
only using 2 elements.

The preemption flow is sligthly different with enhanced execlists, so
this patch turns preemption off temporarily for platforms with ELSQ
while we wait for the new mechanism to land.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
  preemption (Daniele), reuse engine->execlists.elsp (Chris)
v6: use has_logical_ring_elsq to differentiate the new paths

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
---
   drivers/gpu/drm/i915/i915_drv.h  |  7 ++-
   drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
   drivers/gpu/drm/i915/intel_device_info.h |  1 +
   drivers/gpu/drm/i915/intel_lrc.c | 35 
+++-
   drivers/gpu/drm/i915/intel_lrc.h |  3 +++
   drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 --
   6 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692..346209a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2741,8 +2741,13 @@ static inline unsigned int i915_sg_segment_size(void)
   
   #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \

  ((dev_priv)->info.has_logical_ring_contexts)
+#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
+   ((dev_priv)->info.has_logical_ring_elsq)
+
+/* XXX: Preemption disabled for ELSQ until support for new flow lands */
   #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
-   ((dev_priv)->info.has_logical_ring_preemption)
+   ((dev_priv)->info.has_logical_ring_preemption && \
+!HAS_LOGICAL_RING_ELSQ(dev_priv))


It's in the intel_device_info for a reason. I knew I should not have let
Michal turn this into a macro.



You mean setting has_logical_ring_preemption to zero directly? I thought
the policy was to avoid setting things in device_info to values that
don't reflect real HW capabilities and to do the hacks elsewhere.


No, data driven code. intel_device_info was introduced to remove having
heavy predicates so that we could see what will be enabled and what not
in one place.
  

I still do not see any reason why you don't just make the current
preemption work (it will) and then you can refine it if you prove it
worthwhile.



Just didn't see the worth of it ;). It's not a lot of code but it's in
an hot path and we're most likely going to get rid of it soon as the new
stuff is simpler. I'll put the change together and send it out so we can
evaluate that and see what works better with code at hand.


Is the new stuff going to be any simpler? You still need a preemption
point, so a special submission followed by detecting that in the CS
handler to do the unwind.

And whilst I am here, els is awful. Either stick with elsp and note that
they changed the name (+layout) on icl, or replace it with a generic
name. Spelling it out completely as execlists->execlists_submission is
still better than els, but submit[_reg] (or submit_hw) would be clearer.
-Chris



The elsp still exists on gen11, with a slightly different behavior as 
noted in the commit message, that's why I wanted to change the name. 
execlists->submit_reg sounds good.


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

Re: [Intel-gfx] [PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v2

[Ville Syrjälä]

On Fri, Jan 26, 2018 at 08:52:07AM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
> 
> The problem with at least these Dells is that their VBT defines a MIPI
> ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
> reset in their INIT_OTP sequence, but the deassert must be done before
> calling intel_dsi_device_ready(), so that is too late.
> 
> Simply doing the INIT_OTP sequence earlier is not enough to fix this,
> because the INIT_OTP sequence also sends various MIPI packets to the
> panel, which can only happen after calling intel_dsi_device_ready().
> 
> This commit fixes this by splitting the INIT_OTP sequence into everything
> before the first DSI packet and everything else, including the first DSI
> packet. The first part (everything before the first DSI packet) is then
> used as deassert sequence.
> 
> Changed in v2:
> -Split the init OTP sequence into a deassert reset and the actual init
>  OTP sequence, instead of calling it earlier and then having the first
>  mipi_exec_send_packet() call call intel_dsi_device_ready().
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880
> Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205
> Cc: Jan-Michael Brummer 
> Reported-by: Jan-Michael Brummer 
> Tested-by: Hans de Goede 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c |  1 +
>  drivers/gpu/drm/i915/intel_dsi.h |  2 +
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 82 
> 
>  3 files changed, 85 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index f67d321376e4..b59ef34d25f6 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1642,6 +1642,7 @@ static void intel_dsi_encoder_destroy(struct 
> drm_encoder *encoder)
>   if (intel_dsi->gpio_panel)
>   gpiod_put(intel_dsi->gpio_panel);
>  
> + kfree(intel_dsi->deassert_seq);
>   intel_encoder_destroy(encoder);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 7afeb9580f41..5895588144ad 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -46,6 +46,8 @@ struct intel_dsi {
>  
>   struct intel_connector *attached_connector;
>  
> + u8 *deassert_seq;
> +

Should this perhaps live next to the other DSI VBT stuff? I think that
might make more sense. And should probably also move the
intel_dsi_fixup_dsi_sequences() call to parse_mipi_sequence() as well
since we're actually modifying dev_priv->vbt.data. Doing that from the
encoder init doesn't really feel right to me.

Jani, any thoughts?

>   /* bit mask of ports being driven */
>   u16 ports;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 91c07b0c8db9..84664f79cbef 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -499,6 +499,86 @@ int intel_dsi_vbt_get_modes(struct intel_dsi *intel_dsi)
>   return 1;
>  }
>  
> +/*
> + * Get len of pre-fixed deassert from init OTP, skip all delay + gpio 
> operands
> + * and stop at the first DSI packet op.
> + */
> +static int intel_vbi_get_deassert_len(const u8 *data, int total)
> +{
> + int index, len;

if (WARN_ON(seq_version != 1))
return 0;

or something might be nice here to document the requirements and
to deter anyone from using this with other seq versions.

> +
> + /* index = 1 to skip sequence byte */
> + for (index = 1; index < total; index += len) {
> + switch (data[index]) {
> + case MIPI_SEQ_ELEM_SEND_PKT:
> + return index;

What if this is the first element?

Hmm. It does seem to work out in the end. We do end up with
an empty deassert sequence, but I guess hat's fine.

> + case MIPI_SEQ_ELEM_DELAY:
> + len = 5; /* 1 byte for operand + uint32 */
> + break;
> + case MIPI_SEQ_ELEM_GPIO:
> + len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
> + break;
> + default:
> + return 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
> + * The deassert must be done before calling intel_dsi_device_ready, so for
> + * these devices we split the init OTP sequence into a deassert sequence and
> + * the actual init OTP part.
> + */
> +static void intel_dsi_fixup_dsi_sequences(struct intel_dsi *intel_dsi)
> +{
> + struct drm_i915_private 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: only assign dev_priv->pch_id on successful pch detection

[David Weinehall]

On Fri, Jan 26, 2018 at 04:48:05PM +0200, Jani Nikula wrote:
> Currently pch_id gets assigned also when there's no pch. It doesn't look
> like it makes a difference, but do the right thing anyway.

Makes sense.

Reviewed-by: David Weinehall 

> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3e8664de025d..0332e315650c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -183,8 +183,6 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>  
>   id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  
> - dev_priv->pch_id = id;
> -
>   if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>   dev_priv->pch_type = PCH_IBX;
>   DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> @@ -272,6 +270,8 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>   continue;
>   }
>  
> + dev_priv->pch_id = id;
> +
>   break;
>   }
>   if (!pch)
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: reduce indent in pch detection

[David Weinehall]

On Fri, Jan 26, 2018 at 04:48:04PM +0200, Jani Nikula wrote:
> Save some horizontal space.

Yes, please!

Reviewed-by: David Weinehall 

> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 189 
> 
>  1 file changed, 96 insertions(+), 93 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1ec12add34b2..3e8664de025d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -176,100 +176,103 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>* of only checking the first one.
>*/
>   while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> - if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> - unsigned short id = pch->device & 
> INTEL_PCH_DEVICE_ID_MASK;
> -
> - dev_priv->pch_id = id;
> -
> - if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_IBX;
> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> - WARN_ON(!IS_GEN5(dev_priv));
> - } else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_CPT;
> - DRM_DEBUG_KMS("Found CougarPoint PCH\n");
> - WARN_ON(!IS_GEN6(dev_priv) &&
> - !IS_IVYBRIDGE(dev_priv));
> - } else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
> - /* PantherPoint is CPT compatible */
> - dev_priv->pch_type = PCH_CPT;
> - DRM_DEBUG_KMS("Found PantherPoint PCH\n");
> - WARN_ON(!IS_GEN6(dev_priv) &&
> - !IS_IVYBRIDGE(dev_priv));
> - } else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found LynxPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) ||
> - IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> - !IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_WPT_DEVICE_ID_TYPE) {
> - /* WildcatPoint is LPT compatible */
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) ||
> - IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE) {
> - /* WildcatPoint is LPT compatible */
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> - !IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_SPT;
> - DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> - !IS_KABYLAKE(dev_priv));
> - } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_SPT;
> - DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> - !IS_KABYLAKE(dev_priv));
> - } else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_KBP;
> - DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> -  

Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[David Weinehall]

On Thu, Jan 25, 2018 at 02:03:29PM -0800, Rodrigo Vivi wrote:
> Now let's finish the Port-F support by adding the
> proper port F detection, irq and power well support.

lgtm,
Reviewed-by: David Weinehall 

> v2: Rebase
> v3: Use BIT_ULL
> v4: Cover missed case on ddi init.
> v5: Update commit message.
> v6: Rebase on top of display headers rework.
> v7: Squash power-well handling related to DDI F to this
> patch to avoid warns as pointed out by DK.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c|  4 
>  drivers/gpu/drm/i915/intel_display.c|  6 +-
>  drivers/gpu/drm/i915/intel_display.h|  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
>  5 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 076a49107e02..8261fe4c4316 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1304,6 +1304,7 @@ enum i915_power_well_id {
>   SKL_DISP_PW_DDI_B,
>   SKL_DISP_PW_DDI_C,
>   SKL_DISP_PW_DDI_D,
> + CNL_DISP_PW_DDI_F = 6,
>  
>   GLK_DISP_PW_AUX_A = 8,
>   GLK_DISP_PW_AUX_B,
> @@ -8945,6 +8946,7 @@ enum skl_power_gate {
>  #define  SFUSE_STRAP_RAW_FREQUENCY   (1<<8)
>  #define  SFUSE_STRAP_DISPLAY_DISABLED(1<<7)
>  #define  SFUSE_STRAP_CRT_DISABLED(1<<6)
> +#define  SFUSE_STRAP_DDIF_DETECTED   (1<<3)
>  #define  SFUSE_STRAP_DDIB_DETECTED   (1<<2)
>  #define  SFUSE_STRAP_DDIC_DETECTED   (1<<1)
>  #define  SFUSE_STRAP_DDID_DETECTED   (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e51559be2e3b..cfcd9cb37d5d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2946,6 +2946,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   intel_dig_port->ddi_io_power_domain =
>   POWER_DOMAIN_PORT_DDI_E_IO;
>   break;
> + case PORT_F:
> + intel_dig_port->ddi_io_power_domain =
> + POWER_DOMAIN_PORT_DDI_F_IO;
> + break;
>   default:
>   MISSING_CASE(port);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 83de43ce1f3b..fe3c09184c2e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5647,6 +5647,8 @@ enum intel_display_power_domain 
> intel_port_to_power_domain(enum port port)
>   return POWER_DOMAIN_PORT_DDI_D_LANES;
>   case PORT_E:
>   return POWER_DOMAIN_PORT_DDI_E_LANES;
> + case PORT_F:
> + return POWER_DOMAIN_PORT_DDI_F_LANES;
>   default:
>   MISSING_CASE(port);
>   return POWER_DOMAIN_PORT_OTHER;
> @@ -13619,7 +13621,7 @@ static void intel_setup_outputs(struct 
> drm_i915_private *dev_priv)
>   if (found || IS_GEN9_BC(dev_priv))
>   intel_ddi_init(dev_priv, PORT_A);
>  
> - /* DDI B, C and D detection is indicated by the SFUSE_STRAP
> + /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
>* register */
>   found = I915_READ(SFUSE_STRAP);
>  
> @@ -13629,6 +13631,8 @@ static void intel_setup_outputs(struct 
> drm_i915_private *dev_priv)
>   intel_ddi_init(dev_priv, PORT_C);
>   if (found & SFUSE_STRAP_DDID_DETECTED)
>   intel_ddi_init(dev_priv, PORT_D);
> + if (found & SFUSE_STRAP_DDIF_DETECTED)
> + intel_ddi_init(dev_priv, PORT_F);
>   /*
>* On SKL we don't have a way to detect DDI-E so we rely on VBT.
>*/
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index 30fa2041a45f..c4042e342f50 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -157,11 +157,13 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_PORT_DDI_C_LANES,
>   POWER_DOMAIN_PORT_DDI_D_LANES,
>   POWER_DOMAIN_PORT_DDI_E_LANES,
> + POWER_DOMAIN_PORT_DDI_F_LANES,
>   POWER_DOMAIN_PORT_DDI_A_IO,
>   POWER_DOMAIN_PORT_DDI_B_IO,
>   POWER_DOMAIN_PORT_DDI_C_IO,
>   POWER_DOMAIN_PORT_DDI_D_IO,
>   POWER_DOMAIN_PORT_DDI_E_IO,
> + POWER_DOMAIN_PORT_DDI_F_IO,
>   POWER_DOMAIN_PORT_DSI,
>   POWER_DOMAIN_PORT_CRT,
>   POWER_DOMAIN_PORT_OTHER,
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 3526b563b8ec..30e50ea16960 100644
> --- 

Re: [Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support

[David Weinehall]

On Thu, Jan 25, 2018 at 02:03:22PM -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
> 
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
> 

Looks good to me, except the dual sets of review comments and
signed-offs by, which seems kind of odd--did you squash two
patches into one?

Anyway, the code looks clean & documented, and the registers
seem to match documentation, so:

Reviewed-by: David Weinehall 

> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> v8: Fix Aux bits for Port F (DK)
> v9: Fix VBT definition of Port F (DK).
> v10: Squash power well addition to this patch to avoid
>  warns as pointed by DK.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> 
> drm/i915/cnl: Don't try to manage Port F power wells on all CNL.
> 
> SKUs that lacks on the full port F split will just time out
> when touching this power well bits, causing a noisy warn.
> 
> v2: Suggested-by: Imre. Temporarily remove the aux pw id after setting
> it instead of duplicating and redefining everything.
> v3: Simplify even more the logic, using one that don't mix the
> array size with the pw bits. Also add a comment.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c |  6 ++
>  drivers/gpu/drm/i915/i915_reg.h |  9 +
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_dp.c |  8 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +
>  6 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5702ebf17974..f89a1a0a25c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1255,6 +1255,7 @@ enum modeset_restore {
>  #define DP_AUX_B 0x10
>  #define DP_AUX_C 0x20
>  #define DP_AUX_D 0x30
> +#define DP_AUX_F 0x60
>  
>  #define DDC_PIN_B  0x05
>  #define DDC_PIN_C  0x04
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f643d5ad7ff7..4d84b1c41a94 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   GEN9_AUX_CHANNEL_C |
>   GEN9_AUX_CHANNEL_D;
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + tmp_mask |= CNL_AUX_CHANNEL_F;
> +
>   if (iir & tmp_mask) {
>   dp_aux_irq_handler(dev_priv);
>   found = true;
> @@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
>   }
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + de_port_masked |= CNL_AUX_CHANNEL_F;
> +
>   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
>  GEN8_PIPE_FIFO_UNDERRUN;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64933fd74cb6..44f46593172f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1312,6 +1312,7 @@ enum i915_power_well_id {
>   CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
>   CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
>   CNL_DISP_PW_AUX_D,
> + CNL_DISP_PW_AUX_F,
>  
>   SKL_DISP_PW_1 = 14,
>   SKL_DISP_PW_2,
> @@ -5284,6 +5285,13 @@ enum {
>  #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
>  #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
>  
> +#define _DPF_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64510)
> +#define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> +#define _DPF_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64518)
> +#define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
> +#define _DPF_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64520)
> +#define _DPF_AUX_CH_DATA5

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: reduce indent in pch detection

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: reduce indent in pch detection
URL   : https://patchwork.freedesktop.org/series/37180/
State : warning

== Summary ==

Series 37180v1 series starting with [1/2] drm/i915: reduce indent in pch 
detection
https://patchwork.freedesktop.org/api/1.0/series/37180/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-bdw-gvtdvm) fdo#103938
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-bdw-gvtdvm)

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:256  dwarn:8   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:528s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:461s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

59275f1cec1d31adab39ddb6ab948519ac8ddffb drm-tip: 2018y-01m-26d-13h-05m-14s UTC 
integration manifest
c4473bd127ee drm/i915: only assign dev_priv->pch_id on successful pch detection
25346b4e1a35 drm/i915: reduce indent in pch detection

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7790/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 1/2] drm/i915: reduce indent in pch detection

[Jani Nikula]

Save some horizontal space.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 189 
 1 file changed, 96 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ec12add34b2..3e8664de025d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -176,100 +176,103 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 * of only checking the first one.
 */
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
-   if (pch->vendor == PCI_VENDOR_ID_INTEL) {
-   unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
-
-   dev_priv->pch_id = id;
-
-   if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_IBX;
-   DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
-   WARN_ON(!IS_GEN5(dev_priv));
-   } else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_CPT;
-   DRM_DEBUG_KMS("Found CougarPoint PCH\n");
-   WARN_ON(!IS_GEN6(dev_priv) &&
-   !IS_IVYBRIDGE(dev_priv));
-   } else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
-   /* PantherPoint is CPT compatible */
-   dev_priv->pch_type = PCH_CPT;
-   DRM_DEBUG_KMS("Found PantherPoint PCH\n");
-   WARN_ON(!IS_GEN6(dev_priv) &&
-   !IS_IVYBRIDGE(dev_priv));
-   } else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_LPT;
-   DRM_DEBUG_KMS("Found LynxPoint PCH\n");
-   WARN_ON(!IS_HASWELL(dev_priv) &&
-   !IS_BROADWELL(dev_priv));
-   WARN_ON(IS_HSW_ULT(dev_priv) ||
-   IS_BDW_ULT(dev_priv));
-   } else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_LPT;
-   DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
-   WARN_ON(!IS_HASWELL(dev_priv) &&
-   !IS_BROADWELL(dev_priv));
-   WARN_ON(!IS_HSW_ULT(dev_priv) &&
-   !IS_BDW_ULT(dev_priv));
-   } else if (id == INTEL_PCH_WPT_DEVICE_ID_TYPE) {
-   /* WildcatPoint is LPT compatible */
-   dev_priv->pch_type = PCH_LPT;
-   DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
-   WARN_ON(!IS_HASWELL(dev_priv) &&
-   !IS_BROADWELL(dev_priv));
-   WARN_ON(IS_HSW_ULT(dev_priv) ||
-   IS_BDW_ULT(dev_priv));
-   } else if (id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE) {
-   /* WildcatPoint is LPT compatible */
-   dev_priv->pch_type = PCH_LPT;
-   DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
-   WARN_ON(!IS_HASWELL(dev_priv) &&
-   !IS_BROADWELL(dev_priv));
-   WARN_ON(!IS_HSW_ULT(dev_priv) &&
-   !IS_BDW_ULT(dev_priv));
-   } else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_SPT;
-   DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
-   WARN_ON(!IS_SKYLAKE(dev_priv) &&
-   !IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_SPT;
-   DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
-   WARN_ON(!IS_SKYLAKE(dev_priv) &&
-   !IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_KBP;
-   DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
-   WARN_ON(!IS_SKYLAKE(dev_priv) &&
-   !IS_KABYLAKE(dev_priv) &&
-   !IS_COFFEELAKE(dev_priv));
-   } else if (id == 

[Intel-gfx] [PATCH 2/2] drm/i915: only assign dev_priv->pch_id on successful pch detection

[Jani Nikula]

Currently pch_id gets assigned also when there's no pch. It doesn't look
like it makes a difference, but do the right thing anyway.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3e8664de025d..0332e315650c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -183,8 +183,6 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 
id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 
-   dev_priv->pch_id = id;
-
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_IBX;
DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
@@ -272,6 +270,8 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
continue;
}
 
+   dev_priv->pch_id = id;
+
break;
}
if (!pch)
-- 
2.11.0

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/lrc: Remove superfluous WARN_ON (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lrc: Remove superfluous WARN_ON (rev2)
URL   : https://patchwork.freedesktop.org/series/37165/
State : failure

== Summary ==

Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-snb) fdo#103880

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880

shard-apltotal:2838 pass:1752 dwarn:1   dfail:0   fail:21  skip:1064 
time:12660s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:12024s
shard-snbtotal:2758 pass:1290 dwarn:1   dfail:0   fail:10  skip:1457 
time:6519s
Blacklisted hosts:
shard-kbltotal:2825 pass:1856 dwarn:4   dfail:0   fail:22  skip:942 
time:9457s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7789/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 3/6] drm/i915: Give our log messages our name

[Michal Wajdeczko]

On Wed, 24 Jan 2018 17:18:18 +0100, Tvrtko Ursulin   
wrote:



From: Tvrtko Ursulin 

Define DRM_LOG_NAME to i915 so that the log messages we output change
from:

 [drm] RC6 on

to:

 [i915] RC6 on

Signed-off-by: Tvrtko Ursulin 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h  
b/drivers/gpu/drm/i915/i915_drv.h

index 8333692dac5a..2b48a7d2d129 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -30,6 +30,11 @@
 #ifndef _I915_DRV_H_
 #define _I915_DRV_H_
+#ifdef DRM_LOG_NAME
+#undef DRM_LOG_NAME
+#endif
+#define DRM_LOG_NAME "i915"


Maybe better option would be to add this definition to our Makefile

subdir-ccflags-y += -DDRM_LOG_NAME=\"i915\"

Note that drm_print.h (patch 2/6) already has proper #ifndef

Michal


+
 #include 
 #include 

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lrc: Remove superfluous WARN_ON (rev2)

[Chris Wilson]

Quoting Patchwork (2018-01-26 12:41:14)
> == Series Details ==
> 
> Series: drm/i915/lrc: Remove superfluous WARN_ON (rev2)
> URL   : https://patchwork.freedesktop.org/series/37165/
> State : success
> 
> == Summary ==
> 
> Series 37165v2 drm/i915/lrc: Remove superfluous WARN_ON
> https://patchwork.freedesktop.org/api/1.0/series/37165/revisions/2/mbox/
> 
> Test debugfs_test:
> Subgroup read_all_entries:
> dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-b:
> pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
> 
> fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
> fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

I'm feeling confident that a boot check is sufficient, so pushed. Thanks
for the review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lrc: Remove superfluous WARN_ON (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lrc: Remove superfluous WARN_ON (rev2)
URL   : https://patchwork.freedesktop.org/series/37165/
State : success

== Summary ==

Series 37165v2 drm/i915/lrc: Remove superfluous WARN_ON
https://patchwork.freedesktop.org/api/1.0/series/37165/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s

befe69597a107e14199eef8e3e24a1992d3c183b drm-tip: 2018y-01m-26d-11h-38m-09s UTC 
integration manifest
7d15dff0b77a drm/i915/lrc: Remove superfluous WARN_ON

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7789/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Remove superfluous WARN_ON

[Tvrtko Ursulin]

On 26/01/2018 12:18, Chris Wilson wrote:

Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).

v2: Move the deferred alloc guard into the callee, eliminating the need
for the WARN_ON:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1)
Function old new   delta
execlists_context_pin   18191818  -1

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1a3174371c8e..c8a11315b357 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1091,11 +1091,9 @@ execlists_context_pin(struct intel_engine_cs *engine,
goto out;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
  
-	if (!ce->state) {

-   ret = execlists_context_deferred_alloc(ctx, engine);
-   if (ret)
-   goto err;
-   }
+   ret = execlists_context_deferred_alloc(ctx, engine);
+   if (ret)
+   goto err;
GEM_BUG_ON(!ce->state);
  
  	ret = __context_pin(ctx, ce->state);

@@ -1419,7 +1417,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 */
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
-   if (WARN_ON(!IS_ALIGNED(wa_bb[i]->offset, CACHELINE_BYTES))) {
+   if (GEM_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
+   CACHELINE_BYTES))) {
ret = -EINVAL;
break;
}
@@ -2271,7 +2270,8 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
struct intel_ring *ring;
int ret;
  
-	WARN_ON(ce->state);

+   if (ce->state)
+   return 0;
  
  	context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
  



Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH v2] drm/i915/lrc: Remove superfluous WARN_ON

[Chris Wilson]

Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).

v2: Move the deferred alloc guard into the callee, eliminating the need
for the WARN_ON:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1)
Function old new   delta
execlists_context_pin   18191818  -1

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1a3174371c8e..c8a11315b357 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1091,11 +1091,9 @@ execlists_context_pin(struct intel_engine_cs *engine,
goto out;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
 
-   if (!ce->state) {
-   ret = execlists_context_deferred_alloc(ctx, engine);
-   if (ret)
-   goto err;
-   }
+   ret = execlists_context_deferred_alloc(ctx, engine);
+   if (ret)
+   goto err;
GEM_BUG_ON(!ce->state);
 
ret = __context_pin(ctx, ce->state);
@@ -1419,7 +1417,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 */
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
-   if (WARN_ON(!IS_ALIGNED(wa_bb[i]->offset, CACHELINE_BYTES))) {
+   if (GEM_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
+   CACHELINE_BYTES))) {
ret = -EINVAL;
break;
}
@@ -2271,7 +2270,8 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
struct intel_ring *ring;
int ret;
 
-   WARN_ON(ce->state);
+   if (ce->state)
+   return 0;
 
context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
 
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Remove superfluous WARN_ON

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-26 11:49:01)
> 
> On 26/01/2018 09:35, Chris Wilson wrote:
> > Remove the WARN_ON(ce->state) inside the static function only called
> > when ce->state == NULL and downgrade the w/a batch setup warning into a
> > developer only mode (GEM_WARN_ON).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 1a3174371c8e..50b37bf3682a 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1419,7 +1419,8 @@ static int intel_init_workaround_bb(struct 
> > intel_engine_cs *engine)
> >*/
> >   for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
> >   wa_bb[i]->offset = batch_ptr - batch;
> > - if (WARN_ON(!IS_ALIGNED(wa_bb[i]->offset, CACHELINE_BYTES))) {
> > + if (GEM_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
> > + CACHELINE_BYTES))) {
> >   ret = -EINVAL;
> >   break;
> >   }
> > @@ -2271,8 +2272,6 @@ static int execlists_context_deferred_alloc(struct 
> > i915_gem_context *ctx,
> >   struct intel_ring *ring;
> >   int ret;
> >   
> > - WARN_ON(ce->state);
> > -
> 
> Call path is a bit messy, maybe this would be better left as 
> GEM_WARN_ON, return -Esomething?

Caller is a straight if (!ce->state) deferred_alloc().

GEM_BUG_ON() at most, but since this is all static, it just looks
superfluous. Maybe just move the guard here and let the compiler sort it
out.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Remove superfluous WARN_ON

[Tvrtko Ursulin]

On 26/01/2018 09:35, Chris Wilson wrote:

Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1a3174371c8e..50b37bf3682a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1419,7 +1419,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 */
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
-   if (WARN_ON(!IS_ALIGNED(wa_bb[i]->offset, CACHELINE_BYTES))) {
+   if (GEM_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
+   CACHELINE_BYTES))) {
ret = -EINVAL;
break;
}
@@ -2271,8 +2272,6 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
struct intel_ring *ring;
int ret;
  
-	WARN_ON(ce->state);

-


Call path is a bit messy, maybe this would be better left as 
GEM_WARN_ON, return -Esomething?


Regards,

Tvrtko


context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
  
  	/*



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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/lrc: Remove superfluous WARN_ON

[Patchwork]

== Series Details ==

Series: drm/i915/lrc: Remove superfluous WARN_ON
URL   : https://patchwork.freedesktop.org/series/37165/
State : warning

== Summary ==

Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:22  skip:1064 
time:12783s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:12118s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:11  skip:1498 
time:6578s
Blacklisted hosts:
shard-kbltotal:2771 pass:1826 dwarn:4   dfail:0   fail:22  skip:918 
time:9584s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7788/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

[Jani Nikula]

On Tue, 23 Jan 2018, Harry Wentland  wrote:
> On 2018-01-22 05:43 PM, Manasi Navare wrote:
>> Existing helpers add support upto HBR2. This patch
>> adds support for HBR3 rate (8.1 Gbps) introduced as
>> part of DP 1.4 specification.
>> 
>> Cc: Rodrigo Vivi 
>> Cc: Jani Nikula 
>> Cc: dri-de...@lists.freedesktop.org
>> Signed-off-by: Manasi Navare 
>
> Both patches look right according to DP 1.4 spec.
>
> Series is
> Reviewed-by: Harry Wentland 

Both pushed to drm-misc-next, thanks for the patches and review.

BR,
Jani.

>
> Harry
>
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c   | 4 
>>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
>>  include/drm/drm_dp_helper.h   | 1 +
>>  3 files changed, 8 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index adf79be..ffe14ec 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -146,6 +146,8 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate)
>>  return DP_LINK_BW_2_7;
>>  case 54:
>>  return DP_LINK_BW_5_4;
>> +case 81:
>> +return DP_LINK_BW_8_1;
>>  }
>>  }
>>  EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
>> @@ -161,6 +163,8 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>>  return 27;
>>  case DP_LINK_BW_5_4:
>>  return 54;
>> +case DP_LINK_BW_8_1:
>> +return 81;
>>  }
>>  }
>>  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 70dcfa5..36df7df 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -2087,6 +2087,9 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
>>  case DP_LINK_BW_5_4:
>>  *out = 10 * dp_link_count;
>>  break;
>> +case DP_LINK_BW_8_1:
>> +*out = 15 * dp_link_count;
>> +break;
>>  }
>>  return true;
>>  }
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 9d3ce3b..c80fa92 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -334,6 +334,7 @@
>>  # define DP_LINK_BW_1_620x06
>>  # define DP_LINK_BW_2_7 0x0a
>>  # define DP_LINK_BW_5_4 0x14/* 1.2 */
>> +# define DP_LINK_BW_8_1 0x1e/* 1.4 */
>>  
>>  #define DP_LANE_COUNT_SET   0x101
>>  # define DP_LANE_COUNT_MASK 0x0f
>> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 07/27] drm/i915/icl: Interrupt handling

[Jani Nikula]

On Fri, 19 Jan 2018, Chris Wilson  wrote:
> Quoting Paulo Zanoni (2018-01-19 18:10:51)
>> Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu:
>> > On 10/01/2018 10:16, Joonas Lahtinen wrote:
>> > > If these are in a later patch, should be squashed here.
>> > 
>> > It might be possible in some cases, or it might be quite
>> > challenging in others. Need to look into it but no promises. We
>> > might have to live with having place holders like this in the code
>> > which get removed by later patches/series. It's quite complex
>> > logistically to organise multiple series, written by multiple
>> > authors, at different times, and make it look 100% pretty. (And not
>> > just squash and butcher everything up at merge time.)
>> 
>> I agree with Tvrtko here and in the other points above. If we take
>> Joonas's point to the extreme, ICL enabling would be a single giant
>> patch. We have to accept that some things are going to be incomplete
>> in the series that enable a platform. We also have the alpha_support
>> option to protect us here, and CI to make sure ICL's incompleteness
>> doesn't affect the other platforms.
>
> Later in this series is a patch which fixes a bug in this patch. That
> certainly needs to be addressed. ;)

Might be helpful to point that out...

As to the larger point of squashing stuff, it's hard to make the
division into patches for large enabling series just right. Sometimes
it's just an arbitrary choice that's been made at some point to not
bloat the patches too much and to not make the rebasing unnecessarily
hard. All other things being equal, I'd err toward whatever gets us
closer to merging the patches.

BR,
Jani.





> -Chris
> ___
> 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lrc: Remove superfluous WARN_ON

[Patchwork]

== Series Details ==

Series: drm/i915/lrc: Remove superfluous WARN_ON
URL   : https://patchwork.freedesktop.org/series/37165/
State : success

== Summary ==

Series 37165v1 drm/i915/lrc: Remove superfluous WARN_ON
https://patchwork.freedesktop.org/api/1.0/series/37165/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101600
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:476s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:530s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:471s

804d087465e907accca7a2631d8a9485729b9a48 drm-tip: 2018y-01m-25d-18h-22m-16s UTC 
integration manifest
7f199e3e6e0f drm/i915/lrc: Remove superfluous WARN_ON

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7788/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Jani Nikula]

On Thu, 25 Jan 2018, Rodrigo Vivi  wrote:
> The only difference is that this SKUs has the full
> Port A/E split named as Port F.
>
> But since SKUs differences don't matter on the platform
> definition group and ids, let's merge all off them together.
>
> v2: Really include the PCI IDs to the picidlist[];
> v3: Add the PCI Id for another SKU (Anusha).
> v4: Update IDs, really include to pciidlists again.
> v5: Unify all GT2 IDs.
> v6: Unify in a way that we don't break early-quirks.c
> v7: Remove GT reference since it doesn't matter here (Paulo)
> Also move IS_CNL_WITH_PORT_F macro to this patch to
> make it easier for review this part and also to get
> used sooner.
>
> Cc: Dhinakaran Pandiyan 
> Cc: Paulo Zanoni 
> Cc: Lucas De Marchi 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
>  include/drm/i915_pciids.h   | 18 +++---
>  3 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 454d8f937fae..5702ebf17974 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2648,6 +2648,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>(dev_priv)->info.gt == 2)
>  #define IS_CFL_GT3(dev_priv) (IS_COFFEELAKE(dev_priv) && \
>(dev_priv)->info.gt == 3)
> +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> + (INTEL_DEVID(dev_priv) & 0x0004) == 
> 0x0004)

I'd be happy if bit 2 in device id actually meant "port F", but I'm not
so happy with coming up with rules like this for coincidental things.

More generally, I'm not all that happy about *any* of the INTEL_DEVID
uses in i915_drv.h because it spreads out the device id information, so
I'd rather not add more. I'd rather move towards single point of truth
for device ids.

Okay, so this is late in the review cycles, and part of a more general
problem, so we should probably just go with this for now and come back
to this later.


BR,
Jani.




>  
>  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f28c165fc49d..7eb3d5e4350e 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -571,7 +571,7 @@ static const struct intel_device_info 
> intel_coffeelake_gt3_info __initconst = {
>   .ddb_size = 1024, \
>   GLK_COLORS
>  
> -static const struct intel_device_info intel_cannonlake_gt2_info __initconst 
> = {
> +static const struct intel_device_info intel_cannonlake_info __initconst = {
>   GEN10_FEATURES,
>   .is_alpha_support = 1,
>   .platform = INTEL_CANNONLAKE,
> @@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
>   INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
>   INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
> - INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
> - INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
> + INTEL_CNL_IDS(_cannonlake_info),
>   {0, 0, 0}
>  };
>  MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 5db0458dd832..9e1fe6634424 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -414,24 +414,20 @@
>   INTEL_CFL_U_GT2_IDS(info), \
>   INTEL_CFL_U_GT3_IDS(info)
>  
> -/* CNL U 2+2 */
> -#define INTEL_CNL_U_GT2_IDS(info) \
> +/* CNL */
> +#define INTEL_CNL_IDS(info) \
>   INTEL_VGA_DEVICE(0x5A52, info), \
>   INTEL_VGA_DEVICE(0x5A5A, info), \
>   INTEL_VGA_DEVICE(0x5A42, info), \
> - INTEL_VGA_DEVICE(0x5A4A, info)
> -
> -/* CNL Y 2+2 */
> -#define INTEL_CNL_Y_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x5A4A, info), \
>   INTEL_VGA_DEVICE(0x5A51, info), \
>   INTEL_VGA_DEVICE(0x5A59, info), \
>   INTEL_VGA_DEVICE(0x5A41, info), \
>   INTEL_VGA_DEVICE(0x5A49, info), \
>   INTEL_VGA_DEVICE(0x5A71, info), \
> - INTEL_VGA_DEVICE(0x5A79, info)
> -
> -#define INTEL_CNL_IDS(info) \
> - INTEL_CNL_U_GT2_IDS(info), \
> - INTEL_CNL_Y_GT2_IDS(info)
> + INTEL_VGA_DEVICE(0x5A79, info), \
> + INTEL_VGA_DEVICE(0x5A54, info), \
> + INTEL_VGA_DEVICE(0x5A5C, info), \
> + INTEL_VGA_DEVICE(0x5A44, info)
>  
>  #endif /* _I915_PCIIDS_H */

-- 
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/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Chris Wilson (2018-01-24 14:44:01)
> Quoting Tvrtko Ursulin (2018-01-24 13:09:37)
> > 
> > On 22/01/2018 15:41, Chris Wilson wrote:
> > > If we remember to cancel the signaler on a request when retiring it
> > > (after we know that the request has been signaled), we do not need to
> > > carry an additional request in the signaler itself. This prevents an
> > > issue whereby the signaler threads may be delayed and hold on to
> > > thousands of request references, causing severe memory fragmentation and
> > > premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
> > > and frequent use of inter-engine fences).
> > 
> > What is starving the signaler thread, which is set to SCHED_FIFO, and 
> > can't be tasklets on SNB?
> 
> Interrupts. MI_USER_INTERRUPT to be precise, but we have to check all
> the other sources on snb as well.
> 
> > Before I actually start revieweing the code, which I'd rather avoid :) :
> > 
> > Is it just not able to process enough requests in it's time-slice 
> > (need_resched) so is falling behind? It would be surprising since I 
> > would expect it to be much lighter wait processing there, per request, 
> > than on the submission paths.
> 
> The conclusion is a bit odd, but more or less it's just a pathological
> case where interrupts + rt task are contending for one cpu with
> submission proceeding on another. Making the signaler lighter was the
> intention of the rest of the series, but this patch by itself prevents
> the runaway references.

Whilst I'm thinking of this, when I hit oom on snb, there were ~3
million requests allocated (/proc/slabinfo) but only ~3 in-flight.
Tracing the request references gave the clue that the only outstanding
ones were in the signaler (there were only 2 sources of references, one
for the active request and one for the signaler; and we accounted for the
active request knowing that they were being retired).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] About client-controlled GPU workload preemption interface.

[Wang, Zhi A]

Hi:
　Recently, we're discussing about adding some interfaces to preempt and cancel 
the i915 request for GVT-g. After thinking and digging for a while, It looks 
like the requirement are quite generic.

 In a multi-buffered rendering window system, when some events happen, it will 
try to re-draw the screen. During this process, it might want to discard the 
previous workload ASAP then start the new workload, because the a new event 
came and it knew the drawing buffer was out-of-date. In this case, the drawing 
client might want to stop and cancel the workload immediately, then decided if 
the workload need to be re-submitted or not.

The Microsoft Windows rendering preemption also shows the same design and 
requirement for better desktop responsiveness. The preemption is controlled by 
the DirectX Graphics Kernel, aka DXGK, which manages the GPU workload 
scheduling and memory management and other generic resources. It provides some 
preemption hooks for the kernel model driver. When it want to stop the current 
workload, it dispatched the preempt request to the kernel mode driver. The 
re-submission is handled in DXGK.

So, it’s like there are two different kinds of GPU preemption with different 
purposes.

The current GPU preemption implementation in i915 is for those clients which 
just expect a "prioritized workload submission" and don’t expect to manipulate 
stopping and re-submitting the request by themselves.

For clients which expect to control the preemption in a fine granularity level 
for better responsiveness, new interfaces are required.

We can see the two mechanism are not conflicted and overlapped with each other. 
Both of the "prioritized workload submission" and "client-controlled GPU 
workload preemption" has their own field.

Though, the client-controlled GPU workload preemption interface might be only 
required by GVT-g at this time, but if we can see it as a common approach for a 
better drawing and rendering architecture, it would be better to be implemented 
as common APIs not only specific for GVT-g. (Maybe currently only some kernel 
APIs are enough for GVT-g, but if a user mode client also wants to use it, it 
would be easy to have an IOCTL at that time.)

To achieve a fine granularity preemption, the requirements are summarized as 
below:

1. A new interface for the client to be able to stop the workload submitted 
ASAP. The re-submission is controlled by the client. When the interface is 
called, the request might be already in SW scheduler queue or flying on HW. In 
the 1st case, the request can be directly kicked out from the SW scheduler 
queue. In the 2nd case, a preemption-to-idle to the flying request is necessary.

2. The synchronization interface has to aware the cancelation of the request 
and signal the client if the request is cancelled.

That's all in my mind and feel free to share your opinion. :)

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

[Intel-gfx] [PATCH] drm/i915/lrc: Remove superfluous WARN_ON

[Chris Wilson]

Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1a3174371c8e..50b37bf3682a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1419,7 +1419,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 */
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
-   if (WARN_ON(!IS_ALIGNED(wa_bb[i]->offset, CACHELINE_BYTES))) {
+   if (GEM_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
+   CACHELINE_BYTES))) {
ret = -EINVAL;
break;
}
@@ -2271,8 +2272,6 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
struct intel_ring *ring;
int ret;
 
-   WARN_ON(ce->state);
-
context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
 
/*
-- 
2.15.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT 
sequence (rev2)
URL   : https://patchwork.freedesktop.org/series/37105/
State : success

== Summary ==

Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup in-flight-contexts:
fail   -> PASS   (shard-hsw) fdo#104676
Subgroup hibernate:
pass   -> INCOMPLETE (shard-hsw) fdo#103540 +1
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-apl) fdo#103060
Subgroup flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#101623
Test drv_suspend:
Subgroup fence-restore-untiled-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:2838 pass:1752 dwarn:1   dfail:0   fail:21  skip:1064 
time:12663s
shard-hswtotal:2711 pass:1659 dwarn:1   dfail:0   fail:11  skip:1037 
time:11323s
shard-snbtotal:2838 pass:1329 dwarn:2   dfail:0   fail:9   skip:1498 
time:6636s
Blacklisted hosts:
shard-kbltotal:2771 pass:1793 dwarn:34  dfail:2   fail:21  skip:920 
time:9497s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7787/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915/icl: Enhanced execution list support

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-01-26 00:10:09)
> 
> 
> On 24/01/18 09:46, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2018-01-24 17:30:07)
> >> From: Thomas Daniel 
> >>
> >> Enhanced Execlists is an upgraded version of execlists which supports
> >> up to 8 ports. The lrcs to be submitted are written to a submit queue
> >> (the ExecLists Submission Queue - ELSQ), which is then loaded on the
> >> HW. When writing to the ELSP register, the lrcs are written cyclically
> >> in the queue from position 0 to position 7. Alternatively, it is
> >> possible to write directly in the individual positions of the queue
> >> using the ELSQC registers. To be able to re-use all the existing code
> >> we're using the latter method and we're currently limiting ourself to
> >> only using 2 elements.
> >>
> >> The preemption flow is sligthly different with enhanced execlists, so
> >> this patch turns preemption off temporarily for platforms with ELSQ
> >> while we wait for the new mechanism to land.
> >>
> >> v2: Rebase.
> >> v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
> >> v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
> >> v5: Reword commit, rename regs to be closer to specs, turn off
> >>  preemption (Daniele), reuse engine->execlists.elsp (Chris)
> >> v6: use has_logical_ring_elsq to differentiate the new paths
> >>
> >> Cc: Chris Wilson 
> >> Cc: Mika Kuoppala 
> >> Signed-off-by: Thomas Daniel 
> >> Signed-off-by: Rodrigo Vivi 
> >> Signed-off-by: Daniele Ceraolo Spurio 
> >> ---
> >>   drivers/gpu/drm/i915/i915_drv.h  |  7 ++-
> >>   drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
> >>   drivers/gpu/drm/i915/intel_device_info.h |  1 +
> >>   drivers/gpu/drm/i915/intel_lrc.c | 35 
> >> +++-
> >>   drivers/gpu/drm/i915/intel_lrc.h |  3 +++
> >>   drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 --
> >>   6 files changed, 46 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 8333692..346209a 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2741,8 +2741,13 @@ static inline unsigned int 
> >> i915_sg_segment_size(void)
> >>   
> >>   #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
> >>  ((dev_priv)->info.has_logical_ring_contexts)
> >> +#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
> >> +   ((dev_priv)->info.has_logical_ring_elsq)
> >> +
> >> +/* XXX: Preemption disabled for ELSQ until support for new flow lands */
> >>   #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> >> -   ((dev_priv)->info.has_logical_ring_preemption)
> >> +   ((dev_priv)->info.has_logical_ring_preemption && \
> >> +!HAS_LOGICAL_RING_ELSQ(dev_priv))
> > 
> > It's in the intel_device_info for a reason. I knew I should not have let
> > Michal turn this into a macro.
> > 
> 
> You mean setting has_logical_ring_preemption to zero directly? I thought 
> the policy was to avoid setting things in device_info to values that 
> don't reflect real HW capabilities and to do the hacks elsewhere.

No, data driven code. intel_device_info was introduced to remove having
heavy predicates so that we could see what will be enabled and what not
in one place.
 
> > I still do not see any reason why you don't just make the current
> > preemption work (it will) and then you can refine it if you prove it
> > worthwhile.
> > 
> 
> Just didn't see the worth of it ;). It's not a lot of code but it's in 
> an hot path and we're most likely going to get rid of it soon as the new 
> stuff is simpler. I'll put the change together and send it out so we can 
> evaluate that and see what works better with code at hand.

Is the new stuff going to be any simpler? You still need a preemption
point, so a special submission followed by detecting that in the CS
handler to do the unwind.

And whilst I am here, els is awful. Either stick with elsp and note that
they changed the name (+layout) on icl, or replace it with a generic
name. Spelling it out completely as execlists->execlists_submission is
still better than els, but submit[_reg] (or submit_hw) would be clearer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Chris Wilson]

Quoting Rafael Antognolli (2018-01-26 01:26:34)
> Write a PIPE_CONTROL with CS stall followed by 14 dwords of 0 in the
> indirect context wa bb.

14 MI_NOOPS following? That isn't what you wrote in the code, but the
main thing you haven't explained is why. A normal batch will already
have a flush in its setup, but more to the point would be the only
reason this is required is because of an implicit 3DSTATE inside the
context image on preemption. Right? Otherwise it seems to be a purely
userspace problem.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT 
sequence (rev2)
URL   : https://patchwork.freedesktop.org/series/37105/
State : success

== Summary ==

Series 37105v2 drm/i915: Fix DSI panels with v1 MIPI sequences without a 
DEASSERT sequence
https://patchwork.freedesktop.org/api/1.0/series/37105/revisions/2/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101600
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-cnl-y2total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:525s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:435s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

804d087465e907accca7a2631d8a9485729b9a48 drm-tip: 2018y-01m-25d-18h-22m-16s UTC 
integration manifest
57b4c65e08fb drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT 
sequence v2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7787/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx