Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume

2018-02-25 Thread Sagar Arun Kamble 



On 2/23/2018 7:40 PM, Michal Wajdeczko wrote:

We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 

Reviewed-by: Sagar Arun Kamble 

Couple of queries:
Need to add to commit message that ordering of disable_guc_interrupts 
and suspend is now changed as needed

for CTB. right?
Please find below another query.

---



--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -445,3 +445,48 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (USES_GUC_SUBMISSION(dev_priv))
gen9_disable_guc_interrupts(dev_priv);
  }
+
+int intel_uc_suspend(struct drm_i915_private *i915)
+{
+   struct intel_guc *guc = >guc;
+   int err;
+
+   if (!USES_GUC(i915))
+   return 0;
+
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
Assume this will get replaced by intel_uc_fw_is_loaded from other patch 
under review?

+   return 0;
+
+   err = intel_guc_suspend(guc);
+   if (err) {
+   DRM_DEBUG_DRIVER("Failed to suspend GuC, err=%d", err);
+   return err;
+   }
+
+   gen9_disable_guc_interrupts(i915);
+
+   return 0;
+}
+
+int intel_uc_resume(struct drm_i915_private *i915)
+{
+   struct intel_guc *guc = >guc;
+   int err;
+
+   if (!USES_GUC(i915))
+   return 0;
+
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   return 0;
+
+   if (i915_modparams.guc_log_level)
+   gen9_enable_guc_interrupts(i915);
+
+   err = intel_guc_resume(guc);
+   if (err) {
+   DRM_DEBUG_DRIVER("Failed to resume GuC, err=%d", err);
+   return err;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f2984e0..f76d51d 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -39,6 +39,8 @@
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
  void intel_uc_fini(struct drm_i915_private *dev_priv);
+int intel_uc_suspend(struct drm_i915_private *dev_priv);
+int intel_uc_resume(struct drm_i915_private *dev_priv);
  
  static inline bool intel_uc_is_using_guc(void)

  {


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH 22/43] drm/i915: Async execution of hdcp authentication

2018-02-25 Thread Ramalingam C 



On Thursday 22 February 2018 08:09 PM, Sean Paul wrote:

On Wed, Feb 14, 2018 at 07:43:37PM +0530, Ramalingam C wrote:

Each HDCP authentication, could take upto 5.1Sec, based on the
downstream HDCP topology.

Hence to avoid this much delay in the atomic_commit path, this patch
schedules the HDCP authentication into a asynchronous work.

This keeps the UI active, by enabling the flips in parallel to
HDCP auth.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_display.c |  1 +
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  drivers/gpu/drm/i915/intel_hdcp.c| 36 ++--
  3 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 30e38cbeface..048d60b5143b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15317,6 +15317,7 @@ static void intel_hpd_poll_fini(struct drm_device *dev)
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
+   cancel_work_sync(>hdcp_enable_work);
}
}
drm_connector_list_iter_end(_iter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 898064e8bea7..7b9e5f70826f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -412,6 +412,7 @@ struct intel_connector {
uint64_t hdcp_value; /* protected by hdcp_mutex */
struct delayed_work hdcp_check_work;
struct work_struct hdcp_prop_work;
+   struct work_struct hdcp_enable_work;
  };
  
  struct intel_digital_connector_state {

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..e03bd376d92c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -600,8 +600,14 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector),
  connector->hdcp_shim);
-   if (!ret)
+   if (!ret) {
+   connector->hdcp_value =
+   DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>hdcp_prop_work);
+   schedule_delayed_work(>hdcp_check_work,
+ DRM_HDCP_CHECK_PERIOD_MS);
return 0;
+   }
  
  		DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
  
@@ -613,6 +619,17 @@ static int _intel_hdcp_enable(struct intel_connector *connector)

return ret;
  }
  
+static void intel_hdcp_enable_work(struct work_struct *work)

+{
+   struct intel_connector *connector = container_of(work,
+struct intel_connector,
+hdcp_enable_work);
+
+   mutex_lock(>hdcp_mutex);
+   _intel_hdcp_enable(connector);
+   mutex_unlock(>hdcp_mutex);
+}
+
  static void intel_hdcp_check_work(struct work_struct *work)
  {
struct intel_connector *connector = container_of(to_delayed_work(work),
@@ -669,29 +686,20 @@ int intel_hdcp_init(struct intel_connector *connector,
mutex_init(>hdcp_mutex);
INIT_DELAYED_WORK(>hdcp_check_work, intel_hdcp_check_work);
INIT_WORK(>hdcp_prop_work, intel_hdcp_prop_work);
+   INIT_WORK(>hdcp_enable_work, intel_hdcp_enable_work);
return 0;
  }
  
  int intel_hdcp_enable(struct intel_connector *connector)

  {
-   int ret;
-
if (!connector->hdcp_shim)
return -ENOENT;
  
  	mutex_lock(>hdcp_mutex);

Why do you need to hold this lock to schedule the worker?


-
-   ret = _intel_hdcp_enable(connector);
-   if (ret)
-   goto out;
-
-   connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>hdcp_prop_work);
-   schedule_delayed_work(>hdcp_check_work,
- DRM_HDCP_CHECK_PERIOD_MS);
-out:
+   schedule_work(>hdcp_enable_work);

How is this worker cancelled when appropriate (enable/disable, hotplug, etc)?
At present enable flow also non-interuptible on hotplug. disable is not 
even is possible along with enable. correct me if i am wrong.


Since enable flow is blocking the modeset(atomic) also, I am afraid we 
need to adopt a worker for

enable path for facilitate the hotplug processing.

And in case of worker implementation need to check the connector status 
and hdcp preferred state before entering into any wait for msg.
Sleep should be selectively interruptible. every reauth should be 
checking the above conditions. I feel this is do-able.


This patch also not doing all of the above. If you think above

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

2018-02-25 Thread Sagar Arun Kamble 



On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:



On 23/02/18 06:04, Michal Wajdeczko wrote:

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
 don't forget about gem_sanitize path (Daniele)

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c    |  5 -
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c    | 14 ++
  drivers/gpu/drm/i915/intel_uc.h    |  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 14c855b..ae2c4ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct 
drm_i915_private *dev_priv)

  }
    i915_gem_revoke_fences(dev_priv);
+    intel_uc_prepare_to_reset(dev_priv);
    return err;
  }
@@ -4881,8 +4882,10 @@ void i915_gem_sanitize(struct drm_i915_private 
*i915)
   * it may impact the display and we are uncertain about the 
stability

   * of the reset, so this could be applied to even earlier gen.
   */
-    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+    intel_uc_prepare_to_reset(i915);


