[Intel-gfx] [PATCH] drm/i915: Enable atomic support by default on supported platforms.

2017-02-01 Thread Maarten Lankhorst
i915 is pretty much feature complete. Support for atomic i915-specific
connector properties is still missing; those properties can (for now)
only be set through the legacy ioctl.

ILK style watermarks and gen9+ watermarks are handled atomically,
and nonblocking modesets work. FBC has also been made to work with
atomic.

gen4x- and vlv/chv watermarks still need to be fixed, so disable atomic
by default there for now.

Flip the switch!!

Signed-off-by: Maarten Lankhorst 
Cc: Ander Conselvan de Oliveira 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Lyude 
Cc: Matt Roper 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
---
I probably missed a lot of people who also worked on atomic support in i915,
feel free to ack the patch if you've worked on it. :)

 drivers/gpu/drm/i915/i915_drv.c| 10 +++---
 drivers/gpu/drm/i915/i915_params.c |  4 ++--
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0e8eb4b6db00..d4d1abf6d9d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1206,11 +1206,15 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
  */
 int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
+   const struct intel_device_info *match_info =
+   (struct intel_device_info *) ent->driver_data;
struct drm_i915_private *dev_priv;
int ret;
 
-   if (i915.nuclear_pageflip)
-   driver.driver_features |= DRIVER_ATOMIC;
+   /* Enable nuclear pageflip on ILK+, except vlv/chv */
+   if (!i915.nuclear_pageflip &&
+   (match_info->gen < 5 || match_info->has_gmch_display))
+   driver.driver_features &= ~DRIVER_ATOMIC;
 
ret = -ENOMEM;
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
@@ -2614,7 +2618,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
-   DRIVER_RENDER | DRIVER_MODESET,
+   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.preclose = i915_driver_preclose,
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 0e280fbd52f1..bb3feabec238 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -205,9 +205,9 @@ module_param_named(verbose_state_checks, 
i915.verbose_state_checks, bool, 0600);
 MODULE_PARM_DESC(verbose_state_checks,
"Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state 
conditions.");
 
-module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool, 0600);
+module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool, 0400);
 MODULE_PARM_DESC(nuclear_pageflip,
-"Force atomic modeset functionality; asynchronous mode is not 
yet supported. (default: false).");
+"Force enable atomic functionality on platforms that don't 
have full support yet.");
 
 /* WA to get away with the default setting in VBT for early platforms.Will be 
removed */
 module_param_named_unsafe(edp_vswing, i915.edp_vswing, int, 0400);
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Generate i915_params {} using a macro

2017-02-01 Thread Joonas Lahtinen
On ke, 2017-02-01 at 16:50 +, Chris Wilson wrote:
> I want to print the struct from the error state and so would like to use
> the existing struct definition as the template ala DEV_INFO*
> 
> Signed-off-by: Chris Wilson 



> +#define p(T, member) T member

Choice of macro name not so great. Maybe MEMBER or so.

With more reasonable name;

Reviewed-by: Joonas Lahtinen 

Needs some Acked-by's.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Capture module parameters for the GPU error state

2017-02-01 Thread Joonas Lahtinen
On ke, 2017-02-01 at 16:50 +, Chris Wilson wrote:
> They include useful material such as what mode the VM address space is
> running in, what submission mode, extra quirks, etc.
> 
> Signed-off-by: Chris Wilson 


 
> +static void err_print_params(struct drm_i915_error_state_buf *m,
> +  const struct i915_params *p)
> +{
> +#define PRINT(T, x) err_printf(m, #x ": %d\n", p->x);
> + I915_PARAMS_FOR_EACH(PRINT);
> +#undef PRINT_PARAM

#undef PRINT

That fixed;

Reviewed-by: Joonas Lahtinen 

Needs some Acks before merging, though.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Sharma, Shashank

Thanks for the review, Dhinakaran.


Regards

Shashank


On 2/2/2017 1:23 AM, Pandiyan, Dhinakaran wrote:

On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 131 +++-
  include/drm/drm_connector.h |  24 
  include/drm/drm_edid.h  |   6 +-
  3 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 37902e5..f0d940a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define version_greater(edid, maj, min) \

(((edid)->version > (maj)) || \
@@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
*connector,
}
  }
  
+static void drm_detect_hdmi_scrambling(struct drm_connector *connector,

+const u8 *hf_vsdb)
+{
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi_info;
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340M.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
+* * SCDC support available
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   display->max_tmds_clock = hf_vsdb[5] * 5000;

Comment explaining or quoting where the 5000 comes from?

Sure, can be done.



+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+
+   if (hdmi->scdc_supported) {
+   hdmi->scr_info.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   hdmi->scr_info.low_clocks = true;
+   }
+   }
+}
+
+/**
+ * drm_check_scrambling_status - what is status of scrambling?
+ * @adapter: i2c adapter for SCDC channel
+ *
+ * Read the scrambler status over SCDC channel, and check the
+ * scrambling status.
+ *
+ * Return: True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_check_scrambling_status(struct i2c_adapter *adapter)
+{
+   u8 status;
+
+   if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
+   DRM_ERROR("Failed to read scrambling status\n");
+   return false;
+   }
+
+   status &= SCDC_SCRAMBLING_STATUS;
+   return status != 0;
+}
+
+/**
+ * drm_enable_scrambling - enable scrambling
+ * @connector: target drm_connector
+ * @adapter: i2c adapter for SCDC channel
+ * @force: enable scrambling, even if its already enabled
+ *
+ * Write the TMDS config over SCDC channel, and enable scrambling
+ * Return: True if scrambling is successfully enabled, false otherwise.
+ */
+
+bool drm_enable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)
+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (hdmi_info->scr_info.status && !force) {
+   DRM_DEBUG_KMS("Scrambling already enabled\n");
+   return true;
+   }
+
+   if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
+   DRM_ERROR("Failed to read tmds config\n");
+   return false;
+   }
+
+   config |= SCDC_SCRAMBLING_ENABLE;
+
+   if (drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config) < 0) {
+   DRM_ERROR("Failed to enable scrambling, write error\n");
+   return false;
+   }
+
+   hdmi_info->scr_info.status = drm_check_scrambling_status(adapter);
+   return hdmi_info->scr_info.status;
+}
+
+/**
+ * drm_disable_scrambling - disable scrambling
+ * @connector: target drm_connector
+ * @adapter: i2c adapter for SCDC channel
+ * @force: disable scrambling, even if its already disabled
+ *
+ * Write the TMDS config over SCDC channel, and disable scrambling
+ * Return: True if scrambling is successfully disabled, false otherwise.
+ */
+bool drm_disable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)
+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (!hdmi_info->scr_info.status && 

Re: [Intel-gfx] [PATCH 5/6] drm/i915: enable scrambling

2017-02-01 Thread Sharma, Shashank

Regards

Shashank


On 2/1/2017 10:06 PM, Ville Syrjälä wrote:

On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:

Geminilake platform has a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h   |  2 ++
  drivers/gpu/drm/i915/intel_ddi.c  |  5 +
  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
  drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
  4 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 495b789..cc85892 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7807,6 +7807,8 @@ enum {
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
  #define  TRANS_DDI_BFI_ENABLE (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
  
  /* DisplayPort Transport Control */

  #define _DP_TP_CTL_A  0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a9a670..aea81ce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv)) {
+   temp |= intel_hdmi_check_scrambling(intel_encoder,
+   _crtc->config->base.adjusted_mode);
+   }
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 393f243..aafce7f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config,
   struct drm_connector_state *conn_state);
+uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
+   struct drm_display_mode *mode);
  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
  
  
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c

index ebae2bd..92dd9bc 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct drm_connector 
*connector)
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
  }
  
+static void

+intel_hdmi_enable_scrambling(struct drm_connector *connector)
+{
+   struct drm_i915_private *dev_priv = connector->dev->dev_private;
+   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   if (!drm_enable_scrambling(connector, adapter, true))
+   DRM_ERROR("Request to enable scrambling failed\n");
+}

I don't like hiding this somewhere deep like this. It should be
somewhere much higher up.
Why ? All we need to do here is enable two bits in transcoder control 
register, which is already being
programmed in a calling function, so I dont see the use case, but I 
might be missing some bigger picture.

Can you please elaborate on this ?


And I'm thinkign we might want to track the scrambler state
in the crtc state.
Yes, that's a pretty good way to track dynamic status of scrambler, do 
you think we should add this in

drm_crtc_state itself ?

- Shashank

+
+uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
+   struct drm_display_mode *mode)
+{
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(_encoder->base);
+   struct drm_connector *connector = _hdmi->attached_connector->base;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+   uint32_t hdmi_config = 0;
+
+   DRM_DEBUG_KMS("Checking scrambling for enc:%s connector:%s\n",
+   intel_encoder->base.name, connector->name);
+
+   if (mode->clock < 34) {
+   if (hdmi_info->scr_info.low_clocks) {
+   intel_hdmi_enable_scrambling(connector);
+   hdmi_config |= TRANS_DDI_HDMI_SCRAMBLING;
+   }
+   return hdmi_config;

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Sharma, Shashank

Regards

Shashank


On 2/1/2017 10:02 PM, Ville Syrjälä wrote:

On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 131 +++-
  include/drm/drm_connector.h |  24 
  include/drm/drm_edid.h  |   6 +-
  3 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 37902e5..f0d940a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define version_greater(edid, maj, min) \

(((edid)->version > (maj)) || \
@@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
*connector,
}
  }
  
+static void drm_detect_hdmi_scrambling(struct drm_connector *connector,

+const u8 *hf_vsdb)

That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or
something.
Actually, unlike the last patch set, we are not parsing the whole 
hf_vsdb, but parsing it only for
scrambling status byte (hf_vsdb[5]). But may be I can make it 
drm_detect_scrambling_from_hfvsdb
ot something similar. We will have more hf_vsdb parsing for 3d flags, 
yuv420_deep_color etc.

+{
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi_info;
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340M.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
+* * SCDC support available
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   display->max_tmds_clock = hf_vsdb[5] * 5000;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);

I wonder if we should be a little paranoid and ignore this if it's
<=340?

Sure, will do it.



+
+   if (hdmi->scdc_supported) {
+   hdmi->scr_info.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   hdmi->scr_info.low_clocks = true;
+   }
+   }
+}
+
+/**
+ * drm_check_scrambling_status - what is status of scrambling?
+ * @adapter: i2c adapter for SCDC channel
+ *
+ * Read the scrambler status over SCDC channel, and check the
+ * scrambling status.
+ *
+ * Return: True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_check_scrambling_status(struct i2c_adapter *adapter)

The name is again a little wonky. And it looks like something that
should live alognside the SCDC helper stuff.
Yep, Thierry also suggested the same, to move it along with SCDC. Will 
do it.

+{
+   u8 status;
+
+   if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
+   DRM_ERROR("Failed to read scrambling status\n");
+   return false;
+   }
+
+   status &= SCDC_SCRAMBLING_STATUS;
+   return status != 0;

return status & SCDC_SCRAMBLING_STATUS

Sure.

+}
+
+/**
+ * drm_enable_scrambling - enable scrambling
+ * @connector: target drm_connector
+ * @adapter: i2c adapter for SCDC channel
+ * @force: enable scrambling, even if its already enabled
+ *
+ * Write the TMDS config over SCDC channel, and enable scrambling
+ * Return: True if scrambling is successfully enabled, false otherwise.
+ */
+
+bool drm_enable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)
+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (hdmi_info->scr_info.status && !force) {
+   DRM_DEBUG_KMS("Scrambling already enabled\n");
+   return true;
+   }

I don't think we want to track any dynamic state in the display info.
That belongs to the atomic state stuff.

Hummm, ok.


And the function again looks like something that belongs in the SCDC
helper.

Agree.


Since the two pieces of infromaton in this registrer are the scramble
control and the clock ratio, I think we might want to just have one
function to configure both.

That's a good suggestion, thanks.

- Shashank



+
+   if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
+   DRM_ERROR("Failed to read tmds 

Re: [Intel-gfx] [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-01 Thread Sharma, Shashank

Thanks for the review Ville. My comments inline.

Regards
Shashank
On 2/1/2017 10:03 PM, Ville Syrjälä wrote:

On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
   This structure will be used to save and indicate if sink
   supports advance HDMI 2.0 features
- Checks the HF-VSDB block for presence of SCDC, and marks it
   in hdmi_info structure.
- If SCDC is present, checks if sink is capable of generating
   scdc read request, and marks it in hdmi_info structure.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 14 ++
  include/drm/drm_connector.h | 26 ++
  2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96d3e47..37902e5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
  }
  EXPORT_SYMBOL(drm_default_rgb_quant_range);
  
+static void drm_detect_hdmi_scdc(struct drm_connector *connector,

+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = >display_info.hdmi_info;
+
+   if (hf_vsdb[6] & 0x80) {
+   hdmi->scdc_supported = true;
+   if (hf_vsdb[6] & 0x40)
+   hdmi->scdc_rr = true;
+   }
+}
+
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
   const u8 *hdmi)
  {
@@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
  
  		if (cea_db_is_hdmi_vsdb(db))

drm_parse_hdmi_vsdb_video(connector, db);
+   if (cea_db_is_hdmi_forum_vsdb(db))
+   drm_detect_hdmi_scdc(connector, db);
}
  }
  
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h

index e5e1edd..2435598 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,27 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/**
+ * struct drm_hdmi_info - runtime data about the connected sink
+ *
+ * Describes if a given hdmi display supports advance HDMI 2.0 featutes.
+ * This information is available in CEA-861-F extension blocks (like
+ * HF-VSDB)
+ * For sinks which provide an EDID this can be filled out by calling
+ * drm_add_edid_modes().
+ */
+struct drm_hdmi_info {
+   /**
+* @scdc_supported: status control & data channel present.
+*/
+   bool scdc_supported;
+   /**
+* @scdc_rr: sink is capable of generating scdc read request.
+*/
+   bool scdc_rr;

Probably worth spelling the thing out.
Agree. I was afraid it would make it difficult for 80 char stuff, but 
maybe I can make it scdc->read_req


- Shashank

  };
  
  /**

@@ -188,6 +209,11 @@ struct drm_display_info {
 * @cea_rev: CEA revision of the HDMI sink.
 */
u8 cea_rev;
+
+   /**
+* @hdmi_info: advance features of a HDMI sink.
+*/
+   struct drm_hdmi_info hdmi_info;
  };
  
  int drm_display_info_set_bus_formats(struct drm_display_info *info,

--
1.9.1


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


Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Sharma, Shashank

Regards

Shashank


On 2/1/2017 10:02 PM, Thierry Reding wrote:

On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 131 +++-
  include/drm/drm_connector.h |  24 
  include/drm/drm_edid.h  |   6 +-
  3 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 37902e5..f0d940a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define version_greater(edid, maj, min) \

(((edid)->version > (maj)) || \
@@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
*connector,
}
  }
  
+static void drm_detect_hdmi_scrambling(struct drm_connector *connector,

+const u8 *hf_vsdb)
+{
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi_info;
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340M.

In comments below you use Mhz as the abbreviations. This should be
consistent. Also I think "MHz" is actually the correct spelling.

Agree.

+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
+* * SCDC support available
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   display->max_tmds_clock = hf_vsdb[5] * 5000;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+
+   if (hdmi->scdc_supported) {
+   hdmi->scr_info.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   hdmi->scr_info.low_clocks = true;
+   }
+   }
+}
+
+/**
+ * drm_check_scrambling_status - what is status of scrambling?
+ * @adapter: i2c adapter for SCDC channel

"I2C", same in other parts of this patch.

Got it.

+ *
+ * Read the scrambler status over SCDC channel, and check the
+ * scrambling status.
+ *
+ * Return: True if the scrambling is enabled, false otherwise.

I think the rest of DRM/KMS kerneldoc tries to use "Returns:\n" as a
standard way to document return values.

Ok.

+ */
+
+bool drm_check_scrambling_status(struct i2c_adapter *adapter)

Maybe use a drm_scdc_*() prefix for this to make it more consistent with
other SCDC API.

While at it, would this not be better located in drm_scdc.c along with
the other helpers? drm_edid.c is more focussed on the parsing aspects of
all things EDID.

Yeah, the same is mentioned by Ville too, will do that.

+{
+   u8 status;
+
+   if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {

How about storing the error code...


+   DRM_ERROR("Failed to read scrambling status\n");

... and making it part of the error message? Sometimes its useful to
know what exact error triggered this because it helps narrowing down
where things went wrong.
Agree, in fact while debugging and testing this patch series, I had to 
print it explicitly.



+   return false;
+   }
+
+   status &= SCDC_SCRAMBLING_STATUS;
+   return status != 0;

Maybe make this a single line:

return (status & SCDC_SCRAMBLING_STATUS) != 0;

Got it.



+}
+
+/**
+ * drm_enable_scrambling - enable scrambling
+ * @connector: target drm_connector

"target DRM connector"?

Got it.

+ * @adapter: i2c adapter for SCDC channel
+ * @force: enable scrambling, even if its already enabled
+ *
+ * Write the TMDS config over SCDC channel, and enable scrambling
+ * Return: True if scrambling is successfully enabled, false otherwise.
+ */
+
+bool drm_enable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)

I think I'd move this to drm_scdc.c as well because it primarily
operates on SCDC. If you do so, might be worth making adapter the first
argument for consistency with other SCDC API.

Agree, will move it.

+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (hdmi_info->scr_info.status && !force) {
+   DRM_DEBUG_KMS("Scrambling already enabled\n");
+   return true;
+   

Re: [Intel-gfx] [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-01 Thread Sharma, Shashank

Thanks for the review Thierry. My comments inline.

Regards
Shashank
On 2/1/2017 9:40 PM, Thierry Reding wrote:

On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
   This structure will be used to save and indicate if sink
   supports advance HDMI 2.0 features

"advanced"

got it.



- Checks the HF-VSDB block for presence of SCDC, and marks it
   in hdmi_info structure.

"drm_hdmi_info structure"?

yep, sure.

- If SCDC is present, checks if sink is capable of generating
   scdc read request, and marks it in hdmi_info structure.

"SCDC" to be consistent and because it's an abbreviation.

Agree.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 14 ++
  include/drm/drm_connector.h | 26 ++
  2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96d3e47..37902e5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
  }
  EXPORT_SYMBOL(drm_default_rgb_quant_range);
  
+static void drm_detect_hdmi_scdc(struct drm_connector *connector,

+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = >display_info.hdmi_info;
+
+   if (hf_vsdb[6] & 0x80) {
+   hdmi->scdc_supported = true;
+   if (hf_vsdb[6] & 0x40)
+   hdmi->scdc_rr = true;
+   }
+}
+
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
   const u8 *hdmi)
  {
@@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
  
  		if (cea_db_is_hdmi_vsdb(db))

drm_parse_hdmi_vsdb_video(connector, db);
+   if (cea_db_is_hdmi_forum_vsdb(db))
+   drm_detect_hdmi_scdc(connector, db);
}
  }
  
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h

index e5e1edd..2435598 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,27 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/**
+ * struct drm_hdmi_info - runtime data about the connected sink

Maybe "connected HDMI sink"?

Agree.

+ *
+ * Describes if a given hdmi display supports advance HDMI 2.0 featutes.

"HDMI", "advanced", "features"

Oops, got it :-)

+ * This information is available in CEA-861-F extension blocks (like
+ * HF-VSDB)

This should be terminated by a full-stop.

Ok

+ * For sinks which provide an EDID this can be filled out by calling
+ * drm_add_edid_modes().

And maybe make this sentence start right after the one above rather than
breaking it to the next line.

Ok

I'm not sure how useful this line is. Most
driver will be calling drm_add_edid_modes() anyway, but the above makes
it sound like drm_add_edid_modes() is something you have to explicitly
call to get these fields parsed.
Mostly a 'yy' and 'p' from the function above, but makes sense, I can 
remove this line.

+ */
+struct drm_hdmi_info {
+   /**
+* @scdc_supported: status control & data channel present.
+*/
+   bool scdc_supported;
+   /**
+* @scdc_rr: sink is capable of generating scdc read request.
+*/
+   bool scdc_rr;
  };
  
  /**

@@ -188,6 +209,11 @@ struct drm_display_info {
 * @cea_rev: CEA revision of the HDMI sink.
 */
u8 cea_rev;
+
+   /**
+* @hdmi_info: advance features of a HDMI sink.
+*/
+   struct drm_hdmi_info hdmi_info;

I think we can safely drop the _info suffix on the field name. It's
already inside a structure that carries this suffix.

Sure, should I call it hdmi_sink OR connected_hdmi ?
- Shashank


Other than that:

Reviewed-by: Thierry Reding 

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


Re: [Intel-gfx] [PATCH v1½ 12/13] drm/i915/dp: localize link rate index variable more

2017-02-01 Thread Manasi Navare
On Thu, Jan 26, 2017 at 09:44:26PM +0200, Jani Nikula wrote:
> Localize link_rate_index to the if block, and rename to just index to
> reduce indent.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7704d32286a3..429dc70c251a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1639,7 +1639,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   /* Conveniently, the link BW constants become indices with a shift...*/
>   int min_clock = 0;
>   int max_clock;
> - int link_rate_index;
>   int bpp, mode_rate;
>   int link_avail, link_clock;
>   const int *common_rates = intel_dp->common_rates;
> @@ -1684,11 +1683,13 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  
>   /* Use values requested by Compliance Test Request */
>   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> - link_rate_index = intel_dp_find_rate(intel_dp->common_rates,
> -  intel_dp->num_common_rates,
> -  
> intel_dp->compliance.test_link_rate);

Can we not pass just the common_rates as an argument to this function
since common_rates is already assigned intel_dp->common_rates.

Regards
Manasi


> - if (link_rate_index >= 0)
> - min_clock = max_clock = link_rate_index;
> + int index;
> +
> + index = intel_dp_find_rate(intel_dp->common_rates,
> +intel_dp->num_common_rates,
> +intel_dp->compliance.test_link_rate);
> + if (index >= 0)
> + min_clock = max_clock = index;
>   min_lane_count = max_lane_count = 
> intel_dp->compliance.test_lane_count;
>   }
>   DRM_DEBUG_KMS("DP link computation with max lane count %i "
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] usb-C -> HDMI causes weird colors

2017-02-01 Thread Ola Petersson
Hi,

I own a Dell XPS 13 Developer Kaby Lake and have experienced the same
problem as has been reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=99137

USB-c -> HDMI adapters causes psychadelic colors on external
projectors/TV:s but seems to be working on "real" monitors (e.g. 24" dell
IPS screens)

During my debug session of this problem I ran into several other people who
have run into the same issue. Is there something I could provide/do to help
out with this?

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


Re: [Intel-gfx] [PATCH v1½ 07/13] drm/i915/dp: cache common rates with sink rates

2017-02-01 Thread Pandiyan, Dhinakaran
On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> Now that source rates are static and sink rates are updated whenever
> DPCD is updated, we can do and cache the intersection of them whenever
> sink rates are updated. This reduces code complexity, as we don't have
> to keep calling the functions to intersect. We also get rid of several
> common rates arrays on stack.
> 
> Limiting the common rates by a max link rate can be done by picking the
> first N elements of the cached common rates.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 66 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++
>  2 files changed, 40 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f163391e61fa..7d3ff92000c3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -283,17 +283,29 @@ static int intel_dp_find_rate(const int *rates, int 
> len, int rate)
>   return -1;
>  }
>  
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> -  int *common_rates)
> +static void intel_dp_set_common_rates(struct intel_dp *intel_dp)
>  {
> - int max_rate = intel_dp->max_sink_link_rate;
> - int i, common_len;
> + WARN_ON(!intel_dp->num_source_rates || !intel_dp->num_sink_rates);
>  
> - common_len = intersect_rates(intel_dp->source_rates,
> -  intel_dp->num_source_rates,
> -  intel_dp->sink_rates,
> -  intel_dp->num_sink_rates,
> -  common_rates);
> + intel_dp->num_common_rates = intersect_rates(intel_dp->source_rates,
> +  intel_dp->num_source_rates,
> +  intel_dp->sink_rates,
> +  intel_dp->num_sink_rates,
> +  intel_dp->common_rates);


Do we need to pass all these args given that all of them are now
available in intel_dp and intersect_rates() is not used anywhere else? 

-DK
> +
> + /* Paranoia, there should always be something in common. */
> + if (WARN_ON(intel_dp->num_common_rates == 0)) {
> + intel_dp->common_rates[0] = default_rates[0];
> + intel_dp->num_common_rates = 1;
> + }
> +}
> +
> +/* get length of common rates potentially limited by max_rate */
> +static int intel_dp_common_len_rate_limit(struct intel_dp *intel_dp,
> +   int max_rate)
> +{
> + const int *common_rates = intel_dp->common_rates;
> + int i, common_len = intel_dp->num_common_rates;
>  
>   /* Limit results by potentially reduced max rate */
>   for (i = 0; i < common_len; i++) {
> @@ -304,25 +316,23 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> -static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> - int *common_rates, int link_rate)
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int link_rate)
>  {
>   int common_len;
>  
> - common_len = intel_dp_common_rates(intel_dp, common_rates);
> + common_len = intel_dp_common_len_rate_limit(intel_dp,
> + 
> intel_dp->max_sink_link_rate);
>  
> - return intel_dp_find_rate(common_rates, common_len, link_rate);
> + return intel_dp_find_rate(intel_dp->common_rates, common_len, 
> link_rate);
>  }
>  
>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>   int link_rate, uint8_t lane_count)
>  {
> - int common_rates[DP_MAX_SUPPORTED_RATES];
> + const int *common_rates = intel_dp->common_rates;
>   int link_rate_index;
>  
> - link_rate_index = intel_dp_link_rate_index(intel_dp,
> -common_rates,
> -link_rate);
> + link_rate_index = intel_dp_link_rate_index(intel_dp, link_rate);
>   if (link_rate_index > 0) {
>   intel_dp->max_sink_link_rate = common_rates[link_rate_index - 
> 1];
>   intel_dp->max_sink_lane_count = lane_count;
> @@ -1509,8 +1519,6 @@ static void snprintf_int_array(char *str, size_t len,
>  
>  static void intel_dp_print_rates(struct intel_dp *intel_dp)
>  {
> - int common_len;
> - int common_rates[DP_MAX_SUPPORTED_RATES];
>   char str[128]; /* FIXME: too big for stack? */
>  
>   if ((drm_debug & DRM_UT_KMS) == 0)
> @@ -1524,8 +1532,8 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>  intel_dp->sink_rates, 

Re: [Intel-gfx] [PATCH v1½ 03/13] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

2017-02-01 Thread Pandiyan, Dhinakaran
On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> Rename the function, move it at the top, and reuse in
> intel_dp_link_rate_index(). If there was a reason in the past to use
> reverse search order here, there isn't now.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1d66737a3a0f..f3068ff670a1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -266,6 +266,17 @@ static int intersect_rates(const int *source_rates, int 
> source_len,
>   return k;
>  }
>  
> +static int intel_dp_find_rate(const int *rates, int len, int rate)

I wonder if the function name can be more intuitive. The argument is
rate and the function name indicates it also returns rate. I can't tell
what the function does by it's name. Feel free to ignore this comment as
I might be missing some context.

-DK

> +{
> + int i;
> +
> + for (i = 0; i < len; i++)
> + if (rate == rates[i])
> + return i;
> +
> + return -1;
> +}
> +
>  static int intel_dp_common_rates(struct intel_dp *intel_dp,
>int *common_rates)
>  {
> @@ -284,15 +295,10 @@ static int intel_dp_link_rate_index(struct intel_dp 
> *intel_dp,
>   int *common_rates, int link_rate)
>  {
>   int common_len;
> - int index;
>  
>   common_len = intel_dp_common_rates(intel_dp, common_rates);
> - for (index = 0; index < common_len; index++) {
> - if (link_rate == common_rates[common_len - index - 1])
> - return common_len - index - 1;
> - }
>  
> - return -1;
> + return intel_dp_find_rate(common_rates, common_len, link_rate);
>  }
>  
>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> @@ -1542,17 +1548,6 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
>   return true;
>  }
>  
> -static int rate_to_index(const int *rates, int len, int rate)
> -{
> - int i;
> -
> - for (i = 0; i < len; i++)
> - if (rate == rates[i])
> - return i;
> -
> - return -1;
> -}
> -
>  int
>  intel_dp_max_link_rate(struct intel_dp *intel_dp)
>  {
> @@ -1568,8 +1563,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp)
>  
>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
>  {
> - int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates,
> -   rate);
> + int i = intel_dp_find_rate(intel_dp->sink_rates,
> +intel_dp->num_sink_rates, rate);
>  
>   if (WARN_ON(i < 0))
>   i = 0;

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


Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

2017-02-01 Thread Dave Hansen
On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
>> I added some printk()s all over and gathered a bit more information
>> about what's going on.  It looks like the display doesn't work until the
>> drm connector code cleans up the *old* connector.  For some reason, it
>> isn't motivated to do that until I go to the console and back.
>>
>> In this case, the display was connected to DP-4.
>> intel_dp_destroy_mst_connector() got called on it when I switched away,
>> but drm_connector_cleanup() did not get called.  Upon switching back
>> DP-3/5/6 get created.  One of these *eventually* ends up being
>> "enabled", but is not now.  When I switch over to the console,
>> drm_connector_cleanup() finally gets called on the old connector: DP-4
>> and I can switch back to X and I see one of DP-3/5/6 enabled and working.
>>
>> Here are some snippets of dmesg interspersed with what I was doing:
> 
> Ok, so the delayed deleting seems to be involved in the bug (and we only
> do that since we recently introduced refcounting for hotplugged
> connectors). The question is who's getting confused, either kernel or X.
> To figure this out, next time things are out of sync, please compare the
> output of
> 
> $ xrandr
> 
> with what's reported in /sys/class/drm/*/status:
> 
> $ grep . /sys/class/drm/card0-DP-*/status

OK, I collected that 4 times:
1. When everything is OK
2. When the DVI is unplugged
3. When the DVI is re-plugged (no output)
4. After I press Ctrl-Alt-F2 (back to OK)

The good vs. bad diff looks like this:

--- xdebug.1485980540.start.log 2017-02-01 12:22:20.328242293 -0800
+++ xdebug.1485980621.dvi-replugged.log 2017-02-01 12:23:41.964241982 -0800
@@ -25,15 +25,6 @@
 DP2-1 disconnected (normal left inverted right x axis y axis)
 DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x
axis y axis) 518mm x 324mm
1920x1200  60.0*+
-   1920x1080  60.0
-   1600x1200  60.0
-   1680x1050  59.9
-   1280x1024  60.0
-   1280x960   60.0
-   1024x768   60.0
-   800x60060.3
-   640x48059.9
-   720x40070.1
 DP2-3 disconnected (normal left inverted right x axis y axis)
 HDMI1 disconnected (normal left inverted right x axis y axis)
 HDMI2 disconnected (normal left inverted right x axis y axis)
@@ -41,5 +32,5 @@
 /sys/class/drm/card0-DP-1/status:disconnected
 /sys/class/drm/card0-DP-2/status:disconnected
 /sys/class/drm/card0-DP-3/status:disconnected
-/sys/class/drm/card0-DP-5/status:connected
+/sys/class/drm/card0-DP-4/status:connected
 /sys/class/drm/card0-DP-6/status:disconnected

But it's very interesting that when I unplug the DVI, the xrandr output
does not change.  Only the /sys/class/drm/.../status does.

> Another question: What desktop are you using, and if you unplug a screen,
> does that general reconfigure the desktop size to disable that output? The
> zombie connector only sticks around as long as someone is still using it
> in the screen configuration. As soon as the reconfiguration has happened,
> it should go away. You can test this by manually disabling the output when
> it's stuck as on:
> 
> $ xrandr --output DP-4 --off

Yep, it does the delayed cleanup.  The output still shows up in xrandr
(as an 8x8 display) at this point, but it can at least be turned back on.

xrandr snippet:

Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767

So, if I do a pair of these:

xrandr --output DP-4 --off
xrandr --output DP-4 --auto

it does bring the display back consistently.
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
   1920x1080  60.0 +   59.9  
   1680x1050  60.0 59.9  
   1600x1024  60.2  
   1400x1050  60.0  
   1600x900   60.0  
   1280x1024  60.0  
   1440x900   59.9  
   1280x960   60.0  
   1368x768   60.0  
   1360x768   59.8 60.0  
   1152x864   60.0  
   1280x720   60.0  
   1024x768   60.0  
   1024x576   60.0  
   960x54060.0  
   800x60060.3 56.2  
   864x48660.0  
   640x48059.9  
   720x40560.0  
   640x36060.0  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200  60.0*+
   1920x1080  60.0  
   1600x1200  60.0  
   1680x1050  59.9  
   1280x1024  60.0  
   1280x960   60.0  
   1024x768   60.0  
   800x60060.3  
   640x48059.9  
   720x40070.1  
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Release the forgotten connector reference

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Release the forgotten connector reference
URL   : https://patchwork.freedesktop.org/series/18944/
State : success

== Summary ==

Series 18944v1 drm/i915: Release the forgotten connector reference
https://patchwork.freedesktop.org/api/1.0/series/18944/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

a0cc425b0034c42eb3830f7dd612ac2a132a874c drm-tip: 2017y-02m-01d-17h-17m-34s UTC 
integration manifest
7a649d7 drm/i915: Release the forgotten connector reference

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3669/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Release the forgotten connector reference

2017-02-01 Thread Chris Wilson
The reference was gained in
intel_modeset_update_connector_atomic_state() [called from
intel_modeset_setup_hw_state()] and is never lost if no client ever
performs a modeset.

[  649.836069] WARNING: CPU: 6 PID: 8865 at 
drivers/gpu/drm/drm_mode_config.c:424 drm_mode_config_cleanup+0x21b/0x290 [drm]
[  649.836078] Modules linked in: i915(-) intel_gtt drm_kms_helper cfbfillrect 
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm
[  649.836099] CPU: 6 PID: 8865 Comm: drv_selftest Not tainted 4.10.0-rc6+ #908
[  649.836106] Hardware name: Intel Corporation 2012 Client Platform/Emerald 
Lake 2, BIOS ACRVMBY1.86C.0078.P00.1201161002 01/16/2012
[  649.836114] Call Trace:
[  649.836125]  dump_stack+0x4d/0x6f
[  649.836136]  __warn+0xc1/0xe0
[  649.836144]  warn_slowpath_null+0x18/0x20
[  649.836163]  drm_mode_config_cleanup+0x21b/0x290 [drm]
[  649.836213]  intel_modeset_cleanup+0x59/0xa0 [i915]
[  649.836242]  i915_driver_unload+0x84/0x170 [i915]
[  649.836277]  i915_pci_remove+0x14/0x20 [i915]
[  649.836287]  pci_device_remove+0x28/0x60
[  649.836301]  device_release_driver_internal+0x132/0x1d0
[  649.836313]  driver_detach+0x3a/0x80
[  649.836324]  bus_remove_driver+0x47/0xa0
[  649.836335]  driver_unregister+0x27/0x50
[  649.836344]  pci_unregister_driver+0x34/0xa0
[  649.836387]  i915_exit+0x1a/0x71 [i915]
[  649.836401]  SyS_delete_module+0x173/0x1c0
[  649.836413]  entry_SYSCALL_64_fastpath+0x17/0x98
[  649.836422] RIP: 0033:0x7f8d5a841ee7
[  649.836432] RSP: 002b:7fff89161a28 EFLAGS: 0206 ORIG_RAX: 
00b0
[  649.836448] RAX: ffda RBX: 55f6cd1db5c0 RCX: 7f8d5a841ee7
[  649.836458] RDX:  RSI: 0800 RDI: 55f6cd1da7b8
[  649.836467] RBP: 7f8d5aaee440 R08:  R09: 7fff89161a58
[  649.836476] R10: 0062 R11: 0206 R12: 
[  649.836486] R13: 55f6cd1d9010 R14: 003a R15: 7fff891609f0
[  649.836514] ---[ end trace 0e529da316e2a3d1 ]---
[  649.836536] [drm:drm_mode_config_cleanup [drm]] *ERROR* connector VGA-1 
leaked!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_display.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b44e9466d394..801ff845a2f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17301,10 +17301,18 @@ void intel_connector_unregister(struct drm_connector 
*connector)
 void intel_modeset_cleanup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_connector *connector;
 
flush_work(_priv->atomic_helper.free_work);
WARN_ON(!llist_empty(_priv->atomic_helper.free_list));
 
+   for_each_intel_connector(dev, connector) {
+   if (connector->base.state->crtc) {
+   drm_connector_unreference(>base);
+   connector->base.state->crtc = NULL;
+   }
+   }
+
intel_disable_gt_powersave(dev_priv);
 
/*
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Pandiyan, Dhinakaran
On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
> 
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 131 
> +++-
>  include/drm/drm_connector.h |  24 
>  include/drm/drm_edid.h  |   6 +-
>  3 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 37902e5..f0d940a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define version_greater(edid, maj, min) \
>   (((edid)->version > (maj)) || \
> @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi_info;
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340M.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> +  * * SCDC support available
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + display->max_tmds_clock = hf_vsdb[5] * 5000;

Comment explaining or quoting where the 5000 comes from?

> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> +
> + if (hdmi->scdc_supported) {
> + hdmi->scr_info.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + hdmi->scr_info.low_clocks = true;
> + }
> + }
> +}
> +
> +/**
> + * drm_check_scrambling_status - what is status of scrambling?
> + * @adapter: i2c adapter for SCDC channel
> + *
> + * Read the scrambler status over SCDC channel, and check the
> + * scrambling status.
> + *
> + * Return: True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_check_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status;
> +
> + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
> + DRM_ERROR("Failed to read scrambling status\n");
> + return false;
> + }
> +
> + status &= SCDC_SCRAMBLING_STATUS;
> + return status != 0;
> +}
> +
> +/**
> + * drm_enable_scrambling - enable scrambling
> + * @connector: target drm_connector
> + * @adapter: i2c adapter for SCDC channel
> + * @force: enable scrambling, even if its already enabled
> + *
> + * Write the TMDS config over SCDC channel, and enable scrambling
> + * Return: True if scrambling is successfully enabled, false otherwise.
> + */
> +
> +bool drm_enable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)
> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if (hdmi_info->scr_info.status && !force) {
> + DRM_DEBUG_KMS("Scrambling already enabled\n");
> + return true;
> + }
> +
> + if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
> + DRM_ERROR("Failed to read tmds config\n");
> + return false;
> + }
> +
> + config |= SCDC_SCRAMBLING_ENABLE;
> +
> + if (drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config) < 0) {
> + DRM_ERROR("Failed to enable scrambling, write error\n");
> + return false;
> + }
> +
> + hdmi_info->scr_info.status = drm_check_scrambling_status(adapter);
> + return hdmi_info->scr_info.status;
> +}
> +
> +/**
> + * drm_disable_scrambling - disable scrambling
> + * @connector: target drm_connector
> + * @adapter: i2c adapter for SCDC channel
> + * @force: disable scrambling, even if its already disabled
> + *
> + * Write the TMDS config over SCDC channel, and disable scrambling
> + * Return: True if scrambling is successfully disabled, false otherwise.
> + */
> +bool drm_disable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)
> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if 

