[Intel-gfx] [PATCH v2 1/7] drm/i915: Check has_infoframes when enabling infoframes
From: Ville Syrjälä
has_infoframe is what tells us whether infoframes should be enabled, so
let's pass that instead of has_hdmi_sink to .set_infoframes().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 494fbe0..d838e8d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2150,7 +2150,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
- bool has_hdmi_sink,
+ bool has_infoframe,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state,
struct intel_shared_dpll *pll)
@@ -2177,7 +2177,7 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
cnl_ddi_vswing_sequence(encoder, level);
intel_hdmi->set_infoframes(drm_encoder,
- has_hdmi_sink,
+ has_infoframe,
crtc_state, conn_state);
}
@@ -2197,7 +2197,7 @@ static void intel_ddi_pre_enable(struct intel_encoder
*encoder,
}
if (type == INTEL_OUTPUT_HDMI) {
intel_ddi_pre_enable_hdmi(encoder,
- pipe_config->has_hdmi_sink,
+ pipe_config->has_infoframe,
pipe_config, conn_state,
pipe_config->shared_dpll);
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5609976..bab1c5a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1650,7 +1650,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder
*encoder,
intel_hdmi_prepare(encoder, pipe_config);
intel_hdmi->set_infoframes(&encoder->base,
- pipe_config->has_hdmi_sink,
+ pipe_config->has_infoframe,
pipe_config, conn_state);
}
@@ -1670,7 +1670,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder
*encoder,
0x2b247878);
intel_hdmi->set_infoframes(&encoder->base,
- pipe_config->has_hdmi_sink,
+ pipe_config->has_infoframe,
pipe_config, conn_state);
g4x_enable_hdmi(encoder, pipe_config, conn_state);
@@ -1742,7 +1742,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
chv_set_phy_signal_level(encoder, 128, 102, false);
intel_hdmi->set_infoframes(&encoder->base,
- pipe_config->has_hdmi_sink,
+ pipe_config->has_infoframe,
pipe_config, conn_state);
g4x_enable_hdmi(encoder, pipe_config, conn_state);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/7] drm/i915: check LSPCON vendor OUI
Intel LSPCON chip is provided by 2 vendors:
- Megachips America (MCA)
- Parade technologies (Parade tech)
Its important to know the vendor of this chip, as the address to
write AVI infoframes is different for those two.
This patch reads the vendor OUI signature, and marks into LSPCON
encoder structure for future usages.
This patch also does a small re-arrangement of the code, by moving
lspcon mode change into probe function.
V2: Use dp->desc for OUI detection, dont add a helper for this
(Ville)
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h| 6
drivers/gpu/drm/i915/intel_lspcon.c | 69 +
2 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7eadac0..adab635 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1043,9 +1043,15 @@ struct intel_dp {
struct intel_dp_compliance compliance;
};
+enum lspcon_vendor {
+ LSPCON_VENDOR_MCA,
+ LSPCON_VENDOR_PARADE
+};
+
struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
+ enum lspcon_vendor vendor;
};
struct intel_digital_port {
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 5abef482..93507c5 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -27,6 +27,10 @@
#include
#include "intel_drv.h"
+/* LSPCON OUI Vendor ID(signatures) */
+#define LSPCON_VENDOR_PARADE_OUI 0x001CF8
+#define LSPCON_VENDOR_MCA_OUI 0x0060AD
+
static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
{
struct intel_digital_port *dig_port =
@@ -50,6 +54,40 @@ static const char *lspcon_mode_name(enum drm_lspcon_mode
mode)
}
}
+static bool lspcon_detect_vendor(struct intel_lspcon *lspcon)
+{
+ struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
+ struct drm_dp_dpcd_ident *ident;
+ u32 vendor_oui;
+
+ if (drm_dp_read_desc(&dp->aux, &dp->desc, drm_dp_is_branch(dp->dpcd))) {
+ DRM_ERROR("Can't read description\n");
+ return false;
+ }
+
+ ident = &dp->desc.ident;
+ vendor_oui = (ident->oui[0] << 16) | (ident->oui[1] << 8) |
+ ident->oui[2];
+
+ switch (vendor_oui) {
+ case LSPCON_VENDOR_MCA_OUI:
+ lspcon->vendor = LSPCON_VENDOR_MCA;
+ DRM_DEBUG_KMS("Vendor: Mega Chips\n");
+ break;
+
+ case LSPCON_VENDOR_PARADE_OUI:
+ lspcon->vendor = LSPCON_VENDOR_PARADE;
+ DRM_DEBUG_KMS("Vendor: Parade Tech\n");
+ break;
+
+ default:
+ DRM_ERROR("Invalid/Unknown vendor OUI\n");
+ return false;
+ }
+
+ return true;
+}
+
static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
*lspcon)
{
enum drm_lspcon_mode current_mode;
@@ -151,7 +189,18 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
/* Yay ... got a LSPCON device */
DRM_DEBUG_KMS("LSPCON detected\n");
lspcon->mode = lspcon_wait_mode(lspcon, expected_mode);
- lspcon->active = true;
+
+ /*
+* In the SW state machine, lets Put LSPCON in PCON mode only.
+* In this way, it will work with both HDMI 1.4 sinks as well as HDMI
+* 2.0 sinks.
+*/
+ if (lspcon->active && lspcon->mode != DRM_LSPCON_MODE_PCON) {
+ if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
+ DRM_ERROR("LSPCON mode change to PCON failed\n");
+ return false;
+ }
+ }
return true;
}
@@ -223,25 +272,17 @@ bool lspcon_init(struct intel_digital_port
*intel_dig_port)
return false;
}
- /*
- * In the SW state machine, lets Put LSPCON in PCON mode only.
- * In this way, it will work with both HDMI 1.4 sinks as well as HDMI
- * 2.0 sinks.
- */
- if (lspcon->active && lspcon->mode != DRM_LSPCON_MODE_PCON) {
- if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
- DRM_ERROR("LSPCON mode change to PCON failed\n");
- return false;
- }
- }
-
if (!intel_dp_read_dpcd(dp)) {
DRM_ERROR("LSPCON DPCD read failed\n");
return false;
}
- drm_dp_read_desc(&dp->aux, &dp->desc, drm_dp_is_branch(dp->dpcd));
+ if (!lspcon_detect_vendor(lspcon)) {
+ DRM_ERROR("LSPCON vendor detection failed\n");
+ return false;
+ }
+ lspcon->active = true;
DRM_DEBUG_KMS("Success: LSPCON init\n");
return true;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.free
[Intel-gfx] [PATCH v2 6/7] drm/i915: write AVI infoframes for LSPCON
To pass AVI infoframes from display controller to LSPCON, we
have to write infoframe packets into vendor specified AUX address,
in vendor specified way.
Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
chip that the AVI IF packets are written, so that the firmware
can pick it up and apply.
This patch adds function to write AVI infoframes for both MCA as
well as Parade Tech LSPCON chips. These two vendors provide different
methods for writing infoframes, so this patch contains two different
functions, one for each.
V2: Rebase
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c| 12 +-
drivers/gpu/drm/i915/intel_drv.h| 16 +++
drivers/gpu/drm/i915/intel_hdmi.c | 15 ++-
drivers/gpu/drm/i915/intel_lspcon.c | 246
4 files changed, 284 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9384080..08f3567 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2193,6 +2193,15 @@ static void intel_ddi_pre_enable(struct intel_encoder
*encoder,
pipe_config->shared_dpll,
intel_crtc_has_type(pipe_config,
INTEL_OUTPUT_DP_MST));
+
+ if (pipe_config->lspcon_active) {
+ struct intel_digital_port *dig_port =
+ enc_to_dig_port(&encoder->base);
+
+ dig_port->set_infoframes(&encoder->base,
+pipe_config->has_infoframe,
+pipe_config, conn_state);
+ }
}
if (type == INTEL_OUTPUT_HDMI) {
intel_ddi_pre_enable_hdmi(encoder,
@@ -2734,8 +2743,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
- intel_infoframe_init(intel_dig_port);
-
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
@@ -2765,6 +2772,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
port_name(port));
}
+ intel_infoframe_init(intel_dig_port);
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index adab635..99eaab6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1052,6 +1052,10 @@ struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
enum lspcon_vendor vendor;
+
+ void (*write_infoframe)(struct drm_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ union hdmi_infoframe *frame);
};
struct intel_digital_port {
@@ -1978,6 +1982,18 @@ void intel_color_load_luts(struct drm_crtc_state
*crtc_state);
bool lspcon_init(struct intel_digital_port *intel_dig_port);
void lspcon_resume(struct intel_lspcon *lspcon);
void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
+bool lspcon_ycbcr420_config(struct drm_connector *connector,
+struct intel_crtc_state *config);
+void lspcon_write_infoframe(struct drm_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ enum hdmi_infoframe_type type,
+ const void *buf, ssize_t len);
+void lspcon_set_infoframes(struct drm_encoder *encoder,
+ bool enable,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+bool lspcon_infoframe_enabled(struct drm_encoder *encoder,
+ const struct intel_crtc_state *pipe_config);
/* intel_pipe_crc.c */
int intel_pipe_crc_create(struct drm_minor *minor);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e4a27e1..5710029 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1909,9 +1909,18 @@ void intel_infoframe_init(struct intel_digital_port
*intel_dig_port)
intel_dig_port->set_infoframes = g4x_set_infoframes;
intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
} else if (HAS_DDI(dev_priv)) {
- intel_dig_port->write_infoframe = hsw_write_infoframe;
- intel_dig_port->set_infoframes = hsw_set_infoframes;
- intel_dig_port->infoframe_enabled = hsw_infoframe_enabled;
+ if (intel_dig_port->lspcon.active) {
+ intel_dig_port->write_infoframe =
+ lspcon_write_infoframe;
+
[Intel-gfx] [PATCH v2 4/7] drm/i915: Init infoframe vfuncs for DP encoders as well
From: Ville Syrjälä
DP ports may want to use the video DIP for SDP transmission, so let's
initialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 52 ++-
4 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 554d3ce..9384080 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2734,6 +2734,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
+ intel_infoframe_init(intel_dig_port);
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2d42d09..d580243 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6150,6 +6150,9 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;
+ if (port != PORT_A)
+ intel_infoframe_init(intel_dig_port);
+
if (!intel_dp_init_connector(intel_dig_port, intel_connector))
goto err_init_connector;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bde2547..7eadac0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1650,6 +1650,7 @@ void intel_hdmi_handle_sink_scrambling(struct
intel_encoder *intel_encoder,
bool high_tmds_clock_ratio,
bool scrambling);
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
+void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
/* intel_lvds.c */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index d1973ff..e4a27e1 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1895,6 +1895,34 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private
*dev_priv,
return ddc_pin;
}
+void intel_infoframe_init(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_i915_private *dev_priv =
+ to_i915(intel_dig_port->base.base.dev);
+
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ intel_dig_port->write_infoframe = vlv_write_infoframe;
+ intel_dig_port->set_infoframes = vlv_set_infoframes;
+ intel_dig_port->infoframe_enabled = vlv_infoframe_enabled;
+ } else if (IS_G4X(dev_priv)) {
+ intel_dig_port->write_infoframe = g4x_write_infoframe;
+ intel_dig_port->set_infoframes = g4x_set_infoframes;
+ intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
+ } else if (HAS_DDI(dev_priv)) {
+ intel_dig_port->write_infoframe = hsw_write_infoframe;
+ intel_dig_port->set_infoframes = hsw_set_infoframes;
+ intel_dig_port->infoframe_enabled = hsw_infoframe_enabled;
+ } else if (HAS_PCH_IBX(dev_priv)) {
+ intel_dig_port->write_infoframe = ibx_write_infoframe;
+ intel_dig_port->set_infoframes = ibx_set_infoframes;
+ intel_dig_port->infoframe_enabled = ibx_infoframe_enabled;
+ } else {
+ intel_dig_port->write_infoframe = cpt_write_infoframe;
+ intel_dig_port->set_infoframes = cpt_set_infoframes;
+ intel_dig_port->infoframe_enabled = cpt_infoframe_enabled;
+ }
+}
+
void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
{
@@ -1944,28 +1972,6 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
return;
}
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- intel_dig_port->write_infoframe = vlv_write_infoframe;
- intel_dig_port->set_infoframes = vlv_set_infoframes;
- intel_dig_port->infoframe_enabled = vlv_infoframe_enabled;
- } else if (IS_G4X(dev_priv)) {
- intel_dig_port->write_infoframe = g4x_write_infoframe;
- intel_dig_port->set_infoframes = g4x_set_infoframes;
- intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
- } else if (HAS_DDI(dev_priv)) {
- intel_dig_port->write_infoframe = hsw_write_infoframe;
-
[Intel-gfx] [PATCH v2 0/7] YCBCR 4:2:0 support for LSPCON
LSPCON is a DP->HDMI active dongle, enumerated as DP dual mode adapter on Intel GEN9 platforms. It's provided by two different vendors - Mega Chips America (MCA) - Parade Technologies (Parade) In order to support YCBCR 4:2:0 outputs, these are the essential steps: - Convert HDMI output format from RGB to YCBCR 4:4:4. - Set appropriate color space in AVI infoframes. - Write AVI infoframes to vendor specific AUX registers. This patch series adds 7 patches, to accommodate above steps and enable YCBCR 4:2:0 output for LSPCON based HDMI displays. First 4 patches are from Ville Syrjälä's patch series, which makes infoframe functions available for DDI displays, published here: https://patchwork.freedesktop.org/series/8183/ Rest 3 patches add: - Vendor identification for LSPCON chips. - AVI infoframe infrastructure for LSPCON displays. - 4:2:0 support for LSPCON displays. Shashank Sharma (3): drm/i915: check LSPCON vendor OUI drm/i915: write AVI infoframes for LSPCON drm/i915: YCBCR 420 support for LSPCON Ville Syrjälä (4): drm/i915: Check has_infoframes when enabling infoframes drm/i915: Disable infoframes when shutting down DDI HDMI drm/i915: Move infoframe vfuncs into intel_digital_port drm/i915: Init infoframe vfuncs for DP encoders as well drivers/gpu/drm/i915/intel_ddi.c | 37 ++-- drivers/gpu/drm/i915/intel_display.c | 15 +- drivers/gpu/drm/i915/intel_dp.c | 16 +- drivers/gpu/drm/i915/intel_drv.h | 54 -- drivers/gpu/drm/i915/intel_hdmi.c| 97 ++- drivers/gpu/drm/i915/intel_lspcon.c | 317 +-- 6 files changed, 457 insertions(+), 79 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/7] drm/i915: Move infoframe vfuncs into intel_digital_port
From: Ville Syrjälä
DP ports will also want to utilize the video DIP for SDP transmission.
So let's move the vfuncs into the dig_port.
v2: Rebase due to DDI changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 22 ++---
drivers/gpu/drm/i915/intel_drv.h | 21 +++--
drivers/gpu/drm/i915/intel_hdmi.c | 66 +--
3 files changed, 56 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fdfc314..554d3ce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2155,12 +2155,11 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
const struct drm_connector_state
*conn_state,
struct intel_shared_dpll *pll)
{
- struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
+ struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
+ struct intel_hdmi *intel_hdmi = &dig_port->hdmi;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct drm_encoder *drm_encoder = &encoder->base;
enum port port = intel_ddi_get_encoder_port(encoder);
int level = intel_ddi_hdmi_level(dev_priv, port);
- struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
intel_ddi_clk_select(encoder, pll);
@@ -2176,9 +2175,9 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
else if (IS_CANNONLAKE(dev_priv))
cnl_ddi_vswing_sequence(encoder, level);
- intel_hdmi->set_infoframes(drm_encoder,
- has_infoframe,
- crtc_state, conn_state);
+ dig_port->set_infoframes(&encoder->base,
+has_infoframe,
+crtc_state, conn_state);
}
static void intel_ddi_pre_enable(struct intel_encoder *encoder,
@@ -2239,9 +2238,7 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder,
intel_wait_ddi_buf_idle(dev_priv, port);
if (type == INTEL_OUTPUT_HDMI) {
- struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
-
- intel_hdmi->set_infoframes(encoder, false,
+ dig_port->set_infoframes(encoder, false,
old_crtc_state, old_conn_state);
}
@@ -2442,7 +2439,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
- struct intel_hdmi *intel_hdmi;
+ struct intel_digital_port *intel_dig_port;
u32 temp, flags = 0;
/* XXX: DSI transcoder paranoia */
@@ -2481,9 +2478,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
case TRANS_DDI_MODE_SELECT_HDMI:
pipe_config->has_hdmi_sink = true;
- intel_hdmi = enc_to_intel_hdmi(&encoder->base);
+ intel_dig_port = enc_to_dig_port(&encoder->base);
- if (intel_hdmi->infoframe_enabled(&encoder->base, pipe_config))
+ if (intel_dig_port->infoframe_enabled(&encoder->base,
+ pipe_config))
pipe_config->has_infoframe = true;
if ((temp & TRANS_DDI_HDMI_SCRAMBLING_MASK) ==
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ee0daec..bde2547 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -909,16 +909,6 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
- void (*write_infoframe)(struct drm_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- enum hdmi_infoframe_type type,
- const void *frame, ssize_t len);
- void (*set_infoframes)(struct drm_encoder *encoder,
- bool enable,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state);
- bool (*infoframe_enabled)(struct drm_encoder *encoder,
- const struct intel_crtc_state *pipe_config);
};
struct intel_dp_mst_encoder;
@@ -1069,6 +1059,17 @@ struct intel_digital_port {
bool release_cl2_override;
uint8_t max_lanes;
enum intel_display_power_domain ddi_io_power_domain;
+
+
[Intel-gfx] [PATCH v2 2/7] drm/i915: Disable infoframes when shutting down DDI HDMI
From: Ville Syrjälä
Disabling the video DIP when shutting the port down seems like a good
idea.
Bspec says:
"When disabling both the DIP port and DIP transmission,
first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL
for HDMI with bits per color not equal to 8 and disabled after disabling
TRANS_DDI_FUNC_CTL"
So let's do it in the .post_disable() hook.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d838e8d..fdfc314 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2238,6 +2238,13 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder,
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
+ if (type == INTEL_OUTPUT_HDMI) {
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+
+ intel_hdmi->set_infoframes(encoder, false,
+ old_crtc_state, old_conn_state);
+ }
+
if (intel_dp) {
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915: YCBCR 420 support for LSPCON
LSPCON chips support YCBCR420 outputs. To be able to get
YCBCR420 output from LSPCON chip, the source should:
- Generate YCBCR444 HDMI output
- Set AVI infoframes for a YCBCR420 output.
Unlike Native HDMI 4:2:0 outputs, there is no need to
reserve a scaler in pipe, LSPCON does the downsampling from
YCBCR 4:4:4 to 4:2:0 on its own.
LSPCON FW gets the information from AVI infoframes, and generates
YCBCR420 output from a YCBCR444 input. This patch adds the necessary
changes to drive YCBCR420 output from LSPCON based HDMI output.
V2: Dont mess around with 8bpc and 12bpc clocks, its not reqd
for DP links. (Ville)
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_dp.c | 13 -
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_lspcon.c | 2 ++
4 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5a89db1..eb1d93b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4487,7 +4487,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
- if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
+ if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX &&
+ !crtc_state->lspcon_active)
need_scaling = true;
/*
@@ -7970,9 +7971,15 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
if (config->ycbcr420) {
- val |= PIPEMISC_OUTPUT_COLORSPACE_YUV |
- PIPEMISC_YUV420_ENABLE |
- PIPEMISC_YUV420_MODE_FULL_BLEND;
+ val |= PIPEMISC_OUTPUT_COLORSPACE_YUV;
+ /*
+* LSPCON doesn't need scaling/blending to be done in
+* pipe. It just needs YCBCR444 input and proper AVI
+* infoframes for 4:2:0 output enabling.
+*/
+ if (!config->lspcon_active)
+ val |= PIPEMISC_YUV420_ENABLE |
+ PIPEMISC_YUV420_MODE_FULL_BLEND;
}
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d580243..b7774cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1614,7 +1614,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
- enum port port = dp_to_dig_port(intel_dp)->port;
+ struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
+ enum port port = dig_port->port;
+ struct intel_lspcon *lspcon = &dig_port->lspcon;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct intel_digital_connector_state *intel_conn_state =
@@ -1635,6 +1637,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
common_len = intel_dp_common_len_rate_limit(intel_dp,
intel_dp->max_link_rate);
+ /* LSPCON needs special handling to drive YCBCR420 outputs */
+ if (lspcon->active) {
+ struct drm_connector *connector = &intel_connector->base;
+
+ pipe_config->lspcon_active = true;
+ pipe_config->ycbcr420 = lspcon_ycbcr420_config(connector,
+ pipe_config);
+ }
+
/* No common link rates between source and sink */
WARN_ON(common_len <= 0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 99eaab6..b3cbe2d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -783,6 +783,9 @@ struct intel_crtc_state {
/* output format is YCBCR 4:2:0 */
bool ycbcr420;
+
+ /* LSPCON is active on port */
+ bool lspcon_active;
};
struct intel_crtc {
@@ -1182,6 +1185,12 @@ static inline struct intel_dp *enc_to_intel_dp(struct
drm_encoder *encoder)
return &enc_to_dig_port(encoder)->dp;
}
+static inline struct intel_lspcon *
+enc_to_intel_lspcon(struct drm_encoder *encoder)
+{
+ return &enc_to_dig_port(encoder)->lspcon;
+}
+
static inline struct intel_digital_port *
dp_to_dig_port(struct intel_dp *intel_dp)
{
@@ -
Re: [Intel-gfx] [PATCH v13 6/7] drm/i915: Introduce GEM proxy
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> Joonas Lahtinen
> Sent: Monday, August 7, 2017 4:24 PM
> To: Zhang, Tina ; intel-gfx@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; zhen...@linux.intel.com; Lv, Zhiyuan
> ; Wang, Zhi A ;
> alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk;
> dan...@ffwll.ch; kwankh...@nvidia.com; Tian, Kevin
> Subject: Re: [Intel-gfx] [PATCH v13 6/7] drm/i915: Introduce GEM proxy
>
> On ti, 2017-07-25 at 17:28 +0800, Tina Zhang wrote:
> > GEM proxy is a kind of GEM, whose backing physical memory is pinned
> > and produced by guest VM and is used by host as read only. With GEM
> > proxy, host is able to access guest physical memory through GEM object
> > interface. As GEM proxy is such a special kind of GEM, a new flag
> > I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
> > backing storage of GEM proxy.
> >
>
> It is a good idea to add a changelog here to indicate what was changed since
> the
> last patch revision. It'll be easier for the reviewer to spot the differences.
>
> It's also a good idea to add Cc: line for somebody who provided previous
> review,
> this will, too, allow spotting the patch quicker.
Indeed. Thanks.
Tina
>
> > Signed-off-by: Tina Zhang
>
>
>
> > @@ -1730,7 +1744,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> void *data,
> > */
> > if (!obj->base.filp) {
> > i915_gem_object_put(obj);
> > - return -EINVAL;
> > + return -EPERM;
> > }
>
> This hunk should be separate bugfix patch, but other than that the patch looks
> OK to me.
Thanks. I will send this patch separately.
Tina
>
> I'll let Chris comment if he feels previous comments were adequately
> addressed.
>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 1/3] drm/i915/gvt: Add shadow context descriptor updating
From: Kechen Lu
The current context logic only updates the descriptor of context when
it's being pinned to graphics memory space. But this cannot satisfy the
requirement of shadow context. The addressing mode of the pinned shadow
context descriptor may be changed according to the guest addressing mode.
And this won't be updated, as the already pinned shadow context has no
chance to update its descriptor. And this will lead to GPU hang issue,
as shadow context is used with wrong descriptor. This patch fixes this
issue by letting the pinned shadow context descriptor update its
addressing mode on demand.
This patch fixes GPU HANG issue which happends after changing the
grub parameter i915.enable_ppgtt form 0x01 to 0x03 or vice versa and
then rebooting the guest.
Signed-off-by: Tina Zhang
Signed-off-by: Kechen Lu
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/execlist.c
index 3380865..df11f69 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -796,6 +796,8 @@ static void clean_workloads(struct intel_vgpu *vgpu,
unsigned long engine_mask)
list_del_init(&pos->list);
free_workload(pos);
}
+
+ clear_bit(engine->id, vgpu->shadow_ctx_desc_updated);
}
}
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index ba53ad1..ea73671 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -167,6 +167,7 @@ struct intel_vgpu {
atomic_t running_workload_num;
DECLARE_BITMAP(tlb_handle_pending, I915_NUM_ENGINES);
struct i915_gem_context *shadow_ctx;
+ DECLARE_BITMAP(shadow_ctx_desc_updated, I915_NUM_ENGINES);
#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
struct {
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index ca1926d..025aba8 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -184,6 +184,23 @@ static int shadow_context_status_change(struct
notifier_block *nb,
return NOTIFY_OK;
}
+static void shadow_context_descriptor_update(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ struct intel_context *ce = &ctx->engine[engine->id];
+ u64 desc = 0;
+
+ desc = ce->lrc_desc;
+
+ /* Update bits 0-11 of the context descriptor which includes flags
+* like GEN8_CTX_* cached in desc_template
+*/
+ desc &= U64_MAX << 12;
+ desc |= ctx->desc_template & ((1ULL << 12) - 1);
+
+ ce->lrc_desc = desc;
+}
+
/**
* intel_gvt_scan_and_shadow_workload - audit the workload by scanning and
* shadow it as well, include ringbuffer,wa_ctx and ctx.
@@ -210,6 +227,10 @@ int intel_gvt_scan_and_shadow_workload(struct
intel_vgpu_workload *workload)
shadow_ctx->desc_template |= workload->ctx_desc.addressing_mode <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
+ if (!test_and_set_bit(ring_id, vgpu->shadow_ctx_desc_updated))
+ shadow_context_descriptor_update(shadow_ctx,
+ dev_priv->engine[ring_id]);
+
rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
if (IS_ERR(rq)) {
gvt_vgpu_err("fail to allocate gem request\n");
@@ -656,5 +677,7 @@ int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
vgpu->shadow_ctx->engine[RCS].initialised = true;
+ bitmap_zero(vgpu->shadow_ctx_desc_updated, I915_NUM_ENGINES);
+
return 0;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 0/3] drm/i915/gvt: Enable guest i915 48bit full ppgtt support
This patch set is used to enable guest i915 48bit full ppgtt support. v8: 1) CC intel-gfx on i915 change. (Zhenyu) v7: 1) Include a new patch for fixing reboot GPU hang issue. (Kechen) Kechen Lu (1): drm/i915/gvt: Add shadow context descriptor updating Tina Zhang (2): drm/i915/gvt: Fix guest i915 full ppgtt blocking issue drm/i915: Enable guest i915 full ppgtt functionality drivers/gpu/drm/i915/gvt/execlist.c | 2 ++ drivers/gpu/drm/i915/gvt/gtt.c | 45 ++-- drivers/gpu/drm/i915/gvt/gvt.h | 1 + drivers/gpu/drm/i915/gvt/scheduler.c | 23 ++ drivers/gpu/drm/i915/gvt/vgpu.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++ drivers/gpu/drm/i915/i915_pvinfo.h | 8 ++- drivers/gpu/drm/i915/i915_vgpu.c | 7 ++ drivers/gpu/drm/i915/i915_vgpu.h | 3 +++ 10 files changed, 83 insertions(+), 22 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 2/3] drm/i915/gvt: Fix guest i915 full ppgtt blocking issue
Guest i915 full ppgtt functionality was blocking by an issue, which would
lead to gpu hardware hang. Guest i915 driver may update the ppgtt table
just before this workload is going to be submitted to the hardware by
device model. This case wasn't handled well by device model before, due
to the small time window between removing old ppgtt entry and adding the
new one. Errors occur when the workload is executed by hardware during
that small time window. This patch is to remove this time window by adding
the new ppgtt entry first and then remove the old one.
Changes in v2:
- Move VGT_CAPS_FULL_PPGTT introduction to patch 2/4. (Joonas)
Changes since v2:
- Divide the whole patch set into two separate patch series, with one
patch in i915 side to check guest i915 full ppgtt capability and enable
it when this capability is supported by the device model, and the other
one in gvt side which fixs the blocking issue and enables the device
model to provide the capability to guest. And this patch focuses on gvt
side. (Joonas)
- Change the title from "reorder the shadow ppgtt update process by adding
entry first" to "Fix guest i915 full ppgtt blocking issue". (Tina)
Changes since v3:
- Rebase to the latest branch.
Changes since v4:
- Tested by Tina Zhang.
Changes since v5:
- Rebase to the latest branch.
Signed-off-by: Tina Zhang
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 6166e34..27bda42 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -979,29 +979,26 @@ static int ppgtt_populate_shadow_page(struct
intel_vgpu_ppgtt_spt *spt)
}
static int ppgtt_handle_guest_entry_removal(struct intel_vgpu_guest_page *gpt,
- unsigned long index)
+ struct intel_gvt_gtt_entry *se, unsigned long index)
{
struct intel_vgpu_ppgtt_spt *spt = guest_page_to_ppgtt_spt(gpt);
struct intel_vgpu_shadow_page *sp = &spt->shadow_page;
struct intel_vgpu *vgpu = spt->vgpu;
struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
- struct intel_gvt_gtt_entry e;
int ret;
- ppgtt_get_shadow_entry(spt, &e, index);
-
- trace_gpt_change(spt->vgpu->id, "remove", spt, sp->type, e.val64,
+ trace_gpt_change(spt->vgpu->id, "remove", spt, sp->type, se->val64,
index);
- if (!ops->test_present(&e))
+ if (!ops->test_present(se))
return 0;
- if (ops->get_pfn(&e) == vgpu->gtt.scratch_pt[sp->type].page_mfn)
+ if (ops->get_pfn(se) == vgpu->gtt.scratch_pt[sp->type].page_mfn)
return 0;
- if (gtt_type_is_pt(get_next_pt_type(e.type))) {
+ if (gtt_type_is_pt(get_next_pt_type(se->type))) {
struct intel_vgpu_ppgtt_spt *s =
- ppgtt_find_shadow_page(vgpu, ops->get_pfn(&e));
+ ppgtt_find_shadow_page(vgpu, ops->get_pfn(se));
if (!s) {
gvt_vgpu_err("fail to find guest page\n");
ret = -ENXIO;
@@ -1011,12 +1008,10 @@ static int ppgtt_handle_guest_entry_removal(struct
intel_vgpu_guest_page *gpt,
if (ret)
goto fail;
}
- ops->set_pfn(&e, vgpu->gtt.scratch_pt[sp->type].page_mfn);
- ppgtt_set_shadow_entry(spt, &e, index);
return 0;
fail:
gvt_vgpu_err("fail: shadow page %p guest entry 0x%llx type %d\n",
- spt, e.val64, e.type);
+ spt, se->val64, se->type);
return ret;
}
@@ -1236,22 +1231,37 @@ static int ppgtt_handle_guest_write_page_table(
{
struct intel_vgpu_ppgtt_spt *spt = guest_page_to_ppgtt_spt(gpt);
struct intel_vgpu *vgpu = spt->vgpu;
+ int type = spt->shadow_page.type;
struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
+ struct intel_gvt_gtt_entry se;
int ret;
int new_present;
new_present = ops->test_present(we);
- ret = ppgtt_handle_guest_entry_removal(gpt, index);
- if (ret)
- goto fail;
+ /*
+* Adding the new entry first and then removing the old one, that can
+* guarantee the ppgtt table is validated during the window between
+* adding and removal.
+*/
+ ppgtt_get_shadow_entry(spt, &se, index);
if (new_present) {
ret = ppgtt_handle_guest_entry_add(gpt, we, index);
if (ret)
goto fail;
}
+
+ ret = ppgtt_handle_guest_entry_removal(gpt, &se, index);
+ if (ret)
+ goto fail;
+
+ if (!new_present) {
+ ops->set_pfn(&se, vgpu->gtt.scratch_pt[type].page_mfn);
+ ppgtt_set_shadow_entry(spt, &se, index);
+ }
+
return 0;
fail:
gvt_vgpu_err("fail: shadow page %p guest entry 0x%llx type %d.\n",
@@ -1323,7 +1333,7 @@ static int ppgtt_handle_guest_write_page_t
[Intel-gfx] [PATCH v8 3/3] drm/i915: Enable guest i915 full ppgtt functionality
Enable the guest i915 full ppgtt functionality when host can provide this
capability. vgt_caps is introduced to guest i915 driver to get the vgpu
capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the
capabilities type to let guest i915 dirver know that the guest i915 full
ppgtt is supported by device model.
Notice that the minor version of pvinfo isn't bumped because of this
vgt_caps introduction, due to older guest would be broken by simply
increasing the pvinfo version. Although the pvinfo minor version doesn't
increase, the compatibility won't be blocked. The compatibility is ensured
by checking the value of caps field in pvinfo. Zero means no full ppgtt
support and BIT(2) means this feature is provided.
Changes since v1:
- Use u32 instead of uint32_t (Joonas)
- Move VGT_CAPS_FULL_PPGTT introduction to this patch and use #define
instead of enum (Joonas)
- Rewrite the vgpu full ppgtt capability checking logic. (Joonas)
- Some coding style refine. (Joonas)
Changes since v2:
- Divide the whole patch set into two separate patch series, with one
patch in i915 side to check guest i915 full ppgtt capability and enable
it when this capability is supported by the device model, and the other
one in gvt side which fixs the blocking issue and enables the device
model to provide the capability to guest. And this patch focuses on guest
i915 side. (Joonas)
- Change the title from "introduce vgt_caps to pvinfo" to
"Enable guest i915 full ppgtt functionality". (Tina)
Change since v3:
- Add some comments about pvinfo caps and version. (Joonas)
Change since v4:
- Tested by Tina Zhang.
Change since v5:
- Add limitation about supporting 32bit full ppgtt.
Change since v6:
- Change the fallback to 48bit full ppgtt if i915.ppgtt_enable=2. (Zhenyu)
Reviewed-by: Joonas Lahtinen in v2
Signed-off-by: Tina Zhang
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b051122..1b95069 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1879,6 +1879,7 @@ struct i915_workarounds {
struct i915_virtual_gpu {
bool active;
+ u32 caps;
};
/* used in computing the new watermarks state */
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 10aa776..9dcf1bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -141,14 +141,20 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private
*dev_priv,
has_aliasing_ppgtt = dev_priv->info.has_aliasing_ppgtt;
has_full_ppgtt = dev_priv->info.has_full_ppgtt;
- has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
if (intel_vgpu_active(dev_priv)) {
- /* emulation is too hard */
- has_full_ppgtt = false;
- has_full_48bit_ppgtt = false;
+ has_full_ppgtt = intel_vgpu_has_full_ppgtt(dev_priv);
+ /*
+* FIXME: There is a limition of vgpu supporting 32bit full
+* ppgtt.
+*/
+ if (enable_ppgtt == 2)
+ enable_ppgtt = 3;
}
+ has_full_48bit_ppgtt = has_full_ppgtt &&
+ dev_priv->info.has_full_48bit_ppgtt;
+
if (!has_aliasing_ppgtt)
return 0;
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 2cfe96d3..7e958d7 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,12 +49,18 @@ enum vgt_g2v_type {
VGT_G2V_MAX,
};
+/*
+ * VGT capabilities type
+ */
+#define VGT_CAPS_FULL_PPGTT_48BIT BIT(2)
+
struct vgt_if {
u64 magic; /* VGT_MAGIC */
u16 version_major;
u16 version_minor;
u32 vgt_id; /* ID of vGT instance */
- u32 rsv1[12]; /* pad to offset 0x40 */
+ u32 vgt_caps; /* VGT capabilities */
+ u32 rsv1[11]; /* pad to offset 0x40 */
/*
* Data structure to describe the balooning info of resources.
* Each VM can only have one portion of continuous area for now.
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index cf7a958..e85e27c 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -75,10 +75,17 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
return;
}
+ dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
+
dev_priv->vgpu.active = true;
DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
}
+bool intel_vgpu_has_full_ppgtt(struct drm_i915_private *dev_priv)
+{
+ return dev_priv->vgpu.caps & VGT_CAPS_FULL_PPGTT_48BIT;
+}
+
struct _balloon_info_ {
/*
* There are up to 2 regions per mappable/unmappable graphic
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_
Re: [Intel-gfx] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr
On 13/07/17 05:27 PM, Michel Dänzer wrote: > On 18/04/17 07:07 PM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Signed-off-by: Michel Dänzer >> --- >> >> Chris / Ilia / Ben, this should be manageable for the intel/nouveau >> drivers, right? > > Any feedback, guys? > > I want to push the xserver change soon-ish. I could probably come up > with a corresponding patch for nouveau in the worst case, but I'm afraid > not for intel. Chris, in response to your bugzilla comment https://bugs.freedesktop.org/show_bug.cgi?id=100086#c9 and patch https://patchwork.freedesktop.org/patch/143180/, I drafted how the ABI could be fixed to reflect current usage in the first comment to your patch. There was no response in a month, so I went ahead and wrote https://patchwork.freedesktop.org/patch/150938/ . After three months with no feedback, I followed up with the ping above. After almost another month without feedback from you, I pinged you about it on IRC, again no response. I'm afraid my patience has run out, I'll push the xserver patch next week. Until the xf86-video-intel SNA driver is fixed up, it'll continue being broken as the master screen driver with RandR 1.4 slave scanout. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear lost context-switch interrupts across reset
> -Original Message-
> From: Thierry, Michel
> Sent: Tuesday, August 8, 2017 1:40 AM
> To: Chris Wilson ; intel-gfx@lists.freedesktop.org
> Cc: Dong, Chuanxiao ; Ursulin, Tvrtko
> ; Winiarski, Michal
> Subject: Re: [PATCH] drm/i915: Clear lost context-switch interrupts across
> reset
>
> On 8/7/2017 5:19 AM, Chris Wilson wrote:
> > During a global reset, we disable the irq. As we disable the irq, the
> > hardware may be raising a GT interrupt that we then ignore, leaving it
> > pending in the GTIIR. After the reset, we then re-enable the irq,
> > triggering the pending interrupt. However, that interrupt was for the
> > stale state from before the reset, and the contents of the CSB buffer
> > are now invalid.
> >
> > Reported-by: "Dong, Chuanxiao"
> > Signed-off-by: Chris Wilson
> > Cc: "Dong, Chuanxiao"
> > Cc: Tvrtko Ursulin
> > Cc: Michal Winiarski
> > Cc: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index b0738d2b2a7f..bc61948e2601 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1221,6 +1221,14 @@ static int intel_init_workaround_bb(struct
> intel_engine_cs *engine)
> > return ret;
> > }
> >
> > +static u8 gtiir[] = {
> > + [RCS] = 0,
> > + [BCS] = 0,
> > + [VCS] = 1,
> > + [VCS2] = 1,
> > + [VECS] = 3,
> > +};
> > +
> > static int gen8_init_common_ring(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_private *dev_priv = engine->i915; @@ -1245,9
> > +1253,16 @@ static int gen8_init_common_ring(struct intel_engine_cs
> > *engine)
> >
> > DRM_DEBUG_DRIVER("Execlists enabled for %s\n", engine->name);
> >
> > - /* After a GPU reset, we may have requests to replay */
> > + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> > +
> > + /* Clear any pending interrupt state */
> > + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > + GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
> > + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > + GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
>
> Clear twice? Or the second was supposed to be user_interrupt?
To resolve the CSB tail/head trouble, clearing context switching pending
interrupt only should be enough, but seems it is not necessary to keep the
pending user interrupt as well so we can clear user interrupt as well.
Chris, what do you think? And thank you for bringing the fix for this issue. :)
Thanks
Chuanxiao
>
> > clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> >
> > + /* After a GPU reset, we may have requests to replay */
> > submit = false;
> > for (n = 0; n < ARRAY_SIZE(engine->execlist_port); n++) {
> > if (!port_isset(&port[n]))
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for edid read
On 08/08/2017 12:51 AM, Lofstedt, Marta wrote:
Thanks Clinton!
If you add:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100047
You have my Rb.
/Marta
Thanks Marta,
However I'm going to extend the functionality to read the EDID
block size like Daniel suggested. During testing today of the new edid
size read SKL passed and IVB failed. This may be a result of an actual
HDMI port vs LSPCON. More testing is required before I have a actual
working test.
-Clint
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of clinton.a.tay...@intel.com
Sent: Friday, August 4, 2017 9:23 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for
edid read
From: Clint Taylor
Current 50ms max threshold timing for an EDID read is very close to the
actual time for a 2 block HDMI EDID read of 48ms. Any delay like a clock
stretch by the EDID eeprom will cause this test to fail. A 4 block HDMI EDID
read takes approximately 88ms under nominal conditions, making the max
threshold 95ms will allow this test to pass regardless of monitor attached.
Signed-off-by: Clint Taylor
---
tests/kms_sysfs_edid_timing.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
index 1201388..b45e080 100644
--- a/tests/kms_sysfs_edid_timing.c
+++ b/tests/kms_sysfs_edid_timing.c
@@ -27,14 +27,14 @@
#include
#define THRESHOLD_PER_CONNECTOR 10
-#define THRESHOLD_TOTAL50
+#define THRESHOLD_TOTAL95
#define CHECK_TIMES 15
IGT_TEST_DESCRIPTION("This check the time we take to read the content of
all "
"the possible connectors. Without the edid -
ENXIO patch "
"(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083),"
-"we sometimes take a *really* long time. "
-"So let's just check for some reasonable
timing here");
+"we sometimes take a *really* long time. So
let's just "
+"check an approximate HDMI 4 block edid
read timing here");
igt_simple_main
--
1.9.1
___
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 libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
I didn't mean to add libdrm, sorry, there is a separate change for that. I'll double check and test the drivers that don't implement the virtual. Thanks for the quick reply! -j On Tue, Aug 8, 2017 at 4:50 PM, Dave Airlie wrote: > On 9 August 2017 at 09:42, Joe Kniss wrote: > > Because all drivers currently use gem objects for framebuffer planes, > > the virtual create_handle() is not required. This change adds a > > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > > create_handle() function pointer from drm_framebuffer_funcs. The > > corresponding *_create_handle() function is removed from each driver. > > > > In many cases this change eliminates a struct *_framebuffer object, > > as the only need for the derived struct is the addition of the gem > > object pointer. > > Why the libdrm in the tag? this isn't for libdrm. > > This will break drivers that don't current implement the virtual at all. > > I think vwmgfx. > > The current code checks if the virtual is there before callng it, this code > just calls the gem code always. > > Dave. > -- Dr. Joe Michael Kniss | Google ChromeOS | d...@google.com | 1-801-898-7977 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt: add syncobj_basic.
A bunch of these tests assume that the handle is looked up after the other
parameters are checked. Other than that, looks good.
Reviewed-by: Jason Ekstrand
On Tue, Aug 8, 2017 at 4:09 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Some basic sync object interface tests
>
> Signed-off-by: Dave Airlie
> ---
> tests/Makefile.sources | 1 +
> tests/syncobj_basic.c | 260 ++
> +++
> 2 files changed, 261 insertions(+)
> create mode 100644 tests/syncobj_basic.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 5b98a5a..bb013c7 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -229,6 +229,7 @@ TESTS_progs = \
> prime_udl \
> prime_vgem \
> sw_sync \
> + syncobj_basic \
> template \
> tools_test \
> vgem_basic \
> diff --git a/tests/syncobj_basic.c b/tests/syncobj_basic.c
> new file mode 100644
> index 000..a7a6742
> --- /dev/null
> +++ b/tests/syncobj_basic.c
> @@ -0,0 +1,260 @@
> +/*
> + * Copyright © 2017 Red Hat
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "igt.h"
> +#include
> +#include
> +#include "drm.h"
> +
> +IGT_TEST_DESCRIPTION("Basic check for drm sync objects.");
> +
> +/* destroy a random handle */
> +static void
> +test_bad_destroy(int fd)
> +{
> + struct drm_syncobj_destroy destroy;
> + int ret;
> +
> + destroy.handle = 0xdeadbeef;
> + destroy.pad = 0;
> +
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
> +
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +/* handle to fd a bad handle */
> +static void
> +test_bad_handle_to_fd(int fd)
> +{
> + struct drm_syncobj_handle handle;
> + int ret;
> +
> + handle.handle = 0xdeadbeef;
> + handle.flags = 0;
> +
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
> +
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +/* fd to handle a bad fd */
> +static void
> +test_bad_fd_to_handle(int fd)
> +{
> + struct drm_syncobj_handle handle;
> + int ret;
> +
> + handle.fd = -1;
> + handle.flags = 0;
> +
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
> +
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +/* fd to handle an fd but not a sync file one */
> +static void
> +test_illegal_fd_to_handle(int fd)
> +{
> + struct drm_syncobj_handle handle;
> + int ret;
> +
> + handle.fd = fd;
> + handle.flags = 0;
> +
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
> +
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +static void
> +test_bad_flags_fd_to_handle(int fd)
> +{
> + struct drm_syncobj_handle handle = { 0 };
> + int ret;
> +
> + handle.flags = 0xdeadbeef;
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +static void
> +test_bad_flags_handle_to_fd(int fd)
> +{
> + struct drm_syncobj_handle handle = { 0 };
> + int ret;
> +
> + handle.flags = 0xdeadbeef;
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +static void
> +test_bad_pad_handle_to_fd(int fd)
> +{
> + struct drm_syncobj_handle handle = { 0 };
> + int ret;
> +
> + handle.pad = 0xdeadbeef;
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
> + igt_assert(ret == -1 && errno == EINVAL);
> +}
> +
> +static void
> +test_bad_pad_fd_to_handle(int fd)
> +{
> + struct drm_syncobj_handle handle = { 0 };
> + int ret;
> +
> + handle.pad = 0xdeadbeef;
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
> + igt_assert(ret == -1 && e
Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
On 9 August 2017 at 09:42, Joe Kniss wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle() function pointer from drm_framebuffer_funcs. The > corresponding *_create_handle() function is removed from each driver. > > In many cases this change eliminates a struct *_framebuffer object, > as the only need for the derived struct is the addition of the gem > object pointer. Why the libdrm in the tag? this isn't for libdrm. This will break drivers that don't current implement the virtual at all. I think vwmgfx. The current code checks if the virtual is there before callng it, this code just calls the gem code always. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt: add syncobj_basic.
From: Dave Airlie
Some basic sync object interface tests
Signed-off-by: Dave Airlie
---
tests/Makefile.sources | 1 +
tests/syncobj_basic.c | 260 +
2 files changed, 261 insertions(+)
create mode 100644 tests/syncobj_basic.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5b98a5a..bb013c7 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -229,6 +229,7 @@ TESTS_progs = \
prime_udl \
prime_vgem \
sw_sync \
+ syncobj_basic \
template \
tools_test \
vgem_basic \
diff --git a/tests/syncobj_basic.c b/tests/syncobj_basic.c
new file mode 100644
index 000..a7a6742
--- /dev/null
+++ b/tests/syncobj_basic.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright © 2017 Red Hat
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include
+#include
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Basic check for drm sync objects.");
+
+/* destroy a random handle */
+static void
+test_bad_destroy(int fd)
+{
+ struct drm_syncobj_destroy destroy;
+ int ret;
+
+ destroy.handle = 0xdeadbeef;
+ destroy.pad = 0;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
+
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+/* handle to fd a bad handle */
+static void
+test_bad_handle_to_fd(int fd)
+{
+ struct drm_syncobj_handle handle;
+ int ret;
+
+ handle.handle = 0xdeadbeef;
+ handle.flags = 0;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
+
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+/* fd to handle a bad fd */
+static void
+test_bad_fd_to_handle(int fd)
+{
+ struct drm_syncobj_handle handle;
+ int ret;
+
+ handle.fd = -1;
+ handle.flags = 0;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
+
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+/* fd to handle an fd but not a sync file one */
+static void
+test_illegal_fd_to_handle(int fd)
+{
+ struct drm_syncobj_handle handle;
+ int ret;
+
+ handle.fd = fd;
+ handle.flags = 0;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
+
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+static void
+test_bad_flags_fd_to_handle(int fd)
+{
+ struct drm_syncobj_handle handle = { 0 };
+ int ret;
+
+ handle.flags = 0xdeadbeef;
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+static void
+test_bad_flags_handle_to_fd(int fd)
+{
+ struct drm_syncobj_handle handle = { 0 };
+ int ret;
+
+ handle.flags = 0xdeadbeef;
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+static void
+test_bad_pad_handle_to_fd(int fd)
+{
+ struct drm_syncobj_handle handle = { 0 };
+ int ret;
+
+ handle.pad = 0xdeadbeef;
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+static void
+test_bad_pad_fd_to_handle(int fd)
+{
+ struct drm_syncobj_handle handle = { 0 };
+ int ret;
+
+ handle.pad = 0xdeadbeef;
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
+ igt_assert(ret == -1 && errno == EINVAL);
+}
+
+
+
+/* destroy with data in the padding */
+static void
+test_bad_destroy_pad(int fd)
+{
+ struct drm_syncobj_create create = { 0 };
+ struct drm_syncobj_destroy destroy;
+ int ret;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &create);
+
+ destroy.handle = create.handle;
+ destroy.pad = 0xdeadbeef;
+
+ ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
+
+ igt_assert(ret == -1 && errno == EINVAL);
+
+ destroy.handle = create.handle;
+ destroy.pad = 0;
+
+ r
[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_exec_basic: Documentation for subtests
== Series Details == Series: tests/gem_exec_basic: Documentation for subtests URL : https://patchwork.freedesktop.org/series/28524/ State : success == Summary == IGT patchset tested on top of latest successful build 27ff12f00c94a5363f581a4353f08bfde62c59c4 lib: Remove illegal instructions from hang injection with latest DRM-Tip kernel build CI_DRM_2936 e2586470ba9f drm-tip: 2017y-08m-08d-20h-39m-09s UTC integration manifest Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:434s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:418s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:361s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:497s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:495s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:515s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:427s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:403s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:509s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:456s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:577s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:455s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:650s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:461s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:408s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_33/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 14/16] drm/i915/guc: Enable GuC interrupts when using CT
On 08/07/2017 09:14 AM, Michal Wajdeczko wrote:
We will need them in G2H communication to properly handle
responses and requests from the Guc.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Daniele Ceraolo Spurio
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 48a1e93..509497e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1328,7 +1328,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- if (i915.guc_log_level >= 0)
+ if (HAS_GUC_CT(dev_priv) || i915.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 774d740..0209ad0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -395,7 +395,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
intel_guc_auth_huc(dev_priv);
if (i915.enable_guc_submission) {
- if (i915.guc_log_level >= 0)
+ if (HAS_GUC_CT(dev_priv) || i915.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
ret = i915_guc_submission_enable(dev_priv);
Is this enough? There are also gen9_disable_guc_interrupts that will
break CTB (e.g. when logs get disabled).
___
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/psr: Preserve SRD_CTL bit 29 on PSR init (rev2)
== Series Details == Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init (rev2) URL : https://patchwork.freedesktop.org/series/28507/ State : success == Summary == Series 28507v2 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init https://patchwork.freedesktop.org/api/1.0/series/28507/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:436s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:428s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:499s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:498s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:523s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:508s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:588s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:404s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:510s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:484s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:457s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:570s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:523s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:451s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:643s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:464s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:499s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:559s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s e2586470ba9f468a2f72b1619d79aa1d510c45a7 drm-tip: 2017y-08m-08d-20h-39m-09s UTC integration manifest e08ae0378dfb drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5346/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t] tests/gem_exec_basic: Documentation for subtests
This is an RFC for adding documentation to IGT subtests. Each subtest can have
something similar to a WHAT - explaining what the subtest actually does,
and a WHY - which explains a use case, if applicable. Additionally,
include comments for anything in the subtest code which can help
explain HOW the test has been implemented. We don't actually need the WHAT
and WHY tags in the documentation.
These comments will not be linked to gtkdoc as of now, since we do not have a
mechanism to link it to every subtest name.
Signed-off-by: Vinay Belgaumkar
Cc: Daniel Vetter
Cc: Petri Latvala
Cc: Chris Wilson
---
tests/gem_exec_basic.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/gem_exec_basic.c b/tests/gem_exec_basic.c
index 2f057ef..b1491cd 100644
--- a/tests/gem_exec_basic.c
+++ b/tests/gem_exec_basic.c
@@ -25,6 +25,11 @@
IGT_TEST_DESCRIPTION("Basic sanity check of execbuf-ioctl rings.");
+/*
+(WHAT) This subtest submits an empty batch to each ring and verifies
+that it is executed successfully
+(WHY) It validates that GT buffer submission mechanism is functional
+*/
static void noop(int fd, unsigned ring)
{
uint32_t bbe = MI_BATCH_BUFFER_END;
@@ -45,6 +50,11 @@ static void noop(int fd, unsigned ring)
gem_close(fd, exec.handle);
}
+/*
+(WHAT) This subtest memory maps a buffer, marks it as read only,
+and submits it to each ring for execution.
+(WHY) It helps us validate that the GT can execute read-only buffers
+*/
static void readonly(int fd, unsigned ring)
{
uint32_t bbe = MI_BATCH_BUFFER_END;
@@ -57,12 +67,15 @@ static void readonly(int fd, unsigned ring)
exec.handle = gem_create(fd, 4096);
gem_write(fd, exec.handle, 0, &bbe, sizeof(bbe));
+ /* Memory map a buffer and use it as the execbuf to be submitted */
execbuf = mmap(NULL, 4096, PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0);
igt_assert(execbuf != NULL);
execbuf->buffers_ptr = to_user_pointer(&exec);
execbuf->buffer_count = 1;
execbuf->flags = ring;
+
+ /* Now mark the buffer as read-only */
igt_assert(mprotect(execbuf, 4096, PROT_READ) == 0);
gem_execbuf(fd, execbuf);
@@ -70,6 +83,10 @@ static void readonly(int fd, unsigned ring)
gem_close(fd, exec.handle);
}
+/*
+(WHAT) Create a gtt mapped buffer and submit to the GPU.
+(WHY) It ensures GPU can properly map and access GTT mapped buffers
+*/
static void gtt(int fd, unsigned ring)
{
uint32_t bbe = MI_BATCH_BUFFER_END;
@@ -82,6 +99,8 @@ static void gtt(int fd, unsigned ring)
handle = gem_create(fd, 4096);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+
+ /* Create a memory mapping through GTT */
execbuf = gem_mmap__gtt(fd, handle, 4096, PROT_WRITE);
exec = (struct drm_i915_gem_exec_object2 *)(execbuf + 1);
gem_close(fd, handle);
@@ -108,6 +127,8 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
+ /* Start the hang detector process. Test will fail
+ if a GPU hang is detected during any subtest */
igt_fork_hang_detector(fd);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
Bit 29 of SRD_CTL needs to have its value preserved according to the
B-Spec, so right before we write out the register we go ahead and read
the register and preserve the value of that bit before we write out
the configured register value.
v2: Spaces => tabs, minor name change, and commit message wording (Rodrigo)
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b2546ad..56df86e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3872,6 +3872,7 @@ enum {
#define EDP_PSR_CTL_MMIO(dev_priv->psr_mmio_base +
0)
#define EDP_PSR_ENABLE (1<<31)
#define BDW_PSR_SINGLE_FRAME (1<<30)
+#define EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK (1<<29) /* SW can't modify */
#define EDP_PSR_LINK_STANDBY (1<<27)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 559f1ab..1b31ab0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -315,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP1_TP2_SEL;
+ val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
I915_WRITE(EDP_PSR_CTL, val);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
On Tue, Aug 08, 2017 at 07:42:50PM +, Vivi, Rodrigo wrote:
> On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote:
> > Bit 29 of SRD_CTL needs to have its value preserved,
>
> probably good to kind of quote spec somehow:
> "This field is used for hardware communication. Software must not
> change this field."
Added "according to the B-Spec" after the word preserved.
>
> > so right before we
> > write out the register we go ahead and read the register and preserve
> > the value of that bit before we write out the configured register value.
> >
> > Cc: Rodrigo Vivi
> > Cc: Chris Wilson
> > Cc: Jani Nikula
> > Signed-off-by: Jim Bride
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index b2546ad..ea8e421 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3872,6 +3872,7 @@ enum {
> > #define EDP_PSR_CTL
> > _MMIO(dev_priv->psr_mmio_base + 0)
> > #define EDP_PSR_ENABLE (1<<31)
> > #define BDW_PSR_SINGLE_FRAME (1<<30)
> > +#define EDP_PSR_RESTORE_PSR_ACTIVE_CTX(1<<29) /* SW can't modify
> > */
>
> - please use real tabs instead of spaces.
Not sure what happened there, but fixed.
>
> - a MASK on the name is better since we are not using this define to set
> the bit, but to mask instead.
Changed as per suggesation.
> > #define EDP_PSR_LINK_STANDBY (1<<27)
> > #define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
> > #define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 559f1ab..0d08efa 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -315,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
> > *intel_dp)
> > else
> > val |= EDP_PSR_TP1_TP2_SEL;
> >
>
> I wondered if we should add an extra comment here, but I believe it is
> not necessary if we have the "_MASK" on the bit name.
I think it would be redundant with the comment in i915_reg.h, which I
believe to be a better place for the note. In any event, a new version
of the patch is coming with the above changes once I smoke-test
everything again.
Jim
> > + val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX;
> > I915_WRITE(EDP_PSR_CTL, val);
> > }
> >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.
merged to dinq, thanks for the review.
On Tue, Aug 8, 2017 at 4:36 AM, Imre Deak wrote:
> On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote:
>> DDI_E is not supported on CNL-U and CNL-Y
>>
>> When adding the inital support we noticed DDI_E wasn't supported
>> and removed it on v4 and v5 of that patch.
>> However for some reason I missed or put back these 2 chunks.
>>
>> Time to clean it up to avoid later confusion.
>>
>> Fixes: 8bcd3dd41766 ("drm/i915/cnl: Add power wells for CNL")
>> Cc: Clint Taylor
>> Cc: Ville Syrjälä
>> Cc: Imre Deak
>> Cc: Daniel Vetter
>> Cc: Jani Nikula
>> Signed-off-by: Rodrigo Vivi
>
> Looks ok and also the correct thing for CNL_H/S, where the port E DDI
> power well is separate from port A and not dependent on power well #2
> (unlike SKL):
>
> Reviewed-by: Imre Deak
>
>> ---
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 347484ed6d2c..e77e84a6fd2f 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -1796,7 +1796,6 @@ void intel_display_power_put(struct drm_i915_private
>> *dev_priv,
>> BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
>> BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
>> BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
>> - BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
>> BIT_ULL(POWER_DOMAIN_AUX_B) | \
>> BIT_ULL(POWER_DOMAIN_AUX_C) | \
>> BIT_ULL(POWER_DOMAIN_AUX_D) | \
>> @@ -1805,7 +1804,6 @@ void intel_display_power_put(struct drm_i915_private
>> *dev_priv,
>> BIT_ULL(POWER_DOMAIN_INIT))
>> #define CNL_DISPLAY_DDI_A_IO_POWER_DOMAINS ( \
>> BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO) | \
>> - BIT_ULL(POWER_DOMAIN_PORT_DDI_E_IO) | \
>> BIT_ULL(POWER_DOMAIN_INIT))
>> #define CNL_DISPLAY_DDI_B_IO_POWER_DOMAINS ( \
>> BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) | \
>> --
>> 2.13.2
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: DDIA Lane capability bit not set in clone mode
we confirmed that with current supported CNL skus using IS_CANNONLAKE
is enogh for now.
So feel free to change that if and use
Reviewed-by: Rodrigo Vivi
on the v2
On Tue, Aug 1, 2017 at 1:23 PM, Vivi, Rodrigo wrote:
> + Art, couple questions below
>
> On Tue, 2017-08-01 at 09:56 -0700, clinton.a.tay...@intel.com wrote:
>> From: Clint Taylor
>>
>> DDIA Lane capability control 4 lane bit is not being set by firmware during
>> clone mode boot. This occurs when multiple monitors are connected during
>> boot. The driver will configure the port for 2 lane maximum width if this
>> bit is not set.
>>
>> Once DDIA/E lane split is supported in vbt and the i915 driver we will need
>> to revisit this code.
>>
>> Cc: Rodrigo Vivi
>> Signed-off-by: Clint Taylor
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 494fbe0..e7644b4 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2713,9 +2713,10 @@ void intel_ddi_init(struct drm_i915_private
>> *dev_priv, enum port port)
>
> we would need to fix more comment lines:
>
> /*
> * Bspec says that DDI_A_4_LANES is the only supported
> configuration
> * for Broxton. Yet some BIOS fail to set this bit on port A if
> eDP
> * wasn't lit up at boot. Force this bit on in our internal
>>* configuration so that we use the proper lane count for our
>>* calculations.
>>*/
>
> But I believe the approach we currently have with this might not be
> optimal. If BIOS is not bringing the port A up why should we expect it
> to set this bit ever? We probably need to be able to do it by ourselves,
> without expecting others to do...
>
> However, I've never seen a production BIOS that never brings port A when
> it is present. And it is also true that spec tells: "This field must be
> programmed at system boot based on board configuration and may not be
> changed afterwards."
>
> So I have kind of mixed feelings here on this bit.
>
> For BXT it is so clear: "Not supported on Broxton."
>
> Also few other future cases the 0 won't be valid, but not entirely sure
> if this is always true. Art?
>
> I just noticed on spec that DDI E for CNL-U and CNL-Y are marked as "not
> supported", what means that for that SKU we should be able to add this
> workaround here, but at same time means that we need to remove the power
> wells support for DDI-E for these SKUs probably.
>
> Art, could/should we set this bit blindly for all CNL?
>
> and if yes:
>
> Art, will it always be a decision based by SKUs now on? Or should we
> really rely on BIOS?
>
> Is there another way to detect the port E presence? I don't believe VBT
> has that info in a reliable way, does it? Otherwise we would be using it
> already for the missed straps...
>
>
> Thanks,
> Rodrigo.
>
>> - if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
>> + if ((IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
>> + port == PORT_A) {
>> if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
>> - DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES
>> for port A; fixing\n");
>> + DRM_DEBUG_KMS("BIOS forgot to set DDI_A_4_LANES for
>> port A\n");
>> intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
>> max_lanes = 4;
>> }
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
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: Removing missing DDI_E bits from CNL. (rev3)
== Series Details == Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev3) URL : https://patchwork.freedesktop.org/series/28341/ State : success == Summary == Series 28341v3 drm/i915/cnl: Removing missing DDI_E bits from CNL. https://patchwork.freedesktop.org/api/1.0/series/28341/revisions/3/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:438s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:420s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:494s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:489s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:523s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:590s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:422s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:580s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:522s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:642s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:469s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:429s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:470s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:545s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:410s b7a69d408ccdcc8d4976baa3fc4b6dcdc5c21c8b drm-tip: 2017y-08m-08d-13h-56m-35s UTC integration manifest 1c05577ee94b drm/i915/cnl: Removing missing DDI_E bits from CNL. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5345/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave,
Here's the pull for the last week and a bit. It's rather large as I was on
vacation/moving last week. Although the patch count/diffstat is higher than
normal, we have a lot of medium-large sets included. That also explains why the
summary might seem a bit light.
Among the aforementioned sets, there are a few pretty awesome cleanups:
lut/gamma dead code cleanup, dumb_mmap/destroy defaults, and the atomic property
shuffle into core from the helpers.
There are also 4 new UAPI changes, all low risk/new functionality. The armada
change doesn't change the size of the structs, so should be business as usual.
The fb_helper change is a nice improvement, and will simply expose more accurate
information about the display. vc4 ioctl is meant for debugging purposes, so
while it wil be helpful, it's not user facing. Finally, the format/modifier
property shouldn't trip anybody up since all sane userspace should skip over it
if they can't make use of it.
drm-misc-next-2017-08-08:
UAPI Changes:
- vc4: Add ioctl to allow attaching a label to a bo (Eric)
- Add new format/modifier blob plane property (Ben)
- armada: Use __u32/__u64 instead of uint32_t/uint64_t (Mikko)
- [kinda uapi] fb_helper: Expose display_info size via fb_info (David)
Core Changes:
- Default gem_dumb_[map_offset|destroy] as mmap/destroy implementations (Noralf)
- Simplify atomic properties by removing the helpers and handling in core
(Daniel)
Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- vc4: Add HDMI CEC support (Hans)
- rockchip: Refactor register init & soc version handling (Mark)
- misc: Remove .load_lut, .gamma_set, .gamma_get dead code (Peter)
- dw-hdmi: Add HDMI CEC support (Russell)
Cc: Philippe CORNU
Cc: Hans Verkuil
Cc: Eric Anholt
Cc: Noralf Trønnes
Cc: Ben Widawsky
Cc: Mark yao
Cc: Peter Rosin
Cc: Russell King
Cc: Mikko Rapeli
Cc: David Lechner
Cc: Daniel Vetter
Cheers, Sean
The following changes since commit e6742e1021a5cec55fab50a0b115c65217488eda:
drm: linux-next: build failure after merge of the drm-misc tree (2017-07-27
08:27:11 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-08-08
for you to fetch changes up to 16fece0153d5b6573c3fcb8cfbe483f83ca8eb01:
drm: Nuke drm_atomic_legacy_backoff (2017-08-08 14:49:29 +0200)
UAPI Changes:
- vc4: Add ioctl to allow attaching a label to a bo (Eric)
- Add new format/modifier blob plane property (Ben)
- armada: Use __u32/__u64 instead of uint32_t/uint64_t (Mikko)
- [kinda uapi] fb_helper: Expose display_info size via fb_info (David)
Core Changes:
- Default gem_dumb_[map_offset|destroy] as mmap/destroy implementations (Noralf)
- Simplify atomic properties by removing the helpers and handling in core
(Daniel)
Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- vc4: Add HDMI CEC support (Hans)
- rockchip: Refactor register init & soc version handling (Mark)
- misc: Remove .load_lut, .gamma_set, .gamma_get dead code (Peter)
- dw-hdmi: Add HDMI CEC support (Russell)
Cc: Philippe CORNU
Cc: Hans Verkuil
Cc: Eric Anholt
Cc: Noralf Trønnes
Cc: Ben Widawsky
Cc: Mark yao
Cc: Peter Rosin
Cc: Russell King
Cc: Mikko Rapeli
Cc: David Lechner
Cc: Daniel Vetter
Arnd Bergmann (1):
tinydrm: repaper: add CONFIG_THERMAL dependency
Arvind Yadav (1):
drm/atmel-hlcdc : constify drm_plane_helper_funcs and drm_plane_funcs.
Ben Widawsky (2):
drm: Plumb modifiers through plane init
drm: Create a format/modifier blob
Chris Wilson (1):
dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence
Cihangir Akturk (1):
drm/atmel-hlcdc: switch to drm_*{get,put} helpers
Daniel Vetter (8):
drm: Fix kerneldoc for atomic_async_update
drm: Don't update property values for atomic drivers
drm: Handle properties in the core for atomic drivers
drm: Nuke drm_atomic_helper_crtc_set_property
drm: Nuke drm_atomic_helper_plane_set_property
drm: Nuke drm_atomic_helper_connector_set_property
drm: Nuke drm_atomic_helper_connector_dpms
drm: Nuke drm_atomic_legacy_backoff
David Lechner (4):
drm/fb: Fix pointer dereference before null check.
drm/fb-helper: add new drm_setup_crtcs_fb() function
drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
drm/fb-helper: pass physical dimensions to fbdev
Eric Anholt (4):
drm/bridge: Add a devm_ allocator for panel bridge.
drm/vc4: Start using u64_to_user_ptr.
drm/vc4: Add an ioctl for labeling GEM BOs for summary stats
drm/vc4: Convert more lock requirement comments to lockdep assertions.
Gustavo Padovan (2):
dma-buf/sw_sync: move timeline_fence_ops around
dma-buf/sw_sync: clean up list before signaling the fence
Hans Verkuil (3):
drm/vc4: prep
Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
a long time ago I had agreed with Daniel that we would only add new
platforms after it was enabled by default on previous platforms.
a big reason for that is that we was willing to reduce the platforms
to validate and do better validation one by one before enabling.
However now I believe it would be beneficial to have that supported
added so we can get more brave people using in different platforms so
we could capture more corner cases before we enable it by default.
Also we can still enable by default one platform at time if needed.
So:
Acked-by: Rodrigo Vivi
I also checked the spec to see if there was anything else new or
different for these platforms and didn't find anything so:
Reviewed-by: Rodrigo Vivi
But let's wait a bit to merge to give Daniel or others a time to nack ;)
Cheers,
Rodrigo.
On Tue, Aug 8, 2017 at 3:09 AM, David Weinehall
wrote:
> While testing Jim Bride's latest batch of PSR patches I noticed
> that gen9lp doesn't include the has_psr flag, and that our GLK
> system thus reported PSR as unsupported.
>
> This patch simply adds has_psr.
>
> Signed-off-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 09d97e0990b7..11f0e8aa1fe4 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -377,6 +377,7 @@ static const struct intel_device_info
> intel_skylake_gt3_info = {
> .has_ddi = 1, \
> .has_fpga_dbg = 1, \
> .has_fbc = 1, \
> + .has_psr = 1, \
> .has_runtime_pm = 1, \
> .has_pooled_eu = 0, \
> .has_csr = 1, \
> --
> 2.14.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote:
> Bit 29 of SRD_CTL needs to have its value preserved,
probably good to kind of quote spec somehow:
"This field is used for hardware communication. Software must not
change this field."
> so right before we
> write out the register we go ahead and read the register and preserve
> the value of that bit before we write out the configured register value.
>
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Cc: Jani Nikula
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b2546ad..ea8e421 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3872,6 +3872,7 @@ enum {
> #define EDP_PSR_CTL _MMIO(dev_priv->psr_mmio_base +
> 0)
> #define EDP_PSR_ENABLE (1<<31)
> #define BDW_PSR_SINGLE_FRAME (1<<30)
> +#define EDP_PSR_RESTORE_PSR_ACTIVE_CTX(1<<29) /* SW can't modify */
- please use real tabs instead of spaces.
- a MASK on the name is better since we are not using this define to set
the bit, but to mask instead.
> #define EDP_PSR_LINK_STANDBY (1<<27)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES(0<<25)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 559f1ab..0d08efa 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -315,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP1_TP2_SEL;
>
I wondered if we should add an extra comment here, but I believe it is
not necessary if we have the "_MASK" on the bit name.
> + val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX;
> I915_WRITE(EDP_PSR_CTL, val);
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.
DDI_E is not supported on CNL-U and CNL-Y
When adding the inital support we noticed DDI_E wasn't supported
and removed it on v4 and v5 of that patch.
However for some reason I missed or put back these 2 chunks.
Time to clean it up to avoid later confusion.
Fixes: 8bcd3dd41766 ("drm/i915/cnl: Add power wells for CNL")
Cc: Clint Taylor
Cc: Ville Syrjälä
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 347484ed6d2c..e77e84a6fd2f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1796,7 +1796,6 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
- BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
BIT_ULL(POWER_DOMAIN_AUX_B) | \
BIT_ULL(POWER_DOMAIN_AUX_C) | \
BIT_ULL(POWER_DOMAIN_AUX_D) | \
@@ -1805,7 +1804,6 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_DDI_A_IO_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO) | \
- BIT_ULL(POWER_DOMAIN_PORT_DDI_E_IO) | \
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_DDI_B_IO_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) | \
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev2)
== Series Details == Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev2) URL : https://patchwork.freedesktop.org/series/28341/ State : warning == Summary == Series 28341v2 drm/i915/cnl: Removing missing DDI_E bits from CNL. https://patchwork.freedesktop.org/api/1.0/series/28341/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7500u) Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:419s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:504s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:488s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:519s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:586s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:440s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:409s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:511s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:529s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:444s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:646s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:469s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:425s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:475s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:411s b7a69d408ccdcc8d4976baa3fc4b6dcdc5c21c8b drm-tip: 2017y-08m-08d-13h-56m-35s UTC integration manifest 16b4880c4b27 drm/i915/cnl: Removing missing DDI_E bits from CNL. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5344/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.
DDI_E is not supported on CNL-U and CNL-Y
When adding the inital support we noticed DDI_E wasn't supported
and removed it on v4 and v5 of that patch.
However for some reason I missed or put back these 2 chunks.
Time to clean it up to avoid later confusion.
Fixes: 8bcd3dd41766 ("drm/i915/cnl: Add power wells for CNL")
Cc: Clint Taylor
Cc: Ville Syrjälä
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 347484ed6d2c..e77e84a6fd2f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1796,7 +1796,6 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
- BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
BIT_ULL(POWER_DOMAIN_AUX_B) | \
BIT_ULL(POWER_DOMAIN_AUX_C) | \
BIT_ULL(POWER_DOMAIN_AUX_D) | \
@@ -1805,7 +1804,6 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_DDI_A_IO_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO) | \
- BIT_ULL(POWER_DOMAIN_PORT_DDI_E_IO) | \
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_DDI_B_IO_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) | \
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On Tue, 8 Aug 2017 14:18:07 +0530
Kirti Wankhede wrote:
> On 8/7/2017 11:13 PM, Alex Williamson wrote:
> > On Mon, 7 Aug 2017 08:11:43 +
> > "Zhang, Tina" wrote:
> >
> >> After going through the previous discussions, here are some summaries may
> >> be related to the current discussion:
> >> 1. How does user mode figure the device capabilities between region and
> >> dma-buf?
> >> VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case.
> >> Otherwise, the mdev supports dma-buf.
> >
> > Why do we need to make this assumption?
>
> Right, we should not make such assumption. Vendor driver might not
> support both or disable console vnc ( for example, for performance
> testing console VNC need to be disabled)
>
> > What happens when dma-buf is
> > superseded? What happens if a device supports both dma-buf and
> > regions? We have a flags field in vfio_device_gfx_plane_info, doesn't
> > it make sense to use it to identify which field, between region_index
> > and fd, is valid? We could even put region_index and fd into a union
> > with the flag bits indicating how to interpret the union, but I'm not
> > sure everyone was onboard with this idea. Seems like a waste of 4
> > bytes not to do that though.
> >
>
> Agree.
>
> > Thinking further, is the user ever in a situation where they query the
> > graphics plane info and can handle either a dma-buf or a region? It
> > seems more likely that the user needs to know early on which is
> > supported and would then require that they continue to see compatible
> > plane information... Should the user then be able to specify whether
> > they want a dma-buf or a region? Perhaps these flag bits are actually
> > input and the return should be -errno if the driver cannot produce
> > something compatible.
> >
> > Maybe we'd therefore define 3 flag bits: PROBE, DMABUF, REGION. In
> > this initial implementation, DMABUF or REGION would always be set by
> > the user to request that type of interface. Additionally, the QUERY
> > bit could be set to probe compatibility, thus if PROBE and REGION are
> > set, the vendor driver would return success only if it supports the
> > region based interface. If PROBE and DMABUF are set, the vendor driver
> > returns success only if the dma-buf based interface is supported. The
> > value of the remainder of the structure is undefined for PROBE.
> > Additionally setting both DMABUF and REGION is invalid. Undefined
> > flags bits must be validated as zero by the drivers for future use
> > (thus if we later define DMABUFv2, an older driver should
> > automatically return -errno when probed or requested).
> >
>
> Are you saying all of this to be part of VFIO_DEVICE_QUERY_GFX_PLANE ioctl?
>
> Let me summarize what we need, taking QEMU as reference:
> 1. From vfio_initfn(), for REGION case, get region info:
> vfio_get_dev_region_info(.., VFIO_REGION_SUBTYPE_CONSOLE_REGION,
> &vdev->console_opregion)
>
> If above return success, setup console REGION and mmap.
> I don't know what is required for DMABUF at this moment.
>
> If console VNC is supported either DMABUF or REGION, initialize console
> and register its callback operations:
>
> static const GraphicHwOps vfio_console_ops = {
> .gfx_update = vfio_console_update_display,
> };
>
> vdev->console = graphic_console_init(DEVICE(vdev), 0, &vfio_console_ops,
> vdev);
I might structure it that vfio_initfn() would call
ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with the PROBE bit set with either
DMABUF or REGION set as the interface type in the flags field. If
REGION is the probed interface and success is returned, then QEMU might
go look for regions of the appropriate type, however the
vfio_device_gfx_plane_info structure is canonical source for the region
index, so QEMU would probably be wise to use that and only use the
region type for consistency testing.
> 2. On above console registration, vfio_console_update_display() gets
> called for each refresh cycle of console. In that:
> - call ioctl(VFIO_DEVICE_QUERY_GFX_PLANE)
> - if (queried size > 0), update QEMU console surface (for REGION case
> read mmaped region, for DMABUF read surface using fd)
The ioctl would be called with REGION or DMABUF based on the initial
probe call, ex. we probed that REGION is supported and now we continue
to ask for region based updates. QEMU would need to verify the region
index matches that already mapped, remapping a different region if
necessary, and interpret the graphics parameters to provide the screen
update.
> Alex, in your proposal above, my understanding is
> ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with PROBE flag should be called in
> step #1.
> In step #2, ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) will be without PROBE
> flag, but either DMABUF or REGION flag based on what is returned as
> supported by vendor driver in step #1. Is that correct?
Yes, that's the idea. Does it make sense/provide value?
> > It seems like this handles all the cases, the user
Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers
Hi,
On 3 August 2017 at 12:00, Daniel Stone wrote:
> On 1 August 2017 at 17:58, Ben Widawsky wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
>> *dev_priv,
>> plane_formats = skl_plane_formats;
>> num_plane_formats = ARRAY_SIZE(skl_plane_formats);
>> modifiers = skl_plane_format_modifiers;
>> + } else if (INTEL_GEN(dev_priv) >= 9) {
>> + intel_plane->can_scale = true;
>> + state->scaler_id = -1;
>> +
>> + intel_plane->update_plane = skl_update_plane;
>> + intel_plane->disable_plane = skl_disable_plane;
>> +
>> + plane_formats = skl_plane_formats;
>> + num_plane_formats = ARRAY_SIZE(skl_plane_formats);
>> + if (pipe >= PIPE_C)
>
>
> if (pipe >= PIPE_C || plane >= PLANE_SPRITE1)
>
> cf. skl_check_ccs_aux_surface() which rejects CCS on anything other
> than PRIMARY/SPRITE0.
Turns out that should be 1 rather than PLANE_SPRITE1.
Anyway, I've pulled out CCS modifiers for all sprite planes in this
series. Whilst actually testing it, I discovered DDB allocations were
hopelessly broken.
Starting with a 1920x1080 primary plane which had (at some point) had
a CCS surface on it, and moving to a 1920x1080 _linear_ primary plane
with a 256x256 CCS sprite plane, I ended up with a DDB split of 443
primary / 32 plane. Y-tiling needs 33 blocks for even 256x256, so it
didn't work.
Given that, I've removed advertisement of Y, Yf, Y_CCS and Y_CCS, in
order to not give userspace false hope. Once DDB allocation is fixed,
we can start advertising these modifiers.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/8] tests/kms_ccs: Convert int/bool to enum
Rather than using TEST_UNCOMPRESSED / TEST_COMPRESSED as alternately
either an int or a bool, change it to a bitfield enum.
This will let us add more parameters later to control framebuffer
generation.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index ef952f2b..14d23ac1 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -35,6 +35,10 @@ enum test_flags {
TEST_BAD_ROTATION_90= 1 << 4,
};
+enum test_fb_flags {
+ FB_COMPRESSED = 1 << 0,
+};
+
typedef struct {
int drm_fd;
igt_display_t display;
@@ -53,7 +57,7 @@ typedef struct {
#define RED0x00ff
-static void render_fb(data_t *data, bool compressed,
+static void render_fb(data_t *data, enum test_fb_flags fb_flags,
int height, unsigned int stride)
{
struct igt_fb *fb = &data->fb;
@@ -67,7 +71,7 @@ static void render_fb(data_t *data, bool compressed,
0, fb->size,
PROT_READ | PROT_WRITE);
- if (compressed) {
+ if (fb_flags & FB_COMPRESSED) {
/* In the compressed case, we want the top half of the
* surface to be uncompressed and the bottom half to be
* compressed.
@@ -128,7 +132,7 @@ static void render_ccs(data_t *data, uint32_t gem_handle,
munmap(ptr, size);
}
-static void display_fb(data_t *data, int compressed)
+static void display_fb(data_t *data, enum test_fb_flags fb_flags)
{
struct local_drm_mode_fb_cmd2 f = {};
struct igt_fb *fb = &data->fb;
@@ -146,7 +150,7 @@ static void display_fb(data_t *data, int compressed)
mode = igt_output_get_mode(data->output);
- if (compressed)
+ if (fb_flags & FB_COMPRESSED)
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED_CCS;
else
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED;
@@ -167,7 +171,7 @@ static void display_fb(data_t *data, int compressed)
f.offsets[0] = 0;
size[0] = f.pitches[0] * ALIGN(height, 32);
- if (compressed) {
+ if (fb_flags & FB_COMPRESSED) {
/* From the Sky Lake PRM, Vol 12, "Color Control Surface":
*
*"The compression state of the cache-line pair is
@@ -215,9 +219,9 @@ static void display_fb(data_t *data, int compressed)
fb->cairo_surface = NULL;
fb->domain = 0;
- render_fb(data, compressed, f.height, f.pitches[0]);
+ render_fb(data, fb_flags, f.height, f.pitches[0]);
- if (compressed)
+ if (fb_flags & FB_COMPRESSED)
render_ccs(data, f.handles[0], f.offsets[1], size[1],
f.height, f.pitches[1]);
@@ -238,25 +242,24 @@ static void display_fb(data_t *data, int compressed)
igt_debug_wait_for_keypress("ccs");
}
-#define TEST_UNCOMPRESSED 0
-#define TEST_COMPRESSED 1
-
static void test_output(data_t *data)
{
igt_display_t *display = &data->display;
igt_plane_t *primary;
igt_crc_t crc, ref_crc;
igt_pipe_crc_t *pipe_crc;
+ enum test_fb_flags fb_flags = 0;
igt_output_set_pipe(data->output, data->pipe);
if (data->flags & TEST_CRC) {
+
pipe_crc = igt_pipe_crc_new(data->drm_fd, data->pipe,
INTEL_PIPE_CRC_SOURCE_AUTO);
- display_fb(data, TEST_COMPRESSED);
+ display_fb(data, fb_flags | FB_COMPRESSED);
igt_pipe_crc_collect_crc(pipe_crc, &ref_crc);
- display_fb(data, TEST_UNCOMPRESSED);
+ display_fb(data, fb_flags);
igt_pipe_crc_collect_crc(pipe_crc, &crc);
igt_assert_crc_equal(&crc, &ref_crc);
@@ -267,7 +270,7 @@ static void test_output(data_t *data)
if (data->flags & TEST_BAD_PIXEL_FORMAT ||
data->flags & TEST_BAD_ROTATION_90) {
- display_fb(data, TEST_COMPRESSED);
+ display_fb(data, fb_flags | FB_COMPRESSED);
}
primary = igt_output_get_plane_type(data->output,
DRM_PLANE_TYPE_PRIMARY);
--
2.13.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/8] tests/kms_ccs: Paramaterize color for framebuffer
Will be used in later patches.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index c02a0433..50bb2ad6 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -48,14 +48,12 @@ typedef struct {
enum test_flags flags;
} data_t;
+#define RED0x00ff
#define COMPRESSED_RED 0x0fff
-#define COMPRESSED_GREEN 0x000ff00f
-#define COMPRESSED_BLUE0x0fff
#define CCS_UNCOMPRESSED 0x0
#define CCS_COMPRESSED 0x55
-#define RED0x00ff
static void render_fb(data_t *data, uint32_t gem_handle, unsigned int size,
enum test_fb_flags fb_flags,
@@ -63,6 +61,8 @@ static void render_fb(data_t *data, uint32_t gem_handle,
unsigned int size,
{
uint32_t *ptr;
unsigned int half_height, half_size;
+ uint32_t uncompressed_color = RED;
+ uint32_t compressed_color = COMPRESSED_RED;
int i;
ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, size,
@@ -83,13 +83,13 @@ static void render_fb(data_t *data, uint32_t gem_handle,
unsigned int size,
half_size = half_height * stride;
for (i = 0; i < size / 4; i++) {
if (i < half_size / 4)
- ptr[i] = RED;
+ ptr[i] = uncompressed_color;
else
- ptr[i] = COMPRESSED_RED;
+ ptr[i] = compressed_color;
}
} else {
for (i = 0; i < size / 4; i++)
- ptr[i] = RED;
+ ptr[i] = uncompressed_color;
}
munmap(ptr, size);
--
2.13.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/8] tests/kms_ccs: Split FB generation into helper
Create a new helper for generating and rendering the framebuffer, rather
than doing it inline with applying the configuration. This will be used
later to generate a different plane configuration.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 73 ++---
1 file changed, 39 insertions(+), 34 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 14d23ac1..cdc56f79 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -57,18 +57,15 @@ typedef struct {
#define RED0x00ff
-static void render_fb(data_t *data, enum test_fb_flags fb_flags,
+static void render_fb(data_t *data, uint32_t gem_handle, unsigned int size,
+ enum test_fb_flags fb_flags,
int height, unsigned int stride)
{
- struct igt_fb *fb = &data->fb;
uint32_t *ptr;
unsigned int half_height, half_size;
int i;
- igt_assert(fb->fb_id);
-
- ptr = gem_mmap__cpu(data->drm_fd, fb->gem_handle,
- 0, fb->size,
+ ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, size,
PROT_READ | PROT_WRITE);
if (fb_flags & FB_COMPRESSED) {
@@ -84,18 +81,18 @@ static void render_fb(data_t *data, enum test_fb_flags
fb_flags,
*/
half_height = ALIGN(height, 128) / 2;
half_size = half_height * stride;
- for (i = 0; i < fb->size / 4; i++) {
+ for (i = 0; i < size / 4; i++) {
if (i < half_size / 4)
ptr[i] = RED;
else
ptr[i] = COMPRESSED_RED;
}
} else {
- for (i = 0; i < fb->size / 4; i++)
+ for (i = 0; i < size / 4; i++)
ptr[i] = RED;
}
- munmap(ptr, fb->size);
+ munmap(ptr, size);
}
static unsigned int
@@ -118,8 +115,7 @@ static void render_ccs(data_t *data, uint32_t gem_handle,
half_height = ALIGN(height, 128) / 2;
ccs_half_height = half_height / 16;
- ptr = gem_mmap__cpu(data->drm_fd, gem_handle,
- offset, size,
+ ptr = gem_mmap__cpu(data->drm_fd, gem_handle, offset, size,
PROT_READ | PROT_WRITE);
for (i = 0; i < size; i++) {
@@ -132,32 +128,23 @@ static void render_ccs(data_t *data, uint32_t gem_handle,
munmap(ptr, size);
}
-static void display_fb(data_t *data, enum test_fb_flags fb_flags)
+static void generate_fb(data_t *data, struct igt_fb *fb,
+ int width, int height,
+ enum test_fb_flags fb_flags)
{
struct local_drm_mode_fb_cmd2 f = {};
- struct igt_fb *fb = &data->fb;
- igt_display_t *display = &data->display;
- igt_plane_t *primary;
- drmModeModeInfo *mode;
- unsigned int width, height;
unsigned int size[2];
uint64_t modifier;
- enum igt_commit_style commit = COMMIT_UNIVERSAL;
int ret;
- if (data->display.is_atomic)
- commit = COMMIT_ATOMIC;
-
- mode = igt_output_get_mode(data->output);
-
if (fb_flags & FB_COMPRESSED)
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED_CCS;
else
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED;
f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
- f.width = ALIGN(mode->hdisplay, 16);
- f.height = ALIGN(mode->vdisplay, 8);
+ f.width = ALIGN(width, 16);
+ f.height = ALIGN(height, 8);
if (data->flags & TEST_BAD_PIXEL_FORMAT)
f.pixel_format = DRM_FORMAT_RGB565;
@@ -195,9 +182,13 @@ static void display_fb(data_t *data, enum test_fb_flags
fb_flags)
f.handles[0] = gem_create(data->drm_fd, size[0] + size[1]);
f.handles[1] = f.handles[0];
+ render_ccs(data, f.handles[1], f.offsets[1], size[1],
+ height, f.pitches[1]);
} else
f.handles[0] = gem_create(data->drm_fd, size[0]);
+ render_fb(data, f.handles[0], size[0], fb_flags, height, f.pitches[0]);
+
ret = drmIoctl(data->drm_fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f);
if (data->flags & TEST_BAD_PIXEL_FORMAT) {
igt_assert_eq(ret, -1);
@@ -218,15 +209,30 @@ static void display_fb(data_t *data, enum test_fb_flags
fb_flags)
fb->size = size[0];
fb->cairo_surface = NULL;
fb->domain = 0;
+}
+
+static void try_config(data_t *data, enum test_fb_flags fb_flags)
+{
+ igt_display_t *display = &data->display;
+ igt_plane_t *primary;
+ drmModeModeInfo *drm_mode = igt_output_get_mode(data->output);
+ enum igt_commit_style commit;
+ int ret;
- render_fb(data, fb_flags, f.height, f.pitches[0]);
+ if (data->display.is_atomic)
+ commit = COMMIT_ATOMIC;
+
[Intel-gfx] [PATCH i-g-t 5/8] tests/kms_ccs: Reshuffle test name and loop
In preparation for also testing sprites.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 50bb2ad6..1a5cdcd4 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -342,13 +342,13 @@ igt_main
for (data.pipe = PIPE_A; data.pipe < IGT_MAX_PIPES; data.pipe++) {
data.flags = TEST_CRC;
- igt_subtest_f("pipe-%s-crc-basic", kmstest_pipe_name(data.pipe))
+ igt_subtest_f("pipe-%s-crc-primary-basic",
+ kmstest_pipe_name(data.pipe))
test(&data);
- }
- for (data.pipe = PIPE_A; data.pipe < IGT_MAX_PIPES; data.pipe++) {
- data.flags = TEST_CRC | TEST_ROTATE_180;
- igt_subtest_f("pipe-%s-crc-rotation-180",
kmstest_pipe_name(data.pipe))
+ data.flags |= TEST_ROTATE_180;
+ igt_subtest_f("pipe-%s-crc-primary-rotation-180",
+ kmstest_pipe_name(data.pipe))
test(&data);
}
--
2.13.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 6/8] tests/kms_ccs: Test for supported modifier
Make sure the CCS modifier is supported on our plane, before we try to
use it on that plane.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 117 +++-
1 file changed, 116 insertions(+), 1 deletion(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 1a5cdcd4..e74a68af 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -54,6 +54,118 @@ typedef struct {
#define CCS_UNCOMPRESSED 0x0
#define CCS_COMPRESSED 0x55
+struct local_drm_format_modifier {
+ /* Bitmask of formats in get_plane format list this info applies to. The
+ * offset allows a sliding window of which 64 formats (bits).
+ *
+ * Some examples:
+ * In today's world with < 65 formats, and formats 0, and 2 are
+ * supported
+ * 0x0005
+ * ^-offset = 0, formats = 5
+ *
+ * If the number formats grew to 128, and formats 98-102 are
+ * supported with the modifier:
+ *
+ * 0x003c
+ * ^
+ * |__offset = 64, formats = 0x3c
+ *
+ */
+ uint64_t formats;
+ uint32_t offset;
+ uint32_t pad;
+
+ /* This modifier can be used with the format for this plane. */
+ uint64_t modifier;
+};
+
+struct local_drm_format_modifier_blob {
+#define LOCAL_FORMAT_BLOB_CURRENT 1
+ /* Version of this blob format */
+ uint32_t version;
+
+ /* Flags */
+ uint32_t flags;
+
+ /* Number of fourcc formats supported */
+ uint32_t count_formats;
+
+ /* Where in this blob the formats exist (in bytes) */
+ uint32_t formats_offset;
+
+ /* Number of drm_format_modifiers */
+ uint32_t count_modifiers;
+
+ /* Where in this blob the modifiers exist (in bytes) */
+ uint32_t modifiers_offset;
+
+ /* u32 formats[] */
+ /* struct drm_format_modifier modifiers[] */
+};
+
+static inline uint32_t *
+formats_ptr(struct local_drm_format_modifier_blob *blob)
+{
+ return (uint32_t *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct local_drm_format_modifier *
+modifiers_ptr(struct local_drm_format_modifier_blob *blob)
+{
+ return (struct local_drm_format_modifier *)(((char *)blob) +
blob->modifiers_offset);
+}
+
+static void plane_require_ccs(data_t *data, igt_plane_t *plane, uint32_t
format)
+{
+ drmModePropertyBlobPtr blob;
+ struct local_drm_format_modifier_blob *blob_data;
+ struct local_drm_format_modifier *modifiers;
+ uint32_t *formats;
+ uint64_t blob_id;
+ bool ret;
+ int fmt_idx = -1;
+
+ ret = kmstest_get_property(data->drm_fd, plane->drm_plane->plane_id,
+ DRM_MODE_OBJECT_PLANE, "IN_FORMATS",
+ NULL, &blob_id, NULL);
+ igt_skip_on_f(ret == false, "IN_FORMATS not supported by kernel\n");
+ igt_skip_on_f(blob_id == 0, "IN_FORMATS not supported by plane\n");
+ blob = drmModeGetPropertyBlob(data->drm_fd, blob_id);
+ igt_assert(blob);
+ igt_assert_lte(sizeof(struct local_drm_format_modifier_blob),
+ blob->length);
+
+ blob_data = (struct local_drm_format_modifier_blob *) blob->data;
+ formats = formats_ptr(blob_data);
+ for (int i = 0; i < blob_data->count_formats; i++) {
+ if (formats[i] == format) {
+ fmt_idx = i;
+ break;
+ }
+ }
+
+ igt_skip_on_f(fmt_idx == -1,
+ "Format 0x%x not supported by plane\n", format);
+
+ modifiers = modifiers_ptr(blob_data);
+ for (int i = 0; i < blob_data->count_modifiers; i++) {
+ if (modifiers[i].modifier != LOCAL_I915_FORMAT_MOD_Y_TILED_CCS)
+ continue;
+
+ if (modifiers[i].offset > fmt_idx ||
+ fmt_idx > modifiers[i].offset + 63)
+ continue;
+
+ if (modifiers[i].formats &
+ (1UL << (fmt_idx - modifiers[i].offset)))
+ return;
+
+ igt_skip("i915 CCS modifier not supported for format\n");
+ }
+
+ igt_skip("i915 CCS modifier not supported by kernel for plane\n");
+}
static void render_fb(data_t *data, uint32_t gem_handle, unsigned int size,
enum test_fb_flags fb_flags,
@@ -222,12 +334,15 @@ static void try_config(data_t *data, enum test_fb_flags
fb_flags)
else
commit = COMMIT_UNIVERSAL;
+ primary = igt_output_get_plane_type(data->output,
+ DRM_PLANE_TYPE_PRIMARY);
+ plane_require_ccs(data, primary, DRM_FORMAT_XRGB);
+
generate_fb(data, &data->fb, drm_mode->hdisplay, drm_mode->vdisplay,
fb_flags);
if (data->flags & TEST_BAD_PIXEL_FORMAT)
[Intel-gfx] [PATCH i-g-t 7/8] tests/kms_ccs: Split all tests into subtests
Some subtests were magically doing a for-each-pipe loop. Remove that,
and have all multi-pipe tests actually work across all pipes.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 62 +++--
1 file changed, 20 insertions(+), 42 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index e74a68af..79856f97 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -369,6 +369,13 @@ static void test_output(data_t *data)
igt_pipe_crc_t *pipe_crc;
enum test_fb_flags fb_flags = 0;
+ igt_display_require_output_on_pipe(display, data->pipe);
+
+ /* Sets data->output with a valid output. */
+ for_each_valid_output_on_pipe(display, data->pipe, data->output) {
+ break;
+ }
+
igt_output_set_pipe(data->output, data->pipe);
if (data->flags & TEST_CRC) {
@@ -404,31 +411,6 @@ static void test_output(data_t *data)
igt_remove_fb(data->drm_fd, &data->fb);
}
-static void test(data_t *data)
-{
- igt_display_t *display = &data->display;
- int valid_tests = 0;
- enum pipe wanted_pipe = data->pipe;
-
- igt_skip_on(wanted_pipe >= display->n_pipes);
-
- for_each_pipe_with_valid_output(display, data->pipe, data->output) {
- if (wanted_pipe != PIPE_NONE && data->pipe != wanted_pipe)
- continue;
-
- test_output(data);
-
- valid_tests++;
-
- igt_info("\n%s on pipe %s, connector %s: PASSED\n\n",
-igt_subtest_name(),
-kmstest_pipe_name(data->pipe),
-igt_output_name(data->output));
- }
-
- igt_require_f(valid_tests, "no valid crtc/connector combinations
found\n");
-}
-
static data_t data;
igt_main
@@ -443,28 +425,24 @@ igt_main
igt_display_init(&data.display, data.drm_fd);
}
- igt_subtest_f("bad-pixel-format") {
+ for_each_pipe(&data.display, data.pipe) {
+ const char *pipe_name = kmstest_pipe_name(data.pipe);
+
data.flags = TEST_BAD_PIXEL_FORMAT;
- data.pipe = PIPE_NONE;
- test(&data);
- }
+ igt_subtest_f("pipe-%s-bad-pixel-format", pipe_name)
+ test_output(&data);
- igt_subtest_f("bad-rotation-90") {
data.flags = TEST_BAD_ROTATION_90;
- data.pipe = PIPE_NONE;
- test(&data);
- }
+ igt_subtest_f("pipe-%s-bad-rotation-90", pipe_name)
+ test_output(&data);
- for (data.pipe = PIPE_A; data.pipe < IGT_MAX_PIPES; data.pipe++) {
data.flags = TEST_CRC;
- igt_subtest_f("pipe-%s-crc-primary-basic",
- kmstest_pipe_name(data.pipe))
- test(&data);
-
- data.flags |= TEST_ROTATE_180;
- igt_subtest_f("pipe-%s-crc-primary-rotation-180",
- kmstest_pipe_name(data.pipe))
- test(&data);
+ igt_subtest_f("pipe-%s-crc-primary-basic", pipe_name)
+ test_output(&data);
+
+ data.flags = TEST_CRC | TEST_ROTATE_180;
+ igt_subtest_f("pipe-%s-crc-primary-rotation-180", pipe_name)
+ test_output(&data);
}
igt_fixture
--
2.13.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 8/8] tests/kms_ccs: Test CCS on sprite planes
Also try to test CCS on available non-primary planes. However, as there
is not enough bandwidth to scan out both the primary and sprite planes
when using CCS (or even Y-tiled), fall back to linear for the primary
plane when using CCS for a sprite/cursor plane.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 74 +++--
1 file changed, 67 insertions(+), 7 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 79856f97..c544b36f 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -37,19 +37,24 @@ enum test_flags {
enum test_fb_flags {
FB_COMPRESSED = 1 << 0,
+ FB_HAS_PLANE= 1 << 1,
};
typedef struct {
int drm_fd;
igt_display_t display;
struct igt_fb fb;
+ struct igt_fb fb_sprite;
igt_output_t *output;
enum pipe pipe;
enum test_flags flags;
+ igt_plane_t *plane;
} data_t;
#define RED0x00ff
#define COMPRESSED_RED 0x0fff
+#define GREEN 0xff00
+#define COMPRESSED_GREEN 0x000ff00f
#define CCS_UNCOMPRESSED 0x0
#define CCS_COMPRESSED 0x55
@@ -173,8 +178,10 @@ static void render_fb(data_t *data, uint32_t gem_handle,
unsigned int size,
{
uint32_t *ptr;
unsigned int half_height, half_size;
- uint32_t uncompressed_color = RED;
- uint32_t compressed_color = COMPRESSED_RED;
+ uint32_t uncompressed_color = data->plane ? GREEN : RED;
+ uint32_t compressed_color =
+ data->plane ? COMPRESSED_GREEN : COMPRESSED_RED;
+ uint32_t bad_color = RED;
int i;
ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, size,
@@ -200,8 +207,19 @@ static void render_fb(data_t *data, uint32_t gem_handle,
unsigned int size,
ptr[i] = compressed_color;
}
} else {
- for (i = 0; i < size / 4; i++)
- ptr[i] = uncompressed_color;
+ /* When we're displaying the primary plane underneath a
+* sprite plane, cut out a 128 x 128 area (less than the sprite)
+* plane size which we paint red, so we know easily if it's
+* bad.
+*/
+ for (i = 0; i < size / 4; i++) {
+ if ((fb_flags & FB_HAS_PLANE) &&
+i < (stride * 128) && (i % (stride / 4)) < 1) {
+ ptr[i] = bad_color;
+ } else {
+ ptr[i] = uncompressed_color;
+ }
+ }
}
munmap(ptr, size);
@@ -249,10 +267,17 @@ static void generate_fb(data_t *data, struct igt_fb *fb,
uint64_t modifier;
int ret;
+ /* Use either compressed or Y-tiled to test. However, given the lack of
+* available bandwidth, we use linear for the primary plane when
+* testing sprites, since we cannot fit two CCS planes into the
+* available FIFO configurations.
+*/
if (fb_flags & FB_COMPRESSED)
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED_CCS;
- else
+ else if (!(fb_flags & FB_HAS_PLANE))
modifier = LOCAL_I915_FORMAT_MOD_Y_TILED;
+ else
+ modifier = 0;
f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
f.width = width;
@@ -338,8 +363,17 @@ static void try_config(data_t *data, enum test_fb_flags
fb_flags)
DRM_PLANE_TYPE_PRIMARY);
plane_require_ccs(data, primary, DRM_FORMAT_XRGB);
- generate_fb(data, &data->fb, drm_mode->hdisplay, drm_mode->vdisplay,
- fb_flags);
+ if (data->plane && fb_flags & FB_COMPRESSED) {
+ plane_require_ccs(data, data->plane, DRM_FORMAT_XRGB);
+ generate_fb(data, &data->fb, drm_mode->hdisplay,
+ drm_mode->vdisplay,
+ (fb_flags & ~FB_COMPRESSED) | FB_HAS_PLANE);
+ generate_fb(data, &data->fb_sprite, 256, 256, fb_flags);
+ } else {
+ generate_fb(data, &data->fb, drm_mode->hdisplay,
+ drm_mode->vdisplay, fb_flags);
+ }
+
if (data->flags & TEST_BAD_PIXEL_FORMAT)
return;
@@ -347,6 +381,12 @@ static void try_config(data_t *data, enum test_fb_flags
fb_flags)
igt_plane_set_size(primary, drm_mode->hdisplay, drm_mode->vdisplay);
igt_plane_set_fb(primary, &data->fb);
+ if (data->plane && fb_flags & FB_COMPRESSED) {
+ igt_plane_set_position(data->plane, 0, 0);
+ igt_plane_set_size(data->plane, 256, 256);
+ igt_plane_set_fb(data->plane, &data->fb_sprite);
+ }
+
if (data->flags & TEST_ROTATE_180)
igt_plane_set_rotation(primary, IGT_ROTATION_180);
[Intel-gfx] [PATCH i-g-t 3/8] tests/kms_ccs: Remove excessive FB alignment
We don't need to align the framebuffer dimensions to the tile size. As long as the pitch is aligned to the tile width, and the BO dimensions can fit full tiles of both aligned pitch and aligned height, we don't need to claim the FB itself is larger. Signed-off-by: Daniel Stone --- tests/kms_ccs.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c index cdc56f79..c02a0433 100644 --- a/tests/kms_ccs.c +++ b/tests/kms_ccs.c @@ -143,16 +143,14 @@ static void generate_fb(data_t *data, struct igt_fb *fb, modifier = LOCAL_I915_FORMAT_MOD_Y_TILED; f.flags = LOCAL_DRM_MODE_FB_MODIFIERS; - f.width = ALIGN(width, 16); - f.height = ALIGN(height, 8); + f.width = width; + f.height = height; if (data->flags & TEST_BAD_PIXEL_FORMAT) f.pixel_format = DRM_FORMAT_RGB565; else f.pixel_format = DRM_FORMAT_XRGB; - width = f.width; - height = f.height; f.pitches[0] = ALIGN(width * 4, 128); f.modifier[0] = modifier; f.offsets[0] = 0; @@ -173,12 +171,12 @@ static void generate_fb(data_t *data, struct igt_fb *fb, * 32x16. Since the main surface has a 32-bit format, we * need to multiply width by 4 to get bytes. */ - width = ALIGN(f.width * 4, 32) / 32; - height = ALIGN(f.height, 16) / 16; - f.pitches[1] = ALIGN(width * 1, 128); + int ccs_width = ALIGN(width * 4, 32) / 32; + int ccs_height = ALIGN(height, 16) / 16; + f.pitches[1] = ALIGN(ccs_width * 1, 128); f.modifier[1] = modifier; f.offsets[1] = size[0]; - size[1] = f.pitches[1] * ALIGN(height, 32); + size[1] = f.pitches[1] * ALIGN(ccs_height, 32); f.handles[0] = gem_create(data->drm_fd, size[0] + size[1]); f.handles[1] = f.handles[0]; -- 2.13.4 ___ 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/psr: Preserve SRD_CTL bit 29 on PSR init
== Series Details == Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init URL : https://patchwork.freedesktop.org/series/28507/ State : success == Summary == Series 28507v1 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init https://patchwork.freedesktop.org/api/1.0/series/28507/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:415s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:496s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:480s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:527s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:511s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:588s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:459s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:563s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:575s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:529s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:443s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:651s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:424s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:486s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:549s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:409s b7a69d408ccdcc8d4976baa3fc4b6dcdc5c21c8b drm-tip: 2017y-08m-08d-13h-56m-35s UTC integration manifest d7b727d4219b drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5343/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
Bit 29 of SRD_CTL needs to have its value preserved, so right before we
write out the register we go ahead and read the register and preserve
the value of that bit before we write out the configured register value.
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b2546ad..ea8e421 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3872,6 +3872,7 @@ enum {
#define EDP_PSR_CTL_MMIO(dev_priv->psr_mmio_base +
0)
#define EDP_PSR_ENABLE (1<<31)
#define BDW_PSR_SINGLE_FRAME (1<<30)
+#define EDP_PSR_RESTORE_PSR_ACTIVE_CTX(1<<29) /* SW can't modify */
#define EDP_PSR_LINK_STANDBY (1<<27)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 559f1ab..0d08efa 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -315,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP1_TP2_SEL;
+ val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX;
I915_WRITE(EDP_PSR_CTL, val);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Introduce intel_ddi_dp_level.
== Series Details == Series: series starting with [1/6] drm/i915: Introduce intel_ddi_dp_level. URL : https://patchwork.freedesktop.org/series/28499/ State : success == Summary == Series 28499v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/28499/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:436s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:422s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:356s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:494s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:503s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:521s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:511s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:427s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:459s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:568s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:448s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:645s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:467s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:426s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:411s b7a69d408ccdcc8d4976baa3fc4b6dcdc5c21c8b drm-tip: 2017y-08m-08d-13h-56m-35s UTC integration manifest f45c43823f65 drm/i915/cnl: Fix DP max voltage 81a935cee04c drm/i915/cnl: Fix DDI hdmi level selection. 62bd6a4f6c5c drm/i915/cnl: Move ddi buf trans related functions up. 993326e1212f drm/i915/cnl: Move voltage check into ddi buf trans functions. 6027699cafe7 drm/i915: Align vswing sequences with old ddi buffer registers. af03eefc23ab drm/i915: Introduce intel_ddi_dp_level. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5342/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] lib: Add hooks for enabling ftrace
== Series Details == Series: series starting with [1/2] lib: Add hooks for enabling ftrace URL : https://patchwork.freedesktop.org/series/28491/ State : failure == Summary == Making check in lib make[1]: Entering directory '/home/cidrm/intel-gpu-tools/lib' make check-recursive make[2]: Entering directory '/home/cidrm/intel-gpu-tools/lib' Making check in . make[3]: Entering directory '/home/cidrm/intel-gpu-tools/lib' make[3]: Leaving directory '/home/cidrm/intel-gpu-tools/lib' Making check in tests make[3]: Entering directory '/home/cidrm/intel-gpu-tools/lib/tests' make igt_no_exit igt_no_exit_list_only igt_fork_helper igt_list_only igt_no_subtest igt_simulation igt_simple_test_subtests igt_stats igt_timeout igt_invalid_subtest_name igt_segfault igt_subtest_group igt_assert igt_exit_handler igt_hdmi_inject make[4]: Entering directory '/home/cidrm/intel-gpu-tools/lib/tests' CC igt_no_exit.o CC igt_no_exit_list_only.o CC igt_fork_helper.o CC igt_list_only.o CC igt_no_subtest.o CC igt_simulation.o CC igt_simple_test_subtests.o CC igt_stats.o CC igt_timeout.o CC igt_invalid_subtest_name.o CC igt_segfault.o CC igt_subtest_group.o CC igt_assert.o CC igt_exit_handler.o CC igt_hdmi_inject.o CCLD igt_timeout CCLD igt_invalid_subtest_name CCLD igt_simple_test_subtests CCLD igt_no_exit_list_only CCLD igt_no_exit CCLD igt_subtest_group CCLD igt_no_subtest CCLD igt_exit_handler CCLD igt_list_only CCLD igt_fork_helper CCLD igt_assert CCLD igt_simulation CCLD igt_stats CCLD igt_segfault CCLD igt_hdmi_inject make[4]: Leaving directory '/home/cidrm/intel-gpu-tools/lib/tests' make check-TESTS make[4]: Entering directory '/home/cidrm/intel-gpu-tools/lib/tests' make[5]: Entering directory '/home/cidrm/intel-gpu-tools/lib/tests' PASS: igt_list_only XFAIL: igt_no_exit_list_only XFAIL: igt_no_subtest FAIL: igt_simulation XFAIL: igt_no_exit FAIL: igt_segfault PASS: igt_fork_helper FAIL: igt_exit_handler XFAIL: igt_simple_test_subtests FAIL: igt_hdmi_inject FAIL: igt_stats XFAIL: igt_timeout XFAIL: igt_invalid_subtest_name FAIL: igt_assert FAIL: igt_subtest_group Testsuite summary for intel-gpu-tools 1.19 # TOTAL: 15 # PASS: 2 # SKIP: 0 # XFAIL: 6 # FAIL: 7 # XPASS: 0 # ERROR: 0 See lib/tests/test-suite.log Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=IGT Makefile:983: recipe for target 'test-suite.log' failed make[5]: Leaving directory '/home/cidrm/intel-gpu-tools/lib/tests' Makefile:1089: recipe for target 'check-TESTS' failed make[4]: Leaving directory '/home/cidrm/intel-gpu-tools/lib/tests' Makefile:1260: recipe for target 'check-am' failed make[3]: Leaving directory '/home/cidrm/intel-gpu-tools/lib/tests' Makefile:716: recipe for target 'check-recursive' failed make[2]: Leaving directory '/home/cidrm/intel-gpu-tools/lib' Makefile:865: recipe for target 'check' failed make[1]: Leaving directory '/home/cidrm/intel-gpu-tools/lib' Makefile:528: recipe for target 'check-recursive' failed ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for tools/null_state_gen: Don't upload color calc and depth stencil on gen6
== Series Details == Series: tools/null_state_gen: Don't upload color calc and depth stencil on gen6 URL : https://patchwork.freedesktop.org/series/28496/ State : success == Summary == IGT patchset tested on top of latest successful build eeff6a1d9c4e2c195b30ad95ee36a58ef6ca3387 intel_gpu_top: Use drm_open_driver, don't need drm master with latest DRM-Tip kernel build CI_DRM_2933 9d6913ce7311 drm-tip: 2017y-08m-08d-12h-52m-33s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:424s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:356s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:484s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:492s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:520s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:513s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:584s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:426s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:409s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:411s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:511s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:457s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:568s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:574s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:454s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:640s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:413s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_31/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+
On 4 August 2017 at 12:20, Lionel Landwerlin
wrote:
> From: Robert Bragg
>
> Signed-off-by: Robert Bragg
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 806
> ---
> 1 file changed, 768 insertions(+), 38 deletions(-)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index 26581ce4..279ff0c6 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -48,7 +48,9 @@ IGT_TEST_DESCRIPTION("Test the i915 perf metrics streaming
> interface");
> #define OAREPORT_REASON_MASK 0x3f
> #define OAREPORT_REASON_SHIFT 19
> #define OAREPORT_REASON_TIMER (1<<0)
> +#define OAREPORT_REASON_INTERNAL (3<<1)
> #define OAREPORT_REASON_CTX_SWITCH (1<<3)
> +#define OAREPORT_REASON_GO (1<<4)
> #define OAREPORT_REASON_CLK_RATIO (1<<5)
>
> #define GFX_OP_PIPE_CONTROL ((3 << 29) | (3 << 27) | (2 << 24))
> @@ -565,6 +567,22 @@ oa_exponent_to_ns(int exponent)
> return 10ULL * (2ULL << exponent) / timestamp_frequency;
> }
>
> +static bool
> +oa_report_ctx_is_valid(uint32_t *report)
> +{
> + if (IS_HASWELL(devid)) {
> + return false; /* TODO */
> + } else if (IS_GEN8(devid)) {
> + return report[0] & (1ul << 25);
> + } else if (IS_GEN9(devid)) {
> + return report[0] & (1ul << 16);
> + }
> +
> + /* Need to update this function for newer Gen. */
> + igt_assert(!"reached");
> +}
> +
> +
> static void
> hsw_sanity_check_render_basic_reports(uint32_t *oa_report0, uint32_t
> *oa_report1,
> enum drm_i915_oa_format fmt)
> @@ -669,6 +687,100 @@ gen8_40bit_a_delta(uint64_t value0, uint64_t value1)
> return value1 - value0;
> }
>
> +static void
> +accumulate_uint32(size_t offset,
> + uint32_t *report0,
> + uint32_t *report1,
> + uint64_t *delta)
> +{
> + uint32_t value0 = *(uint32_t *)(((uint8_t *)report0) + offset);
> + uint32_t value1 = *(uint32_t *)(((uint8_t *)report1) + offset);
> +
> + *delta += (uint32_t)(value1 - value0);
> +}
> +
> +static void
> +accumulate_uint40(int a_index,
> + uint32_t *report0,
> + uint32_t *report1,
> + enum drm_i915_oa_format format,
> + uint64_t *delta)
> +{
> + uint64_t value0 = gen8_read_40bit_a_counter(report0, format, a_index),
> +value1 = gen8_read_40bit_a_counter(report1, format, a_index);
> +
> + *delta += gen8_40bit_a_delta(value0, value1);
> +}
> +
> +static void
> +accumulate_reports(struct accumulator *accumulator,
> + uint32_t *start,
> + uint32_t *end)
> +{
> + enum drm_i915_oa_format format = accumulator->format;
> + uint64_t *deltas = accumulator->deltas;
> + int idx = 0;
> +
> + if (intel_gen(devid) >= 8) {
> + /* timestamp */
> + accumulate_uint32(4, start, end, deltas + idx++);
> +
> + /* clock cycles */
> + accumulate_uint32(12, start, end, deltas + idx++);
> + } else {
> + /* timestamp */
> + accumulate_uint32(4, start, end, deltas + idx++);
> + }
> +
> + for (int i = 0; i < oa_formats[format].n_a40; i++)
> + accumulate_uint40(i, start, end, format, deltas + idx++);
> +
> + for (int i = 0; i < oa_formats[format].n_a; i++) {
> + accumulate_uint32(oa_formats[format].a_off + 4 * i,
> + start, end, deltas + idx++);
> + }
> +
> + for (int i = 0; i < oa_formats[format].n_b; i++) {
> + accumulate_uint32(oa_formats[format].b_off + 4 * i,
> + start, end, deltas + idx++);
> + }
> +
> + for (int i = 0; i < oa_formats[format].n_c; i++) {
> + accumulate_uint32(oa_formats[format].c_off + 4 * i,
> + start, end, deltas + idx++);
> + }
> +}
> +
> +static void
> +accumulator_print(struct accumulator *accumulator, const char *title)
> +{
> + enum drm_i915_oa_format format = accumulator->format;
> + uint64_t *deltas = accumulator->deltas;
> + int idx = 0;
> +
> + igt_debug("%s:\n", title);
> + if (intel_gen(devid) >= 8) {
> + igt_debug("\ttime delta = %lu\n", deltas[idx++]);
> + igt_debug("\tclock cycle delta = %lu\n", deltas[idx++]);
> +
> + for (int i = 0; i < oa_formats[format].n_a40; i++)
> + igt_debug("\tA%u = %lu\n", i, deltas[idx++]);
> + } else {
> + igt_debug("\ttime delta = %lu\n", deltas[idx++]);
> + }
> +
> + for (int i = 0; i < oa_formats[format].n_a; i++) {
> + int a_id = oa_formats[format].first_a + i;
> + igt_debug("\tA%u = %lu\n", a_id, deltas[idx++]);
> + }
> +
>
[Intel-gfx] [PATCH 3/6] drm/i915/cnl: Move voltage check into ddi buf trans functions.
Let's start converging CNL buf translations to same style
used on previous platforms. So first thing is to use the
standard signature so we don't need to propagate the voltage
check into other parts of the code, but only on the parts
that it is really useful.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 48 ++--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 687b762d1b53..f8bc9ca8a905 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1830,9 +1830,10 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
}
static const struct cnl_ddi_buf_trans *
-cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv,
- u32 voltage, int *n_entries)
+cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_85V);
return cnl_ddi_translations_hdmi_0_85V;
@@ -1842,14 +1843,16 @@ cnl_get_buf_trans_hdmi(struct drm_i915_private
*dev_priv,
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
return cnl_ddi_translations_hdmi_1_05V;
- }
+ } else
+ MISSING_CASE(voltage);
return NULL;
}
static const struct cnl_ddi_buf_trans *
-cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv,
-u32 voltage, int *n_entries)
+cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_85V);
return cnl_ddi_translations_dp_0_85V;
@@ -1859,14 +1862,16 @@ cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv,
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_1_05V);
return cnl_ddi_translations_dp_1_05V;
- }
+ } else
+ MISSING_CASE(voltage);
return NULL;
}
static const struct cnl_ddi_buf_trans *
-cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
- u32 voltage, int *n_entries)
+cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
if (dev_priv->vbt.edp.low_vswing) {
if (voltage == VOLTAGE_INFO_0_85V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
@@ -1877,10 +1882,11 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_1_05V);
return cnl_ddi_translations_edp_1_05V;
- }
+ } else
+ MISSING_CASE(voltage);
return NULL;
} else {
- return cnl_get_buf_trans_dp(dev_priv, voltage, n_entries);
+ return cnl_get_buf_trans_dp(dev_priv, n_entries);
}
}
@@ -1888,31 +1894,19 @@ static void cnl_ddi_vswing_program(struct
drm_i915_private *dev_priv,
u32 level, enum port port, int type)
{
const struct cnl_ddi_buf_trans *ddi_translations = NULL;
- u32 n_entries, val, voltage;
+ u32 n_entries, val;
int ln;
- /*
-* Values for each port type are listed in
-* voltage swing programming tables.
-* Vccio voltage found in PORT_COMP_DW3.
-*/
- voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
-
if (type == INTEL_OUTPUT_HDMI) {
- ddi_translations = cnl_get_buf_trans_hdmi(dev_priv,
- voltage, &n_entries);
+ ddi_translations = cnl_get_buf_trans_hdmi(dev_priv, &n_entries);
} else if (type == INTEL_OUTPUT_DP) {
- ddi_translations = cnl_get_buf_trans_dp(dev_priv,
- voltage, &n_entries);
+ ddi_translations = cnl_get_buf_trans_dp(dev_priv, &n_entries);
} else if (type == INTEL_OUTPUT_EDP) {
- ddi_translations = cnl_get_buf_trans_edp(dev_priv,
-voltage, &n_entries);
+ ddi_translations = cnl_get_buf_trans_edp(dev_priv, &n_entries);
}
- if (ddi_translations == NULL) {
- MISSING_CASE(voltage);
+ if (WARN_ON(ddi_translations == NULL))
return;
- }
if (level >= n_entries) {
[Intel-gfx] [PATCH 6/6] drm/i915/cnl: Fix DP max voltage
On clock recovery this function is called to find out
the max voltage swing level that we could go.
However gen 9 functions use the old buffer translation tables
to figure that out. That table is not valid for CNL
causing an invalid number of entries and an invalid selection
on the max voltage swing level.
v2: Let's use same approach that previous platforms.
Cc: Ville Syrjälä
Cc: Clint Taylor
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 51d59e3e1776..a71d6816c522 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -649,6 +649,29 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
int *n_entries)
}
}
+static int cnl_max_level(struct drm_i915_private *dev_priv,
+enum intel_output_type type)
+{
+ int n_entries = 0;
+
+ switch (type) {
+ case INTEL_OUTPUT_DP:
+ cnl_get_buf_trans_dp(dev_priv, &n_entries);
+ break;
+ case INTEL_OUTPUT_EDP:
+ cnl_get_buf_trans_edp(dev_priv, &n_entries);
+ break;
+ case INTEL_OUTPUT_HDMI:
+ cnl_get_buf_trans_hdmi(dev_priv, &n_entries);
+ break;
+ default:
+ MISSING_CASE(type);
+ return 0;
+ }
+
+ return n_entries - 1;
+}
+
static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port
port)
{
int n_hdmi_entries;
@@ -1879,10 +1902,14 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
int n_entries;
- if (encoder->type == INTEL_OUTPUT_EDP)
- intel_ddi_get_buf_trans_edp(dev_priv, &n_entries);
- else
- intel_ddi_get_buf_trans_dp(dev_priv, &n_entries);
+ if (IS_CANNONLAKE(dev_priv)) {
+ cnl_max_level(dev_priv, encoder->type);
+ } else {
+ if (encoder->type == INTEL_OUTPUT_EDP)
+ intel_ddi_get_buf_trans_edp(dev_priv, &n_entries);
+ else
+ intel_ddi_get_buf_trans_dp(dev_priv, &n_entries);
+ }
if (WARN_ON(n_entries < 1))
n_entries = 1;
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/cnl: Move ddi buf trans related functions up.
No functional changes. But those functions will be needed
to get max level for HDMI and DP, so let's move those
up closer to other similar functions existent for previous
platforms.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 122 +++
1 file changed, 61 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f8bc9ca8a905..64ecbfdf92bf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -588,6 +588,67 @@ skl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv,
int *n_entries)
}
}
+static const struct cnl_ddi_buf_trans *
+cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
+{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
+ if (voltage == VOLTAGE_INFO_0_85V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_85V);
+ return cnl_ddi_translations_hdmi_0_85V;
+ } else if (voltage == VOLTAGE_INFO_0_95V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_95V);
+ return cnl_ddi_translations_hdmi_0_95V;
+ } else if (voltage == VOLTAGE_INFO_1_05V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
+ return cnl_ddi_translations_hdmi_1_05V;
+ } else
+ MISSING_CASE(voltage);
+ return NULL;
+}
+
+static const struct cnl_ddi_buf_trans *
+cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
+{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
+ if (voltage == VOLTAGE_INFO_0_85V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_85V);
+ return cnl_ddi_translations_dp_0_85V;
+ } else if (voltage == VOLTAGE_INFO_0_95V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_95V);
+ return cnl_ddi_translations_dp_0_95V;
+ } else if (voltage == VOLTAGE_INFO_1_05V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_1_05V);
+ return cnl_ddi_translations_dp_1_05V;
+ } else
+ MISSING_CASE(voltage);
+ return NULL;
+}
+
+static const struct cnl_ddi_buf_trans *
+cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
+{
+ u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (voltage == VOLTAGE_INFO_0_85V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
+ return cnl_ddi_translations_dp_0_85V;
+ } else if (voltage == VOLTAGE_INFO_0_95V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
+ return cnl_ddi_translations_edp_0_95V;
+ } else if (voltage == VOLTAGE_INFO_1_05V) {
+ *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_1_05V);
+ return cnl_ddi_translations_edp_1_05V;
+ } else
+ MISSING_CASE(voltage);
+ return NULL;
+ } else {
+ return cnl_get_buf_trans_dp(dev_priv, n_entries);
+ }
+}
+
static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port
port)
{
int n_hdmi_entries;
@@ -1829,67 +1890,6 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
DP_TRAIN_VOLTAGE_SWING_MASK;
}
-static const struct cnl_ddi_buf_trans *
-cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
-{
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
-
- if (voltage == VOLTAGE_INFO_0_85V) {
- *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_85V);
- return cnl_ddi_translations_hdmi_0_85V;
- } else if (voltage == VOLTAGE_INFO_0_95V) {
- *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_95V);
- return cnl_ddi_translations_hdmi_0_95V;
- } else if (voltage == VOLTAGE_INFO_1_05V) {
- *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
- return cnl_ddi_translations_hdmi_1_05V;
- } else
- MISSING_CASE(voltage);
- return NULL;
-}
-
-static const struct cnl_ddi_buf_trans *
-cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
-{
- u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
-
- if (voltage == VOLTAGE_INFO_0_85V) {
- *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_85V);
- return cnl_ddi_translations_dp_0_85V;
- } else if (voltage == VOLTAGE_INFO_0_95V) {
- *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_95V);
- return cnl_ddi_translations_dp_0_95V;
- } else if (voltage == VOLTAGE_INFO_1_05V) {
- *n_entries = ARRAY_SIZE(c
[Intel-gfx] [PATCH 1/6] drm/i915: Introduce intel_ddi_dp_level.
No functional changes. This only moves the DP level
selection to a separated function that will be later
used to organize better the vswing sequences.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 494fbe0a7678..d7594bb16bfc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2054,18 +2054,22 @@ static uint32_t translate_signal_level(int
signal_levels)
return 0;
}
+static uint32_t intel_ddi_dp_level(struct intel_dp *intel_dp)
+{
+ uint8_t train_set = intel_dp->train_set[0];
+ int signal_levels = train_set & (DP_TRAIN_VOLTAGE_SWING_MASK |
+DP_TRAIN_PRE_EMPHASIS_MASK);
+
+ return translate_signal_level(signal_levels);
+}
+
uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
{
struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
struct intel_encoder *encoder = &dport->base;
- uint8_t train_set = intel_dp->train_set[0];
- int signal_levels = train_set & (DP_TRAIN_VOLTAGE_SWING_MASK |
-DP_TRAIN_PRE_EMPHASIS_MASK);
enum port port = dport->port;
- uint32_t level;
-
- level = translate_signal_level(signal_levels);
+ uint32_t level = intel_ddi_dp_level(intel_dp);
if (IS_GEN9_BC(dev_priv))
skl_ddi_set_iboost(encoder, level);
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Align vswing sequences with old ddi buffer registers.
Vswing sequences on BXT and CNL are equivalent
to the ddi buffer registers setting on other platforms.
For some reason it got aligned with skl_ddi_set_iboost what
is semantically incorrect. This forced us to keep skipping
ddi buffer translation tables on the platforms that has
the vswing sequences.
Cc: Vandana Kannan
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Ander Conselvan de Oliveira
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d7594bb16bfc..687b762d1b53 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -688,9 +688,6 @@ static void intel_prepare_dp_ddi_buffers(struct
intel_encoder *encoder)
enum port port = intel_ddi_get_encoder_port(encoder);
const struct ddi_buf_trans *ddi_translations;
- if (IS_GEN9_LP(dev_priv))
- return;
-
switch (encoder->type) {
case INTEL_OUTPUT_EDP:
ddi_translations = intel_ddi_get_buf_trans_edp(dev_priv,
@@ -741,9 +738,6 @@ static void intel_prepare_hdmi_ddi_buffers(struct
intel_encoder *encoder)
enum port port = intel_ddi_get_encoder_port(encoder);
const struct ddi_buf_trans *ddi_translations_hdmi;
- if (IS_GEN9_LP(dev_priv))
- return;
-
hdmi_level = intel_ddi_hdmi_level(dev_priv, port);
if (IS_GEN9_BC(dev_priv)) {
@@ -2068,18 +2062,11 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
struct intel_encoder *encoder = &dport->base;
- enum port port = dport->port;
uint32_t level = intel_ddi_dp_level(intel_dp);
if (IS_GEN9_BC(dev_priv))
skl_ddi_set_iboost(encoder, level);
- else if (IS_GEN9_LP(dev_priv))
- bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
- else if (IS_CANNONLAKE(dev_priv)) {
- cnl_ddi_vswing_sequence(encoder, level);
- /* DDI_BUF_CTL bits 27:24 are reserved on CNL */
- return 0;
- }
+
return DDI_BUF_TRANS_SELECT(level);
}
@@ -2133,6 +2120,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
+ uint32_t level = intel_ddi_dp_level(intel_dp);
WARN_ON(link_mst && (port == PORT_A || port == PORT_E));
@@ -2145,7 +2133,13 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
- intel_prepare_dp_ddi_buffers(encoder);
+ if (IS_CANNONLAKE(dev_priv))
+ cnl_ddi_vswing_sequence(encoder, level);
+ else if (IS_GEN9_LP(dev_priv))
+ bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
+ else
+ intel_prepare_dp_ddi_buffers(encoder);
+
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
@@ -2171,14 +2165,16 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_encoder *encoder,
intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
- intel_prepare_hdmi_ddi_buffers(encoder);
- if (IS_GEN9_BC(dev_priv))
- skl_ddi_set_iboost(encoder, level);
+ if (IS_CANNONLAKE(dev_priv))
+ cnl_ddi_vswing_sequence(encoder, level);
else if (IS_GEN9_LP(dev_priv))
bxt_ddi_vswing_sequence(dev_priv, level, port,
INTEL_OUTPUT_HDMI);
- else if (IS_CANNONLAKE(dev_priv))
- cnl_ddi_vswing_sequence(encoder, level);
+ else
+ intel_prepare_hdmi_ddi_buffers(encoder);
+
+ if (IS_GEN9_BC(dev_priv))
+ skl_ddi_set_iboost(encoder, level);
intel_hdmi->set_infoframes(drm_encoder,
has_hdmi_sink,
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915/cnl: Fix DDI hdmi level selection.
Let's get a proper HDMI DDI entry level for vswing programming
sequences on CNL.
Spec doesn't specify any default for HDMI tables,
so let's pick the last entry as the default for now.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 64ecbfdf92bf..51d59e3e1776 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -660,7 +660,10 @@ static int intel_ddi_hdmi_level(struct drm_i915_private
*dev_priv, enum port por
if (IS_GEN9_LP(dev_priv))
return hdmi_level;
- if (IS_GEN9_BC(dev_priv)) {
+ if (IS_CANNONLAKE(dev_priv)) {
+ cnl_get_buf_trans_hdmi(dev_priv, &n_hdmi_entries);
+ hdmi_default_entry = n_hdmi_entries - 1;
+ } else if (IS_GEN9_BC(dev_priv)) {
skl_get_buf_trans_hdmi(dev_priv, &n_hdmi_entries);
hdmi_default_entry = 8;
} else if (IS_BROADWELL(dev_priv)) {
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6
Quoting Mika Kuoppala (2017-08-08 14:36:59) > Mika Kuoppala writes: > > > We were pointing the color calc and depth stencil states blindly > > to an offset of 1k from bb start. This was foolhardy as it collides > > with other state in the batch and results in a wrecked state upload. > > > > Chris noticed that with snb gt1, it takes 10 seconds for renderstate batch > > to complete. However pointing the states to a known valid 64 aligned > > zero blocks didn't work to reduce the upload time either. > > > > Cave in and omit uploading color calc and depth stencil states. > > Not just yet, ignore this patch. Right, we found the root cause for my issue, so we can actually load the correct state here (i.e. create a NUL block and point both depth-stencil and color-calc to it). We could use that same block for the blend state as well, etc. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate
Quoting Mika Kuoppala (2017-08-08 14:36:39)
> Chris Wilson writes:
>
> > As we may have just bound the renderstate into the GGTT for execution, we
> > need to ensure that the GTT TLB are also flushed.
> >
> > On snb-gt2, this would cause a random GPU hang at the start of a new
> > context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
> > to take ~10s. It was the GPU hang that revealed the truth, as the CS
> > gleefully executed beyond the end of the golden renderstate batch, a good
> > indicator for a GTT TLB miss.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: sta...@vger.kernel.org
>
> The flush has been there but got stomped by:
>
> Fixes: dc4be6071a24 ("drm/i915: Add explicit request management to
> i915_gem_init_hw()")
>
> Now we can fix the gen6 renderstate too ;)
>
> Reviewed-by: Mika Kuoppala
Added
Fixes: 20fe17aa52dc ("drm/i915: Remove redundant TLB invalidate on switching
contexts")
and pushed. Still weird that I can't see anything resembling this on the
farm, despite the two snb machines I have having weird problems. Also
the effect is so random, a TLB miss!, it is hard to imagine devising a
better test (every igt allocates at least one new context executing the
renderstate, and so having an opportunity to hit a bug.)
Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate
Quoting Mika Kuoppala (2017-08-08 14:36:39)
> Chris Wilson writes:
>
> > As we may have just bound the renderstate into the GGTT for execution, we
> > need to ensure that the GTT TLB are also flushed.
> >
> > On snb-gt2, this would cause a random GPU hang at the start of a new
> > context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
> > to take ~10s. It was the GPU hang that revealed the truth, as the CS
> > gleefully executed beyond the end of the golden renderstate batch, a good
> > indicator for a GTT TLB miss.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: sta...@vger.kernel.org
>
> The flush has been there but got stomped by:
>
> Fixes: dc4be6071a24 ("drm/i915: Add explicit request management to
> i915_gem_init_hw()")
Hmm, I think it is actually 20fe17aa52dc ("drm/i915: Remove
redundant TLB invalidate on switching contexts"). The importance is in
having the invalidate after the GTT bind and before the MI_BB_START.
Which just happens to be implied by the ordering of the context switch
emission, but given the indirect link, not guaranteed.
Commit dc4be6071a24 only modifies the sequence after the MI_BB_START, so
doesn't look like the culprit.
-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: Perform an invalidate prior to executing golden renderstate
== Series Details == Series: drm/i915: Perform an invalidate prior to executing golden renderstate URL : https://patchwork.freedesktop.org/series/28497/ State : success == Summary == Series 28497v1 drm/i915: Perform an invalidate prior to executing golden renderstate https://patchwork.freedesktop.org/api/1.0/series/28497/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:424s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:488s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:488s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:520s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:513s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:584s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:459s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:572s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:442s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:643s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:466s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:426s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:473s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s 9d6913ce7311318746f0351c0b117edd6d7baa90 drm-tip: 2017y-08m-08d-12h-52m-33s UTC integration manifest 48acc69ef36b drm/i915: Perform an invalidate prior to executing golden renderstate == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5341/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate
Mika Kuoppala writes:
> Mika Kuoppala writes:
>
>> Chris Wilson writes:
>>
>>> As we may have just bound the renderstate into the GGTT for execution, we
>>> need to ensure that the GTT TLB are also flushed.
>>>
>>> On snb-gt2, this would cause a random GPU hang at the start of a new
>>> context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
>>> to take ~10s. It was the GPU hang that revealed the truth, as the CS
>>> gleefully executed beyond the end of the golden renderstate batch, a good
>>> indicator for a GTT TLB miss.
>>>
>>> Signed-off-by: Chris Wilson
>>> Cc: Mika Kuoppala
>>> Cc: sta...@vger.kernel.org
>>
>> The flush has been there but got stomped by:
>>
>> Fixes: dc4be6071a24 ("drm/i915: Add explicit request management to
>> i915_gem_init_hw()")
>>
>> Now we can fix the gen6 renderstate too ;)
>>
>> Reviewed-by: Mika Kuoppala
>
> On hindsight, should we actually do the flush through add request?
No, as it is not there anymore in gem_init_hw. -ETOOMUCHCOFFEE.
> -Mika
>
>>
>>> ---
>>> drivers/gpu/drm/i915/i915_gem_render_state.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
>>> b/drivers/gpu/drm/i915/i915_gem_render_state.c
>>> index 241d827b85fb..3703dc91eeda 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
>>> @@ -242,6 +242,10 @@ int i915_gem_render_state_emit(struct
>>> drm_i915_gem_request *req)
>>> goto err_unpin;
>>> }
>>>
>>> + ret = req->engine->emit_flush(req, EMIT_INVALIDATE);
>>> + if (ret)
>>> + goto err_unpin;
>>> +
>>> ret = req->engine->emit_bb_start(req,
>>> so->batch_offset, so->batch_size,
>>> I915_DISPATCH_SECURE);
>>> --
>>> 2.13.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] drm/i915: Perform an invalidate prior to executing golden renderstate
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> As we may have just bound the renderstate into the GGTT for execution, we
>> need to ensure that the GTT TLB are also flushed.
>>
>> On snb-gt2, this would cause a random GPU hang at the start of a new
>> context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
>> to take ~10s. It was the GPU hang that revealed the truth, as the CS
>> gleefully executed beyond the end of the golden renderstate batch, a good
>> indicator for a GTT TLB miss.
>>
>> Signed-off-by: Chris Wilson
>> Cc: Mika Kuoppala
>> Cc: sta...@vger.kernel.org
>
> The flush has been there but got stomped by:
>
> Fixes: dc4be6071a24 ("drm/i915: Add explicit request management to
> i915_gem_init_hw()")
>
> Now we can fix the gen6 renderstate too ;)
>
> Reviewed-by: Mika Kuoppala
On hindsight, should we actually do the flush through add request?
-Mika
>
>> ---
>> drivers/gpu/drm/i915/i915_gem_render_state.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
>> b/drivers/gpu/drm/i915/i915_gem_render_state.c
>> index 241d827b85fb..3703dc91eeda 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
>> @@ -242,6 +242,10 @@ int i915_gem_render_state_emit(struct
>> drm_i915_gem_request *req)
>> goto err_unpin;
>> }
>>
>> +ret = req->engine->emit_flush(req, EMIT_INVALIDATE);
>> +if (ret)
>> +goto err_unpin;
>> +
>> ret = req->engine->emit_bb_start(req,
>> so->batch_offset, so->batch_size,
>> I915_DISPATCH_SECURE);
>> --
>> 2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6
Mika Kuoppala writes:
> We were pointing the color calc and depth stencil states blindly
> to an offset of 1k from bb start. This was foolhardy as it collides
> with other state in the batch and results in a wrecked state upload.
>
> Chris noticed that with snb gt1, it takes 10 seconds for renderstate batch
> to complete. However pointing the states to a known valid 64 aligned
> zero blocks didn't work to reduce the upload time either.
>
> Cave in and omit uploading color calc and depth stencil states.
Not just yet, ignore this patch.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> tools/null_state_gen/intel_renderstate_gen6.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/null_state_gen/intel_renderstate_gen6.c
> b/tools/null_state_gen/intel_renderstate_gen6.c
> index 5c1b7f97..c64e17fd 100644
> --- a/tools/null_state_gen/intel_renderstate_gen6.c
> +++ b/tools/null_state_gen/intel_renderstate_gen6.c
> @@ -221,8 +221,10 @@ gen6_emit_cc(struct intel_batchbuffer *batch, uint32_t
> blend)
> {
> OUT_BATCH(GEN6_3DSTATE_CC_STATE_POINTERS | (4 - 2));
> OUT_BATCH_STATE_OFFSET(blend | 1);
> - OUT_BATCH(1024 | 1);
> - OUT_BATCH(1024 | 1);
> + /* no color calc */
> + OUT_BATCH(0);
> + /* no depth stencil */
> + OUT_BATCH(0);
> }
>
> static void
> --
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate
Chris Wilson writes:
> As we may have just bound the renderstate into the GGTT for execution, we
> need to ensure that the GTT TLB are also flushed.
>
> On snb-gt2, this would cause a random GPU hang at the start of a new
> context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
> to take ~10s. It was the GPU hang that revealed the truth, as the CS
> gleefully executed beyond the end of the golden renderstate batch, a good
> indicator for a GTT TLB miss.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: sta...@vger.kernel.org
The flush has been there but got stomped by:
Fixes: dc4be6071a24 ("drm/i915: Add explicit request management to
i915_gem_init_hw()")
Now we can fix the gen6 renderstate too ;)
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_render_state.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
> b/drivers/gpu/drm/i915/i915_gem_render_state.c
> index 241d827b85fb..3703dc91eeda 100644
> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> @@ -242,6 +242,10 @@ int i915_gem_render_state_emit(struct
> drm_i915_gem_request *req)
> goto err_unpin;
> }
>
> + ret = req->engine->emit_flush(req, EMIT_INVALIDATE);
> + if (ret)
> + goto err_unpin;
> +
> ret = req->engine->emit_bb_start(req,
>so->batch_offset, so->batch_size,
>I915_DISPATCH_SECURE);
> --
> 2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt 2/2] lib: Remove illegal instructions from hang injection
On Mon, Aug 07, 2017 at 04:33:40PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The idea behind using an illegal instruction was to hang the GPU must
> > faster than simply using the recursive batch. However, we stopped doing
> > so on gen8+ as the CS parser was much laxer and allowed the illegal
> > command through but still interpreted the packet length (jumping over
> > the recursive batch buffer start that followed). Sandybridge doesn't
> > just hang the GPU when it encounters an illegal command on the BLT
> > engine, it hangs the machine. That goes above and beyond testing our
> > hangcheck + reset, so remove the deadly instructions.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > lib/igt_gt.c | 25 +
> > 1 file changed, 5 insertions(+), 20 deletions(-)
> >
> > diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> > index 6f7daa5e..d5e8b557 100644
> > --- a/lib/igt_gt.c
> > +++ b/lib/igt_gt.c
> > @@ -270,30 +270,15 @@ igt_hang_t igt_hang_ctx(int fd,
> >
> > memset(b, 0xc5, sizeof(b));
> >
> > - /*
> > -* We emit invalid command to provoke a gpu hang.
> > -* If that doesn't work, we do bb start loop.
> > -* Note that the bb start aligment is illegal due this.
> > -* But hey, we are here to hang the gpu so whatever works.
> > -* We skip 0xfff on gen9 as it confuses hw in an such a way that
> > -* it will skip over the bb start, causing runaway head and
> > -* thus much slower hang detection.
> > -*/
>
> Daydreaming about MI_HALT,
>
> Reviewed-by: Mika Kuoppala
I tested both on my snb for a few hours, works solid. I guess I botched
the job when I tried this conversion, resulting in a gpu that couldn't
reset somehow.
Both patches pushed to igt, thanks a lot.
-Daniel
>
> > len = 2;
> > - if (intel_gen(intel_get_drm_devid(fd)) >= 8) {
> > - b[0] = MI_NOOP;
> > + if (intel_gen(intel_get_drm_devid(fd)) >= 8)
> > len++;
> > - } else {
> > - b[0] = 0x;
> > - }
> > -
> > - b[1] = MI_BATCH_BUFFER_START | (len - 2);
> > - b[1+len] = MI_BATCH_BUFFER_END;
> > - b[2+len] = MI_NOOP;
> > + b[0] = MI_BATCH_BUFFER_START | (len - 2);
> > + b[len] = MI_BATCH_BUFFER_END;
> > + b[len+1] = MI_NOOP;
> > gem_write(fd, exec.handle, 0, b, sizeof(b));
> >
> > - reloc.offset = 8;
> > - reloc.delta = 4;
> > + reloc.offset = sizeof(uint32_t);
> > reloc.target_handle = exec.handle;
> > reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
> >
> > --
> > 2.13.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Perform an invalidate prior to executing golden renderstate
As we may have just bound the renderstate into the GGTT for execution, we need to ensure that the GTT TLB are also flushed. On snb-gt2, this would cause a random GPU hang at the start of a new context (e.g. boot) and on snb-gt1, it was causing the renderstate batch to take ~10s. It was the GPU hang that revealed the truth, as the CS gleefully executed beyond the end of the golden renderstate batch, a good indicator for a GTT TLB miss. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_gem_render_state.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c index 241d827b85fb..3703dc91eeda 100644 --- a/drivers/gpu/drm/i915/i915_gem_render_state.c +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c @@ -242,6 +242,10 @@ int i915_gem_render_state_emit(struct drm_i915_gem_request *req) goto err_unpin; } + ret = req->engine->emit_flush(req, EMIT_INVALIDATE); + if (ret) + goto err_unpin; + ret = req->engine->emit_bb_start(req, so->batch_offset, so->batch_size, I915_DISPATCH_SECURE); -- 2.13.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/renderstate: Sandybridge golden renderstate is b0rked
Chris Wilson writes:
> In the null state batch, we try to load the CC_STATE_POINTERS, but pass
> in a pointer to invalid state for the color-calc and depth-stencil
> state. In the rendercopy batch this was imported from, the 1024 offset
> used is known to be 64bytes of zeroes. Tweaking the
> gen6_null_state_batch to point those two offset at known zeroes however
> was not sufficient.
>
> The effect of loading depth-stencil and color-calc causes the golden
> renderstate batch to take 10s (yes, ten seconds) on my snb gt1 (i5-2500).
>
> It would be nice if we could drop this incomplete "golden render state"
> entirely.
>
Agreed. But until then, lets do changes through igt/tools/null_state_gen.
Patch posted.
-Mika
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_renderstate_gen6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> b/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> index 11c8e7b3dd7c..46cfc405ca30 100644
> --- a/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> @@ -107,8 +107,8 @@ static const u32 gen6_null_state_batch[] = {
> 0x,
> 0x780e0002,
> 0x0441,
> - 0x0401,
> - 0x0401,
> + 0x0400,
> + 0x0400,
> 0x78021002,
> 0x,
> 0x,
> --
> 2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] tools/null_state_gen: Don't upload color calc and depth stencil on gen6
We were pointing the color calc and depth stencil states blindly
to an offset of 1k from bb start. This was foolhardy as it collides
with other state in the batch and results in a wrecked state upload.
Chris noticed that with snb gt1, it takes 10 seconds for renderstate batch
to complete. However pointing the states to a known valid 64 aligned
zero blocks didn't work to reduce the upload time either.
Cave in and omit uploading color calc and depth stencil states.
Reported-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tools/null_state_gen/intel_renderstate_gen6.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/null_state_gen/intel_renderstate_gen6.c
b/tools/null_state_gen/intel_renderstate_gen6.c
index 5c1b7f97..c64e17fd 100644
--- a/tools/null_state_gen/intel_renderstate_gen6.c
+++ b/tools/null_state_gen/intel_renderstate_gen6.c
@@ -221,8 +221,10 @@ gen6_emit_cc(struct intel_batchbuffer *batch, uint32_t
blend)
{
OUT_BATCH(GEN6_3DSTATE_CC_STATE_POINTERS | (4 - 2));
OUT_BATCH_STATE_OFFSET(blend | 1);
- OUT_BATCH(1024 | 1);
- OUT_BATCH(1024 | 1);
+ /* no color calc */
+ OUT_BATCH(0);
+ /* no depth stencil */
+ OUT_BATCH(0);
}
static void
--
2.11.0
___
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: Add hooks for enabling ftrace
Quoting Petri Latvala (2017-08-08 13:54:46)
> On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote:
>
> *snip*
>
> > +#define BIT(x) (1ul << (x))
> > +
> > +/* Only a single tracer in the kernel, so we can use a singleton */
> > +struct igt_ftrace {
> > + int dir;
> > +
> > + unsigned long flags;
> > +#define PID_SET BIT(0)
> > +#define INCLUDE_SET BIT(1)
> > +#define EXCLUDE_SET BIT(2)
> > +
> > +} igt_ftrace = { -1 };
> > +
>
>
>
> Why are those #defines inside the struct definition?
They are part of the definition for @flags. It's common enough practice,
since I keep badgering people to do the same.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Allow HW status page to be bound high
At the time of commit 1f767e02d69f ("drm/i915: HWS must be in the
mappable region for g33"), drm_mm insertion would often default to
placing a new object high in the zone forcing us to specify that certain
HWSP must be bound within the low mappable region. Since then, drm_mm
has gained more finesse over its placement and exposes that to the
caller, commit 4e64e5539d15 ("drm: Improve drm_mm search (and fix
topdown allocation) with rbtrees"). As such where possible we want the
HWSP to be outside of the mappable aperture and so need to tell to
specify that it is to be pinned high.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Ville Syrjälä
Cc: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7312f422e7ce..855b42e21ed7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -490,6 +490,8 @@ static int init_status_page(struct intel_engine_cs *engine)
* actualy map it).
*/
flags |= PIN_MAPPABLE;
+ else
+ flags |= PIN_HIGH;
ret = i915_vma_pin(vma, 0, 4096, flags);
if (ret)
goto err;
--
2.13.3
___
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: Add hooks for enabling ftrace
On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote:
*snip*
> +#define BIT(x) (1ul << (x))
> +
> +/* Only a single tracer in the kernel, so we can use a singleton */
> +struct igt_ftrace {
> + int dir;
> +
> + unsigned long flags;
> +#define PID_SET BIT(0)
> +#define INCLUDE_SET BIT(1)
> +#define EXCLUDE_SET BIT(2)
> +
> +} igt_ftrace = { -1 };
> +
Why are those #defines inside the struct definition?
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Calculate gen3- watermarks semi-atomically.
Hi,
On Monday 07 August 2017 04:18 PM, Maarten Lankhorst wrote:
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 14 +++
drivers/gpu/drm/i915/intel_pm.c | 231 +--
3 files changed, 152 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 974d4b577189..234b94cafc7d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14709,7 +14709,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
skl_wm_get_hw_state(dev);
} else if (HAS_PCH_SPLIT(dev_priv)) {
ilk_wm_get_hw_state(dev);
- }
+ } else if (INTEL_GEN(dev_priv) <= 3 && !IS_PINEVIEW(dev_priv))
+ i9xx_wm_get_hw_state(dev);
for_each_intel_crtc(dev, crtc) {
u64 put_domains;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f91de9cb9697..d53d34756048 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -547,6 +547,15 @@ struct g4x_wm_state {
bool fbc_en;
};
+struct i9xx_wm_state {
+ uint16_t plane_wm;
+ bool cxsr;
+
+ struct {
+ uint16_t plane;
should this also be named as plane_wm, because it's again wm with SR.
just a nitpick but not a stopper.
+ } sr;
+};
+
struct intel_crtc_wm_state {
union {
struct {
@@ -591,6 +600,9 @@ struct intel_crtc_wm_state {
/* optimal watermarks */
struct g4x_wm_state optimal;
} g4x;
new line please to match the coding style of function
+ struct {
+ struct i9xx_wm_state optimal;
+ } i9xx;
};
/*
@@ -823,6 +835,7 @@ struct intel_crtc {
struct intel_pipe_wm ilk;
struct vlv_wm_state vlv;
struct g4x_wm_state g4x;
+ struct i9xx_wm_state i9xx;
} active;
} wm;
@@ -1845,6 +1858,7 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq,
struct intel_rps_client *rps);
void intel_queue_rps_boost_for_request(struct drm_i915_gem_request *req);
void g4x_wm_get_hw_state(struct drm_device *dev);
+void i9xx_wm_get_hw_state(struct drm_device *dev);
void vlv_wm_get_hw_state(struct drm_device *dev);
void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e393b217450..807c9a730020 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2224,89 +2224,154 @@ static void i965_update_wm(struct intel_crtc
*unused_crtc)
#undef FW_WM
-static void i9xx_update_wm(struct intel_crtc *unused_crtc)
+static const struct intel_watermark_params *i9xx_get_wm_info(struct
drm_i915_private *dev_priv,
+struct intel_crtc
*crtc)
{
- struct drm_i915_private *dev_priv = to_i915(unused_crtc->base.dev);
- const struct intel_watermark_params *wm_info;
- uint32_t fwater_lo;
- uint32_t fwater_hi;
- int cwm, srwm = 1;
- int fifo_size;
- int planea_wm, planeb_wm;
- struct intel_crtc *crtc, *enabled = NULL;
+ struct intel_plane *plane = to_intel_plane(crtc->base.primary);
if (IS_I945GM(dev_priv))
- wm_info = &i945_wm_info;
+ return &i945_wm_info;
else if (!IS_GEN2(dev_priv))
- wm_info = &i915_wm_info;
+ return &i915_wm_info;
+ else if (plane->plane == PLANE_A)
+ return &i830_a_wm_info;
else
- wm_info = &i830_a_wm_info;
+ return &i830_bc_wm_info;
+}
- fifo_size = dev_priv->display.get_fifo_size(dev_priv, 0);
- crtc = intel_get_crtc_for_plane(dev_priv, 0);
- if (intel_crtc_active(crtc)) {
+static int i9xx_compute_pipe_wm(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(crtc_state->base.state);
+ struct i9xx_wm_state *wm_state = &crtc_state->wm.i9xx.optimal;
+ struct intel_plane *plane = to_intel_plane(crtc->base.primary);
+ const struct drm_plane_state *plane_state = NULL;
+ int fifo_size;
+ const struct intel_watermark_params *wm_info;
+
+ fifo_size = dev_priv->display.get_fifo_size(d
Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property
Hi Daniel, Thank you for the patch. On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. I assume you meant drm_atomic_plane_set_property. With that fixed, Reviewed-by: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Cc: Boris Brezillon > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: Sean Paul > Cc: David Airlie > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Laurent Pinchart > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Jyri Sarha > Cc: "Ville Syrjälä" > Cc: Rongrong Zou > Cc: Shawn Guo > Cc: Alexey Brodkin > Cc: Eric Engestrom > Cc: Chris Wilson > Cc: Rob Clark > Cc: Archit Taneja > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: Thomas Hellstrom > Cc: Maxime Ripard > --- > drivers/gpu/drm/arm/malidp_planes.c | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 1 - > drivers/gpu/drm/drm_atomic.c| 3 +- > drivers/gpu/drm/drm_atomic_helper.c | 55 -- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 - > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - > drivers/gpu/drm/i915/intel_display.c| 2 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 - > drivers/gpu/drm/nouveau/nv50_display.c | 1 - > drivers/gpu/drm/omapdrm/omap_plane.c| 1 - > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 - > drivers/gpu/drm/sti/sti_cursor.c| 1 - > drivers/gpu/drm/sti/sti_gdp.c | 1 - > drivers/gpu/drm/sti/sti_hqvdp.c | 1 - > drivers/gpu/drm/stm/ltdc.c | 1 - > drivers/gpu/drm/tilcdc/tilcdc_plane.c | 1 - > include/drm/drm_atomic.h| 3 -- > include/drm/drm_atomic_helper.h | 3 -- > 20 files changed, 1 insertion(+), 81 deletions(-) -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 15/16] drm/i915/guc: Trace messages from CT while in debug
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
v3: use dedicated Kconfig (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 12 +++
drivers/gpu/drm/i915/intel_guc_ct.c | 41 +++--
2 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 78c5c04..0c20b75 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -73,6 +73,18 @@ config DRM_I915_SW_FENCE_CHECK_DAG
If in doubt, say "N".
+config DRM_I915_DEBUG_GUC
+bool "Enable additional driver debugging for GuC"
+depends on DRM_I915
+default n
+help
+ Choose this option to turn on extra driver debugging that may affect
+ performance but will help resolve GuC related issues.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
+
config DRM_I915_SELFTEST
bool "Enable selftests upon driver load"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index e6912be..28d7228 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,12 @@
#include "i915_drv.h"
#include "intel_guc_ct.h"
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+#define CT_DEBUG_DRIVER(...) DRM_DEBUG_DRIVER(__VA_ARGS__)
+#else
+#define CT_DEBUG_DRIVER(...)
+#endif
+
struct ct_request {
struct list_head link;
u32 fence;
@@ -69,8 +75,8 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
u32 cmds_addr, u32 size, u32 owner)
{
- DRM_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
-desc, cmds_addr, size, owner);
+ CT_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
+ desc, cmds_addr, size, owner);
memset(desc, 0, sizeof(*desc));
desc->addr = cmds_addr;
desc->size = size;
@@ -79,8 +85,8 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc
*desc,
static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
{
- DRM_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
-desc, desc->head, desc->tail);
+ CT_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
+ desc, desc->head, desc->tail);
desc->head = 0;
desc->tail = 0;
desc->is_in_error = 0;
@@ -176,7 +182,7 @@ static int ctch_init(struct intel_guc *guc,
err = PTR_ERR(blob);
goto err_vma;
}
- DRM_DEBUG_DRIVER("CT: vma base=%#x\n", guc_ggtt_offset(ctch->vma));
+ CT_DEBUG_DRIVER("CT: vma base=%#x\n", guc_ggtt_offset(ctch->vma));
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ctch->ctbs); i++) {
@@ -190,8 +196,8 @@ static int ctch_init(struct intel_guc *guc,
err_vma:
i915_vma_unpin_and_release(&ctch->vma);
err_out:
- DRM_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
-ctch->owner, err);
+ CT_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
+ ctch->owner, err);
return err;
}
@@ -211,8 +217,8 @@ static int ctch_open(struct intel_guc *guc,
int err;
int i;
- DRM_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
-ctch->owner, yesno(ctch_is_open(ctch)));
+ CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
+ ctch->owner, yesno(ctch_is_open(ctch)));
if (!ctch->vma) {
err = ctch_init(guc, ctch);
@@ -325,6 +331,10 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
(send_response ? GUC_CT_MSG_SEND_STATUS : 0) |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
+ CT_DEBUG_DRIVER("CT: writing %*phn %*phn %*phn\n",
+ 4, &header, 4, &fence,
+ 4*(len - 1), &action[1]);
+
cmds[tail] = header;
tail = (tail + 1) % size;
@@ -500,6 +510,9 @@ static int intel_guc_send_ct(struct intel_guc *guc, const
u32 *action, u32 len,
if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
action[0], ret, status);
+ } else if (unlikely(ret)) {
+ CT_DEBUG_DRIVER("CT: send action %#x returned %d (%#x)\n",
+ action[0], ret, ret);
}
mutex_unlock(&guc->send_mutex);
@@ -546,10 +559,12 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32
*data)
/
Re: [Intel-gfx] [PATCH 01/21] mm/shmem: introduce shmem_file_setup_with_mnt
Hi Hugh, Could we get this patch merged? Or would you prefer us to merge through drm-tip? For what it's worth, this is: Reviewed-by: Joonas Lahtinen Regards, Joonas On pe, 2017-07-28 at 16:12 +0300, Kirill A. Shutemov wrote: > On Tue, Jul 25, 2017 at 08:21:13PM +0100, Matthew Auld wrote: > > > > We are planning to use our own tmpfs mnt in i915 in place of the > > shm_mnt, such that we can control the mount options, in particular > > huge=, which we require to support huge-gtt-pages. So rather than roll > > our own version of __shmem_file_setup, it would be preferred if we could > > just give shmem our mnt, and let it do the rest. > > > > Signed-off-by: Matthew Auld > > Cc: Joonas Lahtinen > > Cc: Chris Wilson > > Cc: Dave Hansen > > Cc: Kirill A. Shutemov > > Cc: Hugh Dickins > > Cc: linux...@kvack.org > > Looks okay to me. > > Acked-by: Kirill A. Shutemov -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Removing missing DDI_E bits from CNL.
On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote:
> DDI_E is not supported on CNL-U and CNL-Y
>
> When adding the inital support we noticed DDI_E wasn't supported
> and removed it on v4 and v5 of that patch.
> However for some reason I missed or put back these 2 chunks.
>
> Time to clean it up to avoid later confusion.
>
> Fixes: 8bcd3dd41766 ("drm/i915/cnl: Add power wells for CNL")
> Cc: Clint Taylor
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
Looks ok and also the correct thing for CNL_H/S, where the port E DDI
power well is separate from port A and not dependent on power well #2
(unlike SKL):
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 347484ed6d2c..e77e84a6fd2f 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1796,7 +1796,6 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
> BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
> BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
> BIT_ULL(POWER_DOMAIN_AUX_B) | \
> BIT_ULL(POWER_DOMAIN_AUX_C) | \
> BIT_ULL(POWER_DOMAIN_AUX_D) | \
> @@ -1805,7 +1804,6 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_INIT))
> #define CNL_DISPLAY_DDI_A_IO_POWER_DOMAINS ( \
> BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO) | \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_E_IO) | \
> BIT_ULL(POWER_DOMAIN_INIT))
> #define CNL_DISPLAY_DDI_B_IO_POWER_DOMAINS ( \
> BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) | \
> --
> 2.13.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add has_psr-flag to gen9lp
On Tue, Aug 08, 2017 at 10:34:46AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add has_psr-flag to gen9lp > URL : https://patchwork.freedesktop.org/series/28488/ > State : failure > > == Summary == > > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp > https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s3: > pass -> INCOMPLETE (fi-skl-6260u) SKL isn't GEN9LP, so this is unrelated. > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-b: > dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 PineView isn't GEN9LP, so this is also unrelated. > fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:442s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:416s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:358s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:487s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:485s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:523s > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > time:511s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:583s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:433s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:408s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:417s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:497s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:473s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:460s > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:564s > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:579s > fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 > time:584s > fi-skl-6260u total:109 pass:105 dwarn:0 dfail:0 fail:0 skip:3 > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:639s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:468s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:423s > fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:487s > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:545s > fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 > time:405s > > 3d87f89058607b2a2adecf99ddb637a676b4df64 drm-tip: 2017y-08m-08d-09h-05m-05s > UTC integration manifest > 719c12b943ba drm/i915: Add has_psr-flag to gen9lp > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5338/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 2/2] lib: Enable automatic ftrace dumping for suspend failures
Supplement dmesg with the function call graph to try and help identify
why the suspend failed. On the other hand, it may be very noisy and
perturb the system due to its overhead...
Signed-off-by: Chris Wilson
---
lib/igt_aux.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index f428f159..8fa34411 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -56,6 +56,7 @@
#include "intel_chipset.h"
#include "igt_aux.h"
#include "igt_debugfs.h"
+#include "igt_ftrace.h"
#include "igt_gt.h"
#include "igt_rand.h"
#include "igt_sysfs.h"
@@ -762,13 +763,19 @@ static void suspend_via_rtcwake(enum igt_suspend_state
state)
"the rtcwake tool or how your distro is set up.\n",
ret);
+ igt_ftrace_enable();
+
snprintf(cmd, sizeof(cmd), "rtcwake -s %d -m %s ",
delay, suspend_state_name[state]);
ret = system(cmd);
- igt_assert_f(ret == 0,
-"rtcwake failed with %i\n"
-"Check dmesg for further details.\n",
-ret);
+
+ igt_ftrace_disable();
+ if (ret) {
+ igt_warn("rtcwake failed with %i\n", ret);
+ igt_ftrace_dump(__func__);
+ igt_assert_f(ret == 0,
+"Check dmesg for further details.\n");
+ }
}
static void suspend_via_sysfs(int power_dir, enum igt_suspend_state state)
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 1/2] lib: Add hooks for enabling ftrace
If the kernel has tracing support builtin, we can enable around
troublesome tests to obtain greater detail from the kernel that may
prove invaluable in debugging the problem.
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_core.c | 5 ++
lib/igt_ftrace.c | 178 +++
lib/igt_ftrace.h | 46 +
4 files changed, 231 insertions(+)
create mode 100644 lib/igt_ftrace.c
create mode 100644 lib/igt_ftrace.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 53fdb54c..90ff6468 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -12,6 +12,8 @@ lib_source_list = \
igt_aux.c \
igt_aux.h \
igt_edid_template.h \
+ igt_ftrace.c\
+ igt_ftrace.h\
igt_gt.c\
igt_gt.h\
igt_gvt.c \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c0488e94..2509bc64 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -63,6 +63,7 @@
#include "intel_chipset.h"
#include "intel_io.h"
#include "igt_debugfs.h"
+#include "igt_ftrace.h"
#include "version.h"
#include "config.h"
@@ -563,6 +564,8 @@ static void low_mem_killer_disable(bool disable)
bool igt_exit_called;
static void common_exit_handler(int sig)
{
+ igt_ftrace_close();
+
if (!igt_only_list_subtests()) {
low_mem_killer_disable(false);
kick_fbcon(true);
@@ -856,6 +859,8 @@ out:
oom_adjust_for_doom();
low_mem_killer_disable(true);
+
+ igt_ftrace_open();
}
/* install exit handler, to ensure we clean up */
diff --git a/lib/igt_ftrace.c b/lib/igt_ftrace.c
new file mode 100644
index ..486acf71
--- /dev/null
+++ b/lib/igt_ftrace.c
@@ -0,0 +1,178 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "igt_ftrace.h"
+#include "igt_debugfs.h"
+#include "igt_sysfs.h"
+
+#define BIT(x) (1ul << (x))
+
+/* Only a single tracer in the kernel, so we can use a singleton */
+struct igt_ftrace {
+ int dir;
+
+ unsigned long flags;
+#define PID_SET BIT(0)
+#define INCLUDE_SET BIT(1)
+#define EXCLUDE_SET BIT(2)
+
+} igt_ftrace = { -1 };
+
+int igt_ftrace_open(void)
+{
+ int dir;
+ int err;
+
+ dir = open(igt_debugfs_mount(), O_RDONLY);
+ if (dir < 0)
+ return -errno;
+
+ igt_ftrace.dir = openat(dir, "tracing", O_RDONLY);
+ close(dir);
+ if (igt_ftrace.dir < 0)
+ return -errno;
+
+ err = igt_ftrace_disable();
+ if (err)
+ goto ft_close;
+
+ return 0;
+
+ft_close:
+ close(igt_ftrace.dir);
+ igt_ftrace.dir = -1;
+ return err;
+}
+
+int __igt_ftrace_enable(const char *mode,
+ const struct igt_ftrace_options *opts)
+{
+ int err;
+
+ if (igt_ftrace.dir < 0)
+ return -ENODEV;
+
+ if (!mode)
+ return -EINVAL;
+
+ err = igt_sysfs_set(igt_ftrace.dir, "current_tracer", mode);
+ if (err < 0)
+ return err;
+
+ if (opts && opts->pid) {
+ err = igt_sysfs_printf(igt_ftrace.dir,
+ "set_ftrace_pid", "%d",
+ opts->pid);
+ if (err < 0)
+ goto disable;
+
+ igt_ftrace.flags |= PID_SET;
+ }
+
+ if (opts && opts->include) {
+ err = igt_sysfs_set(igt_ftrace.dir,
+ "set_ftrace_filter",
+ opts->include);
+ if (err < 0)
+ goto disable;
+
+
Re: [Intel-gfx] [PATCH 3/3] drm/etnaviv: add thermal dependency
Hi Arnd,
Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to
> `thermal_of_cooling_device_register'
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to
> `thermal_cooling_device_unregister'
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_unbind+0xf0): undefined reference to
> `thermal_cooling_device_unregister'
>
> This adds a Kconfig dependency to prevent etnaviv from being built-in
> with CONFIG_THERMAL=m, while still allowing the valid configurations.
> Unfortunately, simply adding the dependency here breaks Kconfig through
> a dependency loop involving lots of symbols all the way until ACPI_VIDEO,
> which is the only video driver that explicitly selects 'THERMAL'. Turning
> this into a 'depends on' addresses the problem.
> For completeness, I'm also removing the redundant 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
>
> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann
> ---
> v2: spend more thought on ACPI_VIDEO dependencies, as we need another
> patch before this.
> ---
> drivers/acpi/Kconfig| 2 +-
> drivers/gpu/drm/etnaviv/Kconfig | 1 +
> drivers/platform/x86/Kconfig| 1 -
I would like to take this patch, but I'm not sure why it includes x86
and ACPI hunks.
Regards,
Lucas
> 3 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index a8f5a40e2914..1282b2936164 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -184,7 +184,7 @@ config ACPI_VIDEO
> tristate "Video"
> depends on X86
> depends on INPUT
> - select THERMAL
> + depends on THERMAL
> select BACKLIGHT_CLASS_DEVICE
> select BACKLIGHT_LCD_SUPPORT
> default y
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 71cee4e9fefb..1d6c744e7924 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
> + depends on THERMAL || THERMAL=n
> depends on MMU
> select SHMEM
> select SYNC_FILE
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 2d9fb46a8d11..d9238e9ff54a 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -532,7 +532,6 @@ config SENSORS_HDAPS
> config INTEL_MENLOW
> tristate "Thermal Management driver for Intel menlow platform"
> depends on ACPI_THERMAL
> - select THERMAL
> ---help---
> ACPI thermal management enhancement driver on
> Intel Menlow platform.
___
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: Convert gen4- watermarks to atomic. (rev3)
== Series Details == Series: drm/i915: Convert gen4- watermarks to atomic. (rev3) URL : https://patchwork.freedesktop.org/series/23954/ State : failure == Summary == Series 23954v3 drm/i915: Convert gen4- watermarks to atomic. https://patchwork.freedesktop.org/api/1.0/series/23954/revisions/3/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-pnv-d510) Subgroup basic-flip-after-cursor-legacy: pass -> FAIL (fi-pnv-d510) Subgroup basic-flip-after-cursor-varying-size: pass -> FAIL (fi-pnv-d510) Subgroup basic-flip-before-cursor-legacy: pass -> FAIL (fi-pnv-d510) Subgroup basic-flip-before-cursor-varying-size: pass -> FAIL (fi-pnv-d510) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 Test prime_vgem: Subgroup basic-gtt: pass -> FAIL (fi-bxt-j4205) fdo#102066 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fdo#102066 https://bugs.freedesktop.org/show_bug.cgi?id=102066 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:419s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:489s fi-bxt-j4205 total:279 pass:259 dwarn:0 dfail:0 fail:1 skip:19 time:496s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:522s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:508s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:584s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:415s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:508s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:576s fi-pnv-d510 total:279 pass:217 dwarn:2 dfail:0 fail:5 skip:55 time:577s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:447s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:640s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:462s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:426s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:485s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:549s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s 3d87f89058607b2a2adecf99ddb637a676b4df64 drm-tip: 2017y-08m-08d-09h-05m-05s UTC integration manifest ef2fffbfc829 drm/i915: Rip out legacy watermark infrastructure 827fd5b9f7db drm/i915: Kill off intel_crtc_active. 4cb5e76a6a94 drm/i915: Program gen4 watermarks atomically b0236e15378b drm/i915: Calculate gen4 watermarks semiatomically. 75c242e6dbfd drm/i915: Convert pineview watermarks to atomic, v2. 2cb740d2da4e drm/i915: Program gen3- watermarks atomically 99661d1c5824 drm/i915: Calculate gen3- watermarks semi-atomically, v2. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5339/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
> -Original Message-
> From: Zanoni, Paulo R
> Sent: Monday, August 7, 2017 5:54 PM
> To: Lofstedt, Marta ; intel-
> g...@lists.freedesktop.org
> Cc: Latvala, Petri
> Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait
> timeout to 5s
>
> Em Seg, 2017-08-07 às 06:51 +, Lofstedt, Marta escreveu:
> > > -Original Message-
> > > From: Zanoni, Paulo R
> > > Sent: Friday, August 4, 2017 9:56 PM
> > > To: Lofstedt, Marta ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Latvala, Petri
> > > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase
> > > FBC wait timeout to 5s
> > >
> > > Em Sex, 2017-08-04 às 09:47 +, Lofstedt, Marta escreveu:
> > > > +Paolo
> > > >
> > > > > -Original Message-
> > > > > From: Lofstedt, Marta
> > > > > Sent: Wednesday, June 28, 2017 2:17 PM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Latvala, Petri ; Lofstedt, Marta
> > > > >
> > > > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase
> > > > > FBC wait timeout to 5s
> > > > >
> > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> > > > > has non-consistent results, pending between fail and pass.
> > > > > The fails are always due to "FBC disabled".
> > > > > With this increase in timeout the flip-flop behavior is no
> > > > > longer reproducible.
> > >
> > > This is a partial revert of:
> > >
> > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54
> > > kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s
> > >
> > > (but there's no need to make it a full revert if you don't need)
> > >
> > > It would be nice to investigate why we're needing 5 seconds instead
> > > of
> > > 2 now, the document it in the commit message. Also document that
> > > this is a partial revert.
> >
> > Paulo, do you have data backing up that 2 seconds was ever OK, I fail
> > ~1/10 on various fbc subtests.
>
> All the data I have is the commit message of 64590c7b and the testing I did. I
> would imagine something changed in the upstream tree since then, causing
> this to need a longer timeout, that's why I suggested investigating.
>
If I run current IGT with Kernel 4.2.0, which was released 30 august 2015, that
should be around the time when the 64590c7b was done, all
kms_frontbuffer_tracking tests fail. If I reset IGT to 64590c7b half of the
flip-flopping tests consistently fail the rest consistently pass over 10 runs.
If I run IGT@64590c7b on 4.13-rc3+ all kms_fronbuffer_tracking fail. So, indeed
some of these tests appear to actually have passed 2 years ago, but it also
seem that both the tests and the i915 have change a lot during 2 years.
Anyways, I will do some timing analyze to investigate what is really going on
here.
/Marta
> >
> > /Marta
> > >
> > > Acked-by: Paulo Zanoni
> > >
> >
> > Thanks,
> >
> > > > >
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > > > > Signed-off-by: Marta Lofstedt
> > > > > ---
> > > > > 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 c24e4a81..8bec5d5a 100644
> > > > > --- a/tests/kms_frontbuffer_tracking.c
> > > > > +++ b/tests/kms_frontbuffer_tracking.c
> > > > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void)
> > > > >
> > > > > static bool fbc_wait_until_enabled(void) {
> > > > > - return igt_wait(fbc_is_enabled(), 2000, 1);
> > > > > + return igt_wait(fbc_is_enabled(), 5000, 1);
> > > > > }
> > > > >
> > > > > static bool psr_wait_until_enabled(void)
> > > > > --
> > > > > 2.11.0
> > > >
> > > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Calculate gen3- watermarks semi-atomically, v2.
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
CI was having issues on the kms_cursor_legacy tests with too
much debug info printed out, in order to reduce the chattiness
we will kill the prints from intel_calculate_wm.
Changes since v1:
- Neuter intel_calculate_wm.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 14 +++
drivers/gpu/drm/i915/intel_pm.c | 233 ---
3 files changed, 152 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 974d4b577189..234b94cafc7d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14709,7 +14709,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
skl_wm_get_hw_state(dev);
} else if (HAS_PCH_SPLIT(dev_priv)) {
ilk_wm_get_hw_state(dev);
- }
+ } else if (INTEL_GEN(dev_priv) <= 3 && !IS_PINEVIEW(dev_priv))
+ i9xx_wm_get_hw_state(dev);
for_each_intel_crtc(dev, crtc) {
u64 put_domains;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f91de9cb9697..d53d34756048 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -547,6 +547,15 @@ struct g4x_wm_state {
bool fbc_en;
};
+struct i9xx_wm_state {
+ uint16_t plane_wm;
+ bool cxsr;
+
+ struct {
+ uint16_t plane;
+ } sr;
+};
+
struct intel_crtc_wm_state {
union {
struct {
@@ -591,6 +600,9 @@ struct intel_crtc_wm_state {
/* optimal watermarks */
struct g4x_wm_state optimal;
} g4x;
+ struct {
+ struct i9xx_wm_state optimal;
+ } i9xx;
};
/*
@@ -823,6 +835,7 @@ struct intel_crtc {
struct intel_pipe_wm ilk;
struct vlv_wm_state vlv;
struct g4x_wm_state g4x;
+ struct i9xx_wm_state i9xx;
} active;
} wm;
@@ -1845,6 +1858,7 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq,
struct intel_rps_client *rps);
void intel_queue_rps_boost_for_request(struct drm_i915_gem_request *req);
void g4x_wm_get_hw_state(struct drm_device *dev);
+void i9xx_wm_get_hw_state(struct drm_device *dev);
void vlv_wm_get_hw_state(struct drm_device *dev);
void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e393b217450..173a514cd6df 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -751,10 +751,8 @@ static unsigned int intel_calculate_wm(int pixel_rate,
latency_ns / 100);
entries = DIV_ROUND_UP(entries, wm->cacheline_size) +
wm->guard_size;
- DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries);
wm_size = fifo_size - entries;
- DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
/* Don't promote wm_size to unsigned... */
if (wm_size > wm->max_wm)
@@ -2224,89 +,154 @@ static void i965_update_wm(struct intel_crtc
*unused_crtc)
#undef FW_WM
-static void i9xx_update_wm(struct intel_crtc *unused_crtc)
+static const struct intel_watermark_params *i9xx_get_wm_info(struct
drm_i915_private *dev_priv,
+struct intel_crtc
*crtc)
{
- struct drm_i915_private *dev_priv = to_i915(unused_crtc->base.dev);
- const struct intel_watermark_params *wm_info;
- uint32_t fwater_lo;
- uint32_t fwater_hi;
- int cwm, srwm = 1;
- int fifo_size;
- int planea_wm, planeb_wm;
- struct intel_crtc *crtc, *enabled = NULL;
+ struct intel_plane *plane = to_intel_plane(crtc->base.primary);
if (IS_I945GM(dev_priv))
- wm_info = &i945_wm_info;
+ return &i945_wm_info;
else if (!IS_GEN2(dev_priv))
- wm_info = &i915_wm_info;
+ return &i915_wm_info;
+ else if (plane->plane == PLANE_A)
+ return &i830_a_wm_info;
else
- wm_info = &i830_a_wm_info;
+ return &i830_bc_wm_info;
+}
- fifo_size = dev_priv->display.get_fifo_size(dev_priv, 0);
- crtc = intel_get_crtc_for_plane(dev_priv, 0);
- if (intel_crtc_active(crtc)) {
+static int i9xx_compute_pipe_wm(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add has_psr-flag to gen9lp
== Series Details == Series: drm/i915: Add has_psr-flag to gen9lp URL : https://patchwork.freedesktop.org/series/28488/ State : failure == Summary == Series 28488v1 drm/i915: Add has_psr-flag to gen9lp https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-skl-6260u) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:416s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:487s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:485s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:523s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:511s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:408s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:564s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:584s fi-skl-6260u total:109 pass:105 dwarn:0 dfail:0 fail:0 skip:3 fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:639s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:423s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:545s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s 3d87f89058607b2a2adecf99ddb637a676b4df64 drm-tip: 2017y-08m-08d-09h-05m-05s UTC integration manifest 719c12b943ba drm/i915: Add has_psr-flag to gen9lp == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5338/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
While testing Jim Bride's latest batch of PSR patches I noticed
that gen9lp doesn't include the has_psr flag, and that our GLK
system thus reported PSR as unsupported.
This patch simply adds has_psr.
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 09d97e0990b7..11f0e8aa1fe4 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -377,6 +377,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.has_ddi = 1, \
.has_fpga_dbg = 1, \
.has_fbc = 1, \
+ .has_psr = 1, \
.has_runtime_pm = 1, \
.has_pooled_eu = 0, \
.has_csr = 1, \
--
2.14.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2: Rebase over the panel/brideg refactorings in stm/ltdc. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_dvo.c | 1 - > drivers/gpu/drm/sti/sti_hda.c | 1 - > drivers/gpu/drm/sti/sti_hdmi.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Use drm_open_driver, don't need drm master
On 08/08/2017 12:55 PM, Arkadiusz Hiler wrote: On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote: Signed-off-by: Petri Latvala Reviewed-by: Arkadiusz Hiler Thanks, pushed. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_cursor.c| 1 - > drivers/gpu/drm/sti/sti_gdp.c | 1 - > drivers/gpu/drm/sti/sti_hqvdp.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > What is rather strange here is how few drivers set this up, I suspect > the earlier patch to handle properties in the core did end up fixing a > pile of possible issues. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_hdmi.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Use drm_open_driver, don't need drm master
On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote: > Signed-off-by: Petri Latvala Reviewed-by: Arkadiusz Hiler -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb
On Tue, Aug 8, 2017 at 11:25 AM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-08 10:01:59) >> On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson >> wrote: >> > Quoting Daniel Vetter (2017-08-07 17:26:56) >> >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: >> >> > Quoting Daniel Vetter (2017-08-04 17:07:22) >> >> > > We now have full (or a lot at least) igt running in beta CI, and snb >> >> > > blt hangs are really unhappy: >> >> > > >> >> > > - drv_hangman@error-state-capture-blt and gem_exec_capture@capture-blt >> >> > > reliably result in insta-machine death when we try to reset the gpu, >> >> > > both on the CI snb and the one I have here. >> >> > > >> >> > > - Other testcases also randomly (and sometimes rather rarely) die on >> >> > > snb. >> >> > > >> >> > > We can't use the endless batch because that results in a reset failure >> >> > > and wedged gpu, so also not really better. >> >> > >> >> > It shouldn't be the recursion, but the invalid instruction we use to try >> >> > and trigger the hang quicker (otherwise hangcheck may see the advancing >> >> > ACTHD and give us longer to escape the loop). >> >> > >> >> > In gem_exec_capture we shouldn't even need that invalid instruction, we >> >> > just need the busy batch as we pull the trigger ourselves, and if that >> >> > fails to reset a simple recursive batch we have some issues to resolve. >> >> >> >> Endless loop for haning results in a reset failure on blt as described in >> >> the commit message. We end up with a permanent and unrecoverable -EIO, >> >> which is as deadly to CI as outright killing the machine. >> > >> > No, it doesn't. snb-gt1 exhibiting the machine death on invalid blt >> > instruction as reported, after fixes: >> >> Well my gt2 disagreed, but I guess we can push your patches to igt and >> then ask CI whether we need more. > > Fine, dug out the snb-gt2, > > [ickle@huronriver tests]$ sudo ./drv_hangman > IGT-Version: 1.19-gcfd42d1 (i686) (Linux: 4.12.0+ i686) > Subtest error-state-sysfs-entry: SUCCESS (0.000s) > Subtest error-state-basic: SUCCESS (0.004s) > Subtest error-state-capture-render: SUCCESS (13.711s) > Subtest error-state-capture-bsd: SUCCESS (8.006s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-bsd1: SKIP (0.000s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-bsd2: SKIP (0.000s) > Subtest error-state-capture-blt: SUCCESS (6.049s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-vebox: SKIP (0.000s) > Test requirement not met in function hangcheck_unterminated, file > drv_hangman.c:213: > Test requirement: gem_uses_full_ppgtt(device) > Subtest hangcheck-unterminated: SKIP (0.000s) > [ickle@huronriver tests]$ sudo ./gem_exec_capture > IGT-Version: 1.19-gcfd42d1 (i686) (Linux: 4.12.0+ i686) > Subtest capture-render: SUCCESS (0.009s) > Test requirement not met in function __real_main175, file > gem_exec_capture.c:202: > Test requirement: gem_can_store_dword(fd, e->exec_id | e->flags) > Subtest capture-bsd: SKIP (0.000s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-bsd1: SKIP (0.000s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-bsd2: SKIP (0.000s) > Subtest capture-blt: SUCCESS (0.005s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-vebox: SKIP (0.000s) > > Seems solid to me. Ok I'll retest once your patches have landed, could very well be that I screwed up something with my looping batch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_kms: Remove vblank wait after plane update.
On Mon, 2017-08-07 at 10:42 +0200, Maarten Lankhorst wrote:
> Op 04-08-17 om 10:07 schreef Mika Kahola:
> >
> > On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote:
> > >
> > > With the conversion to atomic, this is already handled in the
> > > core.
> > >
> > > Signed-off-by: Maarten Lankhorst > > om>
> > > ---
> > > lib/igt_kms.c | 15 ---
> > > lib/igt_kms.h | 1 -
> > > 2 files changed, 16 deletions(-)
> > >
> > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > index 6390229f1546..14e2701c3afd 100644
> > > --- a/lib/igt_kms.c
> > > +++ b/lib/igt_kms.c
> > > @@ -2374,8 +2374,6 @@ static int
> > > igt_primary_plane_commit_legacy(igt_plane_t *primary,
> > >
> > > CHECK_RETURN(ret, fail_on_error);
> > >
> > > - primary->pipe->enabled = (fb_id != 0);
> > > -
> > How was this related to vblank wait removal?
> There are no users of pipe->enabled left, so it's removed.
Ok. You can add my
Reviewed-by: Mika Kahola
> >
> > >
> > > return 0;
> > > }
> > >
> > > @@ -2413,10 +2411,8 @@ static int igt_pipe_commit(igt_pipe_t
> > > *pipe,
> > > enum igt_commit_style s,
> > > bool fail_on_error)
> > > {
> > > - igt_display_t *display = pipe->display;
> > > int i;
> > > int ret;
> > > - bool need_wait_for_vblank = false;
> > >
> > > if (pipe->background_changed) {
> > > igt_crtc_set_property(pipe, pipe-
> > > >
> > > > background_property,
> > > @@ -2435,21 +2431,10 @@ static int igt_pipe_commit(igt_pipe_t
> > > *pipe,
> > > for (i = 0; i < pipe->n_planes; i++) {
> > > igt_plane_t *plane = &pipe->planes[i];
> > >
> > > - if (plane->fb_changed || plane->position_changed
> > > ||
> > > plane->size_changed)
> > > - need_wait_for_vblank = true;
> > > -
> > > ret = igt_plane_commit(plane, pipe, s,
> > > fail_on_error);
> > > CHECK_RETURN(ret, fail_on_error);
> > > }
> > >
> > > - /*
> > > - * If the crtc is enabled, wait until the next vblank
> > > before
> > > returning
> > > - * if we made changes to any of the planes.
> > > - */
> > > - if (need_wait_for_vblank && pipe->enabled) {
> > > - igt_wait_for_vblank(display->drm_fd, pipe-
> > > >pipe);
> > > - }
> > > -
> > > return 0;
> > > }
> > >
> > > diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> > > index 35428f3e9675..d18a92600933 100644
> > > --- a/lib/igt_kms.h
> > > +++ b/lib/igt_kms.h
> > > @@ -323,7 +323,6 @@ typedef struct {
> > > struct igt_pipe {
> > > igt_display_t *display;
> > > enum pipe pipe;
> > > - bool enabled;
> > >
> > > int n_planes;
> > > int plane_cursor;
>
--
Mika Kahola - Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Convert gen4- watermarks to atomic. (rev2)
Op 07-08-17 om 14:17 schreef Patchwork: > == Series Details == > > Series: drm/i915: Convert gen4- watermarks to atomic. (rev2) > URL : https://patchwork.freedesktop.org/series/23954/ > State : failure > > == Summary == > > Series 23954v2 drm/i915: Convert gen4- watermarks to atomic. > https://patchwork.freedesktop.org/api/1.0/series/23954/revisions/2/mbox/ > > Test gem_exec_parallel: > Subgroup basic: > fail -> PASS (fi-ilk-650) fdo#101735 > Test gem_ringfill: > Subgroup basic-default: > skip -> PASS (fi-bsw-n3050) fdo#101915 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-legacy: > pass -> FAIL (fi-pnv-d510) > Subgroup basic-flip-after-cursor-legacy: > pass -> FAIL (fi-pnv-d510) > Subgroup basic-flip-after-cursor-varying-size: > pass -> FAIL (fi-pnv-d510) > Subgroup basic-flip-before-cursor-legacy: > pass -> FAIL (fi-pnv-d510) > Subgroup basic-flip-before-cursor-varying-size: > pass -> FAIL (fi-pnv-d510) > Test kms_flip: > Subgroup basic-flip-vs-modeset: > skip -> PASS (fi-skl-x1585l) fdo#101781 > Subgroup basic-flip-vs-wf_vblank: > pass -> FAIL (fi-pnv-d510) > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-a: > pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 +1 > > fdo#101735 https://bugs.freedesktop.org/show_bug.cgi?id=101735 > fdo#101915 https://bugs.freedesktop.org/show_bug.cgi?id=101915 > fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 > fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:439s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:425s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:365s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:489s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:501s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:521s > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > time:510s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:583s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:431s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:409s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:421s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:509s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:473s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:456s > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:565s > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:578s > fi-pnv-d510 total:279 pass:215 dwarn:3 dfail:0 fail:6 skip:55 > time:605s > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:448s > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:639s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:458s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:427s > fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:489s > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:553s > fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 > time:407s > > 96c5eac5f202920356b34ef2da8a785bb8b4f320 drm-tip: 2017y-08m-07d-10h-55m-52s > UTC integration manifest > 1349492b8137 drm/i915: Rip out legacy watermark infrastructure > 0ce836b1f4c0 drm/i915: Kill off intel_crtc_active. > dfbc9cf45b41 drm/i915: Program gen4 watermarks atomically > 7c18d8bfbf7c drm/i915: Calculate gen4 watermarks semiatomically. > d9c8a8aea5bf drm/i915: Convert pineview watermarks to atomic, v2. > bcf55b93672f drm/i915: Program gen3- watermarks atomically > eaf653e8ffa8 drm/i915: Calculate gen3- watermarks semi-atomically. Interestingly, kms_cursor_legacy is failing because of too much debug info slowing things down. With drm.debug=0xe we miss all page flips, with drm.debug=0x1f it falls over even sooner. I think this happens because of the serial console, so I'll fix the PNV patch to be less chatty.. This will probably fix the kms_flip failure too, but I'll need to look more at kms_pipe_crc_basic. This series was supposed to fix that bug, so a fai
Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb
Quoting Daniel Vetter (2017-08-08 10:01:59) > On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-08-07 17:26:56) > >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: > >> > Quoting Daniel Vetter (2017-08-04 17:07:22) > >> > > We now have full (or a lot at least) igt running in beta CI, and snb > >> > > blt hangs are really unhappy: > >> > > > >> > > - drv_hangman@error-state-capture-blt and gem_exec_capture@capture-blt > >> > > reliably result in insta-machine death when we try to reset the gpu, > >> > > both on the CI snb and the one I have here. > >> > > > >> > > - Other testcases also randomly (and sometimes rather rarely) die on > >> > > snb. > >> > > > >> > > We can't use the endless batch because that results in a reset failure > >> > > and wedged gpu, so also not really better. > >> > > >> > It shouldn't be the recursion, but the invalid instruction we use to try > >> > and trigger the hang quicker (otherwise hangcheck may see the advancing > >> > ACTHD and give us longer to escape the loop). > >> > > >> > In gem_exec_capture we shouldn't even need that invalid instruction, we > >> > just need the busy batch as we pull the trigger ourselves, and if that > >> > fails to reset a simple recursive batch we have some issues to resolve. > >> > >> Endless loop for haning results in a reset failure on blt as described in > >> the commit message. We end up with a permanent and unrecoverable -EIO, > >> which is as deadly to CI as outright killing the machine. > > > > No, it doesn't. snb-gt1 exhibiting the machine death on invalid blt > > instruction as reported, after fixes: > > Well my gt2 disagreed, but I guess we can push your patches to igt and > then ask CI whether we need more. Fine, dug out the snb-gt2, [ickle@huronriver tests]$ sudo ./drv_hangman IGT-Version: 1.19-gcfd42d1 (i686) (Linux: 4.12.0+ i686) Subtest error-state-sysfs-entry: SUCCESS (0.000s) Subtest error-state-basic: SUCCESS (0.004s) Subtest error-state-capture-render: SUCCESS (13.711s) Subtest error-state-capture-bsd: SUCCESS (8.006s) Test requirement not met in function test_error_state_capture, file drv_hangman.c:187: Test requirement: gem_has_ring(device, ring_id) Subtest error-state-capture-bsd1: SKIP (0.000s) Test requirement not met in function test_error_state_capture, file drv_hangman.c:187: Test requirement: gem_has_ring(device, ring_id) Subtest error-state-capture-bsd2: SKIP (0.000s) Subtest error-state-capture-blt: SUCCESS (6.049s) Test requirement not met in function test_error_state_capture, file drv_hangman.c:187: Test requirement: gem_has_ring(device, ring_id) Subtest error-state-capture-vebox: SKIP (0.000s) Test requirement not met in function hangcheck_unterminated, file drv_hangman.c:213: Test requirement: gem_uses_full_ppgtt(device) Subtest hangcheck-unterminated: SKIP (0.000s) [ickle@huronriver tests]$ sudo ./gem_exec_capture IGT-Version: 1.19-gcfd42d1 (i686) (Linux: 4.12.0+ i686) Subtest capture-render: SUCCESS (0.009s) Test requirement not met in function __real_main175, file gem_exec_capture.c:202: Test requirement: gem_can_store_dword(fd, e->exec_id | e->flags) Subtest capture-bsd: SKIP (0.000s) Test requirement not met in function gem_require_ring, file ioctl_wrappers.c:1642: Test requirement: gem_has_ring(fd, ring) Subtest capture-bsd1: SKIP (0.000s) Test requirement not met in function gem_require_ring, file ioctl_wrappers.c:1642: Test requirement: gem_has_ring(fd, ring) Subtest capture-bsd2: SKIP (0.000s) Subtest capture-blt: SUCCESS (0.005s) Test requirement not met in function gem_require_ring, file ioctl_wrappers.c:1642: Test requirement: gem_has_ring(fd, ring) Subtest capture-vebox: SKIP (0.000s) Seems solid to me. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dim: Fix the broken rerere changes
I screwed up:
- a '/' at the end makes readlink follow the link before testing it.
- only delete everything when it's not a symlink.
Cc: Jani Nikula
Acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
dim | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dim b/dim
index f8be76df4952..619d855b321b 100755
--- a/dim
+++ b/dim
@@ -492,9 +492,9 @@ function check_conflicts # tree
function rr_cache_dir
{
if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
- echo $DIM_PREFIX/drm-tip/.git/rr-cache/
+ echo $DIM_PREFIX/drm-tip/.git/rr-cache
else
- echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
+ echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache
fi
}
@@ -504,10 +504,10 @@ function update_rerere_cache
cd $DIM_PREFIX/drm-rerere/
git pull &> /dev/null
- if [ -d $(rr_cache_dir) ] ; then
- rm -Rf $(rr_cache_dir)
- fi
if [ ! -L $(rr_cache_dir) ] ; then
+ if [ -d $(rr_cache_dir) ] ; then
+ rm -Rf $(rr_cache_dir)
+ fi
ln -s "$DIM_PREFIX/drm-rerere/rr-cache" $(dirname
$(rr_cache_dir))
fi
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb
On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-07 17:26:56) >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: >> > Quoting Daniel Vetter (2017-08-04 17:07:22) >> > > We now have full (or a lot at least) igt running in beta CI, and snb >> > > blt hangs are really unhappy: >> > > >> > > - drv_hangman@error-state-capture-blt and gem_exec_capture@capture-blt >> > > reliably result in insta-machine death when we try to reset the gpu, >> > > both on the CI snb and the one I have here. >> > > >> > > - Other testcases also randomly (and sometimes rather rarely) die on >> > > snb. >> > > >> > > We can't use the endless batch because that results in a reset failure >> > > and wedged gpu, so also not really better. >> > >> > It shouldn't be the recursion, but the invalid instruction we use to try >> > and trigger the hang quicker (otherwise hangcheck may see the advancing >> > ACTHD and give us longer to escape the loop). >> > >> > In gem_exec_capture we shouldn't even need that invalid instruction, we >> > just need the busy batch as we pull the trigger ourselves, and if that >> > fails to reset a simple recursive batch we have some issues to resolve. >> >> Endless loop for haning results in a reset failure on blt as described in >> the commit message. We end up with a permanent and unrecoverable -EIO, >> which is as deadly to CI as outright killing the machine. > > No, it doesn't. snb-gt1 exhibiting the machine death on invalid blt > instruction as reported, after fixes: Well my gt2 disagreed, but I guess we can push your patches to igt and then ask CI whether we need more. -Daniel > > Subtest error-state-basic: SUCCESS (0.001s) > Subtest error-state-capture-render: SUCCESS (7.740s) > Subtest error-state-capture-bsd: SUCCESS (6.024s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-bsd1: SKIP (0.000s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-bsd2: SKIP (0.000s) > Subtest error-state-capture-blt: SUCCESS (13.965s) > Test requirement not met in function test_error_state_capture, file > drv_hangman.c:187: > Test requirement: gem_has_ring(device, ring_id) > Subtest error-state-capture-vebox: SKIP (0.000s) > > Subtest capture-render: SUCCESS (0.003s) > Test requirement not met in function __real_main175, file > gem_exec_capture.c:202: > Test requirement: gem_can_store_dword(fd, e->exec_id | e->flags) > Subtest capture-bsd: SKIP (0.000s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-bsd1: SKIP (0.000s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-bsd2: SKIP (0.000s) > Subtest capture-blt: SUCCESS (0.002s) > Test requirement not met in function gem_require_ring, file > ioctl_wrappers.c:1642: > Test requirement: gem_has_ring(fd, ring) > Subtest capture-vebox: SKIP (0.000s) > > -Chris -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On 8/7/2017 11:13 PM, Alex Williamson wrote:
> On Mon, 7 Aug 2017 08:11:43 +
> "Zhang, Tina" wrote:
>
>> After going through the previous discussions, here are some summaries may be
>> related to the current discussion:
>> 1. How does user mode figure the device capabilities between region and
>> dma-buf?
>> VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case.
>> Otherwise, the mdev supports dma-buf.
>
> Why do we need to make this assumption?
Right, we should not make such assumption. Vendor driver might not
support both or disable console vnc ( for example, for performance
testing console VNC need to be disabled)
> What happens when dma-buf is
> superseded? What happens if a device supports both dma-buf and
> regions? We have a flags field in vfio_device_gfx_plane_info, doesn't
> it make sense to use it to identify which field, between region_index
> and fd, is valid? We could even put region_index and fd into a union
> with the flag bits indicating how to interpret the union, but I'm not
> sure everyone was onboard with this idea. Seems like a waste of 4
> bytes not to do that though.
>
Agree.
> Thinking further, is the user ever in a situation where they query the
> graphics plane info and can handle either a dma-buf or a region? It
> seems more likely that the user needs to know early on which is
> supported and would then require that they continue to see compatible
> plane information... Should the user then be able to specify whether
> they want a dma-buf or a region? Perhaps these flag bits are actually
> input and the return should be -errno if the driver cannot produce
> something compatible.
>
> Maybe we'd therefore define 3 flag bits: PROBE, DMABUF, REGION. In
> this initial implementation, DMABUF or REGION would always be set by
> the user to request that type of interface. Additionally, the QUERY
> bit could be set to probe compatibility, thus if PROBE and REGION are
> set, the vendor driver would return success only if it supports the
> region based interface. If PROBE and DMABUF are set, the vendor driver
> returns success only if the dma-buf based interface is supported. The
> value of the remainder of the structure is undefined for PROBE.
> Additionally setting both DMABUF and REGION is invalid. Undefined
> flags bits must be validated as zero by the drivers for future use
> (thus if we later define DMABUFv2, an older driver should
> automatically return -errno when probed or requested).
>
Are you saying all of this to be part of VFIO_DEVICE_QUERY_GFX_PLANE ioctl?
Let me summarize what we need, taking QEMU as reference:
1. From vfio_initfn(), for REGION case, get region info:
vfio_get_dev_region_info(.., VFIO_REGION_SUBTYPE_CONSOLE_REGION,
&vdev->console_opregion)
If above return success, setup console REGION and mmap.
I don't know what is required for DMABUF at this moment.
If console VNC is supported either DMABUF or REGION, initialize console
and register its callback operations:
static const GraphicHwOps vfio_console_ops = {
.gfx_update = vfio_console_update_display,
};
vdev->console = graphic_console_init(DEVICE(vdev), 0, &vfio_console_ops,
vdev);
2. On above console registration, vfio_console_update_display() gets
called for each refresh cycle of console. In that:
- call ioctl(VFIO_DEVICE_QUERY_GFX_PLANE)
- if (queried size > 0), update QEMU console surface (for REGION case
read mmaped region, for DMABUF read surface using fd)
Alex, in your proposal above, my understanding is
ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with PROBE flag should be called in
step #1.
In step #2, ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) will be without PROBE
flag, but either DMABUF or REGION flag based on what is returned as
supported by vendor driver in step #1. Is that correct?
> It seems like this handles all the cases, the user can ask what's
> supported and specifies the interface they want on every call. The
> user therefore can also choose between region_index and fd and we can
> make that a union.
>
>> 2. For dma-buf, how to differentiate unsupported vs not initialized?
>> For dma-buf, when the mdev doesn't support some arguments, -EINVAL will be
>> returned. And -errno will return when meeting other failures, like -ENOMEM.
>> If the mdev is not initialized, there won't be any returned err. Just zero
>> all the fields in structure vfio_device_gfx_plane_info.
>
> So we're relying on special values again :-\ For which fields is zero
> not a valid value? I prefer the probe interface above unless there are
> better ideas.
>
PROBE will be called during vdev initialization and after that
vfio_console_update_display() gets called at every console refresh
cycle. But until driver in guest is loaded, mmaped buffer/ DMABUF will
not be populated with correct surface data. In that case for QUERY,
vendor driver should return (atleast) size=0 which means there is
nothing to copy. Once guest driver is loaded and surface is created by
guest driver, QUE
Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide
On Mon, 07 Aug 2017, Rodrigo Vivi wrote: > good idea. > > > On Mon, Aug 7, 2017 at 9:10 AM, Daniel Vetter wrote: >> On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: >> >>> + * >>> + * For bit fields, define a _MASK and a _SHIFT macro. Define bit field >>> contents >>> + * so that they are already shifted in place, and can be directly OR'd. For >>> + * convenience, function-like macros may be used to define bit fields, but >>> do >>> + * note that the macros may be needed to read as well as write the register >>> + * contents. > > I'd mention define as needed if needed... > to avoid people adding many definition for shifts and masks that will > never get used... With mask and shift defined you don't need to always look at the spec. > also maybe to add that between name and content the real tabs are required > as much tab as needed to make sure that all bits defines on that bit > is vertically aligned. Added. > Reviewed-by: Rodrigo Vivi Thanks. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide
On Mon, 07 Aug 2017, Daniel Vetter wrote: > On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: >> This is not to try to force a new style; this is my interpretation of >> what the most common existing style is. >> >> With hopes I don't need to answer so many questions about style going >> forward. >> >> Cc: Daniel Vetter >> Signed-off-by: Jani Nikula >> >> --- >> >> N.b. only the *interpretation* of the existing style is up for debate >> here. Proposals to *change* the style going forward can be done in other >> patches changing this description. However, I doubt the usefulness of >> such changes, with the possible exception of promoting the use of BIT(). >> --- >> drivers/gpu/drm/i915/i915_reg.h | 77 >> + >> 1 file changed, 77 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index b2546ade2c45..324cf04d6bfe 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -25,6 +25,83 @@ >> #ifndef _I915_REG_H_ >> #define _I915_REG_H_ >> >> +/* > > DOC: section, plus pull it into our kerneldoc? I'm confused about what you think we should and should not include in the sphinx docs. I've seen you remove a bunch of documentation for i915 internal functions that I thought were useful, and you said weren't needed because they were internal. And here I thought nobody needs to read this until they're about edit the file. So I thought about this and opted against. > >> + * The i915 register macro definition style guide. >> + * >> + * Follow the style described here for new macros, and while changing >> existing >> + * macros. Do not mass change existing definitions just to update the style. >> + * >> + * LAYOUT >> + * >> + * Keep helper macros near the top. For example, _PIPE() and friends. >> + * >> + * Prefix macros that generally should not be used outside of this file with >> + * underscore '_'. For example, _PIPE() and friends, single instances of >> + * registers that are defined solely for the use by function-like macros. >> + * >> + * Avoid using the underscore prefixed macros outside of this file. There >> are >> + * exceptions, but keep them to a minimum. >> + * >> + * There are two basic types of register definitions: Single registers and >> + * register groups. Register groups are registers which have two or more >> + * instances, for example one per pipe, port, transcoder, etc. Register >> groups >> + * should be defined using function-like macros. >> + * >> + * For single registers, define the register offset first, followed by >> register >> + * contents. >> + * >> + * For register groups, define the register instance offsets first, prefixed >> + * with underscore, followed by a function-like macro choosing the right >> + * instance based on the parameter, followed by register contents. >> + * >> + * Define the register contents from most significant to least significant >> + * bit. Indent the bit and bit field macros using two extra spaces between >> + * #define and the macro name. > > Maybe note that since hw engineers love to use bit 31 for enabling a block > this gives some natural ordering. > >> + * >> + * For bit fields, define a _MASK and a _SHIFT macro. Define bit field >> contents >> + * so that they are already shifted in place, and can be directly OR'd. For >> + * convenience, function-like macros may be used to define bit fields, but >> do >> + * note that the macros may be needed to read as well as write the register >> + * contents. >> + * >> + * Define bits using (1 << N) instead of BIT(N). We may change this in the >> + * future, but this is the prevailing style. >> + * >> + * Group the register and its contents together without blank lines, >> separate >> + * from other registers and their contents with one blank line. >> + * >> + * Indent macro values from macro names using TABs. Use braces in macro >> values >> + * as needed to avoid unintended precedence after macro substitution. Use >> spaces >> + * in macro values according to kernel coding style. Use lower case in >> + * hexadecimal values. > > I think we should add: > > "Indent register contents macros by an additional space, to set them off > from the register they are for." > > Feel free to reword/place more suitably. I already have this there: "Indent the bit and bit field macros using two extra spaces between #define and the macro name." >> + * >> + * NAMING >> + * >> + * Try to name registers according to the specs. If the register name >> changes in >> + * the specs from platform to another, stick to the original name. >> + * >> + * Try to re-use existing register macro definitions. Only add new macros >> for >> + * new register offsets, or when the register contents have changed enough >> to >> + * warrant a full redefinition. >> + * >> + * When a register or a bit (field) changes for a new platform, prefix the >> new >> + * macro using the platform acro