This leaves the status with an incorrect value if we boot with 
i915.reset=0, 
It depends on whether WOPCM is locked (In case of resume from S3 I have 
seen it to be the case often).

Then we need not reload GuC also unless we are not doing full GPU reset.
but I think this is still the right place to add this in. 

Yes
There are several things with GuC that are going to break if we use 
reset=0 (e.g. doorbell cleanup) 

Can you elaborate how it might break.
i915 isn't currently communicating to GuC (destroy_doorbell) during 
doorbell cleanup and if we start communicating then it should
not fail as GuC will be available with reset=0.  Also 
__intel_uc_reset_hw isn't gated by reset modparam.
so I wouldn't consider this a regression, but we might want to start 
sanitizing the modparams to not allow reset=0 with GuC.


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


  WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+    }
  }
    int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 52856a9..0f6adb1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 
size);

  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  +static inline void intel_guc_prepare_to_reset(struct intel_guc *guc)
+{
+    intel_uc_fw_prepare_to_reset(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h 
b/drivers/gpu/drm/i915/intel_huc.h

index 40039db..96e24f9 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,9 @@ struct intel_huc {
  int intel_huc_init_hw(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  +static inline void intel_huc_prepare_to_reset(struct intel_huc *huc)
+{
+    intel_uc_fw_prepare_to_reset(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 9f1bac6..8042d4b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -445,3 +445,17 @@ void intel_uc_fini_hw(struct drm_i915_private 
*dev_priv)

  if (USES_GUC_SUBMISSION(dev_priv))
  gen9_disable_guc_interrupts(dev_priv);
  }
+
+void intel_uc_prepare_to_reset(struct drm_i915_private *i915)
+{
+    struct intel_huc *huc = >huc;
+    struct intel_guc *guc = >guc;
+
+    if (!USES_GUC(i915))
+    return;
+
+    GEM_BUG_ON(!HAS_GUC(i915));
+
+    intel_huc_prepare_to_reset(huc);
+    intel_guc_prepare_to_reset(guc);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index f2984e0..7a8ae58 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -39,6 +39,7 @@
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
  void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_prepare_to_reset(struct

Re: [Intel-gfx] [PATCH 23/43] drm/i915: wrapping all hdcp var into intel_hdcp

2018-02-25 Thread Ramalingam C 



On Thursday 22 February 2018 08:17 PM, Sean Paul wrote:

On Wed, Feb 14, 2018 at 07:43:38PM +0530, Ramalingam C wrote:

Considering the upcoming significant no HDCP2.2 variables, it will
be clean to have separate struct fo HDCP.

New structure called intel_hdcp is introduced.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_display.c |   9 ++-
  drivers/gpu/drm/i915/intel_dp.c  |   4 +-
  drivers/gpu/drm/i915/intel_drv.h |  20 +++--
  drivers/gpu/drm/i915/intel_hdcp.c| 141 ---
  4 files changed, 100 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 048d60b5143b..22097349529b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15314,10 +15314,11 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
for_each_intel_connector_iter(connector, _iter) {
if (connector->modeset_retry_work.func)
cancel_work_sync(>modeset_retry_work);
-   if (connector->hdcp_shim) {
-   cancel_delayed_work_sync(>hdcp_check_work);
-   cancel_work_sync(>hdcp_prop_work);
-   cancel_work_sync(>hdcp_enable_work);
+   if (connector->hdcp && connector->hdcp->hdcp_shim) {
+   cancel_delayed_work_sync(
+   >hdcp->hdcp_check_work);
+   cancel_work_sync(>hdcp->hdcp_prop_work);
+   cancel_work_sync(>hdcp->hdcp_enable_work);
}
}
drm_connector_list_iter_end(_iter);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f20b25f98e5a..80476689754f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5445,7 +5445,9 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
WARN(iret, "Acquiring modeset locks failed with %i\n", iret);
  
  		/* Short pulse can signify loss of hdcp authentication */

-   intel_hdcp_check_link(intel_dp->attached_connector);
+   if (intel_dp->attached_connector->hdcp)
+   intel_hdcp_check_link(
+   intel_dp->attached_connector->hdcp);
  
  		if (!handled) {

intel_dp->detect_done = false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b9e5f70826f..5b170ff7ec14 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -375,6 +375,17 @@ struct intel_hdcp_shim {
bool *hdcp_capable);
  };
  
+struct intel_hdcp {

+   struct intel_connector *connector;

You don't need a backpointer, use container_of if necessary.

ok sure.



+
+   const struct intel_hdcp_shim *hdcp_shim;
+   struct mutex hdcp_mutex;
+   uint64_t hdcp_value; /* protected by hdcp_mutex */
+   struct delayed_work hdcp_check_work;
+   struct work_struct hdcp_prop_work;
+   struct work_struct hdcp_enable_work;
+};
+
  struct intel_connector {
struct drm_connector base;
/*
@@ -407,12 +418,7 @@ struct intel_connector {
/* Work struct to schedule a uevent on link train failure */
struct work_struct modeset_retry_work;
  
-	const struct intel_hdcp_shim *hdcp_shim;

-   struct mutex hdcp_mutex;
-   uint64_t hdcp_value; /* protected by hdcp_mutex */
-   struct delayed_work hdcp_check_work;
-   struct work_struct hdcp_prop_work;
-   struct work_struct hdcp_enable_work;
+   struct intel_hdcp *hdcp;
  };
  
  struct intel_digital_connector_state {

@@ -1853,7 +1859,7 @@ int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim);
  int intel_hdcp_enable(struct intel_connector *connector);
  int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
+int intel_hdcp_check_link(struct intel_hdcp *hdcp);
  bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
  
  /* intel_psr.c */

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index e03bd376d92c..9147fb17a9fc 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -545,8 +545,9 @@ struct intel_digital_port *conn_to_dig_port(struct 
intel_connector *connector)
return enc_to_dig_port(_attached_encoder(>base)->base);
  }
  
-static int _intel_hdcp_disable(struct intel_connector *connector)

+static int _intel_hdcp_disable(struct intel_hdcp *hdcp)
  {
+   struct intel_connector *connector = hdcp->connector;

I'm not sure why we need to change all of the function arguments to intel_hdcp
if the first thing we do is fetch the connector.


struct

Re: [Intel-gfx] [PATCH 24/43] drm/i915: wait for cp_irq

2018-02-25 Thread Ramalingam C 



On Thursday 22 February 2018 09:16 PM, Sean Paul wrote:

On Wed, Feb 14, 2018 at 07:43:39PM +0530, Ramalingam C wrote:

DP HDCP asserts the CP_IRQ to indicate the msg availability and
auth state change at the panel.

Implements a completion structure to communicate the cp_irq
assertion and provides a function to wait for cp_irq with a timeout.

This can be used for implementation of both HDCP1.4 and HDCP2.2


But it's not. Please introduce code in the same patch as when it's used.

Wanted to keep this as independent preparation patch for both versions.
Anyway i will squash it with the 2.2 patch that needs this implementation.

Thanks
--Ram



Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_dp.c   | 28 ++--
  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
  drivers/gpu/drm/i915/intel_hdcp.c |  1 +
  3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 80476689754f..8847f1a36504 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4402,6 +4402,7 @@ static bool
  intel_dp_short_pulse(struct intel_dp *intel_dp)
  {
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+   struct intel_connector *connector = intel_dp->attached_connector;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
bool ret;
@@ -4436,8 +4437,13 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
  
  		if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)

intel_dp_handle_test_request(intel_dp);
-   if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
-   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
+   if (sink_irq_vector & DP_CP_IRQ) {
+   if (connector->hdcp)
+   complete(>hdcp->cp_irq_recved);
+   }
+
+   if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
+   DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
}
  
  	intel_dp_check_link_status(intel_dp);

@@ -5049,6 +5055,24 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
  }
  
+static int wait_for_cp_irq(struct completion *cp_irq_recved, int timeout)

+{
+   long ret;
+
+   if (completion_done(cp_irq_recved))
+   reinit_completion(cp_irq_recved);
+
+   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+   msecs_to_jiffies(
+   timeout));
+   reinit_completion(cp_irq_recved);
+   if (ret < 0)
+   return (int)ret;
+   else if (!ret)
+   return -ETIMEDOUT;
+   return 0;
+}
+
  static
  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5b170ff7ec14..1c0d324c1044 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -384,6 +384,9 @@ struct intel_hdcp {
struct delayed_work hdcp_check_work;
struct work_struct hdcp_prop_work;
struct work_struct hdcp_enable_work;
+
+   /* To indicate the assertion of CP_IRQ */
+   struct completion cp_irq_recved;
  };
  
  struct intel_connector {

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9147fb17a9fc..31e1af5b43ec 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -695,6 +695,7 @@ int intel_hdcp_init(struct intel_connector *connector,
INIT_WORK(>hdcp_prop_work, intel_hdcp_prop_work);
INIT_WORK(>hdcp_enable_work, intel_hdcp_enable_work);
  
+	init_completion(>cp_irq_recved);

connector->hdcp = hdcp;
return 0;
  
--

2.7.4



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

Re: [Intel-gfx] [PATCH 25/43] drm/i915: Define HDCP2.2 related variables

2018-02-25 Thread Ramalingam C 



On Thursday 22 February 2018 08:29 PM, Sean Paul wrote:

On Wed, Feb 14, 2018 at 07:43:40PM +0530, Ramalingam C wrote:

For upcoming implementation of HDCP2.2 in I915, all variable required
for HDCP2.2 are defined.

This includes a translation layer called hdcp2_shim for encoder
specific HDCP2.2 spec deviations.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/i915_drv.h  |  5 +++
  drivers/gpu/drm/i915/intel_drv.h | 91 
  2 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3f8d824dc313..09d31db90a38 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -44,6 +44,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -2365,6 +2366,10 @@ struct drm_i915_private {
  
  	struct i915_pmu pmu;
  
+	/* Mei interface handle */

+   struct mei_cl_device *mei_cldev;
+   int mei_ref_cnt;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c0d324c1044..9c05049c25d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -301,6 +301,62 @@ struct intel_panel {
} backlight;
  };
  
+struct intel_hdcp;

Why?
Sorry this is left over from previous version of hdcp2_shim. I will 
remove it.



+
+#define HDCP_CAPABILITYBIT(0)
+#define HDCP2_CAPABILITY   BIT(1)

These names are pretty vague, without a comment it's hard to know what/where
they're used.
These bit definitions are added to update and check the hdcp version 
capability in platform and panel.

If plat_cap and panel_cap are dropped, these definitions are irrelevant.


It's really hard to review changes where things are just defined. Can you please
squash this patch into the patch where you actually use it?


+
+/*
+ * This structure serves as a translation layer between the generic HDCP2.2 
code
+ * and the bus-specific code. What that means is that HDCP over HDMI differs
+ * from HDCP over DP, so to account for these differences, we need to
+ * communicate with the receiver through this shim.
+ *
+ * For completeness, the 2 buses differ in the following ways:
+ * - DP AUX vs. DDC
+ * HDCP registers on the receiver are set via DP AUX for DP, and
+ * they are set via DDC for HDMI.
+ * - Receiver register offsets
+ * The offsets of the registers are different for DP vs. HDMI
+ * - Receiver register masks/offsets
+ * Few register bit definitions are different between DP and HDMI.
+ * - HDCP signalling
+ * Needed for HDMI but not for DP.
+ * - Configure stream type onto receiver
+ * Needed only for DP but not for HDMI.
+ */
+struct intel_hdcp2_shim {

Why don't you just use the same shim? No need to duplicate.
If that is ok, i would prefer to maintain hdcp1.4 and hdcp2.2 
definitions and stack independently.
IMO in that way it will be easy to debug and maintain the  issues from 
the corresponding versions.

Please let me know if you feel other way around.



+
+   /* Write HDCP2.2 messages */
+   int (*write_msg)(struct intel_digital_port *intel_dig_port, void *buf,
+size_t size);
+
+   /* Read HDCP2.2 messages */
+   int (*read_msg)(struct intel_digital_port *intel_dig_port,
+   uint8_t msg_id, void *buf, size_t size);
+
+   /*
+* Implementation of DP Errata for the communication of stream type to
+* Receivers. Not applicable for HDMI.
+*/
+   int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
+
+   /* Enables HDCP signalling on the port. Not applicable for DP. */
+   int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+bool enable);
+
+   /* Link Integrity Check */
+   int (*check_link)(struct intel_digital_port *intel_dig_port);
+
+   /* Detects whether Panel is HDCP2.2 capable */
+   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
+   bool *capable);
+
+   /* Detects the HDCP protocol(DP/HDMI) required on the port */
+   enum hdcp_protocol (*hdcp_protocol)(void);
+};
+
  /*
   * This structure serves as a translation layer between the generic HDCP code
   * and the bus-specific code. What that means is that HDCP over HDMI differs
@@ -378,6 +434,10 @@ struct intel_hdcp_shim {
  struct intel_hdcp {
struct intel_connector *connector;
  
+	/* Flags to represent the HDCP capability of the platform and panel */

+   u32 plat_cap;

I don't think you need this. A simple bool supports_hdcp2 would suffice

Re: [Intel-gfx] [PATCH 26/43] drm/i915: Define Intel HDCP2.2 registers

2018-02-25 Thread Ramalingam C 



On Thursday 22 February 2018 09:13 PM, Sean Paul wrote:

On Wed, Feb 14, 2018 at 07:43:41PM +0530, Ramalingam C wrote:

Intel HDCP2.2 registers are defined with addr offsets and bit details.

Macros are defined for referencing the register offsets based on the
port index.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/i915_reg.h | 120 
  1 file changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e5e7c1..6a57b12d8dab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2268,6 +2268,126 @@ enum i915_power_well_id {
   _PORT_TX_DW14_LN0_C) +   \
  _BXT_LANE_OFFSET(lane))
  
+/*

+ *HDCP Registers
+ **/

Do you need a new section for these? Just stick them with the existing HDCP
registers.

ok



+
+/*
+ * HW register offsets are incresing in the order of B, C, D, A, F, E.
+ * But enum value increses in the order of A, B, C, D, E, F.
+ * So port numbers are adjusted for offset calculations.
+ */
+#define HDCP_PORT_INDEX_ADJUST(p)  (((p) == PORT_A ? PORT_E : \
+   (p) == PORT_E ? (0x6) : \
+   (p)) - 1)
+#define _MMIO_HDCP_PORT(p, a, b)   _MMIO_PORT(HDCP_PORT_INDEX_ADJUST(p), \
+   a, b)

Can you do this the same was as I did _PORT_HDCP_AUTHENC, with _PICK? Then you
aren't limited to just ports a and b (and you don't need the arithmatic above.

Sure. I will use _PICK. Thanks!
--Ram



+
+
+/* RO Registers for I915. Programmable from FW(ME) only */
+#define HDCP2_AUTH_DDI_A   0x66898
+#define HDCP2_AUTH_DDI_B   0x66598
+#define HDCP2_AUTH_DDI_C   0x66698
+#define HDCP2_AUTH_DDI_D   0x66798
+#define HDCP2_AUTH_DDI_E   0x66A98
+#define HDCP2_AUTH_DDI_F   0x66998
+#define   AUTH_LINK_AUTHENTICATED  (1 << 31)
+#define   AUTH_LINK_TYPE   (1 << 30)
+#define   AUTH_FORCE_CLR_INPUTCTR  (1 << 19)
+#define   AUTH_CLR_KEYS(1 << 18)
+
+#define HDCP2_AUTH_DDI(port)   _MMIO_HDCP_PORT(port, \
+   HDCP2_AUTH_DDI_B, \
+   HDCP2_AUTH_DDI_C)
+
+
+/* Multi stream DP registers */
+/* RO Registers for I915. Programmable from FW(ME) only */
+#define HDCP2_AUTH_STREAM_A0x66F00
+#define HDCP2_AUTH_STREAM_B0x66F04
+#define HDCP2_AUTH_STREAM_C0x66F08
+#define HDCP2_AUTH_STREAM_D0x66F0C
+#define   AUTH_STREAM_TYPE (1 << 31)
+
+#define HDCP2_AUTH_STREAM(stream)  _MMIO_PORT(stream, \
+  HDCP2_AUTH_STREAM_A, \
+  HDCP2_AUTH_STREAM_B)
+
+/* RW Registers for I915 */
+#define HDCP2_CTL_DDI_A0x668B0
+#define HDCP2_CTL_DDI_B0x665B0
+#define HDCP2_CTL_DDI_C0x666B0
+#define HDCP2_CTL_DDI_D0x667B0
+#define HDCP2_CTL_DDI_E0x66AB0
+#define HDCP2_CTL_DDI_F0x669B0
+#define   CTL_LINK_ENCRYPTION_REQ  (1 << 31)
+#define   CTL_VBID_TYPE_SELECT_SHIFT   29
+#define   CTL_VBID_TYPE_SELECT_MASK(3 << CTL_VBID_TYPE_SELECT_SHIFT)
+
+#define HDCP2_CTR_DDI(port)_MMIO_HDCP_PORT(port, HDCP2_CTL_DDI_B, \
+   HDCP2_CTL_DDI_C)
+
+/* RO only. For Debug purpose */
+#define HDCP2_INPUTCTR_DDI_A   0x668B8
+#define HDCP2_INPUTCTR_DDI_B   0x665B8
+#define HDCP2_INPUTCTR_DDI_C   0x666B8
+#define HDCP2_INPUTCTR_DDI_D   0x667B8
+#define HDCP2_INPUTCTR_DDI_E   0x66AB8
+#define HDCP2_INPUTCTR_DDI_F   0x669B8
+
+#define HDCP2_INPUTCTR_LO_DDI(port)_MMIO_HDCP_PORT(port, \
+   HDCP2_INPUTCTL_DDI_B, \
+   HDCP2_INPUTCTL_DDI_C)
+
+#define HDCP2_INPUTCTR_HI_DDI(port)_MMIO_HDCP_PORT(port, \
+   (HDCP2_INPUTCTL_DDI_B + 4), \
+   (HDCP2_INPUTCTL_DDI_C + 4))
+
+/* RO Registers for I915. Programmable from FW(ME) only */
+#define HDCP2_RIV_DDI_A0x66890
+#define HDCP2_RIV_DDI_B0x66590
+#define HDCP2_RIV_DDI_C0x66690
+#define HDCP2_RIV_DDI_D0x66790
+#define HDCP2_RIV_DDI_E0x66A90
+#define HDCP2_RIV_DDI_F0x66990
+
+#define HDCP2_RIV_LO_DDI(port) _MMIO_HDCP_PORT(port, HDCP2_RIV_DDI_B, \
+

Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