Re: [Intel-gfx] [PATCH v1½ 00/13] drm/i915/dp: link rate and lane count refactoring

2017-02-01 Thread Manasi Navare
Are you planning on submitting a v2 for these pretty soon
that can make it to patchwork/

Regards
Manasi

On Thu, Jan 26, 2017 at 09:44:14PM +0200, Jani Nikula wrote:
> This is kind of version 1½ of [1], basically just rebased on current git
> (including Manasi's test automation patches) and a couple of more
> cleanups slammed on top.
> 
> BR,
> Jani.
> 
> 
> [1] cover.1485015599.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1485015599.git.jani.nikula@intel.com
> 
> 
> Jani Nikula (13):
>   drm/i915/dp: use known correct array size in rate_to_index
>   drm/i915/dp: return errors from rate_to_index()
>   drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse
>   drm/i915/dp: cache source rates at init
>   drm/i915/dp: generate and cache sink rate array for all DP, not just
> eDP 1.4
>   drm/i915/dp: use the sink rates array for max sink rates
>   drm/i915/dp: cache common rates with sink rates
>   drm/i915/dp: do not limit rate seek when not needed
>   drm/i915/dp: don't call the link parameters sink parameters
>   drm/i915/dp: add functions for max common link rate and lane count
>   drm/i915/mst: use max link not sink lane count
>   drm/i915/dp: localize link rate index variable more
>   drm/i915/dp: use readb and writeb calls for single byte DPCD access
> 
>  drivers/gpu/drm/i915/intel_dp.c   | 275 
> ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c |   3 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  19 +-
>  4 files changed, 166 insertions(+), 135 deletions(-)
> 
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v1½ 00/13] drm/i915/dp: link rate and lane count refactoring

2017-02-01 Thread Pandiyan, Dhinakaran
On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> This is kind of version 1½ of [1], basically just rebased on current git

Looks like this version didn't make it into patchwork.

-DK

> (including Manasi's test automation patches) and a couple of more
> cleanups slammed on top.
> 
> BR,
> Jani.
> 
> 
> [1] cover.1485015599.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1485015599.git.jani.nikula@intel.com
> 
> 
> Jani Nikula (13):
>   drm/i915/dp: use known correct array size in rate_to_index
>   drm/i915/dp: return errors from rate_to_index()
>   drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse
>   drm/i915/dp: cache source rates at init
>   drm/i915/dp: generate and cache sink rate array for all DP, not just
> eDP 1.4
>   drm/i915/dp: use the sink rates array for max sink rates
>   drm/i915/dp: cache common rates with sink rates
>   drm/i915/dp: do not limit rate seek when not needed
>   drm/i915/dp: don't call the link parameters sink parameters
>   drm/i915/dp: add functions for max common link rate and lane count
>   drm/i915/mst: use max link not sink lane count
>   drm/i915/dp: localize link rate index variable more
>   drm/i915/dp: use readb and writeb calls for single byte DPCD access
> 
>  drivers/gpu/drm/i915/intel_dp.c   | 275 
> ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c |   3 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  19 +-
>  4 files changed, 166 insertions(+), 135 deletions(-)
> 

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


[Intel-gfx] [PATCH i-g-t v5 02/10] lib/igt_kms: move igt_kms_get_alt_edid() to the right place

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 4ba6316d..41acce45 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -157,23 +157,6 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"
 
-/**
- * igt_kms_get_alt_edid:
- *
- * Get an alternate edid block, which includes the following modes:
- *
- *  - 1400x1050 60Hz
- *  - 1920x1080 60Hz
- *  - 1280x720 60Hz
- *  - 1024x768 60Hz
- *  - 800x600 60Hz
- *  - 640x480 60Hz
- *
- * This can be extended with further features using functions such as
- * #kmstest_edid_add_3d.
- *
- * Returns: an alternate edid block
- */
 static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
@@ -301,6 +284,23 @@ igt_atomic_fill_pipe_props(igt_display_t *display, 
igt_pipe_t *pipe,
drmModeFreeObjectProperties(props);
 }
 
+/**
+ * igt_kms_get_alt_edid:
+ *
+ * Get an alternate edid block, which includes the following modes:
+ *
+ *  - 1400x1050 60Hz
+ *  - 1920x1080 60Hz
+ *  - 1280x720 60Hz
+ *  - 1024x768 60Hz
+ *  - 800x600 60Hz
+ *  - 640x480 60Hz
+ *
+ * This can be extended with further features using functions such as
+ * #kmstest_edid_add_3d.
+ *
+ * Returns: an alternate edid block
+ */
 const unsigned char* igt_kms_get_alt_edid(void)
 {
update_edid_csum(alt_edid);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 04/10] tests/kms_atomic: use global atomic properties definitions

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 tests/kms_atomic.c | 123 -
 1 file changed, 37 insertions(+), 86 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index e6d71c31..8df51ccd 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -105,55 +105,6 @@ static const char 
*plane_type_prop_names[NUM_PLANE_TYPE_PROPS] = {
"Cursor"
 };
 
-enum plane_properties {
-   PLANE_SRC_X = 0,
-   PLANE_SRC_Y,
-   PLANE_SRC_W,
-   PLANE_SRC_H,
-   PLANE_CRTC_X,
-   PLANE_CRTC_Y,
-   PLANE_CRTC_W,
-   PLANE_CRTC_H,
-   PLANE_FB_ID,
-   PLANE_CRTC_ID,
-   PLANE_TYPE,
-   NUM_PLANE_PROPS
-};
-
-static const char *plane_prop_names[NUM_PLANE_PROPS] = {
-   "SRC_X",
-   "SRC_Y",
-   "SRC_W",
-   "SRC_H",
-   "CRTC_X",
-   "CRTC_Y",
-   "CRTC_W",
-   "CRTC_H",
-   "FB_ID",
-   "CRTC_ID",
-   "type"
-};
-
-enum crtc_properties {
-   CRTC_MODE_ID = 0,
-   CRTC_ACTIVE,
-   NUM_CRTC_PROPS
-};
-
-static const char *crtc_prop_names[NUM_CRTC_PROPS] = {
-   "MODE_ID",
-   "ACTIVE"
-};
-
-enum connector_properties {
-   CONNECTOR_CRTC_ID = 0,
-   NUM_CONNECTOR_PROPS
-};
-
-static const char *connector_prop_names[NUM_CONNECTOR_PROPS] = {
-   "CRTC_ID"
-};
-
 struct kms_atomic_blob {
uint32_t id; /* 0 if not already allocated */
size_t len;
@@ -197,9 +148,9 @@ struct kms_atomic_state {
 
 struct kms_atomic_desc {
int fd;
-   uint32_t props_connector[NUM_CONNECTOR_PROPS];
-   uint32_t props_crtc[NUM_CRTC_PROPS];
-   uint32_t props_plane[NUM_PLANE_PROPS];
+   uint32_t props_connector[IGT_NUM_CONNECTOR_PROPS];
+   uint32_t props_crtc[IGT_NUM_CRTC_PROPS];
+   uint32_t props_plane[IGT_NUM_PLANE_PROPS];
uint64_t props_plane_type[NUM_PLANE_TYPE_PROPS];
 };
 
@@ -280,7 +231,7 @@ connector_get_current_state(struct 
kms_atomic_connector_state *connector)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = connector->state->desc->props_connector;
 
-   if (props->props[i] == prop_ids[CONNECTOR_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_CONNECTOR_CRTC_ID])
connector->crtc_id = props->prop_values[i];
}
drmModeFreeObjectProperties(props);
@@ -348,16 +299,16 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
-   plane_set_prop(req, plane, PLANE_CRTC_ID, plane->crtc_id);
-   plane_set_prop(req, plane, PLANE_FB_ID, plane->fb_id);
-   plane_set_prop(req, plane, PLANE_SRC_X, plane->src_x);
-   plane_set_prop(req, plane, PLANE_SRC_Y, plane->src_y);
-   plane_set_prop(req, plane, PLANE_SRC_W, plane->src_w);
-   plane_set_prop(req, plane, PLANE_SRC_H, plane->src_h);
-   plane_set_prop(req, plane, PLANE_CRTC_X, plane->crtc_x);
-   plane_set_prop(req, plane, PLANE_CRTC_Y, plane->crtc_y);
-   plane_set_prop(req, plane, PLANE_CRTC_W, plane->crtc_w);
-   plane_set_prop(req, plane, PLANE_CRTC_H, plane->crtc_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
+   plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_Y, plane->src_y);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_W, plane->src_w);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_H, plane->src_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_X, plane->crtc_x);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_Y, plane->crtc_y);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_W, plane->crtc_w);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_H, plane->crtc_h);
 }
 
 static void plane_get_current_state(struct kms_atomic_plane_state *plane)
@@ -373,27 +324,27 @@ static void plane_get_current_state(struct 
kms_atomic_plane_state *plane)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = desc->props_plane;
 
-   if (props->props[i] == prop_ids[PLANE_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_PLANE_CRTC_ID])
plane->crtc_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_FB_ID])
+   else if (props->props[i] == prop_ids[IGT_PLANE_FB_ID])
plane->fb_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_CRTC_X])
+   else if (props->props[i] == prop_ids[IGT_PLANE_CRTC_X])
plane->crtc_x = props->prop_values[i];
-   

[Intel-gfx] [PATCH i-g-t v5 10/10] tests/kms_atomic_transition: add in_fences tests

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c |  6 ++
 tests/kms_atomic_transition.c | 19 ++-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7227ebca..8cd91f1e 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2475,6 +2475,12 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
 
for_each_pipe(display, pipe) {
igt_pipe_t *pipe_obj = >pipes[pipe];
+   igt_plane_t *plane;
+
+   /* reset fence_fd to prevent it from being set for the 
next commit */
+   for_each_plane_on_pipe(display, pipe, plane) {
+   igt_plane_set_fence_fd(plane, -1);
+   }
 
if (pipe_obj->out_fence_fd == -1)
continue;
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 4b1278a4..f284cce9 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -612,7 +612,7 @@ static void collect_crcs_mask(igt_pipe_crc_t **pipe_crcs, 
unsigned mask, igt_crc
}
 }
 
-static void run_modeset_tests(igt_display_t *display, int howmany, bool 
nonblocking)
+static void run_modeset_tests(igt_display_t *display, int howmany, bool 
nonblocking, bool fencing)
 {
struct igt_fb fbs[2];
int i, j;
@@ -659,6 +659,9 @@ static void run_modeset_tests(igt_display_t *display, int 
howmany, bool nonblock
igt_plane_set_size(plane, mode->hdisplay, 
mode->vdisplay);
} else
igt_plane_set_fb(plane, NULL);
+
+   if(fencing)
+   igt_pipe_request_out_fence(>pipes[i]);
}
 
/*
@@ -746,7 +749,7 @@ cleanup:
 
 }
 
-static void run_modeset_transition(igt_display_t *display, int 
requested_outputs, bool nonblocking)
+static void run_modeset_transition(igt_display_t *display, int 
requested_outputs, bool nonblocking, bool fencing)
 {
igt_output_t *outputs[I915_MAX_PIPES] = {};
int num_outputs = 0;
@@ -774,7 +777,7 @@ static void run_modeset_transition(igt_display_t *display, 
int requested_outputs
  "Should have at least %i outputs, found %i\n",
  requested_outputs, num_outputs);
 
-   run_modeset_tests(display, requested_outputs, nonblocking);
+   run_modeset_tests(display, requested_outputs, nonblocking, fencing);
 }
 
 igt_main
@@ -833,10 +836,16 @@ igt_main
 
for (i = 1; i <= I915_MAX_PIPES; i++) {
igt_subtest_f("%ix-modeset-transitions", i)
-   run_modeset_transition(, i, false);
+   run_modeset_transition(, i, false, false);
 
igt_subtest_f("%ix-modeset-transitions-nonblocking", i)
-   run_modeset_transition(, i, true);
+   run_modeset_transition(, i, true, false);
+
+   igt_subtest_f("%ix-modeset-transitions-fencing", i)
+   run_modeset_transition(, i, false, true);
+
+   igt_subtest_f("%ix-modeset-transitions-nonblocking-fencing", i)
+   run_modeset_transition(, i, true, true);
}
 
igt_fixture {
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 09/10] tests/kms_atomic_transition: add out_fences tests

2017-02-01 Thread Robert Foss
Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c |  17 +
 tests/kms_atomic_transition.c | 153 --
 2 files changed, 165 insertions(+), 5 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index fbd08515..7227ebca 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
 #include "intel_chipset.h"
 #include "igt_debugfs.h"
 #include "igt_sysfs.h"
+#include "sw_sync.h"
 
 /**
  * SECTION:igt_kms
@@ -2470,6 +2471,22 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
}
 
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   if (!ret) {
+
+   for_each_pipe(display, pipe) {
+   igt_pipe_t *pipe_obj = >pipes[pipe];
+
+   if (pipe_obj->out_fence_fd == -1)
+   continue;
+
+   igt_assert(pipe_obj->out_fence_fd >= 0);
+   ret = sync_fence_wait(pipe_obj->out_fence_fd, 1000);
+   igt_assert(ret == 0);
+   close(pipe_obj->out_fence_fd);
+   pipe_obj->out_fence_fd = -1;
+   }
+   }
+
drmModeAtomicFree(req);
return ret;
 
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 72429759..4b1278a4 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@
 
 #include "igt.h"
 #include "drmtest.h"
+#include "sw_sync.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -253,6 +255,94 @@ retry:
 sprite_width, sprite_height, alpha);
 }
 
+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int n_planes;
+
+   igt_require_sw_sync();
+
+   n_planes = display->pipes[pipe].n_planes;
+   timeline = calloc(sizeof(*timeline), n_planes);
+   igt_assert_f(timeline != NULL, "Failed to allocate memory for 
timelines\n");
+   thread = calloc(sizeof(*thread), n_planes);
+   igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n");
+   seqno = calloc(sizeof(*seqno), n_planes);
+   igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n");
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   close(timeline[plane->index]);
+
+   free(timeline);
+   free(thread);
+   free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+   int t = *((int *) arg);
+
+   pthread_detach(pthread_self());
+
+   usleep(5000);
+   sw_sync_timeline_inc(t, 1);
+   return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int i, fd, ret;
+
+   for_each_plane_on_pipe(display, pipe, plane) {
+
+   if (!plane->fb)
+   continue;
+
+   i = plane->index;
+
+   seqno[i]++;
+   fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+   igt_plane_set_fence_fd(plane, fd);
+   close(fd);
+   ret = pthread_create([i], NULL, fence_inc_thread, 
[i]);
+   igt_assert_eq(ret, 0);
+   }
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   igt_plane_set_fence_fd(plane, -1);
+}
+
+static void atomic_commit(igt_display_t *display, enum pipe pipe, unsigned int 
flags, void *data, bool fencing)
+{
+   if (fencing) {
+   configure_fencing(display, pipe);
+   igt_pipe_request_out_fence(>pipes[pipe]);
+   }
+
+   igt_display_commit_atomic(display, flags, data);
+
+   if (fencing)
+   clear_fencing(display, pipe);
+}
+
 /*
  * 1. Set primary plane to a known fb.
  * 2. Make sure getcrtc returns the correct fb id.
@@ -273,6 +363,10 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
struct plane_parms parms[display->pipes[pipe].n_planes];
bool skip_test = false;
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
+   int ret;
+
+   if (fencing)
+   prepare_fencing(display, pipe);
 
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;
@@ -307,12 +401,48 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
 
setup_parms(display, pipe, mode, _fb, _fb, parms);
 
+   /*
+* In some 

[Intel-gfx] [PATCH i-g-t v5 08/10] tests/kms_atomic_transition: add fencing parameter to run_transition_tests

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 tests/kms_atomic_transition.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 095af515..72429759 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -264,7 +264,7 @@ retry:
  */
 static void
 run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t 
*output,
-   enum transition_type type, bool nonblocking)
+   enum transition_type type, bool nonblocking, bool fencing)
 {
struct igt_fb fb, argb_fb, sprite_fb;
drmModeModeInfo *mode, override_mode;
@@ -674,19 +674,19 @@ igt_main
 
igt_subtest("plane-all-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false, false);
 
igt_subtest("plane-all-transition-nonblocking")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true, false);
 
igt_subtest("plane-all-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false, false);
 
igt_subtest("plane-toggle-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false, false);
 
for (i = 1; i <= I915_MAX_PIPES; i++) {
igt_subtest_f("%ix-modeset-transitions", i)
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 00/10] tests/kms_atomic_transition add fence testing

2017-02-01 Thread Robert Foss
This series adds in/out fence testing to kms_atomic_transition test and makes 
some minor cleanups.

This series can be found here:
https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER


Changes since v4:
  Rebased on upstream/master
  Added Reviewed-by: Brian Starkey   to all patches

  lib/igt_kms: Added igt_pipe_get_last_out_fence()
   - Removed this patch

  lib/igt_kms: Add support for the IN_FENCE_FD property
   - Fixed typo in commit message

  lib/igt_kms:
   - Fixed description for igt_pipe_request_out_fence()
   - Set pipe_obj->out_fence_fd to -1 after close() in igt_atomic_commit()
   - Moved early igt_plane_set_fence_fd(plane, -1) call to igt_atomic_commit()


Changes since v3:
  Rebased on upstream/master

  lib/igt_kms:
   - Change out_fence from int64_t to int32_t
   - Fixed build error halfway in the series
   - Change IN_FENCE_FD to be an int always
   - Change name of out_fence to out_fence_fd
   - Removed useless assert
   - Fixed erroneous fence_fd check in igt_atomic_commit()
   - Implemented igt_plane_set_fence_fd FD close logic
   - Properly close fd in igt_atomic_prepare_plane_commit()

  tests/kms_atomic:
   - Changed type of out_fence_ptr to int32_t

  tests/kms_atomic_transition:
   - Fixed indentation errors in prepare_fencing()
   - Added close() to callers of igt_plane_set_fence_fd with valid FDs
   - Move change atomic_commit to earlier commit to remove inter commit changes


Changes since v2:
  Rebased on upstream/master

  lib/igt_kms:
- Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit()
- Rework out_fencs_ptr to be an int64_t named out_fence
- Add igt_pipe_request_out_fence()

  tests/:
- Switch to using igt_pipe_request_out_fence()
- Close out_fence fd
- Change out_fence to int64_t in run_transition_test()
- Added comments noting that two testcases are not invalid
- Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out


Changes since v1:

  lib/igt_kms:
   - Added gtk-doc for exported symbols
   - Changed integer casting to avoid potential issues
   - Changed out_fence_ptr type to int64_t*
   - Fixed igt_plane_set_fence_fd comment

  tests/:
   - Rework timeout change in commit_display()
   - Extract plane_invalid_params_fence() out plane_invalid_params()
   - Extract crtc_invalid_params_fence() out crtc_invalid_params()
   - Prevent add igt_require_sw_sync to subtests using sw_sync



Gustavo Padovan (8):
  tests/kms_atomic_transition: use igt timeout instead of blocking
  lib/igt_kms: move igt_kms_get_alt_edid() to the right place
  lib/igt_kms: export properties names
  tests/kms_atomic: use global atomic properties definitions
  lib/igt_kms: Add support for the OUT_FENCE_PTR property
  tests/kms_atomic: stress possible fence settings
  tests/kms_atomic_transition: add fencing parameter to
run_transition_tests
  tests/kms_atomic_transition: add in_fences tests

Robert Foss (2):
  lib/igt_kms: Add support for the IN_FENCE_FD property
  tests/kms_atomic_transition: add out_fences tests

 lib/igt_kms.c | 111 ---
 lib/igt_kms.h |  34 -
 tests/kms_atomic.c| 310 +-
 tests/kms_atomic_transition.c | 184 +++--
 4 files changed, 506 insertions(+), 133 deletions(-)

-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 01/10] tests/kms_atomic_transition: use igt timeout instead of blocking

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

If the event never arrives we can timeout and end the test.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 tests/kms_atomic_transition.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 5fdb6175..095af515 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -383,7 +383,9 @@ static void commit_display(igt_display_t *display, unsigned 
event_mask, bool non
struct drm_event_vblank *vblank = (void *)buf;
uint32_t crtc_id, pipe = I915_MAX_PIPES;
 
+   igt_set_timeout(3, "Timed out while reading drm_fd\n");
ret = read(display->drm_fd, buf, sizeof(buf));
+   igt_reset_timeout();
if (ret < 0 && (errno == EINTR || errno == EAGAIN))
continue;
 
-- 
2.11.0.453.g787f75f05

___
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/chamelium: Adapt to dynamic number of planes changes

2017-02-01 Thread Lyude Paul
Reviewed-by: Lyude 

If you need someone to push this let me know

On Wed, 2017-02-01 at 12:56 +0200, Petri Latvala wrote:
> CC: Robert Foss 
> CC: Lyude 
> Signed-off-by: Petri Latvala 
> ---
>  tests/chamelium.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/chamelium.c b/tests/chamelium.c
> index d914d5b..e03acc4 100644
> --- a/tests/chamelium.c
> +++ b/tests/chamelium.c
> @@ -310,7 +310,7 @@ enable_output(data_t *data,
>     struct igt_fb *fb)
>  {
>   igt_display_t *display = output->display;
> - igt_plane_t *primary = igt_output_get_plane(output,
> IGT_PLANE_PRIMARY);
> + igt_plane_t *primary = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
>   drmModeConnector *connector = chamelium_port_get_connector(
>   data->chamelium, port, false);
>  
> @@ -341,7 +341,7 @@ disable_output(data_t *data,
>      igt_output_t *output)
>  {
>   igt_display_t *display = output->display;
> - igt_plane_t *primary = igt_output_get_plane(output,
> IGT_PLANE_PRIMARY);
> + igt_plane_t *primary = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
>   igt_assert(primary);
>  
>   /* Disable the display */
> @@ -364,7 +364,7 @@ test_display_crc_single(data_t *data, struct
> chamelium_port *port)
>  
>   output = prepare_output(data, , port);
>   connector = chamelium_port_get_connector(data->chamelium,
> port, false);
> - primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> + primary = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
>   igt_assert(primary);
>  
>   for (i = 0; i < connector->count_modes; i++) {
> @@ -418,7 +418,7 @@ test_display_crc_multiple(data_t *data, struct
> chamelium_port *port)
>  
>   output = prepare_output(data, , port);
>   connector = chamelium_port_get_connector(data->chamelium,
> port, false);
> - primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> + primary = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
>   igt_assert(primary);
>  
>   for (i = 0; i < connector->count_modes; i++) {
> @@ -477,7 +477,7 @@ test_display_frame_dump(data_t *data, struct
> chamelium_port *port)
>  
>   output = prepare_output(data, , port);
>   connector = chamelium_port_get_connector(data->chamelium,
> port, false);
> - primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> + primary = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
>   igt_assert(primary);
>  
>   for (i = 0; i < connector->count_modes; i++) {
-- 
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t v5 07/10] tests/kms_atomic: stress possible fence settings

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 tests/kms_atomic.c | 187 ++---
 1 file changed, 177 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..e794a62b 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
 #include "drmtest.h"
 #include "igt.h"
 #include "igt_aux.h"
+#include "sw_sync.h"
 
 #ifndef DRM_CLIENT_CAP_ATOMIC
 #define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+   int32_t fence_fd;
 };
 
 struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+   int32_t *out_fence_ptr;
struct kms_atomic_blob mode;
 };
 
@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-   crtc_check_current_state(crtc, plane, relax); \
-   plane_check_current_state(plane, relax); \
+   if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+   crtc_check_current_state(crtc, plane, relax); \
+   plane_check_current_state(plane, relax); \
+   } \
 }
 
-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, 
e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, 
relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
+   if (plane->fence_fd)
+   plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, 
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type 
type,
 static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
  drmModeAtomicReq *req)
 {
+   if (crtc->out_fence_ptr)
+   crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ (uint64_t) crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
 }
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct 
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
 }
 
+static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc,
+   struct kms_atomic_plane_state *plane_old,
+   struct kms_atomic_connector_state *conn)
+{
+   struct kms_atomic_plane_state plane = *plane_old;
+   drmModeAtomicReq *req = drmModeAtomicAlloc();
+   int timeline, fence_fd;
+
+   igt_require_sw_sync();
+
+   /* invalid fence fd */
+   plane.fence_fd = plane.state->desc->fd;
+   plane.crtc_id = plane_old->crtc_id;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   /* Valid fence_fd but invalid CRTC */
+   timeline = sw_sync_timeline_create();
+   fence_fd =  sw_sync_timeline_create_fence(timeline, 1);
+   plane.fence_fd = fence_fd;
+   plane.crtc_id = ~0U;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   plane.fence_fd = -1;
+   close(fence_fd);
+   close(timeline);
+
+   drmModeAtomicFree(req);
+}
+
 static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
 