2018-02-25 Thread Sagar Arun Kamble 



On 2/23/2018 4:35 AM, Oscar Mateo wrote:





+ * We might have detected that some engines are fused off after we 
initialized
+ * the forcewake domains. Prune them, to make sure they only 
reference existing

+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+    if (INTEL_GEN(dev_priv) >= 11) {
+    enum forcewake_domains fw_domains = 
dev_priv->uncore.fw_domains;

+    enum forcewake_domain_id domain_id;
+    int i;
+
+    for (i = 0; i < I915_MAX_VCS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VDBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VCS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
fw_domains check seems redundant as it is initialized based on 
HAS_ENGINE.

we can just have
if (!HAS_ENGINE(dev_priv, _VCS(i)))
    fw_domain_fini(dev_priv, domain_id);


I don't want to call fw_domain_fini on something we never initialized 
in the first place (e.g. VCS1/3 and VECS1/2/3 on an ICL-LP).



Right. Makes sense.
for loop iterating over engines based on ring_mask can help us rely on 
only HAS_ENGINE condition and then we can have complete pruning in 
single for loop.

what do you think?

+ fw_domain_fini(dev_priv, domain_id);
+    }
+
+    for (i = 0; i < I915_MAX_VECS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VEBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VECS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
+    fw_domain_fini(dev_priv, domain_id);
+    }
+    }
+}
+
  void intel_uncore_fini(struct drm_i915_private *dev_priv)
  {
  /* Paranoia: make sure we have disabled everything before we 
exit. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h

index 53ef77d..28feabf 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
    void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
  void intel_uncore_init(struct drm_i915_private *dev_priv);
+void intel_uncore_prune(struct drm_i915_private *dev_priv);
  bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
  bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv);

  void intel_uncore_fini(struct drm_i915_private *dev_priv);






--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH 08/10] drm: i915: Enable VDSC in Source

2018-02-25 Thread kbuild test robot 
Hi Gaurav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180223]
[cannot apply to drm-intel/for-linux-next drm/drm-next v4.16-rc3 v4.16-rc2 
v4.16-rc1 v4.16-rc3]
[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/Gaurav-K-Singh/Enabling-VDSC-in-i915-driver-for-GLK/20180226-114246
config: x86_64-randconfig-x009-201808 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_vdsc.c: In function 'intel_dsc_enable':
>> drivers/gpu//drm/i915/intel_vdsc.c:1164:3: warning: 'dsc_type2' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  configure_dsc_params_for_dsc_controller(encoder, pipe_config,
  ^
   _regs, dsc_type2);
   ~
>> drivers/gpu//drm/i915/intel_vdsc.c:1160:2: warning: 'dsc_type1' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 configure_dsc_params_for_dsc_controller(encoder, pipe_config,
 ^
   _regs, dsc_type1);
   ~

vim +/dsc_type2 +1164 drivers/gpu//drm/i915/intel_vdsc.c

  1103  
  1104  void intel_dsc_enable(struct intel_encoder *encoder,
  1105  struct intel_crtc_state *pipe_config)
  1106  {
  1107  struct intel_dp *intel_dp = enc_to_intel_dp(>base);
  1108  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
  1109  struct picture_parameters_set pps_params;
  1110  struct intel_dsc_regs dsc_regs;
    struct drm_crtc *crtc = pipe_config->base.crtc;
  1112  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
  1113  int pipe = intel_crtc->pipe;
  1114  int dsc_type1;
  1115  int dsc_type2;
  1116  int type = encoder->type;
  1117  unsigned int dss_ctrl1_value = 0;
  1118  unsigned int dss_ctrl2_value = 0;
  1119  
  1120  if ((INTEL_GEN(dev_priv) < 9) ||
  1121  
!intel_dp->compr_params.compression_support)
  1122  return;
  1123  /* TO DO: configure DSC params and program source regs */
  1124  
  1125  if (type == INTEL_OUTPUT_EDP) {
  1126  dsc_regs.dss_ctrl1_reg = DSS_CONTROL1;
  1127  dsc_regs.dss_ctrl2_reg = DSS_CONTROL2;
  1128  dsc_regs.dip_ctrl_reg = VIDEO_DIP_CTL_EDP;
  1129  dsc_regs.dip_pps_data_ctrl_reg = 
VIDEO_DIP_PPS_DATA_EDP_REG;
  1130  dsc_type1 = DSC_A;
  1131  dsc_type2 = DSC_C;
  1132  } else if (type == INTEL_OUTPUT_DP) {
  1133  switch (pipe) {
  1134  case PIPE_A:
  1135  dsc_regs.dss_ctrl1_reg = PIPE_DSS_CTL1_PB;
  1136  dsc_regs.dss_ctrl2_reg = PIPE_DSS_CTL2_PB;
  1137  dsc_regs.dip_ctrl_reg = VIDEO_DIP_CTL_A;
  1138  dsc_regs.dip_pps_data_ctrl_reg =
  1139  
VIDEO_DIP_DRM_DATA_TRANSA_REG;
  1140  dsc_type1 = PIPEA_DSC_0;
  1141  dsc_type2 = PIPEA_DSC_1;
  1142  break;
  1143  case PIPE_B:
  1144  dsc_regs.dss_ctrl1_reg = PIPE_DSS_CTL1_PC;
  1145  dsc_regs.dss_ctrl2_reg = PIPE_DSS_CTL2_PC;
  1146  dsc_regs.dip_ctrl_reg = VIDEO_DIP_CTL_B;
  1147  dsc_regs.dip_pps_data_ctrl_reg =
  1148  
VIDEO_DIP_DRM_DATA_TRANSB_REG;
  1149  dsc_type1 = PIPEB_DSC_0;
  1150  dsc_type2 = PIPEB_DSC_1;
  1151  break;
  1152  default:
  1153  return;
  1154  }
  1155  } else {
  1156  DRM_ERROR("Func:%s Unsupported port:%d\n", __func__, 
type);
  1157  }
  1158  
  1159  intel_dsc_regs_init(encoder, _regs, dsc_type1);
> 1160  configure_dsc_params_for_dsc_controller(encoder, pipe_config,
  1161  _regs, 
dsc_type1);
  1162  if (intel_dp->compr_params.dsc_cfg.num_vdsc_instances != 1) {
  1163  intel_dsc_regs_init(encoder, _regs, dsc_type2);
> 1164  configure_dsc_params_for_dsc_controller(encoder, 
> pipe_config,

---
0-DAY

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable SAGV on pre plane update.

2018-02-25 Thread kbuild test robot 
Hi Rodrigo,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180223]
[cannot apply to v4.16-rc3]
[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/Rodrigo-Vivi/drm-i915-Disable-SAGV-on-pre-plane-update/20180226-094030
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x003-02260939 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_display.c: In function 'intel_post_plane_update':
>> drivers/gpu//drm/i915/intel_display.c:5094:27: error: unused variable 
>> 'dev_priv' [-Werror=unused-variable]
 struct drm_i915_private *dev_priv = to_i915(dev);
  ^~~~
   cc1: all warnings being treated as errors

vim +/dev_priv +5094 drivers/gpu//drm/i915/intel_display.c

  5089  
  5090  static void intel_post_plane_update(struct intel_crtc_state 
*old_crtc_state)
  5091  {
  5092  struct intel_crtc *crtc = 
to_intel_crtc(old_crtc_state->base.crtc);
  5093  struct drm_device *dev = crtc->base.dev;
> 5094  struct drm_i915_private *dev_priv = to_i915(dev);
  5095  struct drm_atomic_state *old_state = old_crtc_state->base.state;
  5096  struct intel_crtc_state *pipe_config =
  5097  
intel_atomic_get_new_crtc_state(to_intel_atomic_state(old_state),
  5098  crtc);
  5099  struct drm_plane *primary = crtc->base.primary;
  5100  struct drm_plane_state *old_pri_state =
  5101  drm_atomic_get_existing_plane_state(old_state, primary);
  5102  
  5103  intel_frontbuffer_flip(to_i915(crtc->base.dev), 
pipe_config->fb_bits);
  5104  
  5105  if (pipe_config->update_wm_post && pipe_config->base.active)
  5106  intel_update_watermarks(crtc);
  5107  
  5108  if (hsw_post_update_enable_ips(old_crtc_state, pipe_config))
  5109  hsw_enable_ips(pipe_config);
  5110  
  5111  if (old_pri_state) {
  5112  struct intel_plane_state *primary_state =
  5113  
intel_atomic_get_new_plane_state(to_intel_atomic_state(old_state),
  5114   
to_intel_plane(primary));
  5115  struct intel_plane_state *old_primary_state =
  5116  to_intel_plane_state(old_pri_state);
  5117  
  5118  intel_fbc_post_update(crtc);
  5119  
  5120  if (primary_state->base.visible &&
  5121  (needs_modeset(_config->base) ||
  5122   !old_primary_state->base.visible))
  5123  intel_post_enable_primary(>base, 
pipe_config);
  5124  }
  5125  }
  5126  

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_busy: Fix extended-bsd aliasing checks

2018-02-25 Thread Patchwork 
== Series Details ==

Series: igt/gem_busy: Fix extended-bsd aliasing checks
URL   : https://patchwork.freedesktop.org/series/38920/
State : warning

== Summary ==

Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-hsw)
Test kms_plane:
Subgroup plane-position-hole-dpms-pipe-b-planes:
fail   -> PASS   (shard-apl)
Test kms_flip:
Subgroup wf_vblank-ts-check-interruptible:
pass   -> FAIL   (shard-apl) fdo#100368 +1
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-top-edge:
fail   -> PASS   (shard-apl)
Test gem_exec_async:
Subgroup concurrent-writes-bsd1:
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl)
Subgroup concurrent-writes-bsd2:
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

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

shard-apltotal:3465 pass:1818 dwarn:1   dfail:0   fail:12  skip:1633 
time:12330s
shard-hswtotal:3465 pass:1766 dwarn:1   dfail:0   fail:3   skip:1694 
time:11579s
shard-snbtotal:3465 pass:1358 dwarn:1   dfail:0   fail:3   skip:2103 
time:6695s
Blacklisted hosts:
shard-kbltotal:3457 pass:1921 dwarn:16  dfail:2   fail:11  skip:1506 
time:9410s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_exec_schedule: Exercise "deep" preemption

2018-02-25 Thread Patchwork 
== Series Details ==

Series: igt/gem_exec_schedule: Exercise "deep" preemption
URL   : https://patchwork.freedesktop.org/series/38914/
State : warning

== Summary ==

Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
skip   -> PASS   (shard-hsw)
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-top-edge:
fail   -> PASS   (shard-apl)
Test kms_flip:
Subgroup wf_vblank-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_plane:
Subgroup plane-position-hole-dpms-pipe-b-planes:
fail   -> PASS   (shard-apl)
Test gem_exec_async:
Subgroup concurrent-writes-bsd1:
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl)
Subgroup concurrent-writes-bsd2:
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925

shard-apltotal:3483 pass:1831 dwarn:1   dfail:0   fail:11  skip:1639 
time:12274s
shard-hswtotal:3483 pass:1763 dwarn:1   dfail:0   fail:6   skip:1712 
time:11714s
shard-snbtotal:3483 pass:1358 dwarn:1   dfail:0   fail:3   skip:2121 
time:6700s
Blacklisted hosts:
shard-kbltotal:3481 pass:1949 dwarn:1   dfail:0   fail:20  skip:1510 
time:9301s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_busy: Fix extended-bsd aliasing checks

2018-02-25 Thread Patchwork 
== Series Details ==

Series: igt/gem_busy: Fix extended-bsd aliasing checks
URL   : https://patchwork.freedesktop.org/series/38920/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
305ebcedc36e98f3118ac27a5bbde0ce7cd71a74 Iterate over physical engines

with latest DRM-Tip kernel build CI_DRM_3830
316ba650abe6 drm-tip: 2018y-02m-23d-16h-41m-52s UTC integration manifest

No testlist changes.

Test kms_chamelium:
Subgroup dp-edid-read:
fail   -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-snb-2520m)
Subgroup force-edid:
skip   -> PASS   (fi-snb-2520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-snb-2520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-snb-2520m)

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:390s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:295s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:464s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_exec_schedule: Exercise "deep" preemption