/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);
 
crtc.mode.id = crtc.obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,

[Intel-gfx] [PATCH i-g-t v5 05/10] lib/igt_kms: Add support for the IN_FENCE_FD property

2017-02-01 Thread Robert Foss
Add support for the IN_FENCE_FD property to enable setting in fences for atomic
commits.

Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c | 25 +
 lib/igt_kms.h |  5 +
 2 files changed, 30 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 142658a6..9b60d74a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+   "IN_FENCE_FD",
"type",
"rotation"
 };
@@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane->type = type;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+   plane->fence_fd = -1;
 
if (is_atomic == 0) {
display->is_atomic = 1;
@@ -1994,6 +1996,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_pipe_t *pipe,
plane->index,
fb_id);
 
+   if (plane->fence_fd >= 0) {
+   uint64_t fence_fd = (int64_t) plane->fence_fd;
+   igt_atomic_populate_plane_req(req, plane, 
IGT_PLANE_IN_FENCE_FD, fence_fd);
+   }
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
@@ -2815,6 +2822,24 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->size_changed = true;
 }
 
+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd)
+{
+   close(plane->fence_fd);
+
+   if (fcntl(fence_fd, F_GETFD) != -1)
+   plane->fence_fd = dup(fence_fd);
+   else
+   plane->fence_fd = -1;
+}
+
 void igt_plane_set_position(igt_plane_t *plane, int x, int y)
 {
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 00e0dc68..8acad8ef 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -248,6 +248,7 @@ enum igt_atomic_plane_properties {
 
IGT_PLANE_FB_ID,
IGT_PLANE_CRTC_ID,
+   IGT_PLANE_IN_FENCE_FD,
IGT_PLANE_TYPE,
IGT_PLANE_ROTATION,
IGT_NUM_PLANE_PROPS
@@ -306,6 +307,9 @@ typedef struct {
uint32_t src_h;
 
igt_rotation_t rotation;
+
+   /* in fence fd */
+   int fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
 } igt_plane_t;
 
@@ -396,6 +400,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, 
size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
 
 void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd);
 void igt_plane_set_position(igt_plane_t *plane, int x, int y);
 void igt_plane_set_size(igt_plane_t *plane, int w, int h);
 void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 03/10] lib/igt_kms: export properties names

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c |  6 +++---
 lib/igt_kms.h | 23 +++
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 41acce45..142658a6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -157,7 +157,7 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"
 
-static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
"SRC_W",
@@ -172,7 +172,7 @@ static const char 
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"rotation"
 };
 
-static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"background_color",
"CTM",
"DEGAMMA_LUT",
@@ -181,7 +181,7 @@ static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] 
= {
"ACTIVE"
 };
 
-static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
"CRTC_ID"
 };
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 25626187..00e0dc68 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -97,12 +97,28 @@ enum igt_atomic_crtc_properties {
IGT_NUM_CRTC_PROPS
 };
 
+/**
+ * igt_crtc_prop_names
+ *
+ * igt_crtc_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_crtc_properties enum.
+ */
+extern const char *igt_crtc_prop_names[];
+
 enum igt_atomic_connector_properties {
IGT_CONNECTOR_SCALING_MODE = 0,
IGT_CONNECTOR_CRTC_ID,
IGT_NUM_CONNECTOR_PROPS
 };
 
+/**
+ * igt_connector_prop_names
+ *
+ * igt_connector_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_connector_properties enum.
+ */
+extern const char *igt_connector_prop_names[];
+
 struct kmstest_connector_config {
drmModeCrtc *crtc;
drmModeConnector *connector;
@@ -237,6 +253,13 @@ enum igt_atomic_plane_properties {
IGT_NUM_PLANE_PROPS
 };
 
+/**
+ * igt_plane_prop_names
+ *
+ * igt_plane_prop_names contains a list of crtc property names,
+ * as indexed by the igt_atomic_plane_properties enum.
+ */
+extern const char *igt_plane_prop_names[];
 
 typedef struct igt_display igt_display_t;
 typedef struct igt_pipe igt_pipe_t;
-- 
2.11.0.453.g787f75f05

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


[Intel-gfx] [PATCH i-g-t v5 06/10] lib/igt_kms: Add support for the OUT_FENCE_PTR property

2017-02-01 Thread Robert Foss
From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
Reviewed-by: Brian Starkey 
---
 lib/igt_kms.c | 23 ++-
 lib/igt_kms.h |  6 +-
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9b60d74a..fbd08515 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-   "ACTIVE"
+   "ACTIVE",
+   "OUT_FENCE_PTR"
 };
 
 const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2385,6 +2386,14 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t 
*pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, 
!!output);
}
 
+   pipe_obj->out_fence_fd = -1;
+   if (pipe_obj->out_fence_requested)
+   {
+   pipe_obj->out_fence_requested = false;
+   igt_atomic_populate_crtc_req(req, pipe_obj, 
IGT_CRTC_OUT_FENCE_PTR,
+   (uint64_t)(uintptr_t) _obj->out_fence_fd);
+   }
+
/*
 *  TODO: Add all crtc level properties here
 */
@@ -2959,6 +2968,18 @@ void igt_plane_set_rotation(igt_plane_t *plane, 
igt_rotation_t rotation)
plane->rotation_changed = true;
 }
 
+/**
+ * igt_pipe_request_out_fence:
+ * @pipe: pipe which out fence will be requested for
+ *
+ * Marks this pipe for requesting an out fence at the next atomic commit
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_request_out_fence(igt_pipe_t *pipe)
+{
+   pipe->out_fence_requested = true;
+}
+
 void
 igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
 {
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8acad8ef..6754d00e 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
IGT_CRTC_GAMMA_LUT,
IGT_CRTC_MODE_ID,
IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
IGT_NUM_CRTC_PROPS
 };
 
@@ -341,6 +342,9 @@ struct igt_pipe {
 
uint64_t mode_blob;
bool mode_changed;
+
+   int32_t out_fence_fd;
+   bool out_fence_requested;
 };
 
 typedef struct {
@@ -394,7 +398,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t 
*plane)
 {
return plane->rotation_property != 0;
 }
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);
 void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
-- 
2.11.0.453.g787f75f05

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


Re: [Intel-gfx] [PATCH i-g-t v4 00/11] tests/kms_atomic_transition add fence testing

2017-02-01 Thread Robert Foss

On 2017-02-01 05:44 AM, Brian Starkey wrote:

Hi Robert,

Some minor comments on 5, 6, 9, 10 and 11. With those addressed, the
whole series is:

Reviewed-by: Brian Starkey 

Thanks!
-Brian


Thanks for the review Brian!

I'll submit v5 and let it soak for a little while before pushing it 
upstream.



Rob.



P.S. Immediately after hitting send I realised I should have trimmed
that blob from my reply. Sorry for bouncing that back to everyone!

On Tue, Jan 31, 2017 at 08:25:09PM -0500, Robert Foss wrote:

This series adds in/out fence testing to kms_atomic_transition test
and makes some minor cleanups.

This series can be found here:
https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER



Changes since v3:
 Rebased on upstream/master

 lib/igt_kms:
  - Change out_fence from int64_t to int32_t
  - Fixed build error halfway in the series
  - Change IN_FENCE_FD to be an int always
  - Change name of out_fence to out_fence_fd
  - Removed useless assert
  - Fixed erroneous fence_fd check in igt_atomic_commit()
  - Implemented igt_plane_set_fence_fd FD close logic
  - Properly close fd in igt_atomic_prepare_plane_commit()

 tests/kms_atomic:
  - Changed type of out_fence_ptr to int32_t

 tests/kms_atomic_transition:
  - Fixed indentation errors in prepare_fencing()
  - Added close() to callers of igt_plane_set_fence_fd with valid FDs
  - Move change atomic_commit to earlier commit to remove inter commit
changes


Changes since v2:
 Rebased on upstream/master

 lib/igt_kms:
   - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit()
   - Rework out_fencs_ptr to be an int64_t named out_fence
   - Add igt_pipe_request_out_fence()

 tests/:
   - Switch to using igt_pipe_request_out_fence()
   - Close out_fence fd
   - Change out_fence to int64_t in run_transition_test()
   - Added comments noting that two testcases are not invalid
   - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out


Changes since v1:

 lib/igt_kms:
  - Added gtk-doc for exported symbols
  - Changed integer casting to avoid potential issues
  - Changed out_fence_ptr type to int64_t*
  - Fixed igt_plane_set_fence_fd comment

 tests/:
  - Rework timeout change in commit_display()
  - Extract plane_invalid_params_fence() out plane_invalid_params()
  - Extract crtc_invalid_params_fence() out crtc_invalid_params()
  - Prevent add igt_require_sw_sync to subtests using sw_sync



Gustavo Padovan (8):
 tests/kms_atomic_transition: use igt timeout instead of blocking
 lib/igt_kms: move igt_kms_get_alt_edid() to the right place
 lib/igt_kms: export properties names
 tests/kms_atomic: use global atomic properties definitions
 lib/igt_kms: Add support for the OUT_FENCE_PTR property
 tests/kms_atomic: stress possible fence settings
 tests/kms_atomic_transition: add fencing parameter to
   run_transition_tests
 tests/kms_atomic_transition: add in_fences tests

Robert Foss (3):
 lib/igt_kms: Add support for the IN_FENCE_FD property
 tests/kms_atomic_transition: add out_fences tests
 lib/igt_kms: Added igt_pipe_get_last_out_fence()

lib/igt_kms.c | 115 +---
lib/igt_kms.h |  35 -
tests/kms_atomic.c| 310
+-
tests/kms_atomic_transition.c | 184 +++--
tools/intel_vbt_decode| Bin 0 -> 384448 bytes
5 files changed, 511 insertions(+), 133 deletions(-)
create mode 100755 tools/intel_vbt_decode

--
2.11.0.453.g787f75f05


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


Re: [Intel-gfx] [PATCH igt] igt/perf: improve robustness of polling/blocking tests

2017-02-01 Thread Matthew Auld
On 24 January 2017 at 00:53, Robert Bragg  wrote:
> There were a couple of problems with both of these tests that could lead
> to false negatives addressed by this patch.
>
> 1) The upper limit for the number of iterations missed a +1 to consider
>that there might be a sample immediately available at the start of the
>loop.
>
> v2) The tests didn't consider that a duration measured in terms of
>(end-start) ticks could be +- 1 tick since we don't know the
>fractional part of the tick counts. Our threshold for stime being <
>one tick could have a false negative for any real stime between 1 to
>10 milliseconds depending on luck.
>
> The tests now both run for a lot longer (1000 x tick duration, or
> typically 10 seconds each) so that a single tick represents a much
> smaller proportion of the total duration (0.1%) and the stime thresholds
> are now set at 1% of the total duration.
>
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Generate i915_params {} using a macro

2017-02-01 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Generate i915_params {} using a 
macro
URL   : https://patchwork.freedesktop.org/series/18937/
State : warning

== Summary ==

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

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-snb-2520m)
Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:214  dwarn:2   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

8126864ab4eab95a09af5677535e8ccae3b6b73a drm-tip: 2017y-02m-01d-15h-25m-23s UTC 
integration manifest
e75210f drm/i915: Capture module parameters for the GPU error state
cb56c4f drm/i915: Generate i915_params {} using a macro

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3668/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 04:57:53PM +, Tvrtko Ursulin wrote:
> >+static bool wait_for_ready(struct igt_wakeup *w)
> >+{
> >+DEFINE_WAIT(ready);
> >+
> >+if (atomic_dec_and_test(w->done))
> >+wake_up_atomic_t(w->done);
> >+
> >+if (test_bit(STOP, >flags))
> >+goto out;
> >+
> >+set_bit(WAITING, >flags);
> >+for (;;) {
> >+prepare_to_wait(w->wq, , TASK_INTERRUPTIBLE);
> >+if (atomic_read(w->ready) == 0)
> >+break;
> >+
> >+schedule();
> >+}
> >+finish_wait(w->wq, );
> >+clear_bit(WAITING, >flags);
> >+
> >+out:
> >+if (atomic_dec_and_test(w->set))
> >+wake_up_atomic_t(w->set);
> >+
> >+return !test_bit(STOP, >flags);
> >+}



> >+atomic_set(, count);
> >+for (n = 0; n < count; n++) {
> >+waiters[n].wq = 
> >+waiters[n].ready = 
> >+waiters[n].set = 
> >+waiters[n].done = 
> >+waiters[n].engine = engine;
> >+waiters[n].flags = 0;
> >+
> >+waiters[n].tsk = kthread_run(igt_wakeup_thread, [n],
> >+ "i915/igt:%d", n);
> >+if (IS_ERR(waiters[n].tsk))
> >+goto out_waiters;
> >+
> >+get_task_struct(waiters[n].tsk);
> >+}
> >+
> >+for (step = 1; step <= max_seqno; step <<= 1) {
> >+u32 seqno;
> >+
> >+/* The waiter threads start paused as we assign them a random
> >+ * seqno and reset the engine. Once the engine is reset,
> >+ * we signal that the threads may begin their, and we wait
> >+ * until all threads are woken.
> >+ */
> >+for (n = 0; n < count; n++) {
> >+GEM_BUG_ON(!test_bit(WAITING, [n].flags));
> 
> Looks like a race condition between thread startup and checking this
> bit. I think the assert is just unnecessary.

I liked it for the document that we only update the waiters state and
reset the engine whilst the threads are idle. You're right about the
startup race, but we can start with the flag set. Maybe s/WAITING/IDLE/
to try and avoid reusing "wait" too often.
-Chris

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


Re: [Intel-gfx] [PATCH v3] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

2017-02-01 Thread Tvrtko Ursulin


On 01/02/2017 13:19, Chris Wilson wrote:

Third retroactive test, make sure that the seqno waiters are woken.

v2: Smattering of comments, rearrange code

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 202 +
 1 file changed, 202 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
index 245e5f1b8373..907503901644 100644
--- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
@@ -263,11 +263,213 @@ static int igt_insert_complete(void *arg)
return err;
 }

+struct igt_wakeup {
+   struct task_struct *tsk;
+   atomic_t *ready, *set, *done;
+   struct intel_engine_cs *engine;
+   unsigned long flags;
+#define STOP 0
+#define WAITING 1
+   wait_queue_head_t *wq;
+   u32 seqno;
+};
+
+static int wait_atomic(atomic_t *p)
+{
+   schedule();
+   return 0;
+}
+
+static int wait_atomic_timeout(atomic_t *p)
+{
+   return schedule_timeout(10 * HZ) ? 0 : -ETIMEDOUT;
+}
+
+static bool wait_for_ready(struct igt_wakeup *w)
+{
+   DEFINE_WAIT(ready);
+
+   if (atomic_dec_and_test(w->done))
+   wake_up_atomic_t(w->done);
+
+   if (test_bit(STOP, >flags))
+   goto out;
+
+   set_bit(WAITING, >flags);
+   for (;;) {
+   prepare_to_wait(w->wq, , TASK_INTERRUPTIBLE);
+   if (atomic_read(w->ready) == 0)
+   break;
+
+   schedule();
+   }
+   finish_wait(w->wq, );
+   clear_bit(WAITING, >flags);
+
+out:
+   if (atomic_dec_and_test(w->set))
+   wake_up_atomic_t(w->set);
+
+   return !test_bit(STOP, >flags);
+}
+
+static int igt_wakeup_thread(void *arg)
+{
+   struct igt_wakeup *w = arg;
+   struct intel_wait wait;
+
+   while (wait_for_ready(w)) {
+   GEM_BUG_ON(kthread_should_stop());
+
+   intel_wait_init(, w->seqno);
+   intel_engine_add_wait(w->engine, );
+   for (;;) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   if (i915_seqno_passed(intel_engine_get_seqno(w->engine),
+ w->seqno))
+   break;
+
+   if (test_bit(STOP, >flags)) /* emergency escape */
+   break;
+
+   schedule();
+   }
+   intel_engine_remove_wait(w->engine, );
+   __set_current_state(TASK_RUNNING);
+   }
+
+   return 0;
+}
+
+static void igt_wake_all_sync(atomic_t *ready,
+ atomic_t *set,
+ atomic_t *done,
+ wait_queue_head_t *wq,
+ int count)
+{
+   atomic_set(set, count);
+   atomic_set(done, count);
+
+   atomic_set(ready, 0);
+   wake_up_all(wq);
+
+   wait_on_atomic_t(set, wait_atomic, TASK_UNINTERRUPTIBLE);
+   atomic_set(ready, count);
+}
+
+static int igt_wakeup(void *arg)
+{
+   I915_RND_STATE(prng);
+   const int state = TASK_UNINTERRUPTIBLE;
+   struct intel_engine_cs *engine = arg;
+   struct igt_wakeup *waiters;
+   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
+   const int count = 4096;
+   const u32 max_seqno = count / 4;
+   atomic_t ready, set, done;
+   int err = -ENOMEM;
+   int n, step;
+
+   mock_engine_reset(engine);
+
+   waiters = drm_malloc_gfp(count, sizeof(*waiters), GFP_TEMPORARY);
+   if (!waiters)
+   goto out_engines;
+
+   /* Create a large number of threads, each waiting on a random seqno.
+* Multiple waiters will be waiting for the same seqno.
+*/
+   atomic_set(, count);
+   for (n = 0; n < count; n++) {
+   waiters[n].wq = 
+   waiters[n].ready = 
+   waiters[n].set = 
+   waiters[n].done = 
+   waiters[n].engine = engine;
+   waiters[n].flags = 0;
+
+   waiters[n].tsk = kthread_run(igt_wakeup_thread, [n],
+"i915/igt:%d", n);
+   if (IS_ERR(waiters[n].tsk))
+   goto out_waiters;
+
+   get_task_struct(waiters[n].tsk);
+   }
+
+   for (step = 1; step <= max_seqno; step <<= 1) {
+   u32 seqno;
+
+   /* The waiter threads start paused as we assign them a random
+* seqno and reset the engine. Once the engine is reset,
+* we signal that the threads may begin their, and we wait
+* until all threads are woken.
+*/
+   for (n = 0; n < count; n++) {
+   GEM_BUG_ON(!test_bit(WAITING, [n].flags));


Looks like a race condition between thread startup 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/scheduler: emulate a scheduler for guc (rev3)

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915/scheduler: emulate a scheduler for guc (rev3)
URL   : https://patchwork.freedesktop.org/series/18909/
State : success

== Summary ==

Series 18909v3 drm/i915/scheduler: emulate a scheduler for guc
https://patchwork.freedesktop.org/api/1.0/series/18909/revisions/3/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

8126864ab4eab95a09af5677535e8ccae3b6b73a drm-tip: 2017y-02m-01d-15h-25m-23s UTC 
integration manifest
b8f86a1 drm/i915/scheduler: emulate a scheduler for guc

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3667/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Capture module parameters for the GPU error state

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 04:50:06PM +, Chris Wilson wrote:
> They include useful material such as what mode the VM address space is
s/The module parameters/
> running in, what submission mode, extra quirks, etc.

and so are invaluable when analysing errors.
-Chris

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


[Intel-gfx] [PATCH 1/2] drm/i915: Generate i915_params {} using a macro

2017-02-01 Thread Chris Wilson
I want to print the struct from the error state and so would like to use
the existing struct definition as the template ala DEV_INFO*

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_params.h | 81 --
 1 file changed, 43 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 8e433de04679..46eb31ae0982 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -27,46 +27,51 @@
 
 #include  /* for __read_mostly */
 
+#define I915_PARAMS_FOR_EACH(func) \
+   func(int, modeset); \
+   func(int, panel_ignore_lid); \
+   func(int, semaphores); \
+   func(int, lvds_channel_mode); \
+   func(int, panel_use_ssc); \
+   func(int, vbt_sdvo_panel_type); \
+   func(int, enable_rc6); \
+   func(int, enable_dc); \
+   func(int, enable_fbc); \
+   func(int, enable_ppgtt); \
+   func(int, enable_execlists); \
+   func(int, enable_psr); \
+   func(unsigned int, alpha_support); \
+   func(int, disable_power_well); \
+   func(int, enable_ips); \
+   func(int, invert_brightness); \
+   func(int, enable_guc_loading); \
+   func(int, enable_guc_submission); \
+   func(int, guc_log_level); \
+   func(int, use_mmio_flip); \
+   func(int, mmio_debug); \
+   func(int, edp_vswing); \
+   func(unsigned int, inject_load_failure); \
+   /* leave bools at the end to not create holes */ \
+   func(bool, enable_cmd_parser); \
+   func(bool, enable_hangcheck); \
+   func(bool, fastboot); \
+   func(bool, prefault_disable); \
+   func(bool, load_detect_test); \
+   func(bool, force_reset_modeset_test); \
+   func(bool, reset); \
+   func(bool, error_capture); \
+   func(bool, disable_display); \
+   func(bool, verbose_state_checks); \
+   func(bool, nuclear_pageflip); \
+   func(bool, enable_dp_mst); \
+   func(bool, enable_dpcd_backlight); \
+   func(bool, enable_gvt)
+
+#define p(T, member) T member
 struct i915_params {
-   int modeset;
-   int panel_ignore_lid;
-   int semaphores;
-   int lvds_channel_mode;
-   int panel_use_ssc;
-   int vbt_sdvo_panel_type;
-   int enable_rc6;
-   int enable_dc;
-   int enable_fbc;
-   int enable_ppgtt;
-   int enable_execlists;
-   int enable_psr;
-   unsigned int alpha_support;
-   int disable_power_well;
-   int enable_ips;
-   int invert_brightness;
-   int enable_guc_loading;
-   int enable_guc_submission;
-   int guc_log_level;
-   int use_mmio_flip;
-   int mmio_debug;
-   int edp_vswing;
-   unsigned int inject_load_failure;
-   /* leave bools at the end to not create holes */
-   bool enable_cmd_parser;
-   bool enable_hangcheck;
-   bool fastboot;
-   bool prefault_disable;
-   bool load_detect_test;
-   bool force_reset_modeset_test;
-   bool reset;
-   bool error_capture;
-   bool disable_display;
-   bool verbose_state_checks;
-   bool nuclear_pageflip;
-   bool enable_dp_mst;
-   bool enable_dpcd_backlight;
-   bool enable_gvt;
+   I915_PARAMS_FOR_EACH(p);
 };
+#undef p
 
 extern struct i915_params i915 __read_mostly;
 
-- 
2.11.0

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


[Intel-gfx] [PATCH 2/2] drm/i915: Capture module parameters for the GPU error state

2017-02-01 Thread Chris Wilson
They include useful material such as what mode the VM address space is
running in, what submission mode, extra quirks, etc.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 27 ---
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 15b6c75ebade..5bcde9395126 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -904,6 +904,7 @@ struct drm_i915_error_state {
u32 reset_count;
u32 suspend_count;
struct intel_device_info device_info;
+   struct i915_params params;
 
/* Generic register state */
u32 eir;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 5283fe815a4d..c01771c1f06f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -546,6 +546,14 @@ static void err_print_capabilities(struct 
drm_i915_error_state_buf *m,
 #undef PRINT_FLAG
 }
 
+static void err_print_params(struct drm_i915_error_state_buf *m,
+const struct i915_params *p)
+{
+#define PRINT(T, x) err_printf(m, #x ": %d\n", p->x);
+   I915_PARAMS_FOR_EACH(PRINT);
+#undef PRINT_PARAM
+}
+
 int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
const struct i915_error_state_file_priv *error_priv)
 {
@@ -568,7 +576,6 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
   error->boottime.tv_sec, error->boottime.tv_usec);
err_printf(m, "Uptime: %ld s %ld us\n",
   error->uptime.tv_sec, error->uptime.tv_usec);
-   err_print_capabilities(m, >device_info);
 
for (i = 0; i < ARRAY_SIZE(error->engine); i++) {
if (error->engine[i].hangcheck_stalled &&
@@ -588,6 +595,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
err_printf(m, "PCI Subsystem: %04x:%04x\n",
   pdev->subsystem_vendor,
   pdev->subsystem_device);
+
err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
 
if (HAS_CSR(dev_priv)) {
@@ -730,6 +738,9 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
if (error->display)
intel_display_print_error_state(m, dev_priv, error->display);
 
+   err_print_capabilities(m, >device_info);
+   err_print_params(m, >params);
+
 out:
if (m->bytes == 0 && m->err)
return m->err;
@@ -1587,6 +1598,14 @@ static int capture(void *data)
 {
struct drm_i915_error_state *error = data;
 
+   do_gettimeofday(>time);
+   error->boottime = ktime_to_timeval(ktime_get_boottime());
+   error->uptime =
+   ktime_to_timeval(ktime_sub(ktime_get(),
+  error->i915->gt.last_init_time));
+
+   error->params = i915;
+
i915_capture_gen_state(error->i915, error);
i915_capture_reg_state(error->i915, error);
i915_gem_record_fences(error->i915, error);
@@ -1595,12 +1614,6 @@ static int capture(void *data)
i915_capture_pinned_buffers(error->i915, error);
i915_gem_capture_guc_log_buffer(error->i915, error);
 
-   do_gettimeofday(>time);
-   error->boottime = ktime_to_timeval(ktime_get_boottime());
-   error->uptime =
-   ktime_to_timeval(ktime_sub(ktime_get(),
-  error->i915->gt.last_init_time));
-
error->overlay = intel_overlay_capture_error_state(error->i915);
error->display = intel_display_capture_error_state(error->i915);
 
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH i-g-t v4 09/11] tests/kms_atomic_transition: add out_fences tests

2017-02-01 Thread Robert Foss



On 2017-02-01 05:40 AM, Brian Starkey wrote:

On Tue, Jan 31, 2017 at 08:25:18PM -0500, Robert Foss wrote:

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c |  16 +
tests/kms_atomic_transition.c | 153
--
2 files changed, 164 insertions(+), 5 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7bf3fa3a..64f8b337 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
#include "intel_chipset.h"
#include "igt_debugfs.h"
#include "igt_sysfs.h"
+#include "sw_sync.h"

/**
 * SECTION:igt_kms
@@ -2470,6 +2471,21 @@ static int igt_atomic_commit(igt_display_t
*display, uint32_t flags, void *user_
}

ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+if (!ret) {
+
+for_each_pipe(display, pipe) {
+igt_pipe_t *pipe_obj = >pipes[pipe];
+
+if (pipe_obj->out_fence_fd == -1)
+continue;
+
+igt_assert(pipe_obj->out_fence_fd >= 0);
+ret = sync_fence_wait(pipe_obj->out_fence_fd, 1000);
+igt_assert(ret == 0);
+close(pipe_obj->out_fence_fd);


Setting it to -1 after closing seems like a good idea.

Also see my comment on patch 11 about interactions with
get_last_out_fence.

-Brian


Ack, fixed in v5.


Rob.




+}
+}
+
drmModeAtomicFree(req);
return ret;

diff --git a/tests/kms_atomic_transition.c
b/tests/kms_atomic_transition.c
index 72429759..4b1278a4 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@

#include "igt.h"
#include "drmtest.h"
+#include "sw_sync.h"
#include 
+#include 
#include 
#include 
#include 
@@ -253,6 +255,94 @@ retry:
 sprite_width, sprite_height, alpha);
}

+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int n_planes;
+
+igt_require_sw_sync();
+
+n_planes = display->pipes[pipe].n_planes;
+timeline = calloc(sizeof(*timeline), n_planes);
+igt_assert_f(timeline != NULL, "Failed to allocate memory for
timelines\n");
+thread = calloc(sizeof(*thread), n_planes);
+igt_assert_f(thread != NULL, "Failed to allocate memory for
thread\n");
+seqno = calloc(sizeof(*seqno), n_planes);
+igt_assert_f(seqno != NULL, "Failed to allocate memory for
seqno\n");
+
+for_each_plane_on_pipe(display, pipe, plane)
+timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+close(timeline[plane->index]);
+
+free(timeline);
+free(thread);
+free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+int t = *((int *) arg);
+
+pthread_detach(pthread_self());
+
+usleep(5000);
+sw_sync_timeline_inc(t, 1);
+return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int i, fd, ret;
+
+for_each_plane_on_pipe(display, pipe, plane) {
+
+if (!plane->fb)
+continue;
+
+i = plane->index;
+
+seqno[i]++;
+fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+igt_plane_set_fence_fd(plane, fd);
+close(fd);
+ret = pthread_create([i], NULL, fence_inc_thread,
[i]);
+igt_assert_eq(ret, 0);
+}
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+igt_plane_set_fence_fd(plane, -1);
+}
+
+static void atomic_commit(igt_display_t *display, enum pipe pipe,
unsigned int flags, void *data, bool fencing)
+{
+if (fencing) {
+configure_fencing(display, pipe);
+igt_pipe_request_out_fence(>pipes[pipe]);
+}
+
+igt_display_commit_atomic(display, flags, data);
+
+if (fencing)
+clear_fencing(display, pipe);
+}
+
/*
 * 1. Set primary plane to a known fb.
 * 2. Make sure getcrtc returns the correct fb id.
@@ -273,6 +363,10 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output
struct plane_parms parms[display->pipes[pipe].n_planes];
bool skip_test = false;
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
+int ret;
+
+if (fencing)
+prepare_fencing(display, pipe);

if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;
@@ -307,12 +401,48 @@ run_transition_test(igt_display_t *display, enum
pipe pipe, igt_output_t *output

setup_parms(display, pipe, mode, _fb, _fb, parms);

+/*
+ * In some configurations the tests may not run to completion
with all
+ * sprite planes lit up at 4k resolution, try decreasing
width/size of secondary
+ * planes to fix this
+ */
+while (1) {
+

Re: [Intel-gfx] [PATCH 5/6] drm/i915: enable scrambling

2017-02-01 Thread Ville Syrjälä
On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> Geminilake platform has a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c  |  5 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 42 
> +++
>  4 files changed, 51 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 495b789..cc85892 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7807,6 +7807,8 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 9a9a670..aea81ce 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv)) {
> + temp |= intel_hdmi_check_scrambling(intel_encoder,
> + _crtc->config->base.adjusted_mode);
> + }
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 393f243..aafce7f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>  struct intel_crtc_state *pipe_config,
>  struct drm_connector_state *conn_state);
> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
> + struct drm_display_mode *mode);
>  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
> enable);
>  
>  
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ebae2bd..92dd9bc 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct drm_connector 
> *connector)
>   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>  
> +static void
> +intel_hdmi_enable_scrambling(struct drm_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = connector->dev->dev_private;
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> + struct i2c_adapter *adapter =
> + intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +
> + if (!drm_enable_scrambling(connector, adapter, true))
> + DRM_ERROR("Request to enable scrambling failed\n");
> +}

I don't like hiding this somewhere deep like this. It should be
somewhere much higher up.

And I'm thinkign we might want to track the scrambler state
in the crtc state.

> +
> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
> + struct drm_display_mode *mode)
> +{
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(_encoder->base);
> + struct drm_connector *connector = _hdmi->attached_connector->base;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> + uint32_t hdmi_config = 0;
> +
> + DRM_DEBUG_KMS("Checking scrambling for enc:%s connector:%s\n",
> + intel_encoder->base.name, connector->name);
> +
> + if (mode->clock < 34) {
> + if (hdmi_info->scr_info.low_clocks) {
> + intel_hdmi_enable_scrambling(connector);
> + hdmi_config |= TRANS_DDI_HDMI_SCRAMBLING;
> + }
> + return hdmi_config;
> + }
> +
> + /* Enable scrambling for clocks > 340M */
> + if (hdmi_info->scr_info.supported) {
> + intel_hdmi_enable_scrambling(connector);
> + hdmi_config |= TRANS_DDI_HDMI_SCRAMBLING;
> + }
> +
> + /* Scrambling or not, if clock > 340M, set high char rate */
> + 

Re: [Intel-gfx] [PATCH i-g-t v4 06/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property

2017-02-01 Thread Robert Foss



On 2017-02-01 05:40 AM, Brian Starkey wrote:

On Tue, Jan 31, 2017 at 08:25:15PM -0500, Robert Foss wrote:

From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out
fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 23 ++-
lib/igt_kms.h |  6 +-
2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9b60d74a..7bf3fa3a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char
*igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-"ACTIVE"
+"ACTIVE",
+"OUT_FENCE_PTR"
};

const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2385,6 +2386,14 @@ static void
igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
}