2018-02-25 Thread Patchwork 
== Series Details ==

Series: igt/gem_exec_schedule: Exercise "deep" preemption
URL   : https://patchwork.freedesktop.org/series/38914/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
305ebcedc36e98f3118ac27a5bbde0ce7cd71a74 Iterate over physical engines

with latest DRM-Tip kernel build CI_DRM_3830
316ba650abe6 drm-tip: 2018y-02m-23d-16h-41m-52s UTC integration manifest

Testlist changes:
+igt@gem_exec_schedule@preempt-other-chain-blt
+igt@gem_exec_schedule@preempt-other-chain-bsd
+igt@gem_exec_schedule@preempt-other-chain-bsd1
+igt@gem_exec_schedule@preempt-other-chain-bsd2
+igt@gem_exec_schedule@preempt-other-chain-render
+igt@gem_exec_schedule@preempt-other-chain-vebox
+igt@gem_exec_schedule@preempt-queue-blt
+igt@gem_exec_schedule@preempt-queue-bsd
+igt@gem_exec_schedule@preempt-queue-bsd1
+igt@gem_exec_schedule@preempt-queue-bsd2
+igt@gem_exec_schedule@preempt-queue-chain-blt
+igt@gem_exec_schedule@preempt-queue-chain-bsd
+igt@gem_exec_schedule@preempt-queue-chain-bsd1
+igt@gem_exec_schedule@preempt-queue-chain-bsd2
+igt@gem_exec_schedule@preempt-queue-chain-render
+igt@gem_exec_schedule@preempt-queue-chain-vebox
+igt@gem_exec_schedule@preempt-queue-render
+igt@gem_exec_schedule@preempt-queue-vebox

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-edid-read:
fail   -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-snb-2520m)
Subgroup force-edid:
skip   -> PASS   (fi-snb-2520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-snb-2520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:452s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23

[Intel-gfx] [PATCH igt] igt/gem_busy: Fix extended-bsd aliasing checks

2018-02-25 Thread Chris Wilson 
Although we want to specify exactly which physical engine to run on, the
busy ioctl can only return the I915_EXEC_RING identifier, i.e. the
aliased I915_EXEC_BSD for vcs0/vcs1. Horrors.

Signed-off-by: Chris Wilson 
---
 tests/gem_busy.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tests/gem_busy.c b/tests/gem_busy.c
index 831bbab1..fcff51a2 100644
--- a/tests/gem_busy.c
+++ b/tests/gem_busy.c
@@ -166,6 +166,7 @@ static void one(int fd, unsigned ring, unsigned test_flags)
struct drm_i915_gem_relocation_entry store[1024+1];
struct drm_i915_gem_execbuffer2 execbuf;
unsigned size = ALIGN(ARRAY_SIZE(store)*16 + 4, 4096);
+   const unsigned uabi = ring & 63;
uint32_t read[2], write[2];
struct timespec tv;
uint32_t *batch, *bbe;
@@ -267,11 +268,11 @@ static void one(int fd, unsigned ring, unsigned 
test_flags)
timeout = 1;
}
 