+pipe_obj->out_fence_fd = -1;
+if (pipe_obj->out_fence_requested)
+{
+pipe_obj->out_fence_requested = false;
+igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR,
+(uint64_t)(uintptr_t) _obj->out_fence_fd);
+}
+
/*
 *TODO: Add all crtc level properties here
 */
@@ -2959,6 +2968,18 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane->rotation_changed = true;
}

+/**
+ * igt_pipe_request_out_fence:
+ * @pipe: pipe pointer to which background color to be set


Wrong description here

-Brian


Ack, fixed in v5.

Rob.




+ *
+ * Marks this pipe for requesting an out fence at the next atomic commit
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_request_out_fence(igt_pipe_t *pipe)
+{
+pipe->out_fence_requested = true;
+}
+
void
igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
{
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8acad8ef..6754d00e 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
   IGT_CRTC_GAMMA_LUT,
   IGT_CRTC_MODE_ID,
   IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
   IGT_NUM_CRTC_PROPS
};

@@ -341,6 +342,9 @@ struct igt_pipe {

uint64_t mode_blob;
bool mode_changed;
+
+int32_t out_fence_fd;
+bool out_fence_requested;
};

typedef struct {
@@ -394,7 +398,7 @@ static inline bool
igt_plane_supports_rotation(igt_plane_t *plane)
{
return plane->rotation_property != 0;
}
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);
void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t
length);
void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
--
2.11.0.453.g787f75f05


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


Re: [Intel-gfx] [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-01 Thread Ville Syrjälä
On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advance HDMI 2.0 features
> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in hdmi_info structure.
> - If SCDC is present, checks if sink is capable of generating
>   scdc read request, and marks it in hdmi_info structure.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 14 ++
>  include/drm/drm_connector.h | 26 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 96d3e47..37902e5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
>  }
>  EXPORT_SYMBOL(drm_default_rgb_quant_range);
>  
> +static void drm_detect_hdmi_scdc(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_hdmi_info *hdmi = >display_info.hdmi_info;
> +
> + if (hf_vsdb[6] & 0x80) {
> + hdmi->scdc_supported = true;
> + if (hf_vsdb[6] & 0x40)
> + hdmi->scdc_rr = true;
> + }
> +}
> +
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
>  const u8 *hdmi)
>  {
> @@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>  
>   if (cea_db_is_hdmi_vsdb(db))
>   drm_parse_hdmi_vsdb_video(connector, db);
> + if (cea_db_is_hdmi_forum_vsdb(db))
> + drm_detect_hdmi_scdc(connector, db);
>   }
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index e5e1edd..2435598 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -87,6 +87,27 @@ enum subpixel_order {
>   SubPixelVerticalRGB,
>   SubPixelVerticalBGR,
>   SubPixelNone,
> +
> +};
> +
> +/**
> + * struct drm_hdmi_info - runtime data about the connected sink
> + *
> + * Describes if a given hdmi display supports advance HDMI 2.0 featutes.
> + * This information is available in CEA-861-F extension blocks (like
> + * HF-VSDB)
> + * For sinks which provide an EDID this can be filled out by calling
> + * drm_add_edid_modes().
> + */
> +struct drm_hdmi_info {
> + /**
> +  * @scdc_supported: status control & data channel present.
> +  */
> + bool scdc_supported;
> + /**
> +  * @scdc_rr: sink is capable of generating scdc read request.
> +  */
> + bool scdc_rr;

Probably worth spelling the thing out.

>  };
>  
>  /**
> @@ -188,6 +209,11 @@ struct drm_display_info {
>* @cea_rev: CEA revision of the HDMI sink.
>*/
>   u8 cea_rev;
> +
> + /**
> +  * @hdmi_info: advance features of a HDMI sink.
> +  */
> + struct drm_hdmi_info hdmi_info;
>  };
>  
>  int drm_display_info_set_bus_formats(struct drm_display_info *info,
> -- 
> 1.9.1

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


Re: [Intel-gfx] [PATCH i-g-t v4 05/11] lib/igt_kms: Add support for the IN_FENCE_FD property

2017-02-01 Thread Robert Foss



On 2017-02-01 05:39 AM, Brian Starkey wrote:

On Tue, Jan 31, 2017 at 08:25:14PM -0500, Robert Foss wrote:

Add support dor the IN_FENCE_FD property to enable setting in fences
for atomic
commits.


trivial... s/dor/for/


Thanks, coming up in v5.

Rob.




Signed-off-by: Robert Foss 
---
lib/igt_kms.c | 25 +
lib/igt_kms.h |  5 +
2 files changed, 30 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 142658a6..9b60d74a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -168,6 +168,7 @@ const char
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+"IN_FENCE_FD",
"type",
"rotation"
};
@@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display,
int drm_fd)
plane->type = type;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+plane->fence_fd = -1;

if (is_atomic == 0) {
display->is_atomic = 1;
@@ -1994,6 +1996,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t
*plane, igt_pipe_t *pipe,
plane->index,
fb_id);

+if (plane->fence_fd >= 0) {
+uint64_t fence_fd = (int64_t) plane->fence_fd;
+igt_atomic_populate_plane_req(req, plane,
IGT_PLANE_IN_FENCE_FD, fence_fd);
+}
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID,
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
fb_id);
@@ -2815,6 +2822,24 @@ void igt_plane_set_fb(igt_plane_t *plane,
struct igt_fb *fb)
plane->size_changed = true;
}

+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some
event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd)
+{
+close(plane->fence_fd);
+
+if (fcntl(fence_fd, F_GETFD) != -1)
+plane->fence_fd = dup(fence_fd);
+else
+plane->fence_fd = -1;
+}
+
void igt_plane_set_position(igt_plane_t *plane, int x, int y)
{
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 00e0dc68..8acad8ef 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -248,6 +248,7 @@ enum igt_atomic_plane_properties {

   IGT_PLANE_FB_ID,
   IGT_PLANE_CRTC_ID,
+   IGT_PLANE_IN_FENCE_FD,
   IGT_PLANE_TYPE,
   IGT_PLANE_ROTATION,
   IGT_NUM_PLANE_PROPS
@@ -306,6 +307,9 @@ typedef struct {
uint32_t src_h;

igt_rotation_t rotation;
+
+/* in fence fd */
+int fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
} igt_plane_t;

@@ -396,6 +400,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe,
void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);

void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, int fence_fd);
void igt_plane_set_position(igt_plane_t *plane, int x, int y);
void igt_plane_set_size(igt_plane_t *plane, int w, int h);
void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
--
2.11.0.453.g787f75f05


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


Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Ville Syrjälä
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
> 
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 131 
> +++-
>  include/drm/drm_connector.h |  24 
>  include/drm/drm_edid.h  |   6 +-
>  3 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 37902e5..f0d940a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define version_greater(edid, maj, min) \
>   (((edid)->version > (maj)) || \
> @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> +  const u8 *hf_vsdb)

That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or
something.

> +{
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi_info;
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340M.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> +  * * SCDC support available
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + display->max_tmds_clock = hf_vsdb[5] * 5000;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);

I wonder if we should be a little paranoid and ignore this if it's
<=340?

> +
> + if (hdmi->scdc_supported) {
> + hdmi->scr_info.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + hdmi->scr_info.low_clocks = true;
> + }
> + }
> +}
> +
> +/**
> + * drm_check_scrambling_status - what is status of scrambling?
> + * @adapter: i2c adapter for SCDC channel
> + *
> + * Read the scrambler status over SCDC channel, and check the
> + * scrambling status.
> + *
> + * Return: True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_check_scrambling_status(struct i2c_adapter *adapter)

The name is again a little wonky. And it looks like something that
should live alognside the SCDC helper stuff.

> +{
> + u8 status;
> +
> + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
> + DRM_ERROR("Failed to read scrambling status\n");
> + return false;
> + }
> +
> + status &= SCDC_SCRAMBLING_STATUS;
> + return status != 0;

return status & SCDC_SCRAMBLING_STATUS

> +}
> +
> +/**
> + * drm_enable_scrambling - enable scrambling
> + * @connector: target drm_connector
> + * @adapter: i2c adapter for SCDC channel
> + * @force: enable scrambling, even if its already enabled
> + *
> + * Write the TMDS config over SCDC channel, and enable scrambling
> + * Return: True if scrambling is successfully enabled, false otherwise.
> + */
> +
> +bool drm_enable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)
> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if (hdmi_info->scr_info.status && !force) {
> + DRM_DEBUG_KMS("Scrambling already enabled\n");
> + return true;
> + }

I don't think we want to track any dynamic state in the display info.
That belongs to the atomic state stuff.

And the function again looks like something that belongs in the SCDC
helper.

Since the two pieces of infromaton in this registrer are the scramble
control and the clock ratio, I think we might want to just have one
function to configure both.

> +
> + if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
> + DRM_ERROR("Failed to read tmds config\n");
> + return false;
> + }
> +
> + config |= SCDC_SCRAMBLING_ENABLE;
> +
> + if (drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config) < 0) {
> + DRM_ERROR("Failed to enable scrambling, write error\n");
> + return false;
> + }
> +
> + hdmi_info->scr_info.status = drm_check_scrambling_status(adapter);
> + return hdmi_info->scr_info.status;
> +}

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Thierry Reding
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
> 
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 131 
> +++-
>  include/drm/drm_connector.h |  24 
>  include/drm/drm_edid.h  |   6 +-
>  3 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 37902e5..f0d940a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define version_greater(edid, maj, min) \
>   (((edid)->version > (maj)) || \
> @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi_info;
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340M.

In comments below you use Mhz as the abbreviations. This should be
consistent. Also I think "MHz" is actually the correct spelling.

> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> +  * * SCDC support available
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + display->max_tmds_clock = hf_vsdb[5] * 5000;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> +
> + if (hdmi->scdc_supported) {
> + hdmi->scr_info.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + hdmi->scr_info.low_clocks = true;
> + }
> + }
> +}
> +
> +/**
> + * drm_check_scrambling_status - what is status of scrambling?
> + * @adapter: i2c adapter for SCDC channel

"I2C", same in other parts of this patch.

> + *
> + * Read the scrambler status over SCDC channel, and check the
> + * scrambling status.
> + *
> + * Return: True if the scrambling is enabled, false otherwise.

I think the rest of DRM/KMS kerneldoc tries to use "Returns:\n" as a
standard way to document return values.

> + */
> +
> +bool drm_check_scrambling_status(struct i2c_adapter *adapter)

Maybe use a drm_scdc_*() prefix for this to make it more consistent with
other SCDC API.

While at it, would this not be better located in drm_scdc.c along with
the other helpers? drm_edid.c is more focussed on the parsing aspects of
all things EDID.

> +{
> + u8 status;
> +
> + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {

How about storing the error code...

> + DRM_ERROR("Failed to read scrambling status\n");

... and making it part of the error message? Sometimes its useful to
know what exact error triggered this because it helps narrowing down
where things went wrong.

> + return false;
> + }
> +
> + status &= SCDC_SCRAMBLING_STATUS;
> + return status != 0;

Maybe make this a single line:

return (status & SCDC_SCRAMBLING_STATUS) != 0;

> +}
> +
> +/**
> + * drm_enable_scrambling - enable scrambling
> + * @connector: target drm_connector

"target DRM connector"?

> + * @adapter: i2c adapter for SCDC channel
> + * @force: enable scrambling, even if its already enabled
> + *
> + * Write the TMDS config over SCDC channel, and enable scrambling
> + * Return: True if scrambling is successfully enabled, false otherwise.
> + */
> +
> +bool drm_enable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)

I think I'd move this to drm_scdc.c as well because it primarily
operates on SCDC. If you do so, might be worth making adapter the first
argument for consistency with other SCDC API.

> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if (hdmi_info->scr_info.status && !force) {
> + DRM_DEBUG_KMS("Scrambling already enabled\n");
> + return true;
> + }
> +
> + if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
> + DRM_ERROR("Failed to read tmds config\n");

Maybe also print the error 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo
URL   : https://patchwork.freedesktop.org/series/18924/
State : success

== Summary ==

Series 18924v1 drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo
https://patchwork.freedesktop.org/api/1.0/series/18924/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

8126864ab4eab95a09af5677535e8ccae3b6b73a drm-tip: 2017y-02m-01d-15h-25m-23s UTC 
integration manifest
0557387 drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3666/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v7] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Tvrtko Ursulin


On 01/02/2017 16:15, Chris Wilson wrote:

This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).

v2: Drop hack status - though iirc there is still a lockdep inversion
between fence and engine->timeline->lock (which is impossible as the
nesting only occurs on different fences - hopefully just requires some
judicious lockdep annotation)
v3: Apply lockdep nesting to enabling signaling on the request, using
the pattern we already have in __i915_gem_request_submit();
v4: Replaying requests after a hang also now needs the timeline
spinlock, to disable the interrupts at least
v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal
v6: Reorder interrupt checking for a happier gcc.
v7: Only signal the tasklet after a user-interrupt if using guc scheduling

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 109 +++--
 drivers/gpu/drm/i915/i915_irq.c|  13 +++-
 drivers/gpu/drm/i915/intel_lrc.c   |   5 +-
 3 files changed, 113 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e26f075..68c32da28094 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -25,6 +25,8 @@
 #include "i915_drv.h"
 #include "intel_uc.h"

+#include 
+
 /**
  * DOC: GuC-based command submission
  *
@@ -348,7 +350,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
u32 freespace;
int ret;

-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
freespace = CIRC_SPACE(client->wq_tail, desc->head, client->wq_size);
freespace -= client->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -358,7 +360,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
client->no_wq_space++;
ret = -EAGAIN;
}
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);

return ret;
 }
@@ -370,9 +372,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request 
*request)

GEM_BUG_ON(READ_ONCE(client->wq_rsvd) < wqi_size);

-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
client->wq_rsvd -= wqi_size;
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 }

 /* Construct a Work Item and append it to the GuC's Work Queue */
@@ -532,10 +534,96 @@ static void __i915_guc_submit(struct drm_i915_gem_request 
*rq)

 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
-   i915_gem_request_submit(rq);
+   __i915_gem_request_submit(rq);
__i915_guc_submit(rq);
 }

+static void nested_enable_signaling(struct drm_i915_gem_request *rq)
+{
+   /* If we use dma_fence_enable_sw_signaling() directly, lockdep
+* detects an ordering issue between the fence lockclass and the
+* global_timeline. This circular dependency can only occur via 2
+* different fences (but same fence lockclass), so we use the nesting
+* annotation here to prevent the warn, equivalent to the nesting
+* inside i915_gem_request_submit() for when we also enable the
+* signaler.
+*/
+
+   if (test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+>fence.flags))
+   return;
+
+   GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags));
+   trace_dma_fence_enable_signal(>fence);
+
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   intel_engine_enable_signaling(rq);
+   spin_unlock(>lock);
+}
+
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *last = port[0].request;
+   unsigned long flags;
+   struct rb_node *rb;
+   bool submit = false;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+   rb = engine->execlist_first;
+   while (rb) {
+   struct drm_i915_gem_request *cursor =
+   rb_entry(rb, typeof(*cursor), priotree.node);
+
+   if (last && cursor->ctx != last->ctx) {
+   if (port != engine->execlist_port)
+   break;
+
+   i915_gem_request_assign(>request, last);
+   nested_enable_signaling(last);
+   port++;
+   }
+
+   rb = rb_next(rb);
+   rb_erase(>priotree.node, >execlist_queue);
+   RB_CLEAR_NODE(>priotree.node);
+   

[Intel-gfx] [PATCH v7] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Chris Wilson
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).

v2: Drop hack status - though iirc there is still a lockdep inversion
between fence and engine->timeline->lock (which is impossible as the
nesting only occurs on different fences - hopefully just requires some
judicious lockdep annotation)
v3: Apply lockdep nesting to enabling signaling on the request, using
the pattern we already have in __i915_gem_request_submit();
v4: Replaying requests after a hang also now needs the timeline
spinlock, to disable the interrupts at least
v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal
v6: Reorder interrupt checking for a happier gcc.
v7: Only signal the tasklet after a user-interrupt if using guc scheduling

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 109 +++--
 drivers/gpu/drm/i915/i915_irq.c|  13 +++-
 drivers/gpu/drm/i915/intel_lrc.c   |   5 +-
 3 files changed, 113 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e26f075..68c32da28094 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -25,6 +25,8 @@
 #include "i915_drv.h"
 #include "intel_uc.h"
 
+#include 
+
 /**
  * DOC: GuC-based command submission
  *
@@ -348,7 +350,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
u32 freespace;
int ret;
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
freespace = CIRC_SPACE(client->wq_tail, desc->head, client->wq_size);
freespace -= client->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -358,7 +360,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
client->no_wq_space++;
ret = -EAGAIN;
}
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 
return ret;
 }
@@ -370,9 +372,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request 
*request)
 
GEM_BUG_ON(READ_ONCE(client->wq_rsvd) < wqi_size);
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
client->wq_rsvd -= wqi_size;
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 }
 
 /* Construct a Work Item and append it to the GuC's Work Queue */
@@ -532,10 +534,96 @@ static void __i915_guc_submit(struct drm_i915_gem_request 
*rq)
 
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
-   i915_gem_request_submit(rq);
+   __i915_gem_request_submit(rq);
__i915_guc_submit(rq);
 }
 
+static void nested_enable_signaling(struct drm_i915_gem_request *rq)
+{
+   /* If we use dma_fence_enable_sw_signaling() directly, lockdep
+* detects an ordering issue between the fence lockclass and the
+* global_timeline. This circular dependency can only occur via 2
+* different fences (but same fence lockclass), so we use the nesting
+* annotation here to prevent the warn, equivalent to the nesting
+* inside i915_gem_request_submit() for when we also enable the
+* signaler.
+*/
+
+   if (test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+>fence.flags))
+   return;
+
+   GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags));
+   trace_dma_fence_enable_signal(>fence);
+
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   intel_engine_enable_signaling(rq);
+   spin_unlock(>lock);
+}
+
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *last = port[0].request;
+   unsigned long flags;
+   struct rb_node *rb;
+   bool submit = false;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+   rb = engine->execlist_first;
+   while (rb) {
+   struct drm_i915_gem_request *cursor =
+   rb_entry(rb, typeof(*cursor), priotree.node);
+
+   if (last && cursor->ctx != last->ctx) {
+   if (port != engine->execlist_port)
+   break;
+
+   i915_gem_request_assign(>request, last);
+   nested_enable_signaling(last);
+   port++;
+   }
+
+   rb = rb_next(rb);
+   rb_erase(>priotree.node, >execlist_queue);
+   RB_CLEAR_NODE(>priotree.node);
+   cursor->priotree.priority = INT_MAX;
+
+   

Re: [Intel-gfx] [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-01 Thread Thierry Reding
On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advance HDMI 2.0 features

"advanced"

> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in hdmi_info structure.

"drm_hdmi_info structure"?

> - If SCDC is present, checks if sink is capable of generating
>   scdc read request, and marks it in hdmi_info structure.

"SCDC" to be consistent and because it's an abbreviation.

> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 14 ++
>  include/drm/drm_connector.h | 26 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 96d3e47..37902e5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
>  }
>  EXPORT_SYMBOL(drm_default_rgb_quant_range);
>  
> +static void drm_detect_hdmi_scdc(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_hdmi_info *hdmi = >display_info.hdmi_info;
> +
> + if (hf_vsdb[6] & 0x80) {
> + hdmi->scdc_supported = true;
> + if (hf_vsdb[6] & 0x40)
> + hdmi->scdc_rr = true;
> + }
> +}
> +
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
>  const u8 *hdmi)
>  {
> @@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>  
>   if (cea_db_is_hdmi_vsdb(db))
>   drm_parse_hdmi_vsdb_video(connector, db);
> + if (cea_db_is_hdmi_forum_vsdb(db))
> + drm_detect_hdmi_scdc(connector, db);
>   }
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index e5e1edd..2435598 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -87,6 +87,27 @@ enum subpixel_order {
>   SubPixelVerticalRGB,
>   SubPixelVerticalBGR,
>   SubPixelNone,
> +
> +};
> +
> +/**
> + * struct drm_hdmi_info - runtime data about the connected sink

Maybe "connected HDMI sink"?

> + *
> + * Describes if a given hdmi display supports advance HDMI 2.0 featutes.

"HDMI", "advanced", "features"

> + * This information is available in CEA-861-F extension blocks (like
> + * HF-VSDB)

This should be terminated by a full-stop.

> + * For sinks which provide an EDID this can be filled out by calling
> + * drm_add_edid_modes().

And maybe make this sentence start right after the one above rather than
breaking it to the next line. I'm not sure how useful this line is. Most
driver will be calling drm_add_edid_modes() anyway, but the above makes
it sound like drm_add_edid_modes() is something you have to explicitly
call to get these fields parsed.

> + */
> +struct drm_hdmi_info {
> + /**
> +  * @scdc_supported: status control & data channel present.
> +  */
> + bool scdc_supported;
> + /**
> +  * @scdc_rr: sink is capable of generating scdc read request.
> +  */
> + bool scdc_rr;
>  };
>  
>  /**
> @@ -188,6 +209,11 @@ struct drm_display_info {
>* @cea_rev: CEA revision of the HDMI sink.
>*/
>   u8 cea_rev;
> +
> + /**
> +  * @hdmi_info: advance features of a HDMI sink.
> +  */
> + struct drm_hdmi_info hdmi_info;

I think we can safely drop the _info suffix on the field name. It's
already inside a structure that carries this suffix.

Other than that:

Reviewed-by: Thierry Reding 


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


Re: [Intel-gfx] [PATCH 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params

2017-02-01 Thread Tvrtko Ursulin


On 01/02/2017 07:20, Joonas Lahtinen wrote:

On ti, 2017-01-31 at 13:15 +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

dev, file and ctx are unused.

Signed-off-by: Tvrtko Ursulin 


Could either squash this to the previous commit, or have this before
previous commit, to avoid going through removed code in previous patch
(easier for rebasing etc.)


Yes I realized that after I wrote it, but was too lazy to reorder. Same 
for the pretty alignment in the first patch. Always when I stumble upon 
those I am 50-50.


Will reorder it, it makes sense.

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH v2 32/38] drm/i915: Verify page layout for rotated VMA

2017-02-01 Thread Tvrtko Ursulin


On 01/02/2017 14:55, Chris Wilson wrote:

On Wed, Feb 01, 2017 at 02:33:22PM +, Tvrtko Ursulin wrote:


[snip]


+   { }
+   }, *a, *b;
+   const unsigned int max_pages = 64;
+   int err = -ENOMEM;
+
+   /* Create VMA for many different combinations of planes and check
+* that the page layout within the rotated VMA match our expectations.
+*/
+
+   obj = i915_gem_object_create_internal(i915, max_pages * PAGE_SIZE);
+   if (IS_ERR(obj))
+   goto err;
+
+   for (a = planes; a->width; a++) {
+   for (b = planes + ARRAY_SIZE(planes); b-- != planes; ) {
+   struct i915_ggtt_view view;
+   struct scatterlist *sg;
+   unsigned int n, max_offset;
+
+   max_offset = max(a->stride * a->height,
+b->stride * b->height);


It shouldn't be min?


+   GEM_BUG_ON(max_offset >= max_pages);
+   max_offset = max_pages - max_offset;


No, because it is inverted ^


I see.


+   view.type = I915_GGTT_VIEW_ROTATED;
+   view.rotated.plane[0] = *a;
+   view.rotated.plane[1] = *b;


Single plane tests could be added as well.


There are. Second plane is set to {0}. That's the only way to do single
plane tests, as I was thinking second plane with a first plane would be
illegal?


Missed that.



+
+   
for_each_prime_number_from(view.rotated.plane[0].offset, 0, max_offset) {
+   
for_each_prime_number_from(view.rotated.plane[1].offset, 0, max_offset) {


I would try all offsets here and not only primes since it is super
fast and more importantly more realistic.


I was worried about the combinatorial explosion. We could have upto
65536 checks for each pair of planes (currently x20).


There is at least one even offset so OK. :)


+   struct i915_address_space *vm =
+   >ggtt.base;
+   struct i915_vma *vma;
+
+   vma = i915_vma_instance(obj, vm, );
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_object;
+   }
+
+   if (!i915_vma_is_ggtt(vma) ||
+   vma->vm != vm) {
+   pr_err("VMA is not in the 
GGTT!\n");
+   err = -EINVAL;
+   goto err_object;
+   }
+
+   if (memcmp(>ggtt_view, , 
sizeof(view))) {


Just because rotation is the largest view! :) Need to use the "type" here.


I wasn't really sure the value in doing both memcmp() and
i915_vma_compare(). I think I'm just going to stick with
i915_vma_compare() only.


I'm OK with that. Wanted even to suggest dropping the is_ggtt test since 
that feels should happen in a more basic VMA creation test. But if such 
doesn't exist then it's fine.


Regards,

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


[Intel-gfx] [PATCH v6] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Chris Wilson
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).

v2: Drop hack status - though iirc there is still a lockdep inversion
between fence and engine->timeline->lock (which is impossible as the
nesting only occurs on different fences - hopefully just requires some
judicious lockdep annotation)
v3: Apply lockdep nesting to enabling signaling on the request, using
the pattern we already have in __i915_gem_request_submit();
v4: Replaying requests after a hang also now needs the timeline
spinlock, to disable the interrupts at least
v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal
v6: Reorder interrupt checking for a happier gcc.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 109 +++--
 drivers/gpu/drm/i915/i915_irq.c|  13 ++--
 drivers/gpu/drm/i915/intel_lrc.c   |   5 +-
 3 files changed, 111 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e26f075..68c32da28094 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -25,6 +25,8 @@
 #include "i915_drv.h"
 #include "intel_uc.h"
 
+#include 
+
 /**
  * DOC: GuC-based command submission
  *
@@ -348,7 +350,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
u32 freespace;
int ret;
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
freespace = CIRC_SPACE(client->wq_tail, desc->head, client->wq_size);
freespace -= client->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -358,7 +360,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
client->no_wq_space++;
ret = -EAGAIN;
}
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 
return ret;
 }
@@ -370,9 +372,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request 
*request)
 
GEM_BUG_ON(READ_ONCE(client->wq_rsvd) < wqi_size);
 
-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
client->wq_rsvd -= wqi_size;
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 }
 
 /* Construct a Work Item and append it to the GuC's Work Queue */
@@ -532,10 +534,96 @@ static void __i915_guc_submit(struct drm_i915_gem_request 
*rq)
 
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
-   i915_gem_request_submit(rq);
+   __i915_gem_request_submit(rq);
__i915_guc_submit(rq);
 }
 
+static void nested_enable_signaling(struct drm_i915_gem_request *rq)
+{
+   /* If we use dma_fence_enable_sw_signaling() directly, lockdep
+* detects an ordering issue between the fence lockclass and the
+* global_timeline. This circular dependency can only occur via 2
+* different fences (but same fence lockclass), so we use the nesting
+* annotation here to prevent the warn, equivalent to the nesting
+* inside i915_gem_request_submit() for when we also enable the
+* signaler.
+*/
+
+   if (test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+>fence.flags))
+   return;
+
+   GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags));
+   trace_dma_fence_enable_signal(>fence);
+
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   intel_engine_enable_signaling(rq);
+   spin_unlock(>lock);
+}
+
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *last = port[0].request;
+   unsigned long flags;
+   struct rb_node *rb;
+   bool submit = false;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+   rb = engine->execlist_first;
+   while (rb) {
+   struct drm_i915_gem_request *cursor =
+   rb_entry(rb, typeof(*cursor), priotree.node);
+
+   if (last && cursor->ctx != last->ctx) {
+   if (port != engine->execlist_port)
+   break;
+
+   i915_gem_request_assign(>request, last);
+   nested_enable_signaling(last);
+   port++;
+   }
+
+   rb = rb_next(rb);
+   rb_erase(>priotree.node, >execlist_queue);
+   RB_CLEAR_NODE(>priotree.node);
+   cursor->priotree.priority = INT_MAX;
+
+   i915_guc_submit(cursor);
+   last = cursor;
+   submit 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode

2017-02-01 Thread Takashi Iwai
On Wed, 01 Feb 2017 16:11:37 +0100,
Ville Syrjälä wrote:
> 
> > +/* DisplayPort Audio w/ LPE */
> > +#define VLV_AUD_PORT_EN_B_DBG  (VLV_DISPLAY_BASE + 0x62F20)
> > +#define VLV_AUD_PORT_EN_C_DBG  (VLV_DISPLAY_BASE + 0x62F30)
> > +#define VLV_AUD_PORT_EN_D_DBG  (VLV_DISPLAY_BASE + 0x62F34)
> 
> We generally like to prefix the raw register offsets with '_' to make
> it clear they're not to be used directly.
> 
> With that fixed the i915 patches are
> Acked-by: Ville Syrjälä 

Alright, below is the respinned one.


Thanks!

Takashi

-- 8< --
From: Pierre-Louis Bossart 
Subject: [PATCH v3] drm/i915: add DisplayPort amp unmute for LPE audio mode

Enable unmute/mute amp notification. This doesn't seem to affect
HDMI support so this is done unconditionally.

An earlier version of this patch set a chicken bit at address 0x62F38
prior to the mute/unmute but this register doesn't seem to do anything
so this phase was removed.

v1->v2: Drop needless pipe A check, avoid temporary reg offset variable.
v2->v3: Add "_" prefix to VLV_AUD_PORT_EN_X_DBG as they are internal.

Signed-off-by: Pierre-Louis Bossart 
Acked-by: Ville Syrjälä 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_reg.h| 10 ++
 drivers/gpu/drm/i915/intel_lpe_audio.c | 12 
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a9ffc8df241b..4e24ba0cdbe8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
 #define I915_HDMI_LPE_AUDIO_BASE   (VLV_DISPLAY_BASE + 0x65000)
 #define I915_HDMI_LPE_AUDIO_SIZE   0x1000
 
+/* DisplayPort Audio w/ LPE */
+#define _VLV_AUD_PORT_EN_B_DBG (VLV_DISPLAY_BASE + 0x62F20)
+#define _VLV_AUD_PORT_EN_C_DBG (VLV_DISPLAY_BASE + 0x62F30)
+#define _VLV_AUD_PORT_EN_D_DBG (VLV_DISPLAY_BASE + 0x62F34)
+#define VLV_AUD_PORT_EN_DBG(port)  _MMIO_PORT3((port) - PORT_B,   \
+   _VLV_AUD_PORT_EN_B_DBG, \
+   _VLV_AUD_PORT_EN_C_DBG, \
+   _VLV_AUD_PORT_EN_D_DBG)
+#define VLV_AMP_MUTE   (1 << 1)
+
 #define GEN6_BSD_RNCID _MMIO(0x12198)
 
 #define GEN7_FF_THREAD_MODE_MMIO(0x20a0)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 245523e14418..5da14f40f94a 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -337,6 +337,7 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
 {
unsigned long irq_flags;
struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
+   u32 audio_enable;
 
if (!HAS_LPE_AUDIO(dev_priv))
return;
@@ -346,6 +347,8 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
 
spin_lock_irqsave(>lpe_audio_slock, irq_flags);
 
+   audio_enable = I915_READ(VLV_AUD_PORT_EN_DBG(port));
+
if (eld != NULL) {
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
@@ -357,11 +360,20 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
pdata->tmds_clock_speed = tmds_clk_speed;
if (link_rate)
pdata->link_rate = link_rate;
+
+   /* Unmute the amp for both DP and HDMI */
+   I915_WRITE(VLV_AUD_PORT_EN_DBG(port),
+  audio_enable & ~VLV_AMP_MUTE);
+
} else {
memset(pdata->eld.eld_data, 0,
HDMI_MAX_ELD_BYTES);
pdata->hdmi_connected = false;
pdata->dp_output = false;
+
+   /* Mute the amp for both DP and HDMI */
+   I915_WRITE(VLV_AUD_PORT_EN_DBG(port),
+  audio_enable | VLV_AMP_MUTE);
}
 
if (pdata->notify_audio_lpe)
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode

2017-02-01 Thread Ville Syrjälä
On Wed, Feb 01, 2017 at 03:53:49PM +0100, Takashi Iwai wrote:
> On Wed, 01 Feb 2017 15:45:24 +0100,
> Ville Syrjälä wrote:
> > 
> > On Tue, Jan 31, 2017 at 10:36:44PM +0100, Takashi Iwai wrote:
> > > From: Pierre-Louis Bossart 
> > > 
> > > Enable unmute/mute amp notification. This doesn't seem to affect
> > > HDMI support so this is done unconditionally.
> > > 
> > > An earlier version of this patch set a chicken bit at address 0x62F38
> > > prior to the mute/unmute but this register doesn't seem to do anything
> > > so this phase was removed.
> > > 
> > > Signed-off-by: Pierre-Louis Bossart 
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h| 10 ++
> > >  drivers/gpu/drm/i915/intel_lpe_audio.c | 17 +
> > >  2 files changed, 27 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index a9ffc8df241b..8fcc80cb864b 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
> > >  #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> > >  #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
> > >  
> > > +/* DisplayPort Audio w/ LPE */
> > > +#define VLV_AUD_PORT_EN_B_DBG(VLV_DISPLAY_BASE + 0x62F20)
> > > +#define VLV_AUD_PORT_EN_C_DBG(VLV_DISPLAY_BASE + 0x62F30)
> > > +#define VLV_AUD_PORT_EN_D_DBG(VLV_DISPLAY_BASE + 0x62F34)
> > > +#define VLV_AUD_PORT_EN_DBG(port)_MMIO_PORT3((port) - PORT_B,
> > >\
> > > + VLV_AUD_PORT_EN_B_DBG, \
> > > + VLV_AUD_PORT_EN_C_DBG, \
> > > + VLV_AUD_PORT_EN_D_DBG)
> > > +#define VLV_AMP_MUTE (1 << 1)
> > > +
> > >  #define GEN6_BSD_RNCID   _MMIO(0x12198)
> > >  
> > >  #define GEN7_FF_THREAD_MODE  _MMIO(0x20a0)
> > > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> > > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > index 245523e14418..f95624a46f27 100644
> > > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > @@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private 
> > > *dev_priv,
> > >  {
> > >   unsigned long irq_flags;
> > >   struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
> > > + u32 audio_enable;
> > > + i915_reg_t mmio;
> > >  
> > >   if (!HAS_LPE_AUDIO(dev_priv))
> > >   return;
> > >  
> > > + if (port == PORT_A) {
> > > + DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n");
> > > + return;
> > > + }
> > 
> > Port A doesn't exists on these platforms at all. So this is
> > just dead code.
> > 
> > > +
> > >   pdata = dev_get_platdata(
> > >   &(dev_priv->lpe_audio.platdev->dev));
> > >  
> > >   spin_lock_irqsave(>lpe_audio_slock, irq_flags);
> > >  
> > > + mmio = VLV_AUD_PORT_EN_DBG(port);
> > 
> > I'm not a fan of these temporary reg offset variables. Makes it hard to
> > figure out later which register is being frobbed, especially when the
> > variable name doesn't say what it actually is (like in this case). So
> > I'd like to see this killed off.
> 
> How about something like below?
> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> From: Pierre-Louis Bossart 
> Subject: [PATCH v2] drm/i915: add DisplayPort amp unmute for LPE audio mode
> 
> Enable unmute/mute amp notification. This doesn't seem to affect
> HDMI support so this is done unconditionally.
> 
> An earlier version of this patch set a chicken bit at address 0x62F38
> prior to the mute/unmute but this register doesn't seem to do anything
> so this phase was removed.
> 
> v1->v2: Drop needless pipe A check, avoid temporary reg offset variable.
> 
> Signed-off-by: Pierre-Louis Bossart 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/i915_reg.h| 10 ++
>  drivers/gpu/drm/i915/intel_lpe_audio.c | 12 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a9ffc8df241b..8fcc80cb864b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
>  #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
>  #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
>  
> +/* DisplayPort Audio w/ LPE */
> +#define VLV_AUD_PORT_EN_B_DBG(VLV_DISPLAY_BASE + 0x62F20)
> +#define VLV_AUD_PORT_EN_C_DBG(VLV_DISPLAY_BASE + 0x62F30)
> +#define VLV_AUD_PORT_EN_D_DBG(VLV_DISPLAY_BASE + 0x62F34)

We generally like to prefix the raw register offsets with '_' to make

Re: [Intel-gfx] [PATCH] drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

2017-02-01 Thread Vivi, Rodrigo


Reviewed-by: Rodrigo Vivi 

> On Feb 1, 2017, at 5:46 AM, Nikula, Jani  wrote:
> 
> Apparently there are machines out there with Skylake CPU and KabyPoint
> PCH. Judging from our driver code, there doesn't seem to be any code
> paths that would do anything different between SunrisePoint and
> KabyPoint PCHs, so it would seem okay to accept the combo without
> warnings.
> 
> Fixes: 22dea0be50b2 ("drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.")
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2017-February/118611.html
> Reported-by: Rainer Koenig 
> Cc: Rainer Koenig 
> Cc: Rodrigo Vivi 
> Cc:  # v4.8+
> Signed-off-by: Jani Nikula 
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 267d5f8c49e1..6a430648fa71 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -213,7 +213,8 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>} else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
>dev_priv->pch_type = PCH_KBP;
>DRM_DEBUG_KMS("Found KabyPoint PCH\n");
> -WARN_ON(!IS_KABYLAKE(dev_priv));
> +WARN_ON(!IS_SKYLAKE(dev_priv) &&
> +!IS_KABYLAKE(dev_priv));
>} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
>   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
>   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] tests/kms_plane_multiple: Test only with maximum number of planes

2017-02-01 Thread Robert Foss

I was pondering making this change myself, but didn't dare change the
functional aspects of the test.

Feel free to add my r-b.


Rob.

On 2017-02-01 09:12 AM, Mika Kahola wrote:

To be more suitable for BAT testing, let's modify the test such a way
that it only uses the maximum number of available planes. This reduces
the total number of subtests.

Cc: Robert Foss 
Signed-off-by: Mika Kahola 
---
 tests/kms_plane_multiple.c | 91 +++---
 1 file changed, 37 insertions(+), 54 deletions(-)

diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index bb84878..48f870e 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -171,7 +171,7 @@ create_fb_for_mode_position(data_t *data, igt_output_t 
*output, drmModeModeInfo
mode->hdisplay, mode->vdisplay,
color->red, color->green, color->blue);