-   igt_assert_eq(write[SCRATCH], ring);
-   igt_assert_eq_u32(read[SCRATCH], 1 << ring);
+   igt_assert_eq(write[SCRATCH], uabi);
+   igt_assert_eq_u32(read[SCRATCH], 1 << uabi);
 
igt_assert_eq(write[BATCH], 0);
-   igt_assert_eq_u32(read[BATCH], 1 << ring);
+   igt_assert_eq_u32(read[BATCH], 1 << uabi);
 
/* Calling busy in a loop should be enough to flush the rendering */
memset(, 0, sizeof(tv));
-- 
2.16.1

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

[Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

2018-02-25 Thread Lukas Wunner 
DRM drivers need to tell vga_switcheroo whether they use runtime PM.
If they do use it, vga_switcheroo lets them autosuspend at their own
discretion.  If on the other hand they do not use it, vga_switcheroo
allows the user to suspend and resume the GPU manually via the
->set_gpu_state hook.

i915 currently tells vga_switcheroo that it never uses runtime PM, even
though it does use it on HSW and newer.  The result is that users may
interfere with the driver's runtime PM on those platforms.  Avoid by
reporting runtime PM support correctly to vga_switcheroo.

Cc: Imre Deak 
Signed-off-by: Lukas Wunner 
---
 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 aaa861b51024..519a1b9568df 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -668,7 +668,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
intel_register_dsm_handler();
 
-   ret = vga_switcheroo_register_client(pdev, _switcheroo_ops, false);
+   ret = vga_switcheroo_register_client(pdev, _switcheroo_ops,
+HAS_RUNTIME_PM(dev_priv));
if (ret)
goto cleanup_vga_client;
 
-- 
2.15.1

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

[Intel-gfx] [PATCH igt] igt/gem_softpin: Only expect EINVAL for color-overlaps for user objects

2018-02-25 Thread Chris Wilson 
If the specified object can not fit into the GTT due to overlap with a
neighbouring pinned object (not part of the execobjects[]), we expect to
fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
error in a badly constructed execobjects[]). To prevent the tests
causing overlap with other external objects expand the test hole by a
page on either side.