-   for (int i = 0; i <= max_planes; i++) {
+   for (int i = 0; i < max_planes; i++) {
if (data->plane[i]->type == DRM_PLANE_TYPE_PRIMARY)
continue;
igt_paint_color(cr, rect_x[i], rect_y[i],
@@ -211,7 +211,7 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t 
*color,
/* planes with random positions */
x[primary->index] = 0;
y[primary->index] = 0;
-   for (i = 1; i <= max_planes; i++) {
+   for (i = 0; i < max_planes; i++) {
igt_plane_t *plane = igt_output_get_plane(output, i);

if (plane->type == DRM_PLANE_TYPE_PRIMARY)
@@ -247,7 +247,7 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t 
*color,
 static void
 test_atomic_plane_position_with_output(data_t *data, enum pipe pipe,
   igt_output_t *output, int n_planes,
-  int max_planes, uint64_t tiling)
+  uint64_t tiling)
 {
char buf[256];
struct drm_event *e = (void *)buf;
@@ -270,7 +270,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,
}

igt_info("Testing connector %s using pipe %s with %d planes %s with seed 
%d\n",
-igt_output_name(output), kmstest_pipe_name(pipe), max_planes,
+igt_output_name(output), kmstest_pipe_name(pipe), n_planes,
 info, opt.seed);

test_init(data, pipe, n_planes);
@@ -280,7 +280,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,

i = 0;
while (i < iterations || loop_forever) {
-   prepare_planes(data, pipe, , tiling, max_planes, output);
+   prepare_planes(data, pipe, , tiling, n_planes, output);

vblank_start = kmstest_get_vblank(data->display.drm_fd, pipe,
  DRM_VBLANK_NEXTONMISS);
@@ -316,7 +316,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,
 static void
 test_legacy_plane_position_with_output(data_t *data, enum pipe pipe,
   igt_output_t *output, int n_planes,
-  int max_planes, uint64_t tiling)
+  uint64_t tiling)
 {
test_position_t test = { .data = data };
color_t blue  = { 0.0f, 0.0f, 1.0f };
@@ -336,7 +336,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,
}

igt_info("Testing connector %s using pipe %s with %d planes %s with seed 
%d\n",
-igt_output_name(output), kmstest_pipe_name(pipe), max_planes,
+igt_output_name(output), kmstest_pipe_name(pipe), n_planes,
 info, opt.seed);

test_init(data, pipe, n_planes);
@@ -346,7 +346,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,

i = 0;
while (i < iterations || loop_forever) {
-   prepare_planes(data, pipe, , tiling, max_planes, output);
+   prepare_planes(data, pipe, , tiling, n_planes, output);

igt_display_commit2(>display, COMMIT_LEGACY);

@@ -366,7 +366,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,

 static void
 test_plane_position(data_t *data, enum pipe pipe, bool atomic, int n_planes,
-   int max_planes, uint64_t tiling)
+   uint64_t tiling)
 {
igt_output_t *output;
int connected_outs;
@@ -376,7 +376,6 @@ test_plane_position(data_t *data, enum pipe pipe, bool 
atomic, int n_planes,
igt_require(data->display.is_atomic);

igt_skip_on(pipe >= data->display.n_pipes);
-   igt_skip_on(max_planes >= data->display.pipes[pipe].n_planes);

if ((tiling == LOCAL_I915_FORMAT_MOD_Y_TILED ||
 tiling == LOCAL_I915_FORMAT_MOD_Yf_TILED))
@@ -392,14 +391,12 @@ test_plane_position(data_t *data, 

Re: [Intel-gfx] [PATCH v2 32/38] drm/i915: Verify page layout for rotated VMA

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 02:33:22PM +, Tvrtko Ursulin wrote:
> 
> On 19/01/2017 11:41, Chris Wilson wrote:
> >Exercise creating rotated VMA and checking the page order within.
> >
> >v2: Be more creative in rotated params
> >
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/selftests/i915_vma.c | 177 
> > ++
> > 1 file changed, 177 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c 
> >b/drivers/gpu/drm/i915/selftests/i915_vma.c
> >index b45b392444e4..2bda93f53b47 100644
> >--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> >+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> >@@ -310,11 +310,188 @@ static int igt_vma_pin1(void *arg)
> > return err;
> > }
> >
> >+static unsigned long rotated_index(const struct intel_rotation_info *r,
> >+   unsigned int n,
> >+   unsigned int x,
> >+   unsigned int y)
> >+{
> >+return (r->plane[n].stride * (r->plane[n].height - y - 1) +
> >+r->plane[n].offset + x);
> >+}
> >+
> >+static struct scatterlist *
> >+assert_rotated(struct drm_i915_gem_object *obj,
> >+   const struct intel_rotation_info *r, unsigned int n,
> >+   struct scatterlist *sg)
> >+{
> >+unsigned int x, y;
> >+
> >+for (x = 0; x < r->plane[n].width; x++) {
> >+for (y = 0; y < r->plane[n].height; y++) {
> >+unsigned long src_idx;
> >+dma_addr_t src;
> >+
> >+src_idx = rotated_index(r, n, x, y);
> >+src = i915_gem_object_get_dma_address(obj, src_idx);
> >+
> >+if (sg_dma_len(sg) != PAGE_SIZE) {
> >+pr_err("Invalid sg.length, found %d, expected 
> >%lu for rotated page (%d, %d) [src index %lu]\n",
> >+   sg_dma_len(sg), PAGE_SIZE,
> >+   x, y, src_idx);
> >+return ERR_PTR(-EINVAL);
> >+}
> >+
> >+if (sg_dma_address(sg) != src) {
> >+pr_err("Invalid address for rotated page (%d, 
> >%d) [src index %lu]\n",
> >+   x, y, src_idx);
> >+return ERR_PTR(-EINVAL);
> >+}
> >+
> >+sg = sg_next(sg);
> >+}
> >+}
> >+
> >+return sg;
> >+}
> >+
> >+static unsigned int rotated_size(const struct intel_rotation_plane_info *a,
> >+ const struct intel_rotation_plane_info *b)
> >+{
> >+return a->width * a->height + b->width * b->height;
> >+}
> >+
> >+static int igt_vma_rotate(void *arg)
> >+{
> >+struct drm_i915_private *i915 = arg;
> >+struct drm_i915_gem_object *obj;
> >+const struct intel_rotation_plane_info planes[] = {
> >+{ .width = 1, .height = 1, .stride = 1 },
> >+{ .width = 3, .height = 5, .stride = 4 },
> >+{ .width = 5, .height = 3, .stride = 7 },
> >+{ .width = 6, .height = 4, .stride = 6 },
> 
> 4x6 stride 4 could be added if you were going for all combinations
> of wide/tall, equal stride and wider stride.

Just trying to pick some interesting ones. No rhyme or reason.

> >+{ }
> >+}, *a, *b;
> >+const unsigned int max_pages = 64;
> >+int err = -ENOMEM;
> >+
> >+/* Create VMA for many different combinations of planes and check
> >+ * that the page layout within the rotated VMA match our expectations.
> >+ */
> >+
> >+obj = i915_gem_object_create_internal(i915, max_pages * PAGE_SIZE);
> >+if (IS_ERR(obj))
> >+goto err;
> >+
> >+for (a = planes; a->width; a++) {
> >+for (b = planes + ARRAY_SIZE(planes); b-- != planes; ) {
> >+struct i915_ggtt_view view;
> >+struct scatterlist *sg;
> >+unsigned int n, max_offset;
> >+
> >+max_offset = max(a->stride * a->height,
> >+ b->stride * b->height);
> 
> It shouldn't be min?
> 
> >+GEM_BUG_ON(max_offset >= max_pages);
> >+max_offset = max_pages - max_offset;

No, because it is inverted ^

> >+view.type = I915_GGTT_VIEW_ROTATED;
> >+view.rotated.plane[0] = *a;
> >+view.rotated.plane[1] = *b;
> 
> Single plane tests could be added as well.

There are. Second plane is set to {0}. That's the only way to do single
plane tests, as I was thinking second plane with a first plane would be
illegal?

> >+
> >+
> >for_each_prime_number_from(view.rotated.plane[0].offset, 0, max_offset) {
> >+
> >for_each_prime_number_from(view.rotated.plane[1].offset, 0, max_offset) {
> 
> I would try all offsets here and not only primes since it 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode

2017-02-01 Thread Takashi Iwai
On Wed, 01 Feb 2017 15:45:24 +0100,
Ville Syrjälä wrote:
> 
> On Tue, Jan 31, 2017 at 10:36:44PM +0100, Takashi Iwai wrote:
> > From: Pierre-Louis Bossart 
> > 
> > Enable unmute/mute amp notification. This doesn't seem to affect
> > HDMI support so this is done unconditionally.
> > 
> > An earlier version of this patch set a chicken bit at address 0x62F38
> > prior to the mute/unmute but this register doesn't seem to do anything
> > so this phase was removed.
> > 
> > Signed-off-by: Pierre-Louis Bossart 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h| 10 ++
> >  drivers/gpu/drm/i915/intel_lpe_audio.c | 17 +
> >  2 files changed, 27 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a9ffc8df241b..8fcc80cb864b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
> >  #define I915_HDMI_LPE_AUDIO_BASE   (VLV_DISPLAY_BASE + 0x65000)
> >  #define I915_HDMI_LPE_AUDIO_SIZE   0x1000
> >  
> > +/* DisplayPort Audio w/ LPE */
> > +#define VLV_AUD_PORT_EN_B_DBG  (VLV_DISPLAY_BASE + 0x62F20)
> > +#define VLV_AUD_PORT_EN_C_DBG  (VLV_DISPLAY_BASE + 0x62F30)
> > +#define VLV_AUD_PORT_EN_D_DBG  (VLV_DISPLAY_BASE + 0x62F34)
> > +#define VLV_AUD_PORT_EN_DBG(port)  _MMIO_PORT3((port) - PORT_B,   \
> > +   VLV_AUD_PORT_EN_B_DBG, \
> > +   VLV_AUD_PORT_EN_C_DBG, \
> > +   VLV_AUD_PORT_EN_D_DBG)
> > +#define VLV_AMP_MUTE   (1 << 1)
> > +
> >  #define GEN6_BSD_RNCID _MMIO(0x12198)
> >  
> >  #define GEN7_FF_THREAD_MODE_MMIO(0x20a0)
> > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index 245523e14418..f95624a46f27 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private 
> > *dev_priv,
> >  {
> > unsigned long irq_flags;
> > struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
> > +   u32 audio_enable;
> > +   i915_reg_t mmio;
> >  
> > if (!HAS_LPE_AUDIO(dev_priv))
> > return;
> >  
> > +   if (port == PORT_A) {
> > +   DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n");
> > +   return;
> > +   }
> 
> Port A doesn't exists on these platforms at all. So this is
> just dead code.
> 
> > +
> > pdata = dev_get_platdata(
> > &(dev_priv->lpe_audio.platdev->dev));
> >  
> > spin_lock_irqsave(>lpe_audio_slock, irq_flags);
> >  
> > +   mmio = VLV_AUD_PORT_EN_DBG(port);
> 
> I'm not a fan of these temporary reg offset variables. Makes it hard to
> figure out later which register is being frobbed, especially when the
> variable name doesn't say what it actually is (like in this case). So
> I'd like to see this killed off.

How about something like below?


thanks,

Takashi

-- 8< --
From: Pierre-Louis Bossart 
Subject: [PATCH v2] drm/i915: add DisplayPort amp unmute for LPE audio mode

Enable unmute/mute amp notification. This doesn't seem to affect
HDMI support so this is done unconditionally.

An earlier version of this patch set a chicken bit at address 0x62F38
prior to the mute/unmute but this register doesn't seem to do anything
so this phase was removed.

v1->v2: Drop needless pipe A check, avoid temporary reg offset variable.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_reg.h| 10 ++
 drivers/gpu/drm/i915/intel_lpe_audio.c | 12 
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a9ffc8df241b..8fcc80cb864b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
 #define I915_HDMI_LPE_AUDIO_BASE   (VLV_DISPLAY_BASE + 0x65000)
 #define I915_HDMI_LPE_AUDIO_SIZE   0x1000
 
+/* DisplayPort Audio w/ LPE */
+#define VLV_AUD_PORT_EN_B_DBG  (VLV_DISPLAY_BASE + 0x62F20)
+#define VLV_AUD_PORT_EN_C_DBG  (VLV_DISPLAY_BASE + 0x62F30)
+#define VLV_AUD_PORT_EN_D_DBG  (VLV_DISPLAY_BASE + 0x62F34)
+#define VLV_AUD_PORT_EN_DBG(port)  _MMIO_PORT3((port) - PORT_B,   \
+   VLV_AUD_PORT_EN_B_DBG, \
+   VLV_AUD_PORT_EN_C_DBG, \
+   VLV_AUD_PORT_EN_D_DBG)
+#define VLV_AMP_MUTE   

Re: [Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode

2017-02-01 Thread Ville Syrjälä
On Tue, Jan 31, 2017 at 10:36:44PM +0100, Takashi Iwai wrote:
> From: Pierre-Louis Bossart 
> 
> Enable unmute/mute amp notification. This doesn't seem to affect
> HDMI support so this is done unconditionally.
> 
> An earlier version of this patch set a chicken bit at address 0x62F38
> prior to the mute/unmute but this register doesn't seem to do anything
> so this phase was removed.
> 
> Signed-off-by: Pierre-Louis Bossart 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/i915_reg.h| 10 ++
>  drivers/gpu/drm/i915/intel_lpe_audio.c | 17 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a9ffc8df241b..8fcc80cb864b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
>  #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
>  #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
>  
> +/* DisplayPort Audio w/ LPE */
> +#define VLV_AUD_PORT_EN_B_DBG(VLV_DISPLAY_BASE + 0x62F20)
> +#define VLV_AUD_PORT_EN_C_DBG(VLV_DISPLAY_BASE + 0x62F30)
> +#define VLV_AUD_PORT_EN_D_DBG(VLV_DISPLAY_BASE + 0x62F34)
> +#define VLV_AUD_PORT_EN_DBG(port)_MMIO_PORT3((port) - PORT_B,   \
> + VLV_AUD_PORT_EN_B_DBG, \
> + VLV_AUD_PORT_EN_C_DBG, \
> + VLV_AUD_PORT_EN_D_DBG)
> +#define VLV_AMP_MUTE (1 << 1)
> +
>  #define GEN6_BSD_RNCID   _MMIO(0x12198)
>  
>  #define GEN7_FF_THREAD_MODE  _MMIO(0x20a0)
> diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> b/drivers/gpu/drm/i915/intel_lpe_audio.c
> index 245523e14418..f95624a46f27 100644
> --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> @@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private 
> *dev_priv,
>  {
>   unsigned long irq_flags;
>   struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
> + u32 audio_enable;
> + i915_reg_t mmio;
>  
>   if (!HAS_LPE_AUDIO(dev_priv))
>   return;
>  
> + if (port == PORT_A) {
> + DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n");
> + return;
> + }

Port A doesn't exists on these platforms at all. So this is
just dead code.

> +
>   pdata = dev_get_platdata(
>   &(dev_priv->lpe_audio.platdev->dev));
>  
>   spin_lock_irqsave(>lpe_audio_slock, irq_flags);
>  
> + mmio = VLV_AUD_PORT_EN_DBG(port);

I'm not a fan of these temporary reg offset variables. Makes it hard to
figure out later which register is being frobbed, especially when the
variable name doesn't say what it actually is (like in this case). So
I'd like to see this killed off.

> + audio_enable = I915_READ(mmio);
> +
>   if (eld != NULL) {
>   memcpy(pdata->eld.eld_data, eld,
>   HDMI_MAX_ELD_BYTES);
> @@ -357,11 +367,18 @@ void intel_lpe_audio_notify(struct drm_i915_private 
> *dev_priv,
>   pdata->tmds_clock_speed = tmds_clk_speed;
>   if (link_rate)
>   pdata->link_rate = link_rate;
> +
> + /* Unmute the amp for both DP and HDMI */
> + I915_WRITE(mmio, audio_enable & ~VLV_AMP_MUTE);
> +
>   } else {
>   memset(pdata->eld.eld_data, 0,
>   HDMI_MAX_ELD_BYTES);
>   pdata->hdmi_connected = false;
>   pdata->dp_output = false;
> +
> + /* Mute the amp for both DP and HDMI */
> + I915_WRITE(mmio, audio_enable | VLV_AMP_MUTE);
>   }
>  
>   if (pdata->notify_audio_lpe)
> -- 
> 2.11.0

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


Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators

2017-02-01 Thread Jani Nikula
On Tue, 31 Jan 2017, Mika Kahola  wrote:
> Looks ok.
>
> Acked-by: Mika Kahola 

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

BR,
Jani.

>
> On Wed, 2017-01-25 at 19:43 +0530, Vidya Srinivas wrote:
>> From: Uma Shankar 
>> 
>> Enable MIPI IO WA for BXT DSI as per bspec and
>> program the DSI regulators.
>> 
>> v2: Moved IO enable to pre-enable as per Mika's
>> review comments. Also reused the existing register
>> definition for BXT_P_CR_GT_DISP_PWRON.
>> 
>> v3: Added Programming the DSI regulators as per disable/enable
>> sequences.
>> 
>> v4: Restricting regulator changes to BXT as suggested by
>> Jani/Mika
>> 
>> v5: Removed redundant read/modify for regulator register as
>> per Jani's comment. Maintain enable/disable symmetry as per spec.
>> 
>> Signed-off-by: Uma Shankar 
>> Signed-off-by: Vidya Srinivas 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  |  7 +++
>>  drivers/gpu/drm/i915/intel_dsi.c | 24 
>>  2 files changed, 31 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 00970aa..0a9ad44 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells {
>>  _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
>>  
>>  #define BXT_P_CR_GT_DISP_PWRON  _MMIO(0x138090)
>> +#define  MIPIO_RST_CTRL (1 << 2)
>>  
>>  #define _BXT_PHY_CTL_DDI_A  0x64C00
>>  #define _BXT_PHY_CTL_DDI_B  0x64C10
>> @@ -8301,6 +8302,12 @@ enum {
>>  #define _BXT_MIPIC_PORT_CTRL0x6B8C0
>>  #define BXT_MIPI_PORT_CTRL(tc)  _MMIO_MIPI(tc,
>> _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL)
>>  
>> +#define BXT_P_DSI_REGULATOR_CFG _MMIO(0x16002
>> 0)
>> +#define  STAP_SELECT(1 << 0)
>> +
>> +#define BXT_P_DSI_REGULATOR_TX_CTRL _MMIO(0x160054)
>> +#define  HS_IO_CTRL_SELECT  (1 << 0)
>> +
>>  #define  DPI_ENABLE (1 << 31)
>> /* A + C */
>>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT  27
>>  #define  MIPIA_MIPI4DPHY_DELAY_COUNT_MASK   (0xf << 27)
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 16732e7..c98234e 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct
>> intel_encoder *encoder,
>>  struct drm_i915_private *dev_priv = to_i915(encoder-
>> >base.dev);
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(
>> >base);
>>  enum port port;
>> +u32 val;
>>  
>>  DRM_DEBUG_KMS("\n");
>>  
>> @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct
>> intel_encoder *encoder,
>>  intel_disable_dsi_pll(encoder);
>>  intel_enable_dsi_pll(encoder, pipe_config);
>>  
>> +if (IS_BROXTON(dev_priv)) {
>> +/* Add MIPI IO reset programming for modeset */
>> +val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
>> +I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
>> +val | MIPIO_RST_CTRL);
>> +
>> +/* Power up DSI regulator */
>> +I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
>> +I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
>> +}
>> +
>>  intel_dsi_prepare(encoder, pipe_config);
>>  
>>  /* Panel Enable over CRC PMIC */
>> @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct
>> intel_encoder *encoder,
>>  {
>>  struct drm_i915_private *dev_priv = to_i915(encoder-
>> >base.dev);
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(
>> >base);
>> +u32 val;
>>  
>>  DRM_DEBUG_KMS("\n");
>>  
>> @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct
>> intel_encoder *encoder,
>>  
>>  intel_dsi_clear_device_ready(encoder);
>>  
>> +if (IS_BROXTON(dev_priv)) {
>> +/* Power down DSI regulator to save power */
>> +I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
>> +I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL,
>> HS_IO_CTRL_SELECT);
>> +
>> +/* Add MIPI IO reset programming for modeset */
>> +val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
>> +I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
>> +val & ~MIPIO_RST_CTRL);
>> +}
>> +
>>  intel_disable_dsi_pll(encoder);
>>  
>>  if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {

-- 
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 RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-01 Thread Ville Syrjälä
On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
> > Hello,
> >
> > On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
> >> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
> >>> From: Chris Wilson 
> >>>
> >>> As the introduced comment admits this is clearly a workaround, but for
> >>> me this is the only known way to make my Lenovo X201 work without
> >>> flickering and crashing.
> >>>
> >>> Signed-off-by: Uwe Kleine-König 
> >>> [uwe: added changelog, comment and restrict to GEN5]
> >>> ---
> >>> Hello,
> >>>
> >>> as I don't like having to compile my own kernel (which has this 
> >>> workaround) I
> >>> suggest to apply this patch until someone with more knowledge than me 
> >>> about
> >>> i915 finds the muse and time to work on this.
> >> Just curious, does this help?
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index ae2c0bb4b2e8..13de4c526ca6 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
> >> intel_crtc_state *cstate,
> >> * this is necessary to avoid flickering.
> >> */
> >>int cpp = 4;
> >> -  int width = pstate->base.visible ? pstate->base.crtc_w : 64;
> >> +  int width = 256;
> >>  
> >>if (!cstate->base.active)
> >>return 0;
> >>
> > On a kernel with this patch applied I cannot reproduce the flickering. I
> > keep that kernel running but expect that it also fixes the crash.
> >
> > Best regards
> > Uwe
> 
> Ok that's good news.
> 
> Maybe ville or matt can comment whether this patch is the right fix?

Well, it's just extending the hack even further. The right fix would be
to fix the wm programming sequence to respect the frame boundaries
correctly (ie. my old vblank based wm stuff).

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


Re: [Intel-gfx] [PATCH v2 32/38] drm/i915: Verify page layout for rotated VMA

2017-02-01 Thread Tvrtko Ursulin


On 19/01/2017 11:41, Chris Wilson wrote:

Exercise creating rotated VMA and checking the page order within.

v2: Be more creative in rotated params

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_vma.c | 177 ++
 1 file changed, 177 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c 
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index b45b392444e4..2bda93f53b47 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -310,11 +310,188 @@ static int igt_vma_pin1(void *arg)
return err;
 }

+static unsigned long rotated_index(const struct intel_rotation_info *r,
+  unsigned int n,
+  unsigned int x,
+  unsigned int y)
+{
+   return (r->plane[n].stride * (r->plane[n].height - y - 1) +
+   r->plane[n].offset + x);
+}
+
+static struct scatterlist *
+assert_rotated(struct drm_i915_gem_object *obj,
+  const struct intel_rotation_info *r, unsigned int n,
+  struct scatterlist *sg)
+{
+   unsigned int x, y;
+
+   for (x = 0; x < r->plane[n].width; x++) {
+   for (y = 0; y < r->plane[n].height; y++) {
+   unsigned long src_idx;
+   dma_addr_t src;
+
+   src_idx = rotated_index(r, n, x, y);
+   src = i915_gem_object_get_dma_address(obj, src_idx);
+
+   if (sg_dma_len(sg) != PAGE_SIZE) {
+   pr_err("Invalid sg.length, found %d, expected %lu 
for rotated page (%d, %d) [src index %lu]\n",
+  sg_dma_len(sg), PAGE_SIZE,
+  x, y, src_idx);
+   return ERR_PTR(-EINVAL);
+   }
+
+   if (sg_dma_address(sg) != src) {
+   pr_err("Invalid address for rotated page (%d, %d) 
[src index %lu]\n",
+  x, y, src_idx);
+   return ERR_PTR(-EINVAL);
+   }
+
+   sg = sg_next(sg);
+   }
+   }
+
+   return sg;
+}
+
+static unsigned int rotated_size(const struct intel_rotation_plane_info *a,
+const struct intel_rotation_plane_info *b)
+{
+   return a->width * a->height + b->width * b->height;
+}
+
+static int igt_vma_rotate(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct drm_i915_gem_object *obj;
+   const struct intel_rotation_plane_info planes[] = {
+   { .width = 1, .height = 1, .stride = 1 },
+   { .width = 3, .height = 5, .stride = 4 },
+   { .width = 5, .height = 3, .stride = 7 },
+   { .width = 6, .height = 4, .stride = 6 },


4x6 stride 4 could be added if you were going for all combinations of 
wide/tall, equal stride and wider stride.



+   { }
+   }, *a, *b;
+   const unsigned int max_pages = 64;
+   int err = -ENOMEM;
+
+   /* Create VMA for many different combinations of planes and check
+* that the page layout within the rotated VMA match our expectations.
+*/
+
+   obj = i915_gem_object_create_internal(i915, max_pages * PAGE_SIZE);
+   if (IS_ERR(obj))
+   goto err;
+
+   for (a = planes; a->width; a++) {
+   for (b = planes + ARRAY_SIZE(planes); b-- != planes; ) {
+   struct i915_ggtt_view view;
+   struct scatterlist *sg;
+   unsigned int n, max_offset;
+
+   max_offset = max(a->stride * a->height,
+b->stride * b->height);


It shouldn't be min?


+   GEM_BUG_ON(max_offset >= max_pages);
+   max_offset = max_pages - max_offset;
+
+   view.type = I915_GGTT_VIEW_ROTATED;
+   view.rotated.plane[0] = *a;
+   view.rotated.plane[1] = *b;


Single plane tests could be added as well.


+
+   
for_each_prime_number_from(view.rotated.plane[0].offset, 0, max_offset) {
+   
for_each_prime_number_from(view.rotated.plane[1].offset, 0, max_offset) {


I would try all offsets here and not only primes since it is super fast 
and more importantly more realistic.



+   struct i915_address_space *vm =
+   >ggtt.base;
+   struct i915_vma *vma;
+
+   vma = i915_vma_instance(obj, vm, );
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+ 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Add interrupt-pending check to intel_execlists_idle()

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Add interrupt-pending check to 
intel_execlists_idle()
URL   : https://patchwork.freedesktop.org/series/18921/
State : success

== Summary ==

Series 18921v1 drm/i915/execlists: Add interrupt-pending check to 
intel_execlists_idle()
https://patchwork.freedesktop.org/api/1.0/series/18921/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

eb9b7b42023edc1b5849d1ff3bef490b492067a3 drm-tip: 2017y-02m-01d-11h-09m-17s UTC 
integration manifest
4d7c172 drm/i915/execlists: Add interrupt-pending check to 
intel_execlists_idle()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3664/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Problem with i915 driver when mixing Skylake CPU with Kabylake chipset

2017-02-01 Thread Rainer Koenig
Am 01.02.2017 um 14:50 schrieb Jani Nikula:

>> I read from that, that the driver issues the warning when PCH is a
>> Kabypoint PCH, but the CPU based graphics is not from a Kabylake CPU.
> 
> It's just a warning. But if there really are such combos out there, we
> should get rid of the warning. Patch sent [1].

Seent the patch, thanks. Those combos are defined by our product
managers to satisfy the demand for systems with the latest chipset that
can be used with Windows 7. ;-) My job is to make them usable for Linux
and now I run into problemns...

>> So my questions is what is the status of the driver regarding the
>> combination of Skylake CPU with Kabylake chipset?
> 
> I'm not aware of any issues, IIUC there shouldn't be differences between
> the PCHs that would affect your perceived userspace segfault, and it
> shouldn't segfault anyway based on what i915 does.

Ack. The segfault thing was the best I could get so far. Other distros
like SLED 12 SP2 just die during bootup. I have to find a way to get
debugger access / serial console working on that system so that I can
find out more...

Thanks
Rainer
-- 
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Clients
FJ EMEIA PR PSO PM CCD ENG SW OSS

Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany

Telephone: +49-821-804-3321
Telefax:   +49-821-804-2131
Mail:  mailto:rainer.koe...@ts.fujitsu.com

Internet ts.fujtsu.com
Company Details  ts.fujitsu.com/imprint.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] tests/kms_plane_multiple: Test only with maximum number of planes

2017-02-01 Thread Mika Kahola
To be more suitable for BAT testing, let's modify the test such a way
that it only uses the maximum number of available planes. This reduces
the total number of subtests.

Cc: Robert Foss 
Signed-off-by: Mika Kahola 
---
 tests/kms_plane_multiple.c | 91 +++---
 1 file changed, 37 insertions(+), 54 deletions(-)

diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index bb84878..48f870e 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -171,7 +171,7 @@ create_fb_for_mode_position(data_t *data, igt_output_t 
*output, drmModeModeInfo
mode->hdisplay, mode->vdisplay,
color->red, color->green, color->blue);
 
-   for (int i = 0; i <= max_planes; i++) {
+   for (int i = 0; i < max_planes; i++) {
if (data->plane[i]->type == DRM_PLANE_TYPE_PRIMARY)
continue;
igt_paint_color(cr, rect_x[i], rect_y[i],
@@ -211,7 +211,7 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t 
*color,
/* planes with random positions */
x[primary->index] = 0;
y[primary->index] = 0;
-   for (i = 1; i <= max_planes; i++) {
+   for (i = 0; i < max_planes; i++) {
igt_plane_t *plane = igt_output_get_plane(output, i);
 
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
@@ -247,7 +247,7 @@ prepare_planes(data_t *data, enum pipe pipe_id, color_t 
*color,
 static void
 test_atomic_plane_position_with_output(data_t *data, enum pipe pipe,
   igt_output_t *output, int n_planes,
-  int max_planes, uint64_t tiling)
+  uint64_t tiling)
 {
char buf[256];
struct drm_event *e = (void *)buf;
@@ -270,7 +270,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,
}
 
igt_info("Testing connector %s using pipe %s with %d planes %s with 
seed %d\n",
-igt_output_name(output), kmstest_pipe_name(pipe), max_planes,
+igt_output_name(output), kmstest_pipe_name(pipe), n_planes,
 info, opt.seed);
 
test_init(data, pipe, n_planes);
@@ -280,7 +280,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,
 
i = 0;
while (i < iterations || loop_forever) {
-   prepare_planes(data, pipe, , tiling, max_planes, output);
+   prepare_planes(data, pipe, , tiling, n_planes, output);
 
vblank_start = kmstest_get_vblank(data->display.drm_fd, pipe,
  DRM_VBLANK_NEXTONMISS);
@@ -316,7 +316,7 @@ test_atomic_plane_position_with_output(data_t *data, enum 
pipe pipe,
 static void
 test_legacy_plane_position_with_output(data_t *data, enum pipe pipe,
   igt_output_t *output, int n_planes,
-  int max_planes, uint64_t tiling)
+  uint64_t tiling)
 {
test_position_t test = { .data = data };
color_t blue  = { 0.0f, 0.0f, 1.0f };
@@ -336,7 +336,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,
}
 
igt_info("Testing connector %s using pipe %s with %d planes %s with 
seed %d\n",
-igt_output_name(output), kmstest_pipe_name(pipe), max_planes,
+igt_output_name(output), kmstest_pipe_name(pipe), n_planes,
 info, opt.seed);
 
test_init(data, pipe, n_planes);
@@ -346,7 +346,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,
 
i = 0;
while (i < iterations || loop_forever) {
-   prepare_planes(data, pipe, , tiling, max_planes, output);
+   prepare_planes(data, pipe, , tiling, n_planes, output);
 
igt_display_commit2(>display, COMMIT_LEGACY);
 
@@ -366,7 +366,7 @@ test_legacy_plane_position_with_output(data_t *data, enum 
pipe pipe,
 
 static void
 test_plane_position(data_t *data, enum pipe pipe, bool atomic, int n_planes,
-   int max_planes, uint64_t tiling)
+   uint64_t tiling)
 {
igt_output_t *output;
int connected_outs;
@@ -376,7 +376,6 @@ test_plane_position(data_t *data, enum pipe pipe, bool 
atomic, int n_planes,
igt_require(data->display.is_atomic);
 
igt_skip_on(pipe >= data->display.n_pipes);
-   igt_skip_on(max_planes >= data->display.pipes[pipe].n_planes);
 
if ((tiling == LOCAL_I915_FORMAT_MOD_Y_TILED ||
 tiling == LOCAL_I915_FORMAT_MOD_Yf_TILED))
@@ -392,14 +391,12 @@ test_plane_position(data_t *data, enum pipe pipe, bool 
atomic, int n_planes,
if (atomic)
test_atomic_plane_position_with_output(data, pipe,
   

Re: [Intel-gfx] [PATCH v2 30/38] drm/i915: Test creation of VMA

2017-02-01 Thread Chris Wilson
On Tue, Jan 31, 2017 at 12:50:20PM +0200, Joonas Lahtinen wrote:
> On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> > +   for_each_prime_number(num_obj, ULONG_MAX - 1) {
> > +   for (; no < num_obj; no++) {
> > +   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > +   if (IS_ERR(obj))
> > +   goto err;
> > +
> > +   list_add(>batch_pool_link, );
> 
> See below;
> 
> > +   }
> > +
> > +   nc = 0;
> > +   for_each_prime_number(num_ctx, MAX_CONTEXT_HW_ID) {
> > +   for (; nc < num_ctx; nc++) {
> > +   ctx = mock_context(i915, "mock");
> > +   if (!ctx)
> > +   goto err;
> > +
> > +   list_move(>link, );
> 
> Why the difference?

I was acquiring ownership of the context from another list.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915/execlists: Add interrupt-pending check to intel_execlists_idle()

2017-02-01 Thread kbuild test robot
Hi Chris,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.10-rc6 next-20170201]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-execlists-Add-interrupt-pending-check-to-intel_execlists_idle/20170201-212404
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x014-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from include/linux/bitops.h:36:0,
from include/linux/kernel.h:10,
from include/linux/interrupt.h:5,
from drivers/gpu/drm/i915/intel_lrc.c:134:
   drivers/gpu/drm/i915/intel_lrc.c: In function 'intel_execlists_idle':
>> drivers/gpu/drm/i915/intel_lrc.c:551:16: error: 'ENGINE_IRQ_EXECLIST' 
>> undeclared (first use in this function)
  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
   ^
   arch/x86/include/asm/bitops.h:349:25: note: in definition of macro 'test_bit'
 (__builtin_constant_p((nr))  \
^~
   drivers/gpu/drm/i915/intel_lrc.c:551:16: note: each undeclared identifier is 
reported only once for each function it appears in
  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
   ^
   arch/x86/include/asm/bitops.h:349:25: note: in definition of macro 'test_bit'
 (__builtin_constant_p((nr))  \
^~
>> drivers/gpu/drm/i915/intel_lrc.c:551:44: error: 'struct intel_engine_cs' has 
>> no member named 'irq_posted'; did you mean 'irq_tasklet'?
  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
   ^
   arch/x86/include/asm/bitops.h:350:30: note: in definition of macro 'test_bit'
  ? constant_test_bit((nr), (addr)) \
 ^~~~
>> drivers/gpu/drm/i915/intel_lrc.c:551:44: error: 'struct intel_engine_cs' has 
>> no member named 'irq_posted'; did you mean 'irq_tasklet'?
  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
   ^
   arch/x86/include/asm/bitops.h:351:30: note: in definition of macro 'test_bit'
  : variable_test_bit((nr), (addr)))
 ^~~~

vim +/ENGINE_IRQ_EXECLIST +551 drivers/gpu/drm/i915/intel_lrc.c

   545  
   546  if (!i915.enable_execlists)
   547  return true;
   548  
   549  for_each_engine(engine, dev_priv, id) {
   550  /* Interrupt/tasklet pending? */
 > 551  if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
   552  return false;
   553  
   554  /* Both ports drained, no more ELSP submission? */

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


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


Re: [Intel-gfx] [PATCH v2 02/38] drm/i915: Provide a hook for selftests

2017-02-01 Thread Chris Wilson
On Wed, Jan 25, 2017 at 01:50:01PM +0200, Joonas Lahtinen wrote:
> On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> > @@ -499,7 +501,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> >     if (vga_switcheroo_client_probe_defer(pdev))
> >     return -EPROBE_DEFER;
> >  
> > -   return i915_driver_load(pdev, ent);
> > +   err = i915_driver_load(pdev, ent);
> > +   if (err)
> > +   return err;
> > +
> > +   err = i915_live_selftests(pdev);
> > +   if (err) {
> > +   i915_driver_unload(pci_get_drvdata(pdev));
> > +   return err > 0 ? -ENOTTY : err;
> 
> What's up with this?

What's up with what? We want to bail from the pci initialisation, so
need to return some error. ENOTTY is chosen as we don't (and I expect
should never) use it from the selftests and the internal routines used.

> >  static void i915_pci_remove(struct pci_dev *pdev)
> > @@ -521,6 +533,11 @@ static struct pci_driver i915_pci_driver = {
> >  static int __init i915_init(void)
> >  {
> >     bool use_kms = true;
> > +   int err;
> > +
> > +   err = i915_mock_selftests();
> > +   if (err)
> > +   return err > 0 ? 0 : err;
> 
> Especially this, is this for skipping the device init completely?

Yes. 

> > +static int run_selftests(const char *name,
> > +    struct selftest *st,
> > +    unsigned int count,
> > +    void *data)
> > +{
> > +   int err = 0;
> > +
> > +   while (!i915_selftest.random_seed)
> > +   i915_selftest.random_seed = get_random_int();
> 
> You know that in theory this might take an eternity. I'm not sure why
> zero is not OK after this point?

You wanted each run to be with a different seed!

The prng generator does produces 0 if state = { 0 }, but that is avoided
by prandom_seed_state().

> > +
> > +   i915_selftest.timeout_jiffies =
> > +   i915_selftest.timeout_ms ?
> > +   msecs_to_jiffies_timeout(i915_selftest.timeout_ms) :
> > +   MAX_SCHEDULE_TIMEOUT;
> 
> You had a default value for the variable too, I guess that's not needed
> now, and gets some bytes off .data.

I can move this into every user, if that's what you mean?
-chris

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR
URL   : https://patchwork.freedesktop.org/series/18918/
State : warning

== Summary ==

Series 18918v1 drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR
https://patchwork.freedesktop.org/api/1.0/series/18918/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:226  dwarn:1   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

eb9b7b42023edc1b5849d1ff3bef490b492067a3 drm-tip: 2017y-02m-01d-11h-09m-17s UTC 
integration manifest
94d58e7 drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3663/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Problem with i915 driver when mixing Skylake CPU with Kabylake chipset

2017-02-01 Thread Jani Nikula
On Wed, 01 Feb 2017, Rainer Koenig  wrote:
> Hello,
>
> I'm investigating a problem on a machine that has a Kabylake PCH but a
> Skylake CPU i5-6500.
>
> Problem is that I can install and use distributions that are based on an
> older kernel, but newer Linux dristributions fail to boot even the
> installer.
>
> So far I managed to get Fedora 25 with a 4.9 kernel installed, but I
> cannot reach runlevel 5. Booting to runlevel 3 shows this message in the
> dmesg:
>
> [1.816627] [ cut here ]
> [1.816943] WARNING: CPU: 5 PID: 373 at
> drivers/gpu/drm/i915/i915_drv.c:210 i915_driver_load+0x1157/0x1410 [i915]
> [1.817193] WARN_ON(!((&({ struct drm_i915_private *__p; if
> (__builtin_types_compatible_p(typeof(*dev), struct drm_i915_private))
> __p = (struct drm_i915_private *)dev; else if
> (__builtin_types_compatible_p(typeof(*dev), struct drm_device)) __p =
> to_i915((struct drm_device *)dev); else do { bool __cond = !(!(1));
> extern void __compiletime_assert_210(void)
> __attribute__((error("BUILD_BUG failed"))); if (__cond)
> __compiletime_assert_210(); do { } while (0); } while (0); __p;
> })->info)->is_kabylake))
> [1.817251] e1000e :00:1f.6 enp0s31f6: renamed from eth0
> [1.818020] Modules linked in:
> [1.818185]  i915(+) i2c_algo_bit e1000e drm_kms_helper crc32c_intel
> drm ptp serio_raw pps_core video i2c_hid fjes
> [1.819091] CPU: 5 PID: 373 Comm: systemd-udevd Not tainted
> 4.9.5-200.fc25.x86_64 #1
>
> Looking at i95_drv.c I find this code snipped that seems to be
> responsible:
>
>
> } else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
> dev_priv->pch_type = PCH_SPT;
> DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> WARN_ON(!IS_SKYLAKE(dev_priv) &&
> !IS_KABYLAKE(dev_priv));
> } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
> dev_priv->pch_type = PCH_SPT;
> DRM_DEBUG_KMS("Found SunrisePoint LP
> PCH\n");
> WARN_ON(!IS_SKYLAKE(dev_priv) &&
> !IS_KABYLAKE(dev_priv));
> } else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
> dev_priv->pch_type = PCH_KBP;
> DRM_DEBUG_KMS("Found KabyPoint PCH\n");
> WARN_ON(!IS_KABYLAKE(dev_priv));
>
>
> I read from that, that the driver issues the warning when PCH is a
> Kabypoint PCH, but the CPU based graphics is not from a Kabylake CPU.

It's just a warning. But if there really are such combos out there, we
should get rid of the warning. Patch sent [1].

[1] 
http://patchwork.freedesktop.org/patch/msgid/1485956769-26015-1-git-send-email-jani.nik...@intel.com

> This explains the warnings in the dmesg. But if I want to start the GUI,
> the next problem rises:
>
> [  125.777880] gnome-shell[1665]: segfault at 0 ip 7f49b6712789 sp
> 7fff9100ca30 error 4 in libEGL.so.1.0.0[7f49b66f8000+3]
>
> So from my perspective it looks like, that something inside the i915
> driver is going wrong when we mix up Skylake CPUs with Kabylake
> Chipsets. The same system works pretty well when I replace the Skylake
> CPU with a Kabylake CPU.
>
> On the other hand we have boards with a H110 chipset (Sunrise Point)
> that also support Kabylake CPUs and where this problem doesn't occur.
>
> So my questions is what is the status of the driver regarding the
> combination of Skylake CPU with Kabylake chipset?

I'm not aware of any issues, IIUC there shouldn't be differences between
the PCHs that would affect your perceived userspace segfault, and it
shouldn't segfault anyway based on what i915 does.

BR,
Jani.


>
> Thanks
> Rainer

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

2017-02-01 Thread Jani Nikula
Apparently there are machines out there with Skylake CPU and KabyPoint
PCH. Judging from our driver code, there doesn't seem to be any code
paths that would do anything different between SunrisePoint and
KabyPoint PCHs, so it would seem okay to accept the combo without
warnings.

Fixes: 22dea0be50b2 ("drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.")
References: 
https://lists.freedesktop.org/archives/intel-gfx/2017-February/118611.html
Reported-by: Rainer Koenig 
Cc: Rainer Koenig 
Cc: Rodrigo Vivi 
Cc:  # v4.8+
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 267d5f8c49e1..6a430648fa71 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -213,7 +213,8 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
} else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_KBP;
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
-   WARN_ON(!IS_KABYLAKE(dev_priv));
+   WARN_ON(!IS_SKYLAKE(dev_priv) &&
+   !IS_KABYLAKE(dev_priv));
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
-- 
2.1.4

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


Re: [Intel-gfx] [PATCH v5] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 01:15:49PM +, Tvrtko Ursulin wrote:
> 
> On 01/02/2017 12:46, Chris Wilson wrote:
> >If we set the context-switch bit too early (and process the
> >user-interrupt and the context-switch as two separate passes through the
> >tasklet), we encounter the error from before that the CSB register may
> >be undefined. Possibly not since the user interrupt should mean the ring
> >is powered up (and so the register restored from the power context, one
> >hopes!), but there is no reason for us to read back the registers until
> >we see the interrupt telling us they have been updated.
> >
> >Note sure the best way to write that for simplicity, so I kept the patch
> >clean.
> >
> >if (!(iir & ((GT_RENDER_USER_INTERRUPT | 
> > GT_CONTEXT_SWITCH_INTERRUPT) << test_shift)))
> >return;
> >
> >if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
> >set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >
> >tasklet_hi_schedule(>irq_tasklet);
> >
> >if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
> >notify_ring(engine);
> >
> >add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-85 (-85)
> >function old new   delta
> >gen8_gt_irq_handler  756 671 -85
> >Total: Before=1093982, After=1093897, chg -0.01%
> >
> >Ok, gcc likes that a lot more.
> 
> What's this add/remove grow/shrink up/down business? Something from
> some standard tool?

That was ./scripts/bloat-o-meter

> Back to the topic - should we be concerned here that in execlist
> mode we might wake up the tasklet prematurely? If it manages to run
> and exit in the window between the user interrupt and the context
> interrupt it would just waste cycles. I can easily see ~150us
> between the two here. What do you think?

Been worrying, but it's been below the level of sensitivity whilst using
my bdw. If some person did have some superfine tools to probe
latency/throughput ;) and it highlighted this as a problem, I was thinking
that we would simply split the gen8/gen9 interrupt (GT?) handling.
-Chris

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


Re: [Intel-gfx] [PATCH v2 38/38] drm/i915: Add initial selftests for hang detection and resets

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 01:43:41PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> > +static u64 hws_address(const struct i915_vma *hws,
> > +  const struct drm_i915_gem_request *rq)
> > +{
> > +   return hws->node.start + offset_in_page(sizeof(u32)*rq->fence.context);
> 
> fence.context is something unique returned by dma_fence_context_alloc()
> and we assume we don't collide in the scope of this test?

Correct, fence.context is unique to a timeline/engine.
(dma_fence_context_alloc() doesn't prevent collisions, but that is a
topic for another day.)

> > +static struct drm_i915_gem_request *
> > +hang_create_request(struct hang *h,
> > +   struct intel_engine_cs *engine,
> > +   struct i915_gem_context *ctx)
> > +{
> > +   struct drm_i915_gem_request *rq;
> > +   int err;
> > +
> > +   if (i915_gem_object_is_active(h->obj)) {
> > +   struct drm_i915_gem_object *obj;
> > +   void *vaddr;
> > +
> > +   obj = i915_gem_object_create_internal(h->i915, PAGE_SIZE);
> > +   if (IS_ERR(obj))
> > +   return ERR_CAST(obj);
> > +
> > +   vaddr = i915_gem_object_pin_map(obj,
> > +   HAS_LLC(h->i915) ? I915_MAP_WB 
> > : I915_MAP_WC);
> > +   if (IS_ERR(vaddr)) {
> > +   i915_gem_object_put(obj);
> > +   return ERR_CAST(vaddr);
> > +   }
> > +
> > +   i915_gem_object_unpin_map(h->obj);
> > +   __i915_gem_object_release_unless_active(h->obj);
> > +
> > +   h->obj = obj;
> > +   h->batch = vaddr;
> 
> This whole block confuses me. Is it about the reset queue test
> if something went wrong with the previous request?

I was trying to write a generic struct hang to handle tests I haven't
thought of yet. In this case, I want to create a new request whilst the
old one is inflight, and so need to replace the pointers with a fresh
bo. It can be more fancy, we could just reuse the same bo until it is
full, but I was trying to get something up and running.

> > +static int igt_wait_reset(void *arg)
> > +{
> > +   struct drm_i915_private *i915 = arg;
> > +   struct drm_i915_gem_request *rq;
> > +   unsigned int reset_count;
> > +   struct hang h;
> > +   long timeout;
> > +   int err;
> > +
> > +   /* Check that we detect a stuck waiter and issue a reset */
> > +
> > +   if (!intel_has_gpu_reset(i915))
> > +   return 0;
> > +
> > +   set_bit(I915_RESET_IN_PROGRESS, >gpu_error.flags);
> 
> Noticed that you do this early. In this test the fake_hangcheck
> would do it for you also but I suspect you want this to gain
> exclusive access after this point?

Yes, I was mostly trying to apply a common pattern, claiming exclusivity
was a bonus. The difference is more apparent later.

What is missing to complete this set of tests are per-engine resets.
Hooking those in will be a fun exercise in improving both.
-Chris

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


Re: [Intel-gfx] [PATCH v2 32/38] drm/i915: Verify page layout for rotated VMA

2017-02-01 Thread Matthew Auld
On 19 January 2017 at 11:41, Chris Wilson  wrote:
> Exercise creating rotated VMA and checking the page order within.
>
> v2: Be more creative in rotated params
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/selftests/i915_vma.c | 177 
> ++
>  1 file changed, 177 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c 
> b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index b45b392444e4..2bda93f53b47 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -310,11 +310,188 @@ static int igt_vma_pin1(void *arg)
> return err;
>  }
>
> +static unsigned long rotated_index(const struct intel_rotation_info *r,
> +  unsigned int n,
> +  unsigned int x,
> +  unsigned int y)
> +{
> +   return (r->plane[n].stride * (r->plane[n].height - y - 1) +
> +   r->plane[n].offset + x);
> +}
> +
> +static struct scatterlist *
> +assert_rotated(struct drm_i915_gem_object *obj,
> +  const struct intel_rotation_info *r, unsigned int n,
> +  struct scatterlist *sg)
> +{
> +   unsigned int x, y;
> +
> +   for (x = 0; x < r->plane[n].width; x++) {
> +   for (y = 0; y < r->plane[n].height; y++) {
> +   unsigned long src_idx;
> +   dma_addr_t src;
> +
> +   src_idx = rotated_index(r, n, x, y);
> +   src = i915_gem_object_get_dma_address(obj, src_idx);
> +
> +   if (sg_dma_len(sg) != PAGE_SIZE) {
> +   pr_err("Invalid sg.length, found %d, expected 
> %lu for rotated page (%d, %d) [src index %lu]\n",
> +  sg_dma_len(sg), PAGE_SIZE,
> +  x, y, src_idx);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   if (sg_dma_address(sg) != src) {
> +   pr_err("Invalid address for rotated page (%d, 
> %d) [src index %lu]\n",
> +  x, y, src_idx);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   sg = sg_next(sg);
> +   }
> +   }
> +
> +   return sg;
> +}
> +
> +static unsigned int rotated_size(const struct intel_rotation_plane_info *a,
> +const struct intel_rotation_plane_info *b)
> +{
> +   return a->width * a->height + b->width * b->height;
> +}
> +
> +static int igt_vma_rotate(void *arg)
> +{
> +   struct drm_i915_private *i915 = arg;
> +   struct drm_i915_gem_object *obj;
> +   const struct intel_rotation_plane_info planes[] = {
> +   { .width = 1, .height = 1, .stride = 1 },
> +   { .width = 3, .height = 5, .stride = 4 },
> +   { .width = 5, .height = 3, .stride = 7 },
> +   { .width = 6, .height = 4, .stride = 6 },
> +   { }
> +   }, *a, *b;
> +   const unsigned int max_pages = 64;
> +   int err = -ENOMEM;
> +
> +   /* Create VMA for many different combinations of planes and check
> +* that the page layout within the rotated VMA match our expectations.
> +*/
> +
> +   obj = i915_gem_object_create_internal(i915, max_pages * PAGE_SIZE);
> +   if (IS_ERR(obj))
> +   goto err;
> +
> +   for (a = planes; a->width; a++) {
> +   for (b = planes + ARRAY_SIZE(planes); b-- != planes; ) {
> +   struct i915_ggtt_view view;
> +   struct scatterlist *sg;
> +   unsigned int n, max_offset;
> +
> +   max_offset = max(a->stride * a->height,
> +b->stride * b->height);
> +   GEM_BUG_ON(max_offset >= max_pages);
> +   max_offset = max_pages - max_offset;
> +
> +   view.type = I915_GGTT_VIEW_ROTATED;
> +   view.rotated.plane[0] = *a;
> +   view.rotated.plane[1] = *b;
> +
> +   
> for_each_prime_number_from(view.rotated.plane[0].offset, 0, max_offset) {
> +   
> for_each_prime_number_from(view.rotated.plane[1].offset, 0, max_offset) {
> +   struct i915_address_space *vm =
> +   >ggtt.base;
> +   struct i915_vma *vma;
> +
> +   vma = i915_vma_instance(obj, vm, 
> );
> +   if (IS_ERR(vma)) {
> +   err = PTR_ERR(vma);
> +   

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Adapt to dynamic number of planes changes

2017-02-01 Thread Robert Foss

This looks good to me, feel free to add my r-b.

Rob.

On 2017-02-01 05:56 AM, Petri Latvala wrote:

CC: Robert Foss 
CC: Lyude 
Signed-off-by: Petri Latvala 
---
 tests/chamelium.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index d914d5b..e03acc4 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -310,7 +310,7 @@ enable_output(data_t *data,
  struct igt_fb *fb)
 {
igt_display_t *display = output->display;
-   igt_plane_t *primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+   igt_plane_t *primary = igt_output_get_plane_type(output, 
DRM_PLANE_TYPE_PRIMARY);
drmModeConnector *connector = chamelium_port_get_connector(
data->chamelium, port, false);

@@ -341,7 +341,7 @@ disable_output(data_t *data,
   igt_output_t *output)
 {
igt_display_t *display = output->display;
-   igt_plane_t *primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+   igt_plane_t *primary = igt_output_get_plane_type(output, 
DRM_PLANE_TYPE_PRIMARY);
igt_assert(primary);

/* Disable the display */
@@ -364,7 +364,7 @@ test_display_crc_single(data_t *data, struct chamelium_port 
*port)

output = prepare_output(data, , port);
connector = chamelium_port_get_connector(data->chamelium, port, false);
-   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+   primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
igt_assert(primary);

for (i = 0; i < connector->count_modes; i++) {
@@ -418,7 +418,7 @@ test_display_crc_multiple(data_t *data, struct 
chamelium_port *port)

output = prepare_output(data, , port);
connector = chamelium_port_get_connector(data->chamelium, port, false);
-   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+   primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
igt_assert(primary);

for (i = 0; i < connector->count_modes; i++) {
@@ -477,7 +477,7 @@ test_display_frame_dump(data_t *data, struct chamelium_port 
*port)

output = prepare_output(data, , port);
connector = chamelium_port_get_connector(data->chamelium, port, false);
-   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+   primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
igt_assert(primary);

for (i = 0; i < connector->count_modes; i++) {


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


Re: [Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)

2017-02-01 Thread David Weinehall
On Wed, Jan 25, 2017 at 01:10:26PM +0100, Martin Steigerwald wrote:
> Am Sonntag, 22. Januar 2017, 13:32:08 CET schrieb Linus Torvalds:
> > Things seem to be calming down a bit, and everything looks nominal.
> > 
> > There's only been about 250 changes (not counting merges) in the last
> > week, and the diffstat touches less than 300 files (with drivers and
> > architecture updates being the bulk, but there's tooling, networking
> > and filesystems in there too).
> > 
> > So keep testing, and I think we'll have a regular release schedule.
> 
> Testing this is no fun:
> 
> Bug 99533 - black screen after switching session
> https://bugs.freedesktop.org/99533
> 
> 
> This after GPU hang/lockups with Kernel 4.9 reported as for example:
> 
> Bug 98922 - [snb] GPU hang on PlaneShift
> https://bugs.freedesktop.org/98922
> 
> Which may be a duplicate of #98747, #98794, #98860, #98891, #98288.
> 
> 
> I am back at kernel 4.8.15 as I need this machine for production work.
> 
> Sometimes I wish for a microkernel that might be able to reincarnate drivers 
> that hang or do wierd things like that. That may at least give a way to 
> actually do some debugging or even get the desktop session back without 
> loosing its state. Especially for graphics drivers and hibernating/resuming 
> from hibernations which also occasionally fails – again without leaving a way 
> to interact with the machine to do further debugging. Linux kernel usually 
> just crashes completely, not even a ping or ssh possible, or it at least 
> stuck 
> with a black display without any way to restart the graphics driver cause it 
> seems to be in some undefined state. Combined with occasionally happening 
> bugs 
> this makes triaging bugs time consuming and risky. I do like to help testing, 
> but maybe its time to just switch to distro kernels and be done about it, as 
> I 
> regularily come across bugs that are too expensive for me to triage.
> 
> Please understand that I am not willing to bisect these occasionally 
> happening 
> bugs with have the potential to cause data loss due to having to switch off 
> the machine forcefully. Fortunately at least KMail saves a mail I write from 
> time to time and also Kate does swap files.
> 
> I am also a bit unwilling to do further debugging of this one as I usually 
> use 
> two sessions when I am at work and I risk loosing data I work on. But… at 
> least with this issue it seems I would have a way to SSH into the machine 
> before kicking it.
> 
> 
> I am dissatisfied with the state of the Intel graphics driver on this 
> ThinkPad 
> T520 with Sandybridge since kernel 4.9 and wonder whether you guys at Intel 
> really test things with older hardware versions.

Yes, we do. But for practical reasons we can only do testing for things
that we actually have testcases for, and obviously we don't have the
manpower to actually do *manual* testing on every platform, so issues
for older platforms that are only triggered by manual interaction tend
to slip under the radar.

We have a testfarm that tests every nightly build on all platforms we
have test machines for. The testcases are publicly available here:

https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

Obviously most of our manpower is spent on development and testing for current
and future platforms, so for issues that involve older platforms,
especially something as old as Sandybridge (which is, by now, 6 years old)
we are happy for help with testing and bisection.

If the issues are specific to certain subsets of a platform it obviously
gets even more complex; it'd be a combinatorial nightmare to build a
testfarm that could test every variation of every platform.

If I got the count right the i915 driver supports around a hundred
different varieties of Intel graphics; combine that with the number of
different displays people connect, the number of eDP display that the
vendors connect, the different BIOSes that vendors use, etc., and I
think you'll begin to see what we're combating) -- to make things even
more complex you can connect several displays to each graphics card
(possibly via adapters), displays that don't always meet the standards
that they claim to meet.  Due to limited room we are also a bit limited
when it comes to testing with multi-monitor setups.

This is why any help is welcome and sometimes even necessary. If you're
afraid of dataloss, be aware that it's possible to boot your system with
file systems mounted read-only; you could also boot from a USB-stick or
similar.

If you can find a testcase in i-g-t that easily reproduces the issue
that'd also be very helpful. Do note that not all testcases in i-g-t
are run as part of our nightly tests, since some of them are *extremely*
time consuming; the full combinatorial testcase, for instance, can
take weeks or months--I haven't done a full run recently--to complete.

I hope this helps you understand why bugs can slip under the radar,
and why a bisect is so important.


Kind regards, 

[Intel-gfx] [PATCH v3] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

2017-02-01 Thread Chris Wilson
Third retroactive test, make sure that the seqno waiters are woken.

v2: Smattering of comments, rearrange code

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 202 +
 1 file changed, 202 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
index 245e5f1b8373..907503901644 100644
--- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
@@ -263,11 +263,213 @@ static int igt_insert_complete(void *arg)
return err;
 }
 
+struct igt_wakeup {
+   struct task_struct *tsk;
+   atomic_t *ready, *set, *done;
+   struct intel_engine_cs *engine;
+   unsigned long flags;
+#define STOP 0
+#define WAITING 1
+   wait_queue_head_t *wq;
+   u32 seqno;
+};
+
+static int wait_atomic(atomic_t *p)
+{
+   schedule();
+   return 0;
+}
+
+static int wait_atomic_timeout(atomic_t *p)
+{
+   return schedule_timeout(10 * HZ) ? 0 : -ETIMEDOUT;
+}
+
+static bool wait_for_ready(struct igt_wakeup *w)
+{
+   DEFINE_WAIT(ready);
+
+   if (atomic_dec_and_test(w->done))
+   wake_up_atomic_t(w->done);
+
+   if (test_bit(STOP, >flags))
+   goto out;
+
+   set_bit(WAITING, >flags);
+   for (;;) {
+   prepare_to_wait(w->wq, , TASK_INTERRUPTIBLE);
+   if (atomic_read(w->ready) == 0)
+   break;
+
+   schedule();
+   }
+   finish_wait(w->wq, );
+   clear_bit(WAITING, >flags);
+
+out:
+   if (atomic_dec_and_test(w->set))
+   wake_up_atomic_t(w->set);
+
+   return !test_bit(STOP, >flags);
+}
+
+static int igt_wakeup_thread(void *arg)
+{
+   struct igt_wakeup *w = arg;
+   struct intel_wait wait;
+
+   while (wait_for_ready(w)) {
+   GEM_BUG_ON(kthread_should_stop());
+
+   intel_wait_init(, w->seqno);
+   intel_engine_add_wait(w->engine, );
+   for (;;) {
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   if (i915_seqno_passed(intel_engine_get_seqno(w->engine),
+ w->seqno))
+   break;
+
+   if (test_bit(STOP, >flags)) /* emergency escape */
+   break;
+
+   schedule();
+   }
+   intel_engine_remove_wait(w->engine, );
+   __set_current_state(TASK_RUNNING);
+   }
+
+   return 0;
+}
+
+static void igt_wake_all_sync(atomic_t *ready,
+ atomic_t *set,
+ atomic_t *done,
+ wait_queue_head_t *wq,
+ int count)
+{
+   atomic_set(set, count);
+   atomic_set(done, count);
+
+   atomic_set(ready, 0);
+   wake_up_all(wq);
+
+   wait_on_atomic_t(set, wait_atomic, TASK_UNINTERRUPTIBLE);
+   atomic_set(ready, count);
+}
+
+static int igt_wakeup(void *arg)
+{
+   I915_RND_STATE(prng);
+   const int state = TASK_UNINTERRUPTIBLE;
+   struct intel_engine_cs *engine = arg;
+   struct igt_wakeup *waiters;
+   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
+   const int count = 4096;
+   const u32 max_seqno = count / 4;
+   atomic_t ready, set, done;
+   int err = -ENOMEM;
+   int n, step;
+
+   mock_engine_reset(engine);
+
+   waiters = drm_malloc_gfp(count, sizeof(*waiters), GFP_TEMPORARY);
+   if (!waiters)
+   goto out_engines;
+
+   /* Create a large number of threads, each waiting on a random seqno.
+* Multiple waiters will be waiting for the same seqno.
+*/
+   atomic_set(, count);
+   for (n = 0; n < count; n++) {
+   waiters[n].wq = 
+   waiters[n].ready = 
+   waiters[n].set = 
+   waiters[n].done = 
+   waiters[n].engine = engine;
+   waiters[n].flags = 0;
+
+   waiters[n].tsk = kthread_run(igt_wakeup_thread, [n],
+"i915/igt:%d", n);
+   if (IS_ERR(waiters[n].tsk))
+   goto out_waiters;
+
+   get_task_struct(waiters[n].tsk);
+   }
+
+   for (step = 1; step <= max_seqno; step <<= 1) {
+   u32 seqno;
+
+   /* The waiter threads start paused as we assign them a random
+* seqno and reset the engine. Once the engine is reset,
+* we signal that the threads may begin their, and we wait
+* until all threads are woken.
+*/
+   for (n = 0; n < count; n++) {
+   GEM_BUG_ON(!test_bit(WAITING, [n].flags));
+   waiters[n].seqno =
+   1 + 

[Intel-gfx] [PATCH i-g-t v3 6/7] tests/kms_plane_lowres: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.

Signed-off-by: Mika Kahola 
---
 tests/kms_plane_lowres.c | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
index 689c248..c23660f 100644
--- a/tests/kms_plane_lowres.c
+++ b/tests/kms_plane_lowres.c
@@ -320,21 +320,53 @@ test_plane_position(data_t *data, enum pipe pipe, 
uint64_t modifier)
 static void
 run_tests_for_pipe(data_t *data, enum pipe pipe)
 {
+   igt_subtest_f("pipe-%s-tiling-none-with-test",
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = true;
+   test_plane_position(data, pipe, LOCAL_DRM_FORMAT_MOD_NONE);
+   }
+
igt_subtest_f("pipe-%s-tiling-none",
- kmstest_pipe_name(pipe))
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = false;
test_plane_position(data, pipe, LOCAL_DRM_FORMAT_MOD_NONE);
+   }
+
+   igt_subtest_f("pipe-%s-tiling-x-with-test",
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = true;
+   test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_X_TILED);
+   }
 
igt_subtest_f("pipe-%s-tiling-x",
- kmstest_pipe_name(pipe))
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = false;
test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_X_TILED);
+   }
+
+   igt_subtest_f("pipe-%s-tiling-y-with-test",
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = true;
+   test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_Y_TILED);
+   }
 
igt_subtest_f("pipe-%s-tiling-y",
- kmstest_pipe_name(pipe))
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = false;
test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_Y_TILED);
+   }
+
+   igt_subtest_f("pipe-%s-tiling-yf-with-test",
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = true;
+   test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_Yf_TILED);
+   }
 
igt_subtest_f("pipe-%s-tiling-yf",
- kmstest_pipe_name(pipe))
+ kmstest_pipe_name(pipe)) {
+   data->display.force_test_atomic = false;
test_plane_position(data, pipe, LOCAL_I915_FORMAT_MOD_Yf_TILED);
+   }
 }
 
 static data_t data;
-- 
2.7.4

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


[Intel-gfx] [PATCH i-g-t v3 3/7] tests/kms_atomic_transition: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic transition display commits without
actual real-life commit.

v2: use flag to force atomic commit with TEST_ONLY flag

Signed-off-by: Mika Kahola 
---
 tests/kms_atomic_transition.c | 66 ---
 1 file changed, 56 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 5fdb617..a1fa5b9 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -670,28 +670,74 @@ igt_main
igt_require_f(valid_outputs, "no valid crtc/connector 
combinations found\n");
}
 
-   igt_subtest("plane-all-transition")
+   igt_subtest("plane-all-transition") {
+   display.force_test_atomic = false;
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   }
+
+   igt_subtest("plane-all-transition-with-test") {
+   display.force_test_atomic = true;
+   for_each_pipe_with_valid_output(, pipe, output)
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   }
+
+   igt_subtest("plane-all-transition-nonblocking") {
+   display.force_test_atomic = false;
+   for_each_pipe_with_valid_output(, pipe, output)
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   }
+
+   igt_subtest("plane-all-transition-nonblocking-with-test") {
+   display.force_test_atomic = true;
+   for_each_pipe_with_valid_output(, pipe, output)
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   }
+
+   igt_subtest("plane-all-modeset-transition") {
+   display.force_test_atomic = false;
+   for_each_pipe_with_valid_output(, pipe, output)
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   }
 
-   igt_subtest("plane-all-transition-nonblocking")
+   igt_subtest("plane-all-modeset-transition-with-test") {
+   display.force_test_atomic = true;
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   }
 
-   igt_subtest("plane-all-modeset-transition")
+   igt_subtest("plane-toggle-modeset-transition") {
+   display.force_test_atomic = false;
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   }
 
-   igt_subtest("plane-toggle-modeset-transition")
+   igt_subtest("plane-toggle-modeset-transition-with-test") {
+   display.force_test_atomic = true;
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   }
 
for (i = 1; i <= I915_MAX_PIPES; i++) {
-   igt_subtest_f("%ix-modeset-transitions", i)
+   igt_subtest_f("%ix-modeset-transitions", i) {
+   display.force_test_atomic = false;
+   run_modeset_transition(, i, false);
+   }
+
+   igt_subtest_f("%ix-modeset-transitions-with-test", i) {
+   display.force_test_atomic = true;
run_modeset_transition(, i, false);
+   }
+
+   igt_subtest_f("%ix-modeset-transitions-nonblocking", i) {
+   display.force_test_atomic = false;
+   run_modeset_transition(, i, true);
+   }
 
-   igt_subtest_f("%ix-modeset-transitions-nonblocking", i)
+   igt_subtest_f("%ix-modeset-transitions-nonblocking-with-test", 
i) {
+   display.force_test_atomic = true;
run_modeset_transition(, i, true);
+   }
}
 
igt_fixture {
-- 
2.7.4

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


[Intel-gfx] [PATCH i-g-t v3 5/7] tests/kms_rotation_crc: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.

Signed-off-by: Mika Kahola 
---
 tests/kms_rotation_crc.c | 139 +++
 1 file changed, 139 insertions(+)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 9bfcde3..2d2606d 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -522,46 +522,109 @@ igt_main
igt_display_init(, data.gfx_fd);
}
igt_subtest_f("primary-rotation-180") {
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_180;
+   test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
+   }
+
+   igt_subtest_f("primary-rotation-180-with-test") {
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_180;
test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
}
 
igt_subtest_f("sprite-rotation-180") {
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_180;
+   test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
+   }
+
+   igt_subtest_f("sprite-rotation-180-with-test") {
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_180;
test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
}
 
igt_subtest_f("cursor-rotation-180") {
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_180;
+   test_plane_rotation(, DRM_PLANE_TYPE_CURSOR);
+   }
+
+   igt_subtest_f("cursor-rotation-180-with-test") {
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_180;
test_plane_rotation(, DRM_PLANE_TYPE_CURSOR);
}
 
igt_subtest_f("primary-rotation-90") {
igt_require(gen >= 9);
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
+   }
+
+   igt_subtest_f("primary-rotation-90-with-test") {
+   igt_require(gen >= 9);
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_90;
test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
}
 
igt_subtest_f("primary-rotation-270") {
igt_require(gen >= 9);
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_270;
+   test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
+   }
+
+   igt_subtest_f("primary-rotation-270-with-test") {
+   igt_require(gen >= 9);
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_270;
test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
}
 
igt_subtest_f("sprite-rotation-90") {
igt_require(gen >= 9);
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
+   }
+
+   igt_subtest_f("sprite-rotation-90-with-test") {
+   igt_require(gen >= 9);
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_90;
test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
}
 
igt_subtest_f("sprite-rotation-270") {
igt_require(gen >= 9);
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_270;
+   test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
+   }
+
+   igt_subtest_f("sprite-rotation-270-with-test") {
+   igt_require(gen >= 9);
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_270;
test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
}
 
igt_subtest_f("sprite-rotation-90-pos-100-0") {
igt_require(gen >= 9);
+   data.display.force_test_atomic = false;
+   data.rotation = IGT_ROTATION_90;
+   data.pos_x = 100,
+   data.pos_y = 0;
+   test_plane_rotation(, DRM_PLANE_TYPE_OVERLAY);
+   }
+
+   igt_subtest_f("sprite-rotation-90-pos-100-0-with-test") {
+   igt_require(gen >= 9);
+   data.display.force_test_atomic = true;
data.rotation = IGT_ROTATION_90;
data.pos_x = 100,
data.pos_y = 0;
@@ -574,6 +637,17 @@ igt_main
data.pos_y = 0;
data.rotation = IGT_ROTATION_90;
data.override_fmt = DRM_FORMAT_RGB565;
+   data.display.force_test_atomic = false;
+   test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY);
+   }
+
+   

[Intel-gfx] [PATCH i-g-t v3 4/7] tests/kms_plane_scaling: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic scaling without
actually committing the changes.

v2: Create subtests with TEST_ONLY flag and one without

Signed-off-by: Mika Kahola 
---
 tests/kms_plane_scaling.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 18ba86c..4e0d16d 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -310,21 +310,34 @@ static void test_plane_scaling(data_t *d)
igt_require_f(valid_tests, "no valid crtc/connector combinations 
found\n");
 }
 
-igt_simple_main
+igt_main
 {
data_t data = {};
 
igt_skip_on_simulation();
 
+   igt_fixture {
+   data.drm_fd = drm_open_driver(DRIVER_INTEL);
+   igt_require_pipe_crc();
+   igt_display_init(, data.drm_fd);
+   data.devid = intel_get_drm_devid(data.drm_fd);
 
-   data.drm_fd = drm_open_driver(DRIVER_INTEL);
-   igt_require_pipe_crc();
-   igt_display_init(, data.drm_fd);
-   data.devid = intel_get_drm_devid(data.drm_fd);
+   data.num_scalers = intel_gen(data.devid) >= 9 ? 2 : 0;
+   }
 
-   data.num_scalers = intel_gen(data.devid) >= 9 ? 2 : 0;
+   igt_subtest("force-atomic-test") {
+   data.display.force_test_atomic = true;
+   test_plane_scaling();
+   }
 
-   test_plane_scaling();
+   igt_subtest("normal") {
+   data.display.force_test_atomic = false;
+   test_plane_scaling();
+   }
+
+   igt_fixture {
+   igt_display_fini();
+   }
 
-   igt_display_fini();
+   igt_exit();
 }
-- 
2.7.4

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


[Intel-gfx] [PATCH i-g-t v3 0/7] Validate TEST_ONLY correctness against full atomic commit

2017-02-01 Thread Mika Kahola
This test case adds TEST_ONLY flag to the following test cases to test
atomic commit correctness.

 - kms_plane_multiple
 - kms_atomic_transitions
 - kms_plane_scaling
 - kms_rotation_crc
 - kms_plane_lowres
 
The test randomly selects one of the above test cases and tests atomic
commit. If the test fails with TEST_ONLY flag the real deal atomic commit
is executed and the outcome is verified.

v2: Add flag to toggle TEST_ONLY for atomic commit.
Remove DRM_MODE_PAGE_FLIP_EVENT flag, if enabled, before trying atomic
commit with TEST_ONLY flag (Maarten)

v3: flag to indicate TEST_ONLY selection in igt core
separate test cases for TEST_ONLY atomic commits (Maarten)

For: VIZ-6956

Mika Kahola (7):
  lib/igt_kms: Add forcing TEST_ONLY for atomic commits
  tests/kms_plane_multiple: Add TEST_ONLY flag
  tests/kms_atomic_transition: Add TEST_ONLY flag
  tests/kms_plane_scaling: Add TEST_ONLY flag
  tests/kms_rotation_crc: Add TEST_ONLY flag
  tests/kms_plane_lowres: Add TEST_ONLY flag
  tests/kms_cursor_legacy: Add TEST_ONLY flag

 lib/igt_kms.c |  18 +++-
 lib/igt_kms.h |   1 +
 tests/kms_atomic_transition.c |  66 ++--
 tests/kms_cursor_legacy.c | 230 +-
 tests/kms_plane_lowres.c  |  40 +++-
 tests/kms_plane_multiple.c|  35 +++
 tests/kms_plane_scaling.c |  29 --
 tests/kms_rotation_crc.c  | 139 +
 8 files changed, 509 insertions(+), 49 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH i-g-t v3 2/7] tests/kms_plane_multiple: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.

v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit

Signed-off-by: Mika Kahola 
---
 tests/kms_plane_multiple.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index bb84878..2104976 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -412,9 +412,37 @@ test_plane_position(data_t *data, enum pipe pipe, bool 
atomic, int n_planes,
 static void
 run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
 {
+   igt_subtest_f("atomic-pipe-%s-tiling-x-planes-with-tests",
+ kmstest_pipe_name(pipe)) {
+   int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = true;
+   for (int planes = 0; planes < n_planes; planes++)
+   test_plane_position(data, pipe, true, n_planes,
+   planes, LOCAL_I915_FORMAT_MOD_X_TILED);
+   }
+
+   igt_subtest_f("atomic-pipe-%s-tiling-y-planes-with-tests",
+ kmstest_pipe_name(pipe)) {
+   int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = true;
+   for (int planes = 0; planes < n_planes; planes++)
+   test_plane_position(data, pipe, true, n_planes,
+   planes, LOCAL_I915_FORMAT_MOD_X_TILED);
+   }
+
+   igt_subtest_f("atomic-pipe-%s-tiling-yf-planes-with-tests",
+ kmstest_pipe_name(pipe)) {
+   int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = true;
+   for (int planes = 0; planes < n_planes; planes++)
+   test_plane_position(data, pipe, true, n_planes,
+   planes, LOCAL_I915_FORMAT_MOD_X_TILED);
+   }
+
igt_subtest_f("legacy-pipe-%s-tiling-none-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, false,  n_planes,
planes, LOCAL_DRM_FORMAT_MOD_NONE);
@@ -423,6 +451,7 @@ run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
igt_subtest_f("atomic-pipe-%s-tiling-none-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, true, n_planes,
planes, LOCAL_I915_FORMAT_MOD_X_TILED);
@@ -431,6 +460,7 @@ run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
igt_subtest_f("legacy-pipe-%s-tiling-x-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, false, n_planes,
planes, LOCAL_I915_FORMAT_MOD_X_TILED);
@@ -439,6 +469,7 @@ run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
igt_subtest_f("atomic-pipe-%s-tiling-x-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, true, n_planes,
planes, LOCAL_I915_FORMAT_MOD_X_TILED);
@@ -447,6 +478,7 @@ run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
igt_subtest_f("legacy-pipe-%s-tiling-y-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, false, n_planes,
planes, LOCAL_I915_FORMAT_MOD_Y_TILED);
@@ -455,6 +487,7 @@ run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
igt_subtest_f("atomic-pipe-%s-tiling-y-planes",
  kmstest_pipe_name(pipe)) {
int n_planes = data->display.pipes[pipe].n_planes;
+   data->display.force_test_atomic = false;
for (int planes = 0; planes < n_planes; planes++)
test_plane_position(data, pipe, true, n_planes,

[Intel-gfx] [PATCH i-g-t v3 7/7] tests/kms_cursor_legacy: Add TEST_ONLY flag

2017-02-01 Thread Mika Kahola
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.

Signed-off-by: Mika Kahola 
---
 tests/kms_cursor_legacy.c | 230 --
 1 file changed, 204 insertions(+), 26 deletions(-)

diff --git a/tests/kms_cursor_legacy.c b/tests/kms_cursor_legacy.c
index c7083a0..97adf8c 100644
--- a/tests/kms_cursor_legacy.c
+++ b/tests/kms_cursor_legacy.c
@@ -1441,53 +1441,165 @@ igt_main
igt_subtest("all-pipes-torture-move")
stress(, -1, -ncpus, DRM_MODE_CURSOR_MOVE, 20);
 
-   igt_subtest("nonblocking-modeset-vs-cursor-atomic")
+   igt_subtest("nonblocking-modeset-vs-cursor-atomic") {
+   display.force_test_atomic = false;
nonblocking_modeset_vs_cursor(, 1);
+   }
+
+   igt_subtest("nonblocking-modeset-vs-cursor-atomic-with-test") {
+   display.force_test_atomic = true;
+   nonblocking_modeset_vs_cursor(, 1);
+   }
 
-   igt_subtest("long-nonblocking-modeset-vs-cursor-atomic")
+   igt_subtest("long-nonblocking-modeset-vs-cursor-atomic") {
+   display.force_test_atomic = false;
nonblocking_modeset_vs_cursor(, 16);
+   }
 
-   igt_subtest("2x-flip-vs-cursor-legacy")
+   igt_subtest("long-nonblocking-modeset-vs-cursor-atomic-with-test") {
+   display.force_test_atomic = true;
+   nonblocking_modeset_vs_cursor(, 16);
+   }
+
+   igt_subtest("2x-flip-vs-cursor-legacy") {
+   display.force_test_atomic = false;
+   two_screens_flip_vs_cursor(, 8, false, false);
+   }
+
+   igt_subtest("2x-flip-vs-cursor-legacy-with-test") {
+   display.force_test_atomic = true;
two_screens_flip_vs_cursor(, 8, false, false);
+   }
+
+   igt_subtest("2x-flip-vs-cursor-atomic") {
+   display.force_test_atomic = false;
+   two_screens_flip_vs_cursor(, 4, false, true);
+   }
 
-   igt_subtest("2x-flip-vs-cursor-atomic")
+   igt_subtest("2x-flip-vs-cursor-atomic-with-test") {
+   display.force_test_atomic = true;
two_screens_flip_vs_cursor(, 4, false, true);
+   }
 
-   igt_subtest("2x-cursor-vs-flip-legacy")
+   igt_subtest("2x-cursor-vs-flip-legacy") {
+   display.force_test_atomic = false;
two_screens_cursor_vs_flip(, 8, false);
+   }
+
+   igt_subtest("2x-cursor-vs-flip-legacy-with-test") {
+   display.force_test_atomic = true;
+   two_screens_cursor_vs_flip(, 8, false);
+   }
 
-   igt_subtest("2x-long-flip-vs-cursor-legacy")
+   igt_subtest("2x-long-flip-vs-cursor-legacy") {
+   display.force_test_atomic = false;
two_screens_flip_vs_cursor(, 150, false, false);
+   }
+
+   igt_subtest("2x-long-flip-vs-cursor-legacy-with-test") {
+   display.force_test_atomic = true;
+   two_screens_flip_vs_cursor(, 150, false, false);
+   }
+
+   igt_subtest("2x-long-flip-vs-cursor-atomic") {
+   display.force_test_atomic = false;
+   two_screens_flip_vs_cursor(, 150, false, true);
+   }
 
-   igt_subtest("2x-long-flip-vs-cursor-atomic")
+   igt_subtest("2x-long-flip-vs-cursor-atomic-with-test") {
+   display.force_test_atomic = true;
two_screens_flip_vs_cursor(, 150, false, true);
+   }
 
-   igt_subtest("2x-long-cursor-vs-flip-legacy")
+   igt_subtest("2x-long-cursor-vs-flip-legacy") {
+   display.force_test_atomic = false;
two_screens_cursor_vs_flip(, 50, false);
+   }
 
-   igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic")
+   igt_subtest("2x-long-cursor-vs-flip-legacy-with-test") {
+   display.force_test_atomic = true;
+   two_screens_cursor_vs_flip(, 50, false);
+   }
+
+   igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic") {
+   display.force_test_atomic = false;
two_screens_flip_vs_cursor(, 8, true, true);
+   }
+
+   igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic-with-test") {
+   display.force_test_atomic = true;
+   two_screens_flip_vs_cursor(, 8, true, true);
+   }
+
+   igt_subtest("2x-cursor-vs-flip-atomic") {
+   display.force_test_atomic = false;
+   two_screens_cursor_vs_flip(, 8, true);
+   }
 
-   igt_subtest("2x-cursor-vs-flip-atomic")
+   igt_subtest("2x-cursor-vs-flip-atomic-with-test") {
+   display.force_test_atomic = true;
two_screens_cursor_vs_flip(, 8, true);
+   }
 
-   igt_subtest("2x-long-nonblocking-modeset-vs-cursor-atomic")
+   igt_subtest("2x-long-nonblocking-modeset-vs-cursor-atomic") {
+   display.force_test_atomic = false;

[Intel-gfx] [PATCH i-g-t v3 1/7] lib/igt_kms: Add forcing TEST_ONLY for atomic commits

2017-02-01 Thread Mika Kahola
Add an option to force atomic commits to do commits with TEST_ONLY flag
first before doing the actual commit.

Signed-off-by: Mika Kahola 
---
 lib/igt_kms.c | 18 +-
 lib/igt_kms.h |  1 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 4ba6316..c513ef8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2453,7 +2453,23 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
igt_atomic_prepare_connector_commit(output, req);
}
 
-   ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   if (display->force_test_atomic &&
+   !(flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
+   unsigned int test_flags = flags & ~DRM_MODE_PAGE_FLIP_EVENT;
+   int test_ret;
+
+   test_flags |= DRM_MODE_ATOMIC_TEST_ONLY;
+
+   test_ret = drmModeAtomicCommit(display->drm_fd, req, 
test_flags, user_data);
+   ret = drmModeAtomicCommit(display->drm_fd, req, flags, 
user_data);
+
+   if (test_ret)
+   igt_assert_eq(test_ret, ret);
+   else
+   igt_assert(ret != -EINVAL);
+   } else
+   ret = drmModeAtomicCommit(display->drm_fd, req, flags, 
user_data);
+
drmModeAtomicFree(req);
return ret;
 
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 2562618..e45fc21 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -338,6 +338,7 @@ struct igt_display {
igt_pipe_t *pipes;
bool has_cursor_plane;
bool is_atomic;
+   bool force_test_atomic;
 };
 
 void igt_display_init(igt_display_t *display, int drm_fd);
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v5] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Tvrtko Ursulin


On 01/02/2017 12:46, Chris Wilson wrote:

On Wed, Feb 01, 2017 at 12:09:40PM +, Tvrtko Ursulin wrote:


On 01/02/2017 10:24, Chris Wilson wrote:

This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).


Not every request since it does have two virtual ports, or even a
bit better with request merging. Just saying so it sounds less
dramatic for people reading commit messages.


We still wakeup after the first virtual port is drained, with the hope
that the second is full to prevent the stall. What you meant is that we
coalesce requests from the same context into a port, so not every
request need result in an extra interrupt. Almost every request.


I was just after a milder description so it doesn't sound like we never 
submit more than one request to the GuC.



diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0ff75f2282fa..e0cec254faa5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1350,8 +1350,10 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
static __always_inline void
gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
{
-   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
+   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
+   tasklet_schedule(>irq_tasklet);
notify_ring(engine);
+   }


Would this be better:

if (iir & (CTX | USR)) {
set_bit();


No because ^.


tasklet_hi_schedule();

if (iir & USR) {
notify_ring();
}
}

?


If we set the context-switch bit too early (and process the
user-interrupt and the context-switch as two separate passes through the
tasklet), we encounter the error from before that the CSB register may
be undefined. Possibly not since the user interrupt should mean the ring
is powered up (and so the register restored from the power context, one
hopes!), but there is no reason for us to read back the registers until
we see the interrupt telling us they have been updated.

Note sure the best way to write that for simplicity, so I kept the patch
clean.

if (!(iir & ((GT_RENDER_USER_INTERRUPT | GT_CONTEXT_SWITCH_INTERRUPT) 
<< test_shift)))
return;

if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);

tasklet_hi_schedule(>irq_tasklet);

if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
notify_ring(engine);

add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-85 (-85)
function old new   delta
gen8_gt_irq_handler  756 671 -85
Total: Before=1093982, After=1093897, chg -0.01%

Ok, gcc likes that a lot more.


What's this add/remove grow/shrink up/down business? Something from some 
standard tool?


Back to the topic - should we be concerned here that in execlist mode we 
might wake up the tasklet prematurely? If it manages to run and exit in 
the window between the user interrupt and the context interrupt it would 
just waste cycles. I can easily see ~150us between the two here. What do 
you think?


Regards,

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


[Intel-gfx] [PATCH] drm/i915/execlists: Add interrupt-pending check to intel_execlists_idle()

2017-02-01 Thread Chris Wilson
Primarily this serves as a sanity check that the bit has been cleared
before we suspend (and hasn't reappeared after resume).

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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 753458452997..44a92ea464ba 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -508,9 +508,15 @@ bool intel_execlists_idle(struct drm_i915_private 
*dev_priv)
if (!i915.enable_execlists)
return true;
 
-   for_each_engine(engine, dev_priv, id)
+   for_each_engine(engine, dev_priv, id) {
+   /* Interrupt/tasklet pending? */
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   return false;
+
+   /* Both ports drained, no more ELSP submission? */
if (!execlists_elsp_idle(engine))
return false;
+   }
 
return true;
 }
-- 
2.11.0

___
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 HDMI 2.0: Scrambling support in DRM layer

2017-02-01 Thread Sharma, Shashank
I build bzImage, keeping I915 as part of kernel (not as a module)
Looks like I need to add EXPORT_SYMBOL(drm_enable_scrambling) 
Will cover this in V2. 

Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Wednesday, February 1, 2017 6:33 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for HDMI 2.0: Scrambling support in DRM layer

== Series Details ==

Series: HDMI 2.0: Scrambling support in DRM layer
URL   : https://patchwork.freedesktop.org/series/18915/
State : failure

== Summary ==

  CHECK   usr/include/linux/byteorder/ (2 files)
  CHECK   usr/include/linux/android/ (1 files)
  CHECK   usr/include/linux/caif/ (2 files)
  CHECK   usr/include/linux/iio/ (2 files)
  CHECK   usr/include/linux/netfilter_ipv4/ (9 files)
  CHECK   usr/include/linux/netfilter_bridge/ (17 files)
  CHECK   usr/include/linux/can/ (5 files)
  CHECK   usr/include/linux/raid/ (2 files)
  CHECK   usr/include/linux/nfsd/ (5 files)
  CHECK   usr/include/linux/hdlc/ (1 files)
  CHECK   usr/include/linux/isdn/ (1 files)
  CHECK   usr/include/linux/netfilter/ (87 files)
  CHECK   usr/include/linux/tc_act/ (14 files)
  CHECK   usr/include/linux/netfilter_arp/ (2 files)
  CHECK   usr/include/linux/hsi/ (2 files)
  CHECK   usr/include/linux/tc_ematch/ (4 files)
  CHECK   usr/include/linux/mmc/ (1 files)
  CHECK   usr/include/linux/dvb/ (8 files)
  CHECK   usr/include/linux/sunrpc/ (1 files)
  CHECK   usr/include/linux/wimax/ (1 files)
  CHECK   usr/include/linux/spi/ (1 files)
  CHECK   usr/include/linux/netfilter/ipset/ (4 files)
  CHECK   usr/include/linux/usb/ (11 files)
  CHECK   usr/include/linux/ (443 files)
  CHECK   usr/include/linux/netfilter_ipv6/ (12 files)
  CHECK   usr/include/asm/ (62 files)
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  vmlinux.o
  MODPOST vmlinux.o
  KSYM.tmp_kallsyms1.o
  KSYM.tmp_kallsyms2.o
  LD  vmlinux
  SORTEX  vmlinux
  SYSMAP  System.map
  CC  arch/x86/boot/a20.o
  AS  arch/x86/boot/bioscall.o
  CC  arch/x86/boot/cmdline.o
  HOSTCC  arch/x86/boot/mkcpustr
  CC  arch/x86/boot/early_serial_console.o
  CC  arch/x86/boot/cpuflags.o
  CC  arch/x86/boot/cpucheck.o
  AS  arch/x86/boot/copy.o
  CC  arch/x86/boot/edd.o
  CC  arch/x86/boot/main.o
  AS  arch/x86/boot/pmjump.o
  CC  arch/x86/boot/printf.o
  CC  arch/x86/boot/memory.o
  CC  arch/x86/boot/regs.o
  CC  arch/x86/boot/string.o
  CC  arch/x86/boot/pm.o
  CC  arch/x86/boot/video.o
  CC  arch/x86/boot/version.o
  CC  arch/x86/boot/video-vesa.o
  CC  arch/x86/boot/video-vga.o
  CC  arch/x86/boot/video-mode.o
  CC  arch/x86/boot/video-bios.o
  CC  arch/x86/boot/tty.o
  HOSTCC  arch/x86/boot/tools/build
  Building modules, stage 2.
  LDS arch/x86/boot/compressed/vmlinux.lds
  AS  arch/x86/boot/compressed/head_64.o
  VOFFSET arch/x86/boot/compressed/../voffset.h
  CPUSTR  arch/x86/boot/cpustr.h
  CC  arch/x86/boot/compressed/string.o
  MODPOST 97 modules
  CC  arch/x86/boot/compressed/cmdline.o
  CC  arch/x86/boot/compressed/error.o
  OBJCOPY arch/x86/boot/compressed/vmlinux.bin
  HOSTCC  arch/x86/boot/compressed/mkpiggy
  CC  arch/x86/boot/compressed/early_serial_console.o
  CC  arch/x86/boot/compressed/eboot.o
  AS  arch/x86/boot/compressed/efi_stub_64.o
  CC  arch/x86/boot/cpu.o
  CC  arch/x86/boot/compressed/cpuflags.o
  XZKERN  arch/x86/boot/compressed/vmlinux.bin.xz
ERROR: "drm_enable_scrambling" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1196: recipe for target 'modules' failed
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs
  CC  arch/x86/boot/compressed/misc.o
  MKPIGGY arch/x86/boot/compressed/piggy.S
  AS  arch/x86/boot/compressed/piggy.o
  DATAREL arch/x86/boot/compressed/vmlinux
  LD  arch/x86/boot/compressed/vmlinux
  ZOFFSET arch/x86/boot/zoffset.h
  OBJCOPY arch/x86/boot/vmlinux.bin
  AS  arch/x86/boot/header.o
  LD  arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Setup is 16412 bytes (padded to 16896 bytes).
System is 4853 kB
CRC e574db06
Kernel: arch/x86/boot/bzImage is ready  (#1)

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


Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR

2017-02-01 Thread Mika Kuoppala
Chris Wilson  writes:

> As we now flag when the GPU signals a context-switch and do not read the
> status register before we see that signal, we do not have to ensure that
> it is cleared upon reset (and can leave it to the GPU to reset it from
> the power context).
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0e99d53d5523..753458452997 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1317,7 +1317,6 @@ static int gen9_init_render_ring(struct intel_engine_cs 
> *engine)
>  static void reset_common_ring(struct intel_engine_cs *engine,
> struct drm_i915_gem_request *request)
>  {
> - struct drm_i915_private *dev_priv = engine->i915;
>   struct execlist_port *port = engine->execlist_port;
>   struct intel_context *ce = >ctx->engine[engine->id];
>  
> @@ -1344,7 +1343,6 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   return;
>  
>   /* Catch up with any missed context-switch interrupts */
> - I915_WRITE(RING_CONTEXT_STATUS_PTR(engine), _MASKED_FIELD(0x, 0));
>   if (request->ctx != port[0].request->ctx) {
>   i915_gem_request_put(port[0].request);
>   port[0] = port[1];
> -- 
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI 2.0: Scrambling support in DRM layer

2017-02-01 Thread Patchwork
== Series Details ==

Series: HDMI 2.0: Scrambling support in DRM layer
URL   : https://patchwork.freedesktop.org/series/18915/
State : failure

== Summary ==

  CHECK   usr/include/linux/byteorder/ (2 files)
  CHECK   usr/include/linux/android/ (1 files)
  CHECK   usr/include/linux/caif/ (2 files)
  CHECK   usr/include/linux/iio/ (2 files)
  CHECK   usr/include/linux/netfilter_ipv4/ (9 files)
  CHECK   usr/include/linux/netfilter_bridge/ (17 files)
  CHECK   usr/include/linux/can/ (5 files)
  CHECK   usr/include/linux/raid/ (2 files)
  CHECK   usr/include/linux/nfsd/ (5 files)
  CHECK   usr/include/linux/hdlc/ (1 files)
  CHECK   usr/include/linux/isdn/ (1 files)
  CHECK   usr/include/linux/netfilter/ (87 files)
  CHECK   usr/include/linux/tc_act/ (14 files)
  CHECK   usr/include/linux/netfilter_arp/ (2 files)
  CHECK   usr/include/linux/hsi/ (2 files)
  CHECK   usr/include/linux/tc_ematch/ (4 files)
  CHECK   usr/include/linux/mmc/ (1 files)
  CHECK   usr/include/linux/dvb/ (8 files)
  CHECK   usr/include/linux/sunrpc/ (1 files)
  CHECK   usr/include/linux/wimax/ (1 files)
  CHECK   usr/include/linux/spi/ (1 files)
  CHECK   usr/include/linux/netfilter/ipset/ (4 files)
  CHECK   usr/include/linux/usb/ (11 files)
  CHECK   usr/include/linux/ (443 files)
  CHECK   usr/include/linux/netfilter_ipv6/ (12 files)
  CHECK   usr/include/asm/ (62 files)
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  vmlinux.o
  MODPOST vmlinux.o
  KSYM.tmp_kallsyms1.o
  KSYM.tmp_kallsyms2.o
  LD  vmlinux
  SORTEX  vmlinux
  SYSMAP  System.map
  CC  arch/x86/boot/a20.o
  AS  arch/x86/boot/bioscall.o
  CC  arch/x86/boot/cmdline.o
  HOSTCC  arch/x86/boot/mkcpustr
  CC  arch/x86/boot/early_serial_console.o
  CC  arch/x86/boot/cpuflags.o
  CC  arch/x86/boot/cpucheck.o
  AS  arch/x86/boot/copy.o
  CC  arch/x86/boot/edd.o
  CC  arch/x86/boot/main.o
  AS  arch/x86/boot/pmjump.o
  CC  arch/x86/boot/printf.o
  CC  arch/x86/boot/memory.o
  CC  arch/x86/boot/regs.o
  CC  arch/x86/boot/string.o
  CC  arch/x86/boot/pm.o
  CC  arch/x86/boot/video.o
  CC  arch/x86/boot/version.o
  CC  arch/x86/boot/video-vesa.o
  CC  arch/x86/boot/video-vga.o
  CC  arch/x86/boot/video-mode.o
  CC  arch/x86/boot/video-bios.o
  CC  arch/x86/boot/tty.o
  HOSTCC  arch/x86/boot/tools/build
  Building modules, stage 2.
  LDS arch/x86/boot/compressed/vmlinux.lds
  AS  arch/x86/boot/compressed/head_64.o
  VOFFSET arch/x86/boot/compressed/../voffset.h
  CPUSTR  arch/x86/boot/cpustr.h
  CC  arch/x86/boot/compressed/string.o
  MODPOST 97 modules
  CC  arch/x86/boot/compressed/cmdline.o
  CC  arch/x86/boot/compressed/error.o
  OBJCOPY arch/x86/boot/compressed/vmlinux.bin
  HOSTCC  arch/x86/boot/compressed/mkpiggy
  CC  arch/x86/boot/compressed/early_serial_console.o
  CC  arch/x86/boot/compressed/eboot.o
  AS  arch/x86/boot/compressed/efi_stub_64.o
  CC  arch/x86/boot/cpu.o
  CC  arch/x86/boot/compressed/cpuflags.o
  XZKERN  arch/x86/boot/compressed/vmlinux.bin.xz
ERROR: "drm_enable_scrambling" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1196: recipe for target 'modules' failed
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs
  CC  arch/x86/boot/compressed/misc.o
  MKPIGGY arch/x86/boot/compressed/piggy.S
  AS  arch/x86/boot/compressed/piggy.o
  DATAREL arch/x86/boot/compressed/vmlinux
  LD  arch/x86/boot/compressed/vmlinux
  ZOFFSET arch/x86/boot/zoffset.h
  OBJCOPY arch/x86/boot/vmlinux.bin
  AS  arch/x86/boot/header.o
  LD  arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Setup is 16412 bytes (padded to 16896 bytes).
System is 4853 kB
CRC e574db06
Kernel: arch/x86/boot/bzImage is ready  (#1)

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Patchwork
== Series Details ==

Series: drm/i915/scheduler: emulate a scheduler for guc
URL   : https://patchwork.freedesktop.org/series/18909/
State : success

== Summary ==

Series 18909v1 drm/i915/scheduler: emulate a scheduler for guc
https://patchwork.freedesktop.org/api/1.0/series/18909/revisions/1/mbox/


fi-bdw-5557u total:247  pass:233  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:247  pass:208  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:247  pass:225  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:78   pass:65   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:247  pass:228  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:247  pass:226  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:247  pass:224  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:247  pass:227  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:247  pass:222  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:247  pass:234  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:247  pass:216  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:247  pass:215  dwarn:0   dfail:0   fail:0   skip:32 

eb9b7b42023edc1b5849d1ff3bef490b492067a3 drm-tip: 2017y-02m-01d-11h-09m-17s UTC 
integration manifest
27530f8 drm/i915/scheduler: emulate a scheduler for guc

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3661/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR

2017-02-01 Thread Chris Wilson
As we now flag when the GPU signals a context-switch and do not read the
status register before we see that signal, we do not have to ensure that
it is cleared upon reset (and can leave it to the GPU to reset it from
the power context).

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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0e99d53d5523..753458452997 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1317,7 +1317,6 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
 static void reset_common_ring(struct intel_engine_cs *engine,
  struct drm_i915_gem_request *request)
 {
-   struct drm_i915_private *dev_priv = engine->i915;
struct execlist_port *port = engine->execlist_port;
struct intel_context *ce = >ctx->engine[engine->id];
 
@@ -1344,7 +1343,6 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
return;
 
/* Catch up with any missed context-switch interrupts */
-   I915_WRITE(RING_CONTEXT_STATUS_PTR(engine), _MASKED_FIELD(0x, 0));
if (request->ctx != port[0].request->ctx) {
i915_gem_request_put(port[0].request);
port[0] = port[1];
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH v5] drm/i915/scheduler: emulate a scheduler for guc

2017-02-01 Thread Chris Wilson
On Wed, Feb 01, 2017 at 12:09:40PM +, Tvrtko Ursulin wrote:
> 
> On 01/02/2017 10:24, Chris Wilson wrote:
> >This emulates execlists on top of the GuC in order to defer submission of
> >requests to the hardware. This deferral allows time for high priority
> >requests to gazump their way to the head of the queue, however it nerfs
> >the GuC by converting it back into a simple execlist (where the CPU has
> >to wake up after every request to feed new commands into the GuC).
> 
> Not every request since it does have two virtual ports, or even a
> bit better with request merging. Just saying so it sounds less
> dramatic for people reading commit messages.

We still wakeup after the first virtual port is drained, with the hope
that the second is full to prevent the stall. What you meant is that we
coalesce requests from the same context into a port, so not every
request need result in an extra interrupt. Almost every request.
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 0ff75f2282fa..e0cec254faa5 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -1350,8 +1350,10 @@ static void snb_gt_irq_handler(struct 
> >drm_i915_private *dev_priv,
> > static __always_inline void
> > gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
> > {
> >-if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
> >+if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
> >+tasklet_schedule(>irq_tasklet);
> > notify_ring(engine);
> >+}
> 
> Would this be better:
> 
> if (iir & (CTX | USR)) {
>   set_bit();

No because ^.

>   tasklet_hi_schedule();
>   
>   if (iir & USR) {
>   notify_ring();
>   }
> }
> 
> ?

If we set the context-switch bit too early (and process the
user-interrupt and the context-switch as two separate passes through the
tasklet), we encounter the error from before that the CSB register may
be undefined. Possibly not since the user interrupt should mean the ring
is powered up (and so the register restored from the power context, one
hopes!), but there is no reason for us to read back the registers until
we see the interrupt telling us they have been updated.

Note sure the best way to write that for simplicity, so I kept the patch
clean.

if (!(iir & ((GT_RENDER_USER_INTERRUPT | GT_CONTEXT_SWITCH_INTERRUPT) 
<< test_shift)))
return;

if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);

tasklet_hi_schedule(>irq_tasklet);

if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
notify_ring(engine);

add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-85 (-85)
function old new   delta
gen8_gt_irq_handler  756 671 -85
Total: Before=1093982, After=1093897, chg -0.01%

Ok, gcc likes that a lot more.

> > if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
> > set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 0e99d53d5523..1b7fc0ffa7ad 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -1272,7 +1272,7 @@ static int gen8_init_common_ring(struct 
> >intel_engine_cs *engine)
> >
> > /* After a GPU reset, we may have requests to replay */
> > clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >-if (!execlists_elsp_idle(engine)) {
> >+if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) {
> > engine->execlist_port[0].count = 0;
> > engine->execlist_port[1].count = 0;
> > execlists_submit_ports(engine);
> >@@ -1340,9 +1340,6 @@ static void reset_common_ring(struct intel_engine_cs 
> >*engine,
> > request->ring->last_retired_head = -1;
> > intel_ring_update_space(request->ring);
> >
> >-if (i915.enable_guc_submission)
> >-return;
> >-
> > /* Catch up with any missed context-switch interrupts */
> > I915_WRITE(RING_CONTEXT_STATUS_PTR(engine), _MASKED_FIELD(0x, 0));
> 
> Should we put this write under the i915.enable_guc_submission
> perhasp? Maybe it makes no difference since this is after the reset
> but don't know, perhaps it is more logical.

Perhaps. Although now with the set_bit(CTX_SWITCH), we should be able to
remove this line entirely.
-Chris

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


[Intel-gfx] Problem with i915 driver when mixing Skylake CPU with Kabylake chipset

2017-02-01 Thread Rainer Koenig
Hello,

I'm investigating a problem on a machine that has a Kabylake PCH but a
Skylake CPU i5-6500.

Problem is that I can install and use distributions that are based on an
older kernel, but newer Linux dristributions fail to boot even the
installer.

So far I managed to get Fedora 25 with a 4.9 kernel installed, but I
cannot reach runlevel 5. Booting to runlevel 3 shows this message in the
dmesg:

[1.816627] [ cut here ]
[1.816943] WARNING: CPU: 5 PID: 373 at
drivers/gpu/drm/i915/i915_drv.c:210 i915_driver_load+0x1157/0x1410 [i915]
[1.817193] WARN_ON(!((&({ struct drm_i915_private *__p; if
(__builtin_types_compatible_p(typeof(*dev), struct drm_i915_private))
__p = (struct drm_i915_private *)dev; else if
(__builtin_types_compatible_p(typeof(*dev), struct drm_device)) __p =
to_i915((struct drm_device *)dev); else do { bool __cond = !(!(1));
extern void __compiletime_assert_210(void)
__attribute__((error("BUILD_BUG failed"))); if (__cond)
__compiletime_assert_210(); do { } while (0); } while (0); __p;
})->info)->is_kabylake))
[1.817251] e1000e :00:1f.6 enp0s31f6: renamed from eth0
[1.818020] Modules linked in:
[1.818185]  i915(+) i2c_algo_bit e1000e drm_kms_helper crc32c_intel
drm ptp serio_raw pps_core video i2c_hid fjes
[1.819091] CPU: 5 PID: 373 Comm: systemd-udevd Not tainted
4.9.5-200.fc25.x86_64 #1

Looking at i95_drv.c I find this code snipped that seems to be
responsible:


} else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
} else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP
PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
} else if (id == INTEL_PCH_KBP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_KBP;
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_KABYLAKE(dev_priv));


I read from that, that the driver issues the warning when PCH is a
Kabypoint PCH, but the CPU based graphics is not from a Kabylake CPU.

This explains the warnings in the dmesg. But if I want to start the GUI,
the next problem rises:

[  125.777880] gnome-shell[1665]: segfault at 0 ip 7f49b6712789 sp
7fff9100ca30 error 4 in libEGL.so.1.0.0[7f49b66f8000+3]

So from my perspective it looks like, that something inside the i915
driver is going wrong when we mix up Skylake CPUs with Kabylake
Chipsets. The same system works pretty well when I replace the Skylake
CPU with a Kabylake CPU.

On the other hand we have boards with a H110 chipset (Sunrise Point)
that also support Kabylake CPUs and where this problem doesn't occur.

So my questions is what is the status of the driver regarding the
combination of Skylake CPU with Kabylake chipset?

Thanks
Rainer
-- 
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Clients
FJ EMEIA PR PSO PM CCD ENG SW OSS

Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany

Telephone: +49-821-804-3321
Telefax:   +49-821-804-2131
Mail:  mailto:rainer.koe...@ts.fujitsu.com

Internet ts.fujtsu.com
Company Details  ts.fujitsu.com/imprint.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-01 Thread Maarten Lankhorst
Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
> Hello,
>
> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
>> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
>>> From: Chris Wilson 
>>>
>>> As the introduced comment admits this is clearly a workaround, but for
>>> me this is the only known way to make my Lenovo X201 work without
>>> flickering and crashing.
>>>
>>> Signed-off-by: Uwe Kleine-König 
>>> [uwe: added changelog, comment and restrict to GEN5]
>>> ---
>>> Hello,
>>>
>>> as I don't like having to compile my own kernel (which has this workaround) 
>>> I
>>> suggest to apply this patch until someone with more knowledge than me about
>>> i915 finds the muse and time to work on this.
>> Just curious, does this help?
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index ae2c0bb4b2e8..13de4c526ca6 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
>> intel_crtc_state *cstate,
>>   * this is necessary to avoid flickering.
>>   */
>>  int cpp = 4;
>> -int width = pstate->base.visible ? pstate->base.crtc_w : 64;
>> +int width = 256;
>>  
>>  if (!cstate->base.active)
>>  return 0;
>>
> On a kernel with this patch applied I cannot reproduce the flickering. I
> keep that kernel running but expect that it also fixes the crash.
>
> Best regards
> Uwe

Ok that's good news.

Maybe ville or matt can comment whether this patch is the right fix?

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


[Intel-gfx] [PATCH 0/6] HDMI 2.0: Scrambling support in DRM layer

2017-02-01 Thread Shashank Sharma
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.

This patch series contains 6 patches:
- First two patches add generic drm helper functions to read and
  write into SCDC registers. These patches are written by Thierry,
  in a patch series published here:
  https://patchwork.kernel.org/patch/9459051/
  Minor changes were done to map the patches into this series.
- Next two patches add functions for scrambling detection and
  scrambling control.
- Next two patches use this infrastructure in DRM layer from
  I915 driver, to enable scrambling on a GLK deivce which sports
  a native HDMI 2.0 controller.

Shashank Sharma (4):
  drm/edid: detect SCDC support in HF-VSDB
  drm: scrambling support in drm layer
  drm/i915: enable scrambling
  drm/i915: allow HDMI 2.0 clock rates

Thierry Reding (2):
  drm: Add SCDC helpers
  drm/edid: check for HF-VSDB block

 Documentation/gpu/drm-kms-helpers.rst |  12 +++
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_edid.c| 158 ++
 drivers/gpu/drm/drm_scdc_helper.c | 111 
 drivers/gpu/drm/i915/i915_reg.h   |   2 +
 drivers/gpu/drm/i915/intel_ddi.c  |   5 ++
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c |  44 ++
 include/drm/drm_connector.h   |  50 +++
 include/drm/drm_edid.h|   6 +-
 include/drm/drm_scdc_helper.h | 132 
 include/linux/hdmi.h  |   1 +
 12 files changed, 524 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

-- 
1.9.1

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


[Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers

2017-02-01 Thread Shashank Sharma
From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

Signed-off-by: Thierry Reding 
---
 Documentation/gpu/drm-kms-helpers.rst |  12 
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_scdc_helper.c | 111 
 include/drm/drm_scdc_helper.h | 132 ++
 4 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
 
+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
 Rectangle Utilities Reference
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 92de399..ad91cd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o
+   drm_simple_kms_helper.o drm_modeset_helper.o \
+   drm_scdc_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..fe0e121
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * 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, sub license,
+ * 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 NON-INFRINGEMENT. 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 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+   struct i2c_msg msgs[2] = {
+   {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   }, {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = I2C_M_RD,
+   .len = size,
+   .buf = buffer,
+   }
+   };
+
+   return i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+}

[Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

2017-02-01 Thread Shashank Sharma
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 131 +++-
 include/drm/drm_connector.h |  24 
 include/drm/drm_edid.h  |   6 +-
 3 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 37902e5..f0d940a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define version_greater(edid, maj, min) \
(((edid)->version > (maj)) || \
@@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
*connector,
}
 }
 
+static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi_info;
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340M.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
+* * SCDC support available
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   display->max_tmds_clock = hf_vsdb[5] * 5000;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+
+   if (hdmi->scdc_supported) {
+   hdmi->scr_info.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   hdmi->scr_info.low_clocks = true;
+   }
+   }
+}
+
+/**
+ * drm_check_scrambling_status - what is status of scrambling?
+ * @adapter: i2c adapter for SCDC channel
+ *
+ * Read the scrambler status over SCDC channel, and check the
+ * scrambling status.
+ *
+ * Return: True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_check_scrambling_status(struct i2c_adapter *adapter)
+{
+   u8 status;
+
+   if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
+   DRM_ERROR("Failed to read scrambling status\n");
+   return false;
+   }
+
+   status &= SCDC_SCRAMBLING_STATUS;
+   return status != 0;
+}
+
+/**
+ * drm_enable_scrambling - enable scrambling
+ * @connector: target drm_connector
+ * @adapter: i2c adapter for SCDC channel
+ * @force: enable scrambling, even if its already enabled
+ *
+ * Write the TMDS config over SCDC channel, and enable scrambling
+ * Return: True if scrambling is successfully enabled, false otherwise.
+ */
+
+bool drm_enable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)
+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (hdmi_info->scr_info.status && !force) {
+   DRM_DEBUG_KMS("Scrambling already enabled\n");
+   return true;
+   }
+
+   if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
+   DRM_ERROR("Failed to read tmds config\n");
+   return false;
+   }
+
+   config |= SCDC_SCRAMBLING_ENABLE;
+
+   if (drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config) < 0) {
+   DRM_ERROR("Failed to enable scrambling, write error\n");
+   return false;
+   }
+
+   hdmi_info->scr_info.status = drm_check_scrambling_status(adapter);
+   return hdmi_info->scr_info.status;
+}
+
+/**
+ * drm_disable_scrambling - disable scrambling
+ * @connector: target drm_connector
+ * @adapter: i2c adapter for SCDC channel
+ * @force: disable scrambling, even if its already disabled
+ *
+ * Write the TMDS config over SCDC channel, and disable scrambling
+ * Return: True if scrambling is successfully disabled, false otherwise.
+ */
+bool drm_disable_scrambling(struct drm_connector *connector,
+   struct i2c_adapter *adapter, bool force)
+{
+   u8 config;
+   struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
+
+   if (!hdmi_info->scr_info.status && !force) {
+   DRM_DEBUG_KMS("Scrambling already disabled\n");
+   return true;
+   }
+
+   if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
+   DRM_ERROR("Failed to read tmds config\n");
+   return 

  1   2   >