(Setting up the system to deliberately hit ENOSPC is trickier as for
example it requires pinned an object into the scanout with enough free
space on either side to test.)

Signed-off-by: Chris Wilson 
---
 tests/gem_softpin.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
index 99388599..23f93623 100644
--- a/tests/gem_softpin.c
+++ b/tests/gem_softpin.c
@@ -302,11 +302,11 @@ static void test_evict_snoop(int fd)
 
/* Find a hole */
memset(object, 0, sizeof(object));
-   object[0].handle = gem_create(fd, 3*4096);
+   object[0].handle = gem_create(fd, 5*4096);
gem_write(fd, object[0].handle, 0, , sizeof(bbe));
gem_execbuf(fd, );
gem_close(fd, object[0].handle);
-   hole = object[0].offset;
+   hole = object[0].offset + 4096;
 
/* Create a snoop + uncached pair */
object[0].handle = gem_create(fd, 4096);
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH v3 01/10] pwm: extend PWM framework with PWM modes

2018-02-25 Thread kbuild test robot 
Hi Claudiu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pwm/for-next]
[also build test WARNING on v4.16-rc2 next-20180223]
[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/Claudiu-Beznea/extend-PWM-framework-to-support-PWM-modes/20180225-024011
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git 
for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

>> drivers//pwm/pwm-sun4i.c:36:0: warning: "PWM_MODE" redefined
#define PWM_MODE  BIT(7)

   In file included from drivers//pwm/pwm-sun4i.c:19:0:
   include/linux/pwm.h:40:0: note: this is the location of the previous 
definition
#define PWM_MODE(name)  BIT(PWM_MODE_##name##_BIT)


vim +/PWM_MODE +36 drivers//pwm/pwm-sun4i.c

09853ce7 Alexandre Belloni 2014-12-17  29  
09853ce7 Alexandre Belloni 2014-12-17  30  #define PWMCH_OFFSET 15
09853ce7 Alexandre Belloni 2014-12-17  31  #define PWM_PRESCAL_MASK 
GENMASK(3, 0)
09853ce7 Alexandre Belloni 2014-12-17  32  #define PWM_PRESCAL_OFF  0
09853ce7 Alexandre Belloni 2014-12-17  33  #define PWM_EN   
BIT(4)
09853ce7 Alexandre Belloni 2014-12-17  34  #define PWM_ACT_STATE
BIT(5)
09853ce7 Alexandre Belloni 2014-12-17  35  #define PWM_CLK_GATING   
BIT(6)
09853ce7 Alexandre Belloni 2014-12-17 @36  #define PWM_MODE BIT(7)
09853ce7 Alexandre Belloni 2014-12-17  37  #define PWM_PULSEBIT(8)
09853ce7 Alexandre Belloni 2014-12-17  38  #define PWM_BYPASS   BIT(9)
09853ce7 Alexandre Belloni 2014-12-17  39  

:: The code at line 36 was first introduced by commit
:: 09853ce7bc1003a490c7ee74a5705d7a7cf16b7d pwm: Add Allwinner SoC support

:: TO: Alexandre Belloni <alexandre.bell...@free-electrons.com>
:: CC: Thierry Reding <thierry.red...@gmail.com>

---
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 igt] igt/gem_busy: Fix extended-bsd aliasing checks

2018-02-25 Thread Chris Wilson 
Quoting Chris Wilson (2018-02-24 19:14:00)
> Although we want to specify exactly which physical engine to run on, the
> busy ioctl can only return the I915_EXEC_RING identifier, i.e. the
> aliased I915_EXEC_BSD for vcs0/vcs1. Horrors.

Fixes: 305ebcedc36e ("Iterate over physical engines")
> Signed-off-by: Chris Wilson 
> ---
>  tests/gem_busy.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/gem_busy.c b/tests/gem_busy.c
> index 831bbab1..fcff51a2 100644
> --- a/tests/gem_busy.c
> +++ b/tests/gem_busy.c
> @@ -166,6 +166,7 @@ static void one(int fd, unsigned ring, unsigned 
> test_flags)
> struct drm_i915_gem_relocation_entry store[1024+1];
> struct drm_i915_gem_execbuffer2 execbuf;
> unsigned size = ALIGN(ARRAY_SIZE(store)*16 + 4, 4096);
> +   const unsigned uabi = ring & 63;
> uint32_t read[2], write[2];
> struct timespec tv;
> uint32_t *batch, *bbe;
> @@ -267,11 +268,11 @@ static void one(int fd, unsigned ring, unsigned 
> test_flags)
> timeout = 1;
> }
>  
> -   igt_assert_eq(write[SCRATCH], ring);
> -   igt_assert_eq_u32(read[SCRATCH], 1 << ring);
> +   igt_assert_eq(write[SCRATCH], uabi);
> +   igt_assert_eq_u32(read[SCRATCH], 1 << uabi);
>  
> igt_assert_eq(write[BATCH], 0);
> -   igt_assert_eq_u32(read[BATCH], 1 << ring);
> +   igt_assert_eq_u32(read[BATCH], 1 << uabi);
>  
> /* Calling busy in a loop should be enough to flush the rendering */
> memset(, 0, sizeof(tv));
> -- 
> 2.16.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise "deep" preemption

2018-02-25 Thread Chris Wilson 
In investigating the issue with having to force preemption within the
executing ELSP[], we want to trigger preemption between all elements of
that array. To that end, we issue a series of requests with different
priorities to fill the in-flight ELSP[] and then demand preemption into
the middle of that series. One can think of even more complicated
reordering requirements of ELSP[], trying to switch between every
possible combination of permutations. Rather than check all 2 billion
combinations, be content with a few.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
---
 tests/gem_exec_schedule.c | 172 +-
 1 file changed, 153 insertions(+), 19 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 8a69ab5c..87fe4572 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -373,13 +373,77 @@ static void preempt(int fd, unsigned ring, unsigned flags)
gem_close(fd, result);
 }
 
-static void preempt_other(int fd, unsigned ring)
+#define CHAIN 0x1
+
+static igt_spin_t *__noise(int fd, uint32_t ctx, int prio, igt_spin_t *spin)
+{
+   unsigned other;
+
+   gem_context_set_priority(fd, ctx, prio);
+
+   for_each_physical_engine(fd, other) {
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, ctx, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .rsvd1 = ctx,
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+   }
+
+   return spin;
+}
+
+static void __preempt_other(int fd,
+   uint32_t *ctx,
+   unsigned int target, unsigned int primary,
+   unsigned flags)
 {
uint32_t result = gem_create(fd, 4096);
uint32_t *ptr = gem_mmap__gtt(fd, result, 4096, PROT_READ);
-   igt_spin_t *spin[MAX_ENGINES];
-   unsigned int other;
-   unsigned int n, i;
+   unsigned int n, i, other;
+
+   n = 0;
+   store_dword(fd, ctx[LO], primary,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+   n++;
+
+   if (flags & CHAIN) {
+   for_each_physical_engine(fd, other) {
+   store_dword(fd, ctx[LO], other,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+   n++;
+   }
+   }
+
+   store_dword(fd, ctx[HI], target,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+
+   igt_debugfs_dump(fd, "i915_engine_info");
+   gem_set_domain(fd, result, I915_GEM_DOMAIN_GTT, 0);
+
+   n++;
+   for (i = 0; i <= n; i++)
+   igt_assert_eq_u32(ptr[i], i);
+
+   munmap(ptr, 4096);
+   gem_close(fd, result);
+}
+
+static void preempt_other(int fd, unsigned ring, unsigned int flags)
+{
+   unsigned int primary;
+   igt_spin_t *spin = NULL;
uint32_t ctx[3];
 
/* On each engine, insert
@@ -396,36 +460,87 @@ static void preempt_other(int fd, unsigned ring)
gem_context_set_priority(fd, ctx[LO], MIN_PRIO);
 
ctx[NOISE] = gem_context_create(fd);
+   spin = __noise(fd, ctx[NOISE], 0, NULL);
 
ctx[HI] = gem_context_create(fd);
gem_context_set_priority(fd, ctx[HI], MAX_PRIO);
 
+   for_each_physical_engine(fd, primary) {
+   igt_debug("Primary engine: %s\n", e__->name);
+   __preempt_other(fd, ctx, ring, primary, flags);
+
+   }
+
+   igt_assert(gem_bo_busy(fd, spin->handle));
+   igt_spin_batch_free(fd, spin);
+
+   gem_context_destroy(fd, ctx[LO]);
+   gem_context_destroy(fd, ctx[NOISE]);
+   gem_context_destroy(fd, ctx[HI]);
+}
+
+static void __preempt_queue(int fd,
+   unsigned target, unsigned primary,
+   unsigned depth, unsigned flags)
+{
+   uint32_t result = gem_create(fd, 4096);
+   uint32_t *ptr = gem_mmap__gtt(fd, result, 4096, PROT_READ);
+   igt_spin_t *above = NULL, *below = NULL;
+   unsigned int other, n, i;
+   int prio = MAX_PRIO;
+   uint32_t ctx[3] = {
+   gem_context_create(fd),
+   gem_context_create(fd),
+   gem_context_create(fd),
+   };
+
+   for (n = 0; n < depth; n++)
+   above = __noise(fd,

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for extend PWM framework to support PWM modes

2018-02-25 Thread Claudiu Beznea 
I will check it with latest GCC version and fix it in next version.

Thank you,
Claudiu Beznea

On 22.02.2018 23:00, Patchwork wrote:
> == Series Details ==
> 
> Series: extend PWM framework to support PWM modes
> URL   : https://patchwork.freedesktop.org/series/38809/
> State : failure
> 
> == Summary ==
> 
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   DESCEND  objtool
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   CHK kernel/config_data.h
>   CC [M]  drivers/gpu/drm/i915/intel_panel.o
> In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
> ./include/linux/pwm.h:586:34: error: type qualifiers ignored on function 
> return type [-Werror=ignored-qualifiers]
>  static inline const char * const pwm_mode_desc(unsigned long mode)
>   ^
> cc1: all warnings being treated as errors
> scripts/Makefile.build:316: recipe for target 
> 'drivers/gpu/drm/i915/intel_panel.o' failed
> make[4]: *** [drivers/gpu/drm/i915/intel_panel.o] Error 1
> scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:575: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1048: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx