[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/fbc: disable FBC on FIFO underruns (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: disable FBC on FIFO underruns (rev2)
URL   : https://patchwork.freedesktop.org/series/8575/
State : failure

== Summary ==

Series 8575v2 drm/i915/fbc: disable FBC on FIFO underruns
http://patchwork.freedesktop.org/api/1.0/series/8575/revisions/2/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (ro-hsw-i3-4010u)
Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-snb-i7-2600)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-skl3-i5-6260u)
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (ro-bdw-i7-5600u)
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-kbl-qkkr  total:244  pass:185  dwarn:29  dfail:0   fail:3   skip:27 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:2   dfail:0   fail:1   skip:18 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:193  dwarn:0   dfail:0   fail:5   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:213  dwarn:0   dfail:0   fail:0   skip:27 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1880/

bc5705c drm-intel-nightly: 2016y-08m-15d-15h-16m-01s UTC integration manifest
0e8d83a drm/i915/fbc: disable FBC on FIFO underruns

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

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Goel, Akash]

On 8/15/2016 10:26 PM, Chris Wilson wrote:

On Mon, Aug 15, 2016 at 10:16:56PM +0530, Goel, Akash wrote:



On 8/15/2016 9:36 PM, Chris Wilson wrote:

On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote:

+static void guc_read_update_log_buffer(struct intel_guc *guc)
+{
+   struct guc_log_buffer_state *log_buffer_state, 
*log_buffer_snapshot_state;
+   struct guc_log_buffer_state log_buffer_state_local;
+   void *src_data_ptr, *dst_data_ptr;
+   unsigned int buffer_size, expected_size;
+   enum guc_log_buffer_type type;
+
+   if (WARN_ON(!guc->log.buf_addr))
+   return;
+
+   /* Get the pointer to shared GuC log buffer */
+   log_buffer_state = src_data_ptr = guc->log.buf_addr;
+
+   /* Get the pointer to local buffer to store the logs */
+   dst_data_ptr = log_buffer_snapshot_state = guc_get_write_buffer(guc);
+
+   /* Actual logs are present from the 2nd page */
+   src_data_ptr += PAGE_SIZE;
+   dst_data_ptr += PAGE_SIZE;
+
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   /* Make a copy of the state structure in GuC log buffer (which
+* is uncached mapped) on the stack to avoid reading from it
+* multiple times.
+*/
+   memcpy(_buffer_state_local, log_buffer_state,
+  sizeof(struct guc_log_buffer_state));
+   buffer_size = log_buffer_state_local.size;
+
+   if (log_buffer_snapshot_state) {
+   /* First copy the state structure in snapshot buffer */
+   memcpy(log_buffer_snapshot_state, 
_buffer_state_local,
+  sizeof(struct guc_log_buffer_state));
+
+   /* The write pointer could have been updated by the GuC
+* firmware, after sending the flush interrupt to Host,
+* for consistency set the write pointer value to same
+* value of sampled_write_ptr in the snapshot buffer.
+*/
+   log_buffer_snapshot_state->write_ptr =
+   log_buffer_snapshot_state->sampled_write_ptr;
+
+   log_buffer_snapshot_state++;
+
+   /* Now copy the actual logs, but before that validate
+* the buffer size value retrieved from state structure.
+*/
+   if (type == GUC_ISR_LOG_BUFFER)
+   expected_size = (GUC_LOG_ISR_PAGES+1)*PAGE_SIZE;
+   else if (type == GUC_DPC_LOG_BUFFER)
+   expected_size = (GUC_LOG_DPC_PAGES+1)*PAGE_SIZE;
+   else
+   expected_size = 
(GUC_LOG_CRASH_PAGES+1)*PAGE_SIZE;
+
+   if (unlikely(buffer_size != expected_size)) {
+   DRM_ERROR("unexpected log buffer size\n");
+   /* Continue with further copying, already state
+* structure has been copied which is enough to
+* let Userspace know about the anomaly.
+*/
+   buffer_size = expected_size;


Urm, no.

You tell userspace one thing and then do another. This code should just
be a conduit and not apply its own outdated interpretation.


Userspace parser would get to know from the state structure about
the anomalous buffer size.


It will, but it won't be told what the kernel did. So if believes the
GuC (as it should since it is a packet that should be unadulterated) the
entire stream is then corrupt.


Please suggest that what should be done here ideally.

Should the further copying (for this snapshot) be skipped ?


The kernel should be avoiding interpretting the log packets as much as
possible - I would prefer it if we just moved the byte stream without
trying to interpret it as datagrams. But there is probably some merit to
at least using the log packets (datagrams).

It would have been ideal if log packets can be dumped without any 
interpretation.


We copy the payload without any interpretation, only some bits of header 
we parse.


We also have to interpret the header (in subsequent patch) to copy only 
the updated payload data, for better performance.



+   }
+
+   memcpy(dst_data_ptr, src_data_ptr, buffer_size);


Where do you validate that buffer_size is sane before copying?

Sorry didn't get you, the check for buffer_size is being done right
before this memcpy.


There is no explicit check for valid src_data_ptr + buffer_size or
dst_data_ptr + buffer_size, and a quick glance at the code suggested no
reason to believe they must be valid.
Actually if buffer_size has been validated & corrected, then both 
src_data_ptr + buffer_size and 

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Silence GCC warning for cmn_a_well

[Patchwork]

== Series Details ==

Series: drm/i915: Silence GCC warning for cmn_a_well
URL   : https://patchwork.freedesktop.org/series/11121/
State : warning

== Summary ==

Series 11121v1 drm/i915: Silence GCC warning for cmn_a_well
http://patchwork.freedesktop.org/api/1.0/series/11121/revisions/1/mbox

Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-snb-i7-2600)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (ro-bdw-i7-5600u)
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-kbl-qkkr  total:244  pass:185  dwarn:30  dfail:0   fail:2   skip:27 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:2   dfail:0   fail:1   skip:18 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1879/

bc5705c drm-intel-nightly: 2016y-08m-15d-15h-16m-01s UTC integration manifest
31d0925 drm/i915: Silence GCC warning for cmn_a_well

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

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

[Goel, Akash]

On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote:


On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

Before capturing the GuC logs as a part of error state, there should be a
force log buffer flush action sent to GuC before proceeding with GPU
reset
and re-initializing GUC. There could be some data in the log buffer which
is yet to be captured and those logs would be particularly useful to
understand that why the GPU reset was initiated.

v2:
- Avoid the wait via flush_work, to serialize against an ongoing log
   buffer flush, from the error state capture path. (Chris)


Could you explain if the patch does anything now that the flush has been
removed?


flush_work for the regular log buffer flush work item has been removed
but the forceful command is still sent to GuC.


In fact I don't even understand what it was doing before. :)


I am sorry for that.


If the idea is to send a flush command to GuC so it can raise an
interrupt for a partially full buffer,

Yes exactly this is the idea.


then i915_guc_flush_logs should
send the flush command and wait for that interrupt/work.

But the function is first waiting for the work item to complete and then
sending the flush command to the GuC. So I am confused.

Actually GuC firmware just ignores the forceful flush command received 
from Host, if it sees there is a pending request for regular log buffer

flush, for which it hasn't received the ack.

So that's why from Host side, before sending the forceful flush command 
to GuC, had to first wait for the regular log buffer flush work item to

finish execution.

Best regards
Akash


Regards,

Tvrtko


- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_gpu_error.c  |  2 ++
  drivers/gpu/drm/i915/i915_guc_submission.c | 30
++
  drivers/gpu/drm/i915/intel_guc.h   |  1 +
  3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 94297aa..b73c671 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1301,6 +1301,8 @@ static void
i915_gem_capture_guc_log_buffer(struct drm_i915_private *dev_priv,
  if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
  return;

+i915_guc_flush_logs(dev_priv, false);
+
  error->guc_log = i915_error_object_create(dev_priv,
dev_priv->guc.log.vma);
  }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b8d6313..85df2f3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,6 +185,16 @@ static int
host2guc_logbuffer_flush_complete(struct intel_guc *guc)
  return host2guc_action(guc, data, 1);
  }

+static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
+{
+u32 data[2];
+
+data[0] = HOST2GUC_ACTION_FORCE_LOG_BUFFER_FLUSH;
+data[1] = 0;
+
+return host2guc_action(guc, data, 2);
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -1536,6 +1546,26 @@ void i915_guc_capture_logs(struct
drm_i915_private *dev_priv)
  intel_runtime_pm_put(dev_priv);
  }

+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool
can_wait)
+{
+if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
+return;
+
+/* First disable the interrupts, will be renabled afterwards */
+gen9_disable_guc_interrupts(dev_priv);
+
+/* Before initiating the forceful flush, wait for any
pending/ongoing
+ * flush to complete otherwise forceful flush may not happen, but
wait
+ * can't be done for some paths like error state capture in which
case
+ * take a chance & directly attempt the forceful flush.
+ */
+if (can_wait)
+flush_work(_priv->guc.log.flush_work);
+
+/* Ask GuC to update the log buffer state */
+host2guc_force_logbuffer_flush(_priv->guc);
+}
+
  void i915_guc_unregister(struct drm_i915_private *dev_priv)
  {
  if (!i915.enable_guc_submission)
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 8598f38..d7eda42 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -182,6 +182,7 @@ int i915_guc_wq_check_space(struct
drm_i915_gem_request *rq);
  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
  void i915_guc_capture_logs(struct drm_i915_private *dev_priv);
+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool
can_wait);
  void i915_guc_register(struct drm_i915_private *dev_priv);
  void i915_guc_unregister(struct drm_i915_private *dev_priv);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 1/2] drm/i915: make i915 the source of acpi device ids for _DOD

[Marcos Paulo de Souza]

From: Jani Nikula 

The graphics driver is supposed to define the DIDL, which are used for
_DOD, not the BIOS. Restore that behaviour.

This is basically a revert of

commit 3143751ff51a163b77f7efd389043e038f3e008e
Author: Zhang Rui 
Date:   Mon Mar 29 15:12:16 2010 +0800

drm/i915: set DIDL using the ACPI video output device _ADR method return.

which went out of its way to cater to a specific BIOS, setting up DIDL
based on _ADR method. Perhaps that approach worked on that specific
machine, but on the machines I checked the _ADR method invents the
device identifiers out of thin air if DIDL has not been set. The source
for _ADR is also supposed to be the DIDL set by the driver, not the
other way around.

With this, we'll also limit the number of outputs to what the driver
actually has.

v2: do not set ACPI_DEVICE_ID_SCHEME in the device id (Peter Wu)

Reviewed-and-tested-by: Peter Wu 
Tested-by: Marcos Paulo de Souza 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_opregion.c | 89 ++-
 2 files changed, 28 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cc937a1..8656b4c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,9 @@ struct intel_connector {
 */
struct intel_encoder *encoder;
 
+   /* ACPI device id for ACPI and driver cooperation */
+   u32 acpi_device_id;
+
/* Reads out the current hw, returning true if the connector is enabled
 * and active (i.e. dpms ON state). */
bool (*get_hw_state)(struct intel_connector *);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index adca262..494559a 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -674,11 +674,11 @@ static void set_did(struct intel_opregion *opregion, int 
i, u32 val)
}
 }
 
-static u32 acpi_display_type(struct drm_connector *connector)
+static u32 acpi_display_type(struct intel_connector *connector)
 {
u32 display_type;
 
-   switch (connector->connector_type) {
+   switch (connector->base.connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
display_type = ACPI_DISPLAY_TYPE_VGA;
@@ -707,7 +707,7 @@ static u32 acpi_display_type(struct drm_connector 
*connector)
display_type = ACPI_DISPLAY_TYPE_OTHER;
break;
default:
-   MISSING_CASE(connector->connector_type);
+   MISSING_CASE(connector->base.connector_type);
display_type = ACPI_DISPLAY_TYPE_OTHER;
break;
}
@@ -718,34 +718,10 @@ static u32 acpi_display_type(struct drm_connector 
*connector)
 static void intel_didl_outputs(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
-   struct pci_dev *pdev = dev_priv->drm.pdev;
-   struct drm_connector *connector;
-   acpi_handle handle;
-   struct acpi_device *acpi_dev, *acpi_cdev, *acpi_video_bus = NULL;
-   unsigned long long device_id;
-   acpi_status status;
-   u32 temp, max_outputs;
-   int i = 0;
-
-   handle = ACPI_HANDLE(>dev);
-   if (!handle || acpi_bus_get_device(handle, _dev))
-   return;
-
-   if (acpi_is_video_device(handle))
-   acpi_video_bus = acpi_dev;
-   else {
-   list_for_each_entry(acpi_cdev, _dev->children, node) {
-   if (acpi_is_video_device(acpi_cdev->handle)) {
-   acpi_video_bus = acpi_cdev;
-   break;
-   }
-   }
-   }
-
-   if (!acpi_video_bus) {
-   DRM_DEBUG_KMS("No ACPI video bus found\n");
-   return;
-   }
+   struct intel_connector *connector;
+   struct drm_device *dev = _priv->drm;
+   int i = 0, max_outputs;
+   int display_index[16] = {};
 
/*
 * In theory, did2, the extended didl, gets added at opregion version
@@ -757,46 +733,31 @@ static void intel_didl_outputs(struct drm_i915_private 
*dev_priv)
max_outputs = ARRAY_SIZE(opregion->acpi->didl) +
ARRAY_SIZE(opregion->acpi->did2);
 
-   list_for_each_entry(acpi_cdev, _video_bus->children, node) {
-   if (i >= max_outputs) {
-   DRM_DEBUG_KMS("More than %u outputs detected via 
ACPI\n",
- max_outputs);
-   return;
-   }
-   status = acpi_evaluate_integer(acpi_cdev->handle, "_ADR",
-  NULL, _id);
-   if (ACPI_SUCCESS(status)) {
-  

[Intel-gfx] [PATCH 2/2] drm/i915/opregion: update cadl based on actually active outputs

[Marcos Paulo de Souza]

From: Jani Nikula 

Previously we've just shoved the first eight devices in DIDL to CADL
(list of active outputs). Some of the active outputs may have been left
outside of CADL. The problem is, some BIOS implementations prevent
laptop brightness hotkey propagation if the flat panel is not active.

Now that we have connector to acpi device id mapping covered, we can
update CADL based on which outputs are actually active.

v3: actually git add the dev->dev_priv change.

v4: update cadl in intel_shared_dpll_commit() if intel_state->modeset
(Maarten)

Cc: Maarten Lankhorst 
Reviewed-and-tested-by: Peter Wu 
Tested-by: Marcos Paulo de Souza 
Signed-off-by: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 +
 drivers/gpu/drm/i915/intel_display.c  |  4 ++
 drivers/gpu/drm/i915/intel_opregion.c | 71 +++
 3 files changed, 44 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 21f9390..062e5c3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3741,6 +3741,7 @@ extern int intel_opregion_notify_encoder(struct 
intel_encoder *intel_encoder,
 extern int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
 pci_power_t state);
 extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
+extern void intel_opregion_update_cadl(struct drm_i915_private *dev_priv);
 #else
 static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 
0; }
 static inline void intel_opregion_register(struct drm_i915_private *dev_priv) 
{ }
@@ -3762,6 +3763,7 @@ static inline int intel_opregion_get_panel_type(struct 
drm_i915_private *dev)
 {
return -ENODEV;
 }
+static inline void intel_opregion_update_cadl(struct drm_i915_private 
*dev_priv) { }
 #endif
 
 /* intel_acpi.c */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dcf93b3..4062a2f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13856,6 +13856,10 @@ static int intel_atomic_commit(struct drm_device *dev,
dev_priv->wm.distrust_bios_wm = false;
dev_priv->wm.skl_results = intel_state->wm_results;
intel_shared_dpll_commit(state);
+
+   if (intel_state->modeset)
+   intel_opregion_update_cadl(dev_priv);
+
intel_atomic_track_fbs(state);
 
if (nonblock)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 494559a..7968587 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -642,24 +642,6 @@ static struct notifier_block intel_opregion_notifier = {
  * (version 3)
  */
 
-static u32 get_did(struct intel_opregion *opregion, int i)
-{
-   u32 did;
-
-   if (i < ARRAY_SIZE(opregion->acpi->didl)) {
-   did = opregion->acpi->didl[i];
-   } else {
-   i -= ARRAY_SIZE(opregion->acpi->didl);
-
-   if (WARN_ON(i >= ARRAY_SIZE(opregion->acpi->did2)))
-   return 0;
-
-   did = opregion->acpi->did2[i];
-   }
-
-   return did;
-}
-
 static void set_did(struct intel_opregion *opregion, int i, u32 val)
 {
if (i < ARRAY_SIZE(opregion->acpi->didl)) {
@@ -674,6 +656,14 @@ static void set_did(struct intel_opregion *opregion, int 
i, u32 val)
}
 }
 
+static void set_cad(struct intel_opregion *opregion, int i, u32 val)
+{
+   if (WARN_ON(i >= ARRAY_SIZE(opregion->acpi->cadl)))
+   return;
+
+   opregion->acpi->cadl[i] = val;
+}
+
 static u32 acpi_display_type(struct intel_connector *connector)
 {
u32 display_type;
@@ -760,22 +750,37 @@ static void intel_didl_outputs(struct drm_i915_private 
*dev_priv)
set_did(opregion, i, 0);
 }
 
-static void intel_setup_cadls(struct drm_i915_private *dev_priv)
+/* Update CADL to reflect active outputs. */
+void intel_opregion_update_cadl(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
-   int i = 0;
-   u32 disp_id;
-
-   /* Initialize the CADL field by duplicating the DIDL values.
-* Technically, this is not always correct as display outputs may exist,
-* but not active. This initialization is necessary for some Clevo
-* laptops that check this field before processing the brightness and
-* display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
-* there are less than eight devices. */
-   do {
-   disp_id = get_did(opregion, i);
-   opregion->acpi->cadl[i] = disp_id;
-   } while (++i < 8 && disp_id != 0);
+   struct 

[Intel-gfx] [PATCH 0/2] Adapt patches from Jani to solve brightness hot key problem

[Marcos Paulo de Souza]

Hi guys,

these are the same patches that Jani sent some time ago[1], but adapted to 
current 4.8-rc1. These fixed
the problem I had with my Asus laptop[2], and now the brightness hotkeys are 
working in my machine.

The only adaptation needed was change dev_priv->dev to dev_priv->drm on 
for_each_* macros. Along with
this fix, I also added myself as tester.

Please let me know if it needs more adjustments before merging.

Thanks,

[1] https://patchwork.freedesktop.org/series/4783/
[2] https://bugzilla.kernel.org/show_bug.cgi?id=152091

Jani Nikula (2):
  drm/i915: make i915 the source of acpi device ids for _DOD
  drm/i915/opregion: update cadl based on actually active outputs

 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/intel_display.c  |   4 +
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_opregion.c | 158 +-
 4 files changed, 71 insertions(+), 96 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Move audio_connector to intel_encoder

[Dhinakaran Pandiyan]

With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_connector from struct intel_digital_port to struct intel_encoder.
This also simplifies access to the right audio_connector from codec
functions in intel_audio.c that receive intel_encoder.

Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/i915/intel_audio.c | 10 --
 drivers/gpu/drm/i915/intel_drv.h   |  4 ++--
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index d32f586..ef20875 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -523,7 +523,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
 adjusted_mode);
 
mutex_lock(_priv->av_mutex);
-   intel_dig_port->audio_connector = connector;
+   intel_encoder->audio_connector = connector;
/* referred in audio callbacks */
dev_priv->dig_port_map[port] = intel_encoder;
mutex_unlock(_priv->av_mutex);
@@ -552,7 +552,7 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
dev_priv->display.audio_codec_disable(intel_encoder);
 
mutex_lock(_priv->av_mutex);
-   intel_dig_port->audio_connector = NULL;
+   intel_encoder->audio_connector = NULL;
dev_priv->dig_port_map[port] = NULL;
mutex_unlock(_priv->av_mutex);
 
@@ -713,7 +713,6 @@ static int i915_audio_component_get_eld(struct device *dev, 
int port,
 {
struct drm_i915_private *dev_priv = dev_to_i915(dev);
struct intel_encoder *intel_encoder;
-   struct intel_digital_port *intel_dig_port;
const u8 *eld;
int ret = -EINVAL;
 
@@ -722,10 +721,9 @@ static int i915_audio_component_get_eld(struct device 
*dev, int port,
/* intel_encoder might be NULL for DP MST */
if (intel_encoder) {
ret = 0;
-   intel_dig_port = enc_to_dig_port(_encoder->base);
-   *enabled = intel_dig_port->audio_connector != NULL;
+   *enabled = intel_encoder->audio_connector != NULL;
if (*enabled) {
-   eld = intel_dig_port->audio_connector->eld;
+   eld = intel_encoder->audio_connector->eld;
ret = drm_eld_size(eld);
memcpy(buf, eld, min(max_bytes, ret));
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 19aab7b..c20fb49 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -220,6 +220,8 @@ struct intel_encoder {
void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
+   /* for communication with audio component; protected by av_mutex */
+   const struct drm_connector *audio_connector;
 };
 
 struct intel_panel {
@@ -930,8 +932,6 @@ struct intel_digital_port {
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
-   /* for communication with audio component; protected by av_mutex */
-   const struct drm_connector *audio_connector;
 };
 
 struct intel_dp_mst_encoder {
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 3/3] drm/i915: start adding dp mst audio

[Dhinakaran Pandiyan]

From: Libin Yang 

(This patch is developed by Dave Airlie  originally)

This patch adds support for DP MST audio in i915.

Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.

Another separated patches to support DP MST audio will be implemented
in audio driver.

Signed-off-by: Libin Yang 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
 drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c | 21 +
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 4 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9bd4158..31c5e38 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2973,6 +2973,20 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, _connector->panel);
 }
 
+static void intel_dp_mst_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+   struct intel_encoder *intel_encoder = intel_connector->encoder;
+   struct intel_dp_mst_encoder *intel_mst =
+   enc_to_mst(_encoder->base);
+   struct intel_digital_port *intel_dig_port = intel_mst->primary;
+   struct intel_dp *intel_dp = _dig_port->dp;
+   bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
+   intel_connector->port);
+
+   seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
+}
+
 static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
 {
@@ -3015,7 +3029,10 @@ static void intel_connector_info(struct seq_file *m,
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DisplayPort:
case DRM_MODE_CONNECTOR_eDP:
-   intel_dp_info(m, intel_connector);
+   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
+   intel_dp_mst_info(m, intel_connector);
+   else
+   intel_dp_info(m, intel_connector);
break;
case DRM_MODE_CONNECTOR_LVDS:
if (intel_encoder->type == INTEL_OUTPUT_LVDS)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 13ceef4..0ce42cb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2155,6 +2155,19 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
 }
 
+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc)
+{
+   u32 temp;
+
+   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
+   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
+   return true;
+   }
+   return false;
+}
+
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config)
 {
@@ -2220,11 +2233,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
 
-   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
-   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
-   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
-   pipe_config->has_audio = true;
-   }
+   pipe_config->has_audio =
+   intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
 
if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 629337d..c8b036b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -76,6 +76,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
return false;
}
 
+   if (drm_dp_mst_port_has_audio(_dp->mst_mgr, found->port))
+   pipe_config->has_audio = true;
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
 
pipe_config->pbn = mst_pbn;
@@ -97,6 +99,10 @@ static void intel_mst_disable_dp(struct intel_encoder 
*encoder)
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(>base);
struct intel_digital_port *intel_dig_port = intel_mst->primary;
struct intel_dp *intel_dp = _dig_port->dp;
+   struct drm_device *dev = encoder->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = encoder->base.crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int ret;
 

[Intel-gfx] [PATCH v2 0/3] Prep. for DP audio MST support

[Dhinakaran Pandiyan]

This series lays the groundwork for more DP MST audio work that will
follow. 

(c) got possibly reverted because enc_to_dig_port() was incorrectly used
on MST encoders. Let's bring it back with the fix introduced in (a).

v2:
(a) -different solution replacing the enc_to_dig_port() fix (Ville, Lyude)
(b) and (c) -no changes since Lyude reviewed them.
Reordered the patches (Lyude) 


Dhinakaran Pandiyan (2):
  (a) drm/i915: Add function to return port from an encoder
  (b) drm/i915: Move audio_connector to intel_encoder

Libin Yang (1):
  (c) drm/i915: start adding dp mst audio

 drivers/gpu/drm/i915/i915_debugfs.c   | 19 ++-
 drivers/gpu/drm/i915/intel_audio.c| 10 +++---
 drivers/gpu/drm/i915/intel_ddi.c  | 62 +++
 drivers/gpu/drm/i915/intel_display.c  | 18 ++
 drivers/gpu/drm/i915/intel_dp_mst.c   | 21 
 drivers/gpu/drm/i915/intel_drv.h  | 14 ++--
 drivers/gpu/drm/i915/intel_opregion.c |  2 +-
 7 files changed, 100 insertions(+), 46 deletions(-)

-- 
2.5.0

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

[Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

[Dhinakaran Pandiyan]

There are places in the driver where we just need the 'port' associated
with an encoder and not 'struct intel_digital_port' that contains it.
This basically is a generic implementation of intel_ddi_get_encoder_port()
handling both DDI and Non-DDI encoders. The handling of the analog encoder
is delegated to the DDI specific function.

The idea to have a generic implementation that returned the 'enum port'
from 'struct intel_encoder' came from Ville.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 42 ++-
 drivers/gpu/drm/i915/intel_display.c  | 18 +++
 drivers/gpu/drm/i915/intel_drv.h  |  8 ++-
 drivers/gpu/drm/i915/intel_opregion.c |  2 +-
 4 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c2df4e4..13ceef4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -301,24 +301,6 @@ static const struct bxt_ddi_buf_trans 
bxt_ddi_translations_hdmi[] = {
{ 154, 0x9A, 1, 128, true },/* 9:   12000   */
 };
 
-enum port intel_ddi_get_encoder_port(struct intel_encoder *encoder)
-{
-   switch (encoder->type) {
-   case INTEL_OUTPUT_DP_MST:
-   return enc_to_mst(>base)->primary->port;
-   case INTEL_OUTPUT_DP:
-   case INTEL_OUTPUT_EDP:
-   case INTEL_OUTPUT_HDMI:
-   case INTEL_OUTPUT_UNKNOWN:
-   return enc_to_dig_port(>base)->port;
-   case INTEL_OUTPUT_ANALOG:
-   return PORT_E;
-   default:
-   MISSING_CASE(encoder->type);
-   return PORT_A;
-   }
-}
-
 static const struct ddi_buf_trans *
 bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
 {
@@ -421,7 +403,7 @@ void intel_prepare_dp_ddi_buffers(struct intel_encoder 
*encoder)
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 iboost_bit = 0;
int i, n_dp_entries, n_edp_entries, size;
-   enum port port = intel_ddi_get_encoder_port(encoder);
+   enum port port = intel_get_encoder_port(encoder);
const struct ddi_buf_trans *ddi_translations_fdi;
const struct ddi_buf_trans *ddi_translations_dp;
const struct ddi_buf_trans *ddi_translations_edp;
@@ -499,7 +481,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct 
intel_encoder *encoder)
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 iboost_bit = 0;
int n_hdmi_entries, hdmi_level;
-   enum port port = intel_ddi_get_encoder_port(encoder);
+   enum port port = intel_get_encoder_port(encoder);
const struct ddi_buf_trans *ddi_translations_hdmi;
 
if (IS_BROXTON(dev_priv))
@@ -987,7 +969,7 @@ static void bxt_ddi_clock_get(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   enum port port = intel_ddi_get_encoder_port(encoder);
+   enum port port = intel_get_encoder_port(encoder);
uint32_t dpll = port;
 
pipe_config->port_clock = bxt_calc_pll_link(dev_priv, dpll);
@@ -1130,7 +1112,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
enum pipe pipe = intel_crtc->pipe;
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
-   enum port port = intel_ddi_get_encoder_port(intel_encoder);
+   enum port port = intel_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1226,7 +1208,7 @@ bool intel_ddi_connector_get_hw_state(struct 
intel_connector *intel_connector)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_encoder *intel_encoder = intel_connector->encoder;
int type = intel_connector->base.connector_type;
-   enum port port = intel_ddi_get_encoder_port(intel_encoder);
+   enum port port = intel_get_encoder_port(intel_encoder);
enum pipe pipe = 0;
enum transcoder cpu_transcoder;
enum intel_display_power_domain power_domain;
@@ -1286,7 +1268,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
 {
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   enum port port = intel_ddi_get_encoder_port(encoder);
+   enum port port = intel_get_encoder_port(encoder);
enum intel_display_power_domain power_domain;
u32 tmp;
int i;
@@ -1361,7 +1343,7 @@ void intel_ddi_enable_pipe_clock(struct intel_crtc 
*intel_crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum port port = 

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

[Zanoni, Paulo R]

Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu:
> On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote:
> > 
> > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
> > during atomic commits. This will continue to guarantee that we
> > deactivate FBC and it will also update the state checking
> > structures
> > at the correct time. Then, later, at the point where we were
> > calling
> > intel_fbc_update, we'll only need to call intel_fbc_post_update.
> > 
> > Also add the proper warnings in case we don't have the appropriate
> > locks. Daniel mentioned the warnings will have to be removed for
> > async
> > commits, but let's keep them here while we can.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 11 +--
> >  drivers/gpu/drm/i915/intel_drv.h |  8 +---
> >  drivers/gpu/drm/i915/intel_fbc.c | 33 ++
> > ---
> >  3 files changed, 28 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index baab41046..baa4cc9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> > 
> > @@ -11733,7 +11733,7 @@ static int intel_crtc_page_flip(struct
> > drm_crtc *crtc,
> >       to_intel_plane(primary)-
> > >frontbuffer_bit);
> >     mutex_unlock(>struct_mutex);
> >  
> > -   intel_fbc_deactivate(intel_crtc);
> > +   intel_fbc_pre_update(intel_crtc);
> >     intel_frontbuffer_flip_prepare(dev,
> >        to_intel_plane(primary)-
> > >frontbuffer_bit);
> >  
> > +void intel_fbc_pre_update(struct intel_crtc *crtc)
> >  {
> >     struct drm_i915_private *dev_priv = crtc->base.dev-
> > >dev_private;
> >     struct intel_fbc *fbc = _priv->fbc;
> >  
> > -   WARN_ON(!mutex_is_locked(>lock));
> > +   if (!fbc_supported(dev_priv))
> > +   return;
> > +
> > +   mutex_lock(>lock);
> >  
> >     if (!multiple_pipes_ok(dev_priv)) {
> >     set_no_fbc_reason(dev_priv, "more than one pipe
> > active");
> > @@ -907,15 +915,17 @@ static void intel_fbc_pre_update(struct
> > intel_crtc *crtc)
> >     }
> >  
> >     if (!fbc->enabled || fbc->crtc != crtc)
> > -   return;
> > +   goto unlock;
> >  
> >     intel_fbc_update_state_cache(crtc);
> >  
> >  deactivate:
> >     __intel_fbc_deactivate(dev_priv);
> > +unlock:
> > +   mutex_unlock(>lock);
> >  }
> 
> 
> So this change is broken as intel_fbc_pre_update() depends upon state
> derived from the pinned framebuffer object but is being called by
> intel_crtc_page_flip() before that object is pinned with
> intel_pin_and_fence_fb - i.e. state such as the gtt_offset or the
> fence
> for the object are incorrect, and even trying to look at them can
> cause
> an oops.

Nope:
$ git show
1eb52238a5f5b6a3f497b47e6da39ccfebe6b878:drivers/gpu/drm/i915/intel_dis
play.c

Back when the commit was merged, the pre_update() call was done after
pin_and_fence_fb(). It looks like some later commit introduced the
problem you point.

Still, looks like we have code to fix.

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

[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Paulo Zanoni]

Ever since I started working on FBC I was already aware that FBC can
really amplify the FIFO underrun symptoms. On systems where FIFO
underruns were harmless error messages, enabling FBC would cause the
underruns to give black screens.

We recently tried to enable FBC on Haswell and got reports of a system
that would hang after some hours of uptime, and the first bad commit
was the one that enabled FBC. We also observed that this system had
FIFO underrun error messages on its dmesg. Although we don't have any
evidence that fixing the underruns would solve the bug and make FBC
work properly on this machine, IMHO it's better if we minimize the
amount of possible problems by just giving up FBC whenever we detect
an underrun.

v2: New version, different implementation and commit message.
v3: Clarify the fact that we run from an IRQ handler (Chris).

Cc: Stefan Richter 
Cc: Lyude 
Cc: stevenhoney...@gmail.com 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_fbc.c   | 61 ++
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35caa9b..baa9c66 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -941,6 +941,9 @@ struct intel_fbc {
bool enabled;
bool active;
 
+   bool underrun_detected;
+   struct work_struct underrun_work;
+
struct intel_fbc_state_cache {
struct {
unsigned int mode_flags;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c700b0..50c1eb0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1494,6 +1494,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
 void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
port);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e122052..950aed5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -750,6 +750,13 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = _priv->fbc;
struct intel_fbc_state_cache *cache = >state_cache;
 
+   /* We don't need to use a state cache here since this information is
+* global for every CRTC. */
+   if (fbc->underrun_detected) {
+   fbc->no_fbc_reason = "underrun detected";
+   return false;
+   }
+
if (!cache->plane.visible) {
fbc->no_fbc_reason = "primary plane not visible";
return false;
@@ -1193,6 +1200,59 @@ void intel_fbc_global_disable(struct drm_i915_private 
*dev_priv)
cancel_work_sync(>work.work);
 }
 
+static void intel_fbc_underrun_work_fn(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, fbc.underrun_work);
+   struct intel_fbc *fbc = _priv->fbc;
+
+   mutex_lock(>lock);
+
+   /* Maybe we were scheduled twice. */
+   if (fbc->underrun_detected)
+   goto out;
+
+   DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
+   fbc->underrun_detected = true;
+
+   intel_fbc_deactivate(dev_priv);
+out:
+   mutex_unlock(>lock);
+}
+
+/**
+ * intel_fbc_handle_fifo_underrun_irq - disable FBC when we get a FIFO underrun
+ * @dev_priv: i915 device instance
+ *
+ * Without FBC, most underruns are harmless and don't really cause too many
+ * problems, except for an annoying message on dmesg. With FBC, underruns can
+ * become black screens or even worse, especially when paired with bad
+ * watermarks. So in order for us to be on the safe side, completely disable 
FBC
+ * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
+ * already suggests that watermarks may be bad, so try to be as safe as
+ * possible.
+ *
+ * This function is called from the IRQ handler.
+ */
+void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
+{
+   struct intel_fbc *fbc = _priv->fbc;
+
+   if (!fbc_supported(dev_priv))
+   return;
+
+   /* There's no guarantee that underrun_detected won't be set to true
+* right after this check and before the work is scheduled, but that's
+* not a problem since we'll check it again under the work function
+* while FBC is 

Re: [Intel-gfx] [PATCH v3 21/21] drm/i915: Move HAS_GUC definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:27AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform definition allows for
>   - standard place when adding new features from new platform
>   - possible to see supported features when dumping struct
>   definitions
> 


Reviewed-by: Rodrigo Vivi 

> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8e0e0fa..497854e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -782,6 +782,7 @@ struct intel_csr {
>   func(has_logical_ring_contexts) sep \
>   func(has_l3_dpf) sep \
>   func(has_gmch_display) sep \
> + func(has_guc) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2790,7 +2791,7 @@ struct drm_i915_cmd_table {
>   * command submission once loaded. But these are logically independent
>   * properties, so we have separate macros to test them.
>   */
> -#define HAS_GUC(dev) (IS_GEN9(dev))
> +#define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc)
>  #define HAS_GUC_UCODE(dev)   (HAS_GUC(dev))
>  #define HAS_GUC_SCHED(dev)   (HAS_GUC(dev))
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index c5f4078..02a7619 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -331,6 +331,7 @@ static const struct intel_device_info intel_skylake_info 
> = {
>   .is_skylake = 1,
>   .gen = 9,
>   .has_csr = 1,
> + .has_guc = 1,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
> @@ -338,6 +339,7 @@ static const struct intel_device_info 
> intel_skylake_gt3_info = {
>   .is_skylake = 1,
>   .gen = 9,
>   .has_csr = 1,
> + .has_guc = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> @@ -359,6 +361,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_gmbus_irq = 1,
>   .has_hw_contexts = 1,
>   .has_logical_ring_contexts = 1,
> + .has_guc = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> @@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info 
> = {
>   .is_kabylake = 1,
>   .gen = 9,
>   .has_csr = 1,
> + .has_guc = 1,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> @@ -376,6 +380,7 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info = {
>   .is_kabylake = 1,
>   .gen = 9,
>   .has_csr = 1,
> + .has_guc = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 20/21] drm/i915: Make HWS_NEEDS_PHYSICAL the exception

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:26AM -0700, Carlos Santa wrote:
> Make the .hws_needs_physical the exception by switching the flag
> on earlier platforms since they are fewer to support. Remove the flag on
> later GPUs hardware since they all use GTT hws by default.
> 
> Switch the logic as well in the driver to reflect this change.
> 
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++--
>  drivers/gpu/drm/i915/i915_gpu_error.c   |  2 +-
>  drivers/gpu/drm/i915/i915_pci.c | 27 +--
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--
>  4 files changed, 30 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 233feb9..8e0e0fa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -755,7 +755,7 @@ struct intel_csr {
>   func(is_i915g) sep \
>   func(is_i945gm) sep \
>   func(is_g33) sep \
> - func(need_gfx_hws) sep \
> + func(hws_needs_physical) sep \
>   func(is_g4x) sep \
>   func(is_pineview) sep \
>   func(is_broadwater) sep \
> @@ -2731,7 +2731,7 @@ struct drm_i915_cmd_table {
>  #define HAS_EDRAM(dev)   (!!(__I915__(dev)->edram_cap & 
> EDRAM_ENABLED))
>  #define HAS_WT(dev)  ((IS_HASWELL(dev) || IS_BROADWELL(dev)) && \
>HAS_EDRAM(dev))
> -#define I915_NEED_GFX_HWS(dev)   (INTEL_INFO(dev)->need_gfx_hws)
> +#define HWS_NEEDS_PHYSICAL(dev)  (INTEL_INFO(dev)->hws_needs_physical)

At first sight I was going to complain about the name, since need_hws_physical 
sounded the correct,
but indeed it seems that for this HWS (what ever that is) we need this physical 
status page because
we don't have the HSW specific registers on those platforms.
So now I believe the name you chose is indeed better.

When applying this patch I got one conflict... wiggle could solve and it seems 
correct but maybe a
rebased version is better.

Anyways:


Reviewed-by: Rodrigo Vivi 



>  
>  #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->has_hw_contexts)
>  #define HAS_LOGICAL_RING_CONTEXTS(dev)   
> (INTEL_INFO(dev)->has_logical_ring_contexts)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index eecb870..ba68327 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1008,7 +1008,7 @@ static void error_record_engine_registers(struct 
> drm_i915_error_state *error,
>   ee->tail = I915_READ_TAIL(engine);
>   ee->ctl = I915_READ_CTL(engine);
>  
> - if (I915_NEED_GFX_HWS(dev_priv)) {
> + if (!HWS_NEEDS_PHYSICAL(dev_priv)) {
>   i915_reg_t mmio;
>  
>   if (IS_GEN7(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 1c2f5fa..c5f4078 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -58,6 +58,7 @@
>   .gen = 2, \
>   .has_overlay = 1, .overlay_needs_physical = 1, \
>   .has_gmch_display = 1, \
> + .hws_needs_physical = 1, \
>   .ring_mask = RENDER_RING, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -95,6 +96,7 @@ static const struct intel_device_info intel_i915g_info = {
>   GEN3_FEATURES,
>   .is_i915g = 1, .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
> + .hws_needs_physical = 1,
>  };
>  static const struct intel_device_info intel_i915gm_info = {
>   GEN3_FEATURES,
> @@ -103,11 +105,13 @@ static const struct intel_device_info intel_i915gm_info 
> = {
>   .has_overlay = 1, .overlay_needs_physical = 1,
>   .supports_tv = 1,
>   .has_fbc = 1,
> + .hws_needs_physical = 1,
>  };
>  static const struct intel_device_info intel_i945g_info = {
>   GEN3_FEATURES,
>   .has_hotplug = 1, .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
> + .hws_needs_physical = 1,
>  };
>  static const struct intel_device_info intel_i945gm_info = {
>   GEN3_FEATURES,
> @@ -116,6 +120,7 @@ static const struct intel_device_info intel_i945gm_info = 
> {
>   .has_overlay = 1, .overlay_needs_physical = 1,
>   .supports_tv = 1,
>   .has_fbc = 1,
> + .hws_needs_physical = 1,
>  };
>  
>  #define GEN4_FEATURES \
> @@ -130,6 +135,7 @@ static const struct intel_device_info intel_i965g_info = {
>   GEN4_FEATURES,
>   .is_broadwater = 1,
>   .has_overlay = 1,
> + .hws_needs_physical = 1,
>  };
>  
>  static const struct intel_device_info intel_i965gm_info = {
> @@ -138,11 +144,12 @@ static const struct intel_device_info intel_i965gm_info 
> = {
>   .is_mobile = 1, .has_fbc = 1,
>   .has_overlay = 1,
>   .supports_tv = 1,
> + .hws_needs_physical = 1,
>  };
>  
>  static const struct intel_device_info intel_g33_info = {

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

[Chris Wilson]

On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote:
> We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
> during atomic commits. This will continue to guarantee that we
> deactivate FBC and it will also update the state checking structures
> at the correct time. Then, later, at the point where we were calling
> intel_fbc_update, we'll only need to call intel_fbc_post_update.
> 
> Also add the proper warnings in case we don't have the appropriate
> locks. Daniel mentioned the warnings will have to be removed for async
> commits, but let's keep them here while we can.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 11 +--
>  drivers/gpu/drm/i915/intel_drv.h |  8 +---
>  drivers/gpu/drm/i915/intel_fbc.c | 33 ++---
>  3 files changed, 28 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index baab41046..baa4cc9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c

> @@ -11733,7 +11733,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> to_intel_plane(primary)->frontbuffer_bit);
>   mutex_unlock(>struct_mutex);
>  
> - intel_fbc_deactivate(intel_crtc);
> + intel_fbc_pre_update(intel_crtc);
>   intel_frontbuffer_flip_prepare(dev,
>  
> to_intel_plane(primary)->frontbuffer_bit);
>  
> +void intel_fbc_pre_update(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
>   struct intel_fbc *fbc = _priv->fbc;
>  
> - WARN_ON(!mutex_is_locked(>lock));
> + if (!fbc_supported(dev_priv))
> + return;
> +
> + mutex_lock(>lock);
>  
>   if (!multiple_pipes_ok(dev_priv)) {
>   set_no_fbc_reason(dev_priv, "more than one pipe active");
> @@ -907,15 +915,17 @@ static void intel_fbc_pre_update(struct intel_crtc 
> *crtc)
>   }
>  
>   if (!fbc->enabled || fbc->crtc != crtc)
> - return;
> + goto unlock;
>  
>   intel_fbc_update_state_cache(crtc);
>  
>  deactivate:
>   __intel_fbc_deactivate(dev_priv);
> +unlock:
> + mutex_unlock(>lock);
>  }


So this change is broken as intel_fbc_pre_update() depends upon state
derived from the pinned framebuffer object but is being called by
intel_crtc_page_flip() before that object is pinned with
intel_pin_and_fence_fb - i.e. state such as the gtt_offset or the fence
for the object are incorrect, and even trying to look at them can cause
an oops.
-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 19/21] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:25AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20c793f..233feb9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -781,6 +781,7 @@ struct intel_csr {
>   func(has_hw_contexts) sep \
>   func(has_logical_ring_contexts) sep \
>   func(has_l3_dpf) sep \
> + func(has_gmch_display) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2821,8 +2822,7 @@ struct drm_i915_cmd_table {
>  #define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
>  #define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
>  
> -#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->gen < 5 || \
> -IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> +#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->has_gmch_display)
>  
>  /* DPF == dynamic parity feature */
>  #define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d219a01..1c2f5fa 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -57,6 +57,7 @@
>  #define GEN2_FEATURES \
>   .gen = 2, \
>   .has_overlay = 1, .overlay_needs_physical = 1, \
> + .has_gmch_display = 1, \
>   .ring_mask = RENDER_RING, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -85,6 +86,7 @@ static const struct intel_device_info intel_i865g_info = {
>  
>  #define GEN3_FEATURES \
>   .gen = 3, .num_pipes = 2, \
> + .has_gmch_display = 1, \
>   .ring_mask = RENDER_RING, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -119,6 +121,7 @@ static const struct intel_device_info intel_i945gm_info = 
> {
>  #define GEN4_FEATURES \
>   .gen = 4, .num_pipes = 2, \
>   .has_hotplug = 1, \
> + .has_gmch_display = 1, \
>   .ring_mask = RENDER_RING, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -250,6 +253,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>   .has_rc6 = 1, \
>   .has_gmbus_irq = 1, \
>   .has_hw_contexts = 1, \
> + .has_gmch_display = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -308,6 +312,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .has_gmbus_irq = 1,
>   .has_hw_contexts = 1,
>   .has_logical_ring_contexts = 1,
> + .has_gmch_display = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 18/21] drm/i915: Move HAS_L3_DPF definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:24AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 


Reviewed-by: Rodrigo Vivi 

> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 4 
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 18c9fc5..20c793f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -780,6 +780,7 @@ struct intel_csr {
>   func(has_gmbus_irq) sep \
>   func(has_hw_contexts) sep \
>   func(has_logical_ring_contexts) sep \
> + func(has_l3_dpf) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2824,7 +2825,7 @@ struct drm_i915_cmd_table {
>  IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
>  
>  /* DPF == dynamic parity feature */
> -#define HAS_L3_DPF(dev) (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
> +#define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
>  #define NUM_L3_SLICES(dev) (IS_HSW_GT3(dev) ? 2 : HAS_L3_DPF(dev))
>  
>  #define GT_FREQUENCY_MULTIPLIER 50
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index db15fc2..d219a01 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -226,18 +226,21 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
>  static const struct intel_device_info intel_ivybridge_d_info = {
>   GEN7_FEATURES,
>   .is_ivybridge = 1,
> + .has_l3_dpf = 1,
>  };
>  
>  static const struct intel_device_info intel_ivybridge_m_info = {
>   GEN7_FEATURES,
>   .is_ivybridge = 1,
>   .is_mobile = 1,
> + .has_l3_dpf = 1,
>  };
>  
>  static const struct intel_device_info intel_ivybridge_q_info = {
>   GEN7_FEATURES,
>   .is_ivybridge = 1,
>   .num_pipes = 0, /* legal, last one wins */
> + .has_l3_dpf = 1,
>  };
>  
>  #define VLV_FEATURES  \
> @@ -272,6 +275,7 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>  static const struct intel_device_info intel_haswell_info = {
>   HSW_FEATURES,
>   .is_haswell = 1,
> + .has_l3_dpf = 1,
>  };
>  
>  #define BDW_FEATURES \
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 17/21] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:23AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 


Reviewed-by: Rodrigo Vivi 

> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 -
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 919ae65..18c9fc5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -779,6 +779,7 @@ struct intel_csr {
>   func(has_dp_mst) sep \
>   func(has_gmbus_irq) sep \
>   func(has_hw_contexts) sep \
> + func(has_logical_ring_contexts) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2731,7 +2732,7 @@ struct drm_i915_cmd_table {
>  #define I915_NEED_GFX_HWS(dev)   (INTEL_INFO(dev)->need_gfx_hws)
>  
>  #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->has_hw_contexts)
> -#define HAS_LOGICAL_RING_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 8)
> +#define HAS_LOGICAL_RING_CONTEXTS(dev)   
> (INTEL_INFO(dev)->has_logical_ring_contexts)
>  #define USES_PPGTT(dev)  (i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
>  #define USES_FULL_48BIT_PPGTT(dev)   (i915.enable_ppgtt == 3)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 9d42b68..db15fc2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -276,7 +276,8 @@ static const struct intel_device_info intel_haswell_info 
> = {
>  
>  #define BDW_FEATURES \
>   HSW_FEATURES, \
> - BDW_COLORS
> + BDW_COLORS, \
> + .has_logical_ring_contexts = 1
>  
>  static const struct intel_device_info intel_broadwell_info = {
>   BDW_FEATURES,
> @@ -302,6 +303,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .has_rc6 = 1,
>   .has_gmbus_irq = 1,
>   .has_hw_contexts = 1,
> + .has_logical_ring_contexts = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -340,6 +342,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_dp_mst = 1,
>   .has_gmbus_irq = 1,
>   .has_hw_contexts = 1,
> + .has_logical_ring_contexts = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu:
> On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote:
> Do we know why we get black screens in this scenario?

I don't know exactly, but I can speculate that it's probably because
the display engine fails to decompress the framebuffer and gets
completely lost on when the data ends, so it gives up and shows black.

> > 
> > > 
> > > +/**
> > > + * intel_fbc_handle_fifo_underrun - disable FBC when we get a
> > > FIFO underrun
> > > + * @dev_priv: i915 device instance
> > > + *
> > > + * Without FBC, most underruns are harmless and don't really
> > > cause too many
> > > + * problems, except for an annoying message on dmesg. With FBC,
> > > underruns can
> > > + * become black screens or even worse, especially when paired
> > > with bad
> > > + * watermarks. So in order for us to be on the safe side,
> > > completely disable FBC
> > > + * in case we ever detect a FIFO underrun on any pipe. An
> > > underrun on any pipe
> > > + * already suggests that watermarks may be bad, so try to be as
> > > safe as
> > > + * possible.
> > > + */
> > > +void intel_fbc_handle_fifo_underrun(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + struct intel_fbc *fbc = _priv->fbc;
> > > +
> > > + if (!fbc_supported(dev_priv))
> > > + return;
> > > +
> > 
> > Should we bail out if fbc is not enabled?

No. Even if FBC is disabled or deactivated we need to make sure the
code doesn't decide to enable/activate FBC later, and simply disabling
it now won't prevent it from being reactivated on the next modesets.

> > Also, can we just disable fbc if we see an underrun instead of
> > using a
> > new flag to prevent activation?

No, for the same reason as above: we don't want the code to decide to
enable/activate FBC later.

> 
> The information that is crucially absent in the function name, and
> its
> kerneldoc, is that this function is run from hardirq context. There
> isn't
> much you are allowed to do here but schedule work.

You're right. I'll rename the function and improve the doc.

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

Re: [Intel-gfx] [PATCH v3 16/21] drm/i915: Move HAS_HW_CONTEXTS definition to platform

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:22AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 729a91b..919ae65 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -778,6 +778,7 @@ struct intel_csr {
>   func(has_rc6p) sep \
>   func(has_dp_mst) sep \
>   func(has_gmbus_irq) sep \
> + func(has_hw_contexts) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2729,7 +2730,7 @@ struct drm_i915_cmd_table {
>HAS_EDRAM(dev))
>  #define I915_NEED_GFX_HWS(dev)   (INTEL_INFO(dev)->need_gfx_hws)
>  
> -#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
> +#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->has_hw_contexts)
>  #define HAS_LOGICAL_RING_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 8)
>  #define USES_PPGTT(dev)  (i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 3cd0d8f..9d42b68 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -196,6 +196,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
>   .has_llc = 1, \
>   .has_rc6 = 1, \
>   .has_rc6p = 1, \
> + .has_hw_contexts = 1, \
>   .has_gmbus_irq = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -218,6 +219,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
>   .has_rc6 = 1, \
>   .has_rc6p = 1, \
>   .has_gmbus_irq = 1, \
> + .has_hw_contexts = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   IVB_CURSOR_OFFSETS
>  
> @@ -244,6 +246,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>   .has_runtime_pm = 1, \
>   .has_rc6 = 1, \
>   .has_gmbus_irq = 1, \
> + .has_hw_contexts = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -298,6 +301,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .has_resource_streamer = 1,
>   .has_rc6 = 1,
>   .has_gmbus_irq = 1,
> + .has_hw_contexts = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -335,6 +339,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_rc6 = 1,
>   .has_dp_mst = 1,
>   .has_gmbus_irq = 1,
> + .has_hw_contexts = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 15/21] drm/i915: Introduce GEN2_FEATURES for device info

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:21AM -0700, Carlos Santa wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>

same as others

> Use it for 830, 845g, i85x, i865g.
> 
> Signed-off-by: Carlos Santa 


> ---
>  drivers/gpu/drm/i915/i915_pci.c | 37 -
>  1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2f65898..3cd0d8f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -54,38 +54,33 @@
>  #define CHV_COLORS \
>   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
>  
> +#define GEN2_FEATURES \
> + .gen = 2, \
> + .has_overlay = 1, .overlay_needs_physical = 1, \
> + .ring_mask = RENDER_RING, \
> + GEN_DEFAULT_PIPEOFFSETS, \
> + CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_i830_info = {
> - .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> - .has_overlay = 1, .overlay_needs_physical = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN2_FEATURES,
> + .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,

maybe GEN2_FEATURES should define num_pipes = 1 and this overwrites it, like 
you have the ring in gen3 or gen4...

anyways:
Reviewed-by: Rodrigo Vivi 

>  };
>  
>  static const struct intel_device_info intel_845g_info = {
> - .gen = 2, .num_pipes = 1,
> - .has_overlay = 1, .overlay_needs_physical = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN2_FEATURES,
> + .num_pipes = 1,
>  };
>  
>  static const struct intel_device_info intel_i85x_info = {
> - .gen = 2, .is_i85x = 1, .is_mobile = 1, .num_pipes = 2,
> - .cursor_needs_physical = 1,
> - .has_overlay = 1, .overlay_needs_physical = 1,
> + GEN2_FEATURES,
> + .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> + .is_i85x = 1,
>   .has_fbc = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  static const struct intel_device_info intel_i865g_info = {
> - .gen = 2, .num_pipes = 1,
> - .has_overlay = 1, .overlay_needs_physical = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN2_FEATURES,
> + .num_pipes = 1,
>  };
>  
>  #define GEN3_FEATURES \
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 14/21] drm/i915: Introduce GEN3_FEATURES for device info

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:20AM -0700, Carlos Santa wrote:
> Based on the GEN7_FEATURES from Ben W.
>

same as previous

> Use it for i915g, i915gm, i945g, i945gm, g33 and pnv.
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_pci.c | 30 ++
>  1 file changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 356f16d..2f65898 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -88,39 +88,37 @@ static const struct intel_device_info intel_i865g_info = {
>   CURSOR_OFFSETS,
>  };
>  
> +#define GEN3_FEATURES \
> + .gen = 3, .num_pipes = 2, \
> + .ring_mask = RENDER_RING, \
> + GEN_DEFAULT_PIPEOFFSETS, \
> + CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_i915g_info = {
> - .gen = 3, .is_i915g = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> + GEN3_FEATURES,
> + .is_i915g = 1, .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  static const struct intel_device_info intel_i915gm_info = {
> - .gen = 3, .is_mobile = 1, .num_pipes = 2,
> + GEN3_FEATURES,
> + .is_mobile = 1,
>   .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
>   .supports_tv = 1,
>   .has_fbc = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  static const struct intel_device_info intel_i945g_info = {
> - .gen = 3, .has_hotplug = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> + GEN3_FEATURES,
> + .has_hotplug = 1, .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  static const struct intel_device_info intel_i945gm_info = {
> - .gen = 3, .is_i945gm = 1, .is_mobile = 1, .num_pipes = 2,
> + GEN3_FEATURES,
> + .is_i945gm = 1, .is_mobile = 1,
>   .has_hotplug = 1, .cursor_needs_physical = 1,
>   .has_overlay = 1, .overlay_needs_physical = 1,
>   .supports_tv = 1,
>   .has_fbc = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  #define GEN4_FEATURES \
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 13/21] drm/i915: Introduce GEN4_FEATURES for device info

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:19AM -0700, Carlos Santa wrote:
> Based on the GEN7_FEATURES changes from Ben W.

same comments as for gen5

> 
> Use it for i965g, i965gm, g45 and gm45.
> 
> Signed-off-by: Carlos Santa 

Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/i915_pci.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 59c958a4..356f16d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -123,23 +123,25 @@ static const struct intel_device_info intel_i945gm_info 
> = {
>   CURSOR_OFFSETS,
>  };
>  
> +#define GEN4_FEATURES \
> + .gen = 4, .num_pipes = 2, \
> + .has_hotplug = 1, \
> + .ring_mask = RENDER_RING, \
> + GEN_DEFAULT_PIPEOFFSETS, \
> + CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_i965g_info = {
> - .gen = 4, .is_broadwater = 1, .num_pipes = 2,
> - .has_hotplug = 1,
> + GEN4_FEATURES,
> + .is_broadwater = 1,
>   .has_overlay = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  static const struct intel_device_info intel_i965gm_info = {
> - .gen = 4, .is_crestline = 1, .num_pipes = 2,
> - .is_mobile = 1, .has_fbc = 1, .has_hotplug = 1,
> + GEN4_FEATURES,
> + .is_crestline = 1,
> + .is_mobile = 1, .has_fbc = 1,
>   .has_overlay = 1,
>   .supports_tv = 1,
> - .ring_mask = RENDER_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  static const struct intel_device_info intel_g33_info = {
> @@ -152,21 +154,19 @@ static const struct intel_device_info intel_g33_info = {
>  };
>  
>  static const struct intel_device_info intel_g45_info = {
> - .gen = 4, .is_g4x = 1, .need_gfx_hws = 1, .num_pipes = 2,
> - .has_pipe_cxsr = 1, .has_hotplug = 1,
> + GEN4_FEATURES,
> + .is_g4x = 1, .need_gfx_hws = 1,
> + .has_pipe_cxsr = 1,
>   .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  static const struct intel_device_info intel_gm45_info = {
> - .gen = 4, .is_g4x = 1, .num_pipes = 2,
> + GEN4_FEATURES,
> + .is_g4x = 1,
>   .is_mobile = 1, .need_gfx_hws = 1, .has_fbc = 1,
> - .has_pipe_cxsr = 1, .has_hotplug = 1,
> + .has_pipe_cxsr = 1,
>   .supports_tv = 1,
>   .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
>  };
>  
>  static const struct intel_device_info intel_pineview_info = {
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 12/21] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:18AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 


Reviewed-by: Rodrigo Vivi 

> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 6 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c4621ae..729a91b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -777,6 +777,7 @@ struct intel_csr {
>   func(has_rc6) sep \
>   func(has_rc6p) sep \
>   func(has_dp_mst) sep \
> + func(has_gmbus_irq) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2753,7 +2754,7 @@ struct drm_i915_cmd_table {
>   * interrupt source and so prevents the other device from working properly.
>   */
>  #define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->has_gmbus_irq)
>  
>  /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
>   * rows, which changed the alignment requirements and fence programming.
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 8a50e45..59c958a4 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -181,6 +181,7 @@ static const struct intel_device_info intel_pineview_info 
> = {
>  #define GEN5_FEATURES \
>   .gen = 5, .num_pipes = 2, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
> + .has_gmbus_irq = 1, \
>   .ring_mask = RENDER_RING | BSD_RING, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
> @@ -202,6 +203,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
>   .has_llc = 1, \
>   .has_rc6 = 1, \
>   .has_rc6p = 1, \
> + .has_gmbus_irq = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
>  
> @@ -222,6 +224,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
>   .has_llc = 1, \
>   .has_rc6 = 1, \
>   .has_rc6p = 1, \
> + .has_gmbus_irq = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   IVB_CURSOR_OFFSETS
>  
> @@ -247,6 +250,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>   .has_psr = 1, \
>   .has_runtime_pm = 1, \
>   .has_rc6 = 1, \
> + .has_gmbus_irq = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -300,6 +304,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .has_runtime_pm = 1,
>   .has_resource_streamer = 1,
>   .has_rc6 = 1,
> + .has_gmbus_irq = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -336,6 +341,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_resource_streamer = 1,
>   .has_rc6 = 1,
>   .has_dp_mst = 1,
> + .has_gmbus_irq = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 11/21] drm/i915: Introduce GEN5_FEATURES for device info

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:17AM -0700, Carlos Santa wrote:
> Based on the GEN7_FEATURES changes from Ben w.

Maybe this comment and also on the previous GEN6_FEATURE could be improved.
And also good to Cc people you are mentioning on the commit message.

Besides I still believe we should add this but also making the next platform 
get based on the previous one.
Anyway this can be done later so I won't block the progress here. Feel free to 
use

Reviewed-by: Rodrigo Vivi 



> 
> Use it for ilk.



> 
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ba0f5c8f..8a50e45 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -178,21 +178,20 @@ static const struct intel_device_info 
> intel_pineview_info = {
>   CURSOR_OFFSETS,
>  };
>  
> +#define GEN5_FEATURES \
> + .gen = 5, .num_pipes = 2, \
> + .need_gfx_hws = 1, .has_hotplug = 1, \
> + .ring_mask = RENDER_RING | BSD_RING, \
> + GEN_DEFAULT_PIPEOFFSETS, \
> + CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_ironlake_d_info = {
> - .gen = 5, .num_pipes = 2,
> - .need_gfx_hws = 1, .has_hotplug = 1,
> - .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN5_FEATURES,
>  };
>  
>  static const struct intel_device_info intel_ironlake_m_info = {
> - .gen = 5, .is_mobile = 1, .num_pipes = 2,
> - .need_gfx_hws = 1, .has_hotplug = 1,
> - .has_fbc = 1,
> - .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN5_FEATURES,
> + .is_mobile = 1,
>  };
>  
>  #define GEN6_FEATURES \
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 10/21] drm/i915: Move HAS_DP_MST definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:16AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 611771b..c4621ae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -776,6 +776,7 @@ struct intel_csr {
>   func(has_resource_streamer) sep \
>   func(has_rc6) sep \
>   func(has_rc6p) sep \
> + func(has_dp_mst) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2768,8 +2769,7 @@ struct drm_i915_cmd_table {
>  
>  #define HAS_IPS(dev) (IS_HSW_ULT(dev) || IS_BROADWELL(dev))
>  
> -#define HAS_DP_MST(dev)  (IS_HASWELL(dev) || IS_BROADWELL(dev) 
> || \
> -  INTEL_INFO(dev)->gen >= 9)
> +#define HAS_DP_MST(dev)  (INTEL_INFO(dev)->has_dp_mst)
>  
>  #define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)  (INTEL_INFO(dev)->has_fpga_dbg)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ce78a18..ba0f5c8f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -266,6 +266,7 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>   .has_fpga_dbg = 1, \
>   .has_psr = 1, \
>   .has_resource_streamer = 1, \
> + .has_dp_mst = 1, \
>   .has_rc6p = 0 /*RC6p excludes HSW*/, \
>   .has_runtime_pm = 1
>  
> @@ -335,6 +336,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_csr = 1,
>   .has_resource_streamer = 1,
>   .has_rc6 = 1,
> + .has_dp_mst = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 09/21] drm/i915: Move HAS_RC6p definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:15AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bc6df5b..611771b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -775,6 +775,7 @@ struct intel_csr {
>   func(has_csr) sep \
>   func(has_resource_streamer) sep \
>   func(has_rc6) sep \
> + func(has_rc6p) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2775,7 +2776,7 @@ struct drm_i915_cmd_table {
>  #define HAS_PSR(dev) (INTEL_INFO(dev)->has_psr)
>  #define HAS_RUNTIME_PM(dev)  (INTEL_INFO(dev)->has_runtime_pm)
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->has_rc6)
> -#define HAS_RC6p(dev)(IS_GEN6(dev) || IS_IVYBRIDGE(dev))
> +#define HAS_RC6p(dev)(INTEL_INFO(dev)->has_rc6p)
>  
>  #define HAS_CSR(dev) (INTEL_INFO(dev)->has_csr)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 42108dc..ce78a18 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -202,6 +202,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .has_llc = 1, \
>   .has_rc6 = 1, \
> + .has_rc6p = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
>  
> @@ -221,6 +222,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .has_llc = 1, \
>   .has_rc6 = 1, \
> + .has_rc6p = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   IVB_CURSOR_OFFSETS
>  
> @@ -264,6 +266,7 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>   .has_fpga_dbg = 1, \
>   .has_psr = 1, \
>   .has_resource_streamer = 1, \
> + .has_rc6p = 0 /*RC6p excludes HSW*/, \

better with spaces /* Comment */
But also I don't like the message content. This one seems to tell that HSW is 
the only platform
without RC6p.

What about: "RC6p removed-by HSW". So we kind of follow new BSpec scheme of 
"REMOVEDBY"

>   .has_runtime_pm = 1
>  
>  static const struct intel_device_info intel_haswell_info = {
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 08/21] drm/i915: Move HAS_RC6 definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:14AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e9d95c5..bc6df5b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -774,6 +774,7 @@ struct intel_csr {
>   func(has_runtime_pm) sep \
>   func(has_csr) sep \
>   func(has_resource_streamer) sep \
> + func(has_rc6) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2773,7 +2774,7 @@ struct drm_i915_cmd_table {
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)  (INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev) (INTEL_INFO(dev)->has_psr)
>  #define HAS_RUNTIME_PM(dev)  (INTEL_INFO(dev)->has_runtime_pm)
> -#define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
> +#define HAS_RC6(dev) (INTEL_INFO(dev)->has_rc6)
>  #define HAS_RC6p(dev)(IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>  
>  #define HAS_CSR(dev) (INTEL_INFO(dev)->has_csr)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 46c48ed..42108dc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -201,6 +201,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
>   .has_fbc = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .has_llc = 1, \
> + .has_rc6 = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
>  
> @@ -219,6 +220,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
>   .has_fbc = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .has_llc = 1, \
> + .has_rc6 = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
>   IVB_CURSOR_OFFSETS
>  
> @@ -243,6 +245,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>   .gen = 7, .num_pipes = 2, \
>   .has_psr = 1, \
>   .has_runtime_pm = 1, \
> + .has_rc6 = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -293,6 +296,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .has_psr = 1,
>   .has_runtime_pm = 1,
>   .has_resource_streamer = 1,
> + .has_rc6 = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -327,6 +331,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_pooled_eu = 0,
>   .has_csr = 1,
>   .has_resource_streamer = 1,
> + .has_rc6 = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 07/21] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:13AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 

This is one of those patches where only reading the patch it looks like
the definition went to the wrong place, but looking to the final results
it is possible to see that has_resource_streamer went to the correct
platforms.

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 14e8911..e9d95c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -773,6 +773,7 @@ struct intel_csr {
>   func(has_psr) sep \
>   func(has_runtime_pm) sep \
>   func(has_csr) sep \
> + func(has_resource_streamer) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2786,8 +2787,7 @@ struct drm_i915_cmd_table {
>  #define HAS_GUC_UCODE(dev)   (HAS_GUC(dev))
>  #define HAS_GUC_SCHED(dev)   (HAS_GUC(dev))
>  
> -#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
> - INTEL_INFO(dev)->gen >= 8)
> +#define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
>  
>  #define HAS_POOLED_EU(dev)   (INTEL_INFO(dev)->has_pooled_eu)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 21a3bc5..46c48ed 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -260,6 +260,7 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>   .has_ddi = 1, \
>   .has_fpga_dbg = 1, \
>   .has_psr = 1, \
> + .has_resource_streamer = 1, \
>   .has_runtime_pm = 1
>  
>  static const struct intel_device_info intel_haswell_info = {
> @@ -291,6 +292,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .is_cherryview = 1,
>   .has_psr = 1,
>   .has_runtime_pm = 1,
> + .has_resource_streamer = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -324,6 +326,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_runtime_pm = 1,
>   .has_pooled_eu = 0,
>   .has_csr = 1,
> + .has_resource_streamer = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 06/21] drm/i915 Move HAS_CSR definition to platform definition

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:12AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3ab63c0..14e8911 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -772,6 +772,7 @@ struct intel_csr {
>   func(has_fbc) sep \
>   func(has_psr) sep \
>   func(has_runtime_pm) sep \
> + func(has_csr) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2774,7 +2775,7 @@ struct drm_i915_cmd_table {
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)(IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>  
> -#define HAS_CSR(dev) (IS_GEN9(dev))
> +#define HAS_CSR(dev) (INTEL_INFO(dev)->has_csr)
>  
>  /*
>   * For now, anything with a GuC requires uCode loading, and then supports
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 9d78836..21a3bc5 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -301,12 +301,14 @@ static const struct intel_device_info 
> intel_skylake_info = {
>   BDW_FEATURES,
>   .is_skylake = 1,
>   .gen = 9,
> + .has_csr = 1,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
>   BDW_FEATURES,
>   .is_skylake = 1,
>   .gen = 9,
> + .has_csr = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> @@ -321,6 +323,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_fbc = 1,
>   .has_runtime_pm = 1,
>   .has_pooled_eu = 0,
> + .has_csr = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> @@ -330,12 +333,14 @@ static const struct intel_device_info 
> intel_kabylake_info = {
>   BDW_FEATURES,
>   .is_kabylake = 1,
>   .gen = 9,
> + .has_csr = 1,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
>   BDW_FEATURES,
>   .is_kabylake = 1,
>   .gen = 9,
> + .has_csr = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 04/21] drm/i915: Move HAS_RUNTIME_PM definition to platform

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:10AM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
> 
> Feedback from V. Syrjala: remove runtime PM support for snb as it breaks
> hotplug support.

I believe it is better a separated patch on top of this re-org. Just in case
it needs to be reverted.

> 
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 6 ++
>  drivers/gpu/drm/i915/i915_pci.c | 6 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6f2f066..0eaf28f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -771,6 +771,7 @@ struct intel_csr {
>   func(is_preliminary) sep \
>   func(has_fbc) sep \
>   func(has_psr) sep \
> + func(has_runtime_pm) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2769,10 +2770,7 @@ struct drm_i915_cmd_table {
>  #define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)  (INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev) (INTEL_INFO(dev)->has_psr)
> -#define HAS_RUNTIME_PM(dev)  (IS_GEN6(dev) || IS_HASWELL(dev) || \
> -  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
> -  IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
> -  IS_KABYLAKE(dev) || IS_BROXTON(dev))
> +#define HAS_RUNTIME_PM(dev)  (INTEL_INFO(dev)->has_runtime_pm)
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)(IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index bdc2071..9d78836 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -242,6 +242,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>  #define VLV_FEATURES  \
>   .gen = 7, .num_pipes = 2, \
>   .has_psr = 1, \
> + .has_runtime_pm = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -258,7 +259,8 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
>   .has_ddi = 1, \
>   .has_fpga_dbg = 1, \
> - .has_psr = 1
> + .has_psr = 1, \
> + .has_runtime_pm = 1
>  
>  static const struct intel_device_info intel_haswell_info = {
>   HSW_FEATURES,
> @@ -288,6 +290,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .is_cherryview = 1,
>   .has_psr = 1,
> + .has_runtime_pm = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -316,6 +319,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
>   .has_fbc = 1,
> + .has_runtime_pm = 1,
>   .has_pooled_eu = 0,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 02/21] drm/i915: Remove .is_mobile field from platform struct

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 11:45:08AM -0700, Carlos Santa wrote:
> As recommended by Ville Syrjala removing .is_mobile field from the
> platform struct definition for vlv and hsw+ GPUs as there's no need to
> make the distinction in later hardware anymore. Keep it for older GPUs
> as it is still needed for ilk-ivb.

good idea!

> 
> Signed-off-by: Carlos Santa 


Reviewed-by: Rodrigo Vivi 

> ---
>  arch/x86/kernel/early-quirks.c  |  9 +++--
>  drivers/gpu/drm/i915/i915_pci.c | 45 
> -
>  include/drm/i915_pciids.h   | 38 +-
>  3 files changed, 25 insertions(+), 67 deletions(-)
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index de7501e..e6bd329 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -512,8 +512,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_I915GM_IDS(_early_ops),
>   INTEL_I945G_IDS(_early_ops),
>   INTEL_I945GM_IDS(_early_ops),
> - INTEL_VLV_M_IDS(_early_ops),
> - INTEL_VLV_D_IDS(_early_ops),
> + INTEL_VLV_IDS(_early_ops),
>   INTEL_PINEVIEW_IDS(_early_ops),
>   INTEL_I965G_IDS(_early_ops),
>   INTEL_G33_IDS(_early_ops),
> @@ -526,10 +525,8 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_SNB_M_IDS(_early_ops),
>   INTEL_IVB_M_IDS(_early_ops),
>   INTEL_IVB_D_IDS(_early_ops),
> - INTEL_HSW_D_IDS(_early_ops),
> - INTEL_HSW_M_IDS(_early_ops),
> - INTEL_BDW_M_IDS(_early_ops),
> - INTEL_BDW_D_IDS(_early_ops),
> + INTEL_HSW_IDS(_early_ops),
> + INTEL_BDW_IDS(_early_ops),
>   INTEL_CHV_IDS(_early_ops),
>   INTEL_SKL_IDS(_early_ops),
>   INTEL_BXT_IDS(_early_ops),
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e1caa0b..b5ec8a7 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -250,13 +250,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>   GEN_DEFAULT_PIPEOFFSETS, \
>   CURSOR_OFFSETS
>  
> -static const struct intel_device_info intel_valleyview_m_info = {
> - VLV_FEATURES,
> - .is_valleyview = 1,
> - .is_mobile = 1,
> -};
> -
> -static const struct intel_device_info intel_valleyview_d_info = {
> +static const struct intel_device_info intel_valleyview_info = {
>   VLV_FEATURES,
>   .is_valleyview = 1,
>  };
> @@ -268,47 +262,28 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
>   .has_fpga_dbg = 1, \
>   .has_psr = 1
>  
> -static const struct intel_device_info intel_haswell_d_info = {
> +static const struct intel_device_info intel_haswell_info = {
>   HSW_FEATURES,
>   .is_haswell = 1,
>  };
>  
> -static const struct intel_device_info intel_haswell_m_info = {
> - HSW_FEATURES,
> - .is_haswell = 1,
> - .is_mobile = 1,
> -};
> -
>  #define BDW_FEATURES \
>   HSW_FEATURES, \
>   BDW_COLORS
>  
> -static const struct intel_device_info intel_broadwell_d_info = {
> +static const struct intel_device_info intel_broadwell_info = {
>   BDW_FEATURES,
>   .gen = 8,
>   .is_broadwell = 1,
>  };
>  
> -static const struct intel_device_info intel_broadwell_m_info = {
> - BDW_FEATURES,
> - .gen = 8, .is_mobile = 1,
> - .is_broadwell = 1,
> -};
> -
> -static const struct intel_device_info intel_broadwell_gt3d_info = {
> +static const struct intel_device_info intel_broadwell_gt3_info = {
>   BDW_FEATURES,
>   .gen = 8,
>   .is_broadwell = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> -static const struct intel_device_info intel_broadwell_gt3m_info = {
> - BDW_FEATURES,
> - .gen = 8, .is_mobile = 1,
> - .is_broadwell = 1,
> - .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> -};
> -
>  static const struct intel_device_info intel_cherryview_info = {
>   .gen = 8, .num_pipes = 3,
>   .need_gfx_hws = 1, .has_hotplug = 1,
> @@ -390,14 +365,10 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_IVB_Q_IDS(_ivybridge_q_info), /* must be first IVB */
>   INTEL_IVB_M_IDS(_ivybridge_m_info),
>   INTEL_IVB_D_IDS(_ivybridge_d_info),
> - INTEL_HSW_D_IDS(_haswell_d_info),
> - INTEL_HSW_M_IDS(_haswell_m_info),
> - INTEL_VLV_M_IDS(_valleyview_m_info),
> - INTEL_VLV_D_IDS(_valleyview_d_info),
> - INTEL_BDW_GT12M_IDS(_broadwell_m_info),
> - INTEL_BDW_GT12D_IDS(_broadwell_d_info),
> - INTEL_BDW_GT3M_IDS(_broadwell_gt3m_info),
> - INTEL_BDW_GT3D_IDS(_broadwell_gt3d_info),
> + INTEL_HSW_IDS(_haswell_info),
> + INTEL_VLV_IDS(_valleyview_info),
> + INTEL_BDW_GT12_IDS(_broadwell_info),
> + INTEL_BDW_GT3_IDS(_broadwell_gt3_info),
>   INTEL_CHV_IDS(_cherryview_info),
>   

Re: [Intel-gfx] [PATCH v3 05/21] drm/i915: Get rid of HAS_CORE_RING_FREQ

[Rodrigo Vivi]

On Tue, Aug 09, 2016 at 07:59:38PM +0100, Chris Wilson wrote:
> On Tue, Aug 09, 2016 at 11:45:11AM -0700, Carlos Santa wrote:
> > No need for HAS_CORE_RING_FREQ as that flag is actually the same as
> > .has_llc. Feedback from V. Syrjala.
> > 
> > Signed-off-by: Carlos Santa 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
> >  drivers/gpu/drm/i915/i915_drv.h | 4 
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 9bd4158..01b6735 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1898,11 +1898,12 @@ static int i915_ring_freq_table(struct seq_file *m, 
> > void *unused)
> > struct drm_info_node *node = m->private;
> > struct drm_device *dev = node->minor->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > +   struct intel_device_info *info = mkwrite_device_info(dev_priv);
> > int ret = 0;
> > int gpu_freq, ia_freq;
> > unsigned int max_gpu_freq, min_gpu_freq;
> >  
> > -   if (!HAS_CORE_RING_FREQ(dev)) {
> > +   if (!info->has_llc) {
> 
> Why do you need write access?
> 
>   if (INTEL_INFO(dev_priv)->has_llc)
> 
> or even if (HAS_LLC(dev_priv).

indeed better with HAS_() than with write access.

> -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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Silence GCC warning for cmn_a_well

[Chris Wilson]

Just make the logic simple enough for even GCC to understand (and
foolproof against random changes):

drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be
used uninitialized in this function [-Wuninitialized]:  => 871:23

Reported-by: Geert Uytterhoeven 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index d659d6f..a1d73c2 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -856,7 +856,7 @@ static void bxt_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
enum skl_disp_power_wells power_well_id = power_well->data;
-   struct i915_power_well *cmn_a_well;
+   struct i915_power_well *cmn_a_well = NULL;
 
if (power_well_id == BXT_DPIO_CMN_BC) {
/*
@@ -869,7 +869,7 @@ static void bxt_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
 
bxt_ddi_phy_init(dev_priv, bxt_power_well_to_phy(power_well));
 
-   if (power_well_id == BXT_DPIO_CMN_BC)
+   if (cmn_a_well)
intel_power_well_put(dev_priv, cmn_a_well);
 }
 
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Chris Wilson]

On Mon, Aug 15, 2016 at 10:16:56PM +0530, Goel, Akash wrote:
> 
> 
> On 8/15/2016 9:36 PM, Chris Wilson wrote:
> >On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote:
> >>+static void guc_read_update_log_buffer(struct intel_guc *guc)
> >>+{
> >>+   struct guc_log_buffer_state *log_buffer_state, 
> >>*log_buffer_snapshot_state;
> >>+   struct guc_log_buffer_state log_buffer_state_local;
> >>+   void *src_data_ptr, *dst_data_ptr;
> >>+   unsigned int buffer_size, expected_size;
> >>+   enum guc_log_buffer_type type;
> >>+
> >>+   if (WARN_ON(!guc->log.buf_addr))
> >>+   return;
> >>+
> >>+   /* Get the pointer to shared GuC log buffer */
> >>+   log_buffer_state = src_data_ptr = guc->log.buf_addr;
> >>+
> >>+   /* Get the pointer to local buffer to store the logs */
> >>+   dst_data_ptr = log_buffer_snapshot_state = guc_get_write_buffer(guc);
> >>+
> >>+   /* Actual logs are present from the 2nd page */
> >>+   src_data_ptr += PAGE_SIZE;
> >>+   dst_data_ptr += PAGE_SIZE;
> >>+
> >>+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> >>+   /* Make a copy of the state structure in GuC log buffer (which
> >>+* is uncached mapped) on the stack to avoid reading from it
> >>+* multiple times.
> >>+*/
> >>+   memcpy(_buffer_state_local, log_buffer_state,
> >>+  sizeof(struct guc_log_buffer_state));
> >>+   buffer_size = log_buffer_state_local.size;
> >>+
> >>+   if (log_buffer_snapshot_state) {
> >>+   /* First copy the state structure in snapshot buffer */
> >>+   memcpy(log_buffer_snapshot_state, 
> >>_buffer_state_local,
> >>+  sizeof(struct guc_log_buffer_state));
> >>+
> >>+   /* The write pointer could have been updated by the GuC
> >>+* firmware, after sending the flush interrupt to Host,
> >>+* for consistency set the write pointer value to same
> >>+* value of sampled_write_ptr in the snapshot buffer.
> >>+*/
> >>+   log_buffer_snapshot_state->write_ptr =
> >>+   log_buffer_snapshot_state->sampled_write_ptr;
> >>+
> >>+   log_buffer_snapshot_state++;
> >>+
> >>+   /* Now copy the actual logs, but before that validate
> >>+* the buffer size value retrieved from state structure.
> >>+*/
> >>+   if (type == GUC_ISR_LOG_BUFFER)
> >>+   expected_size = (GUC_LOG_ISR_PAGES+1)*PAGE_SIZE;
> >>+   else if (type == GUC_DPC_LOG_BUFFER)
> >>+   expected_size = (GUC_LOG_DPC_PAGES+1)*PAGE_SIZE;
> >>+   else
> >>+   expected_size = 
> >>(GUC_LOG_CRASH_PAGES+1)*PAGE_SIZE;
> >>+
> >>+   if (unlikely(buffer_size != expected_size)) {
> >>+   DRM_ERROR("unexpected log buffer size\n");
> >>+   /* Continue with further copying, already state
> >>+* structure has been copied which is enough to
> >>+* let Userspace know about the anomaly.
> >>+*/
> >>+   buffer_size = expected_size;
> >
> >Urm, no.
> >
> >You tell userspace one thing and then do another. This code should just
> >be a conduit and not apply its own outdated interpretation.
> >
> Userspace parser would get to know from the state structure about
> the anomalous buffer size.

It will, but it won't be told what the kernel did. So if believes the
GuC (as it should since it is a packet that should be unadulterated) the
entire stream is then corrupt.

> Please suggest that what should be done here ideally.
> 
> Should the further copying (for this snapshot) be skipped ?

The kernel should be avoiding interpretting the log packets as much as
possible - I would prefer it if we just moved the byte stream without
trying to interpret it as datagrams. But there is probably some merit to
at least using the log packets (datagrams).

> >>+   }
> >>+
> >>+   memcpy(dst_data_ptr, src_data_ptr, buffer_size);
> >
> >Where do you validate that buffer_size is sane before copying?
> Sorry didn't get you, the check for buffer_size is being done right
> before this memcpy.

There is no explicit check for valid src_data_ptr + buffer_size or
dst_data_ptr + buffer_size, and a quick glance at the code suggested no
reason to believe they must be valid.
-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 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Goel, Akash]

On 8/15/2016 9:36 PM, Chris Wilson wrote:

On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote:

+static void guc_read_update_log_buffer(struct intel_guc *guc)
+{
+   struct guc_log_buffer_state *log_buffer_state, 
*log_buffer_snapshot_state;
+   struct guc_log_buffer_state log_buffer_state_local;
+   void *src_data_ptr, *dst_data_ptr;
+   unsigned int buffer_size, expected_size;
+   enum guc_log_buffer_type type;
+
+   if (WARN_ON(!guc->log.buf_addr))
+   return;
+
+   /* Get the pointer to shared GuC log buffer */
+   log_buffer_state = src_data_ptr = guc->log.buf_addr;
+
+   /* Get the pointer to local buffer to store the logs */
+   dst_data_ptr = log_buffer_snapshot_state = guc_get_write_buffer(guc);
+
+   /* Actual logs are present from the 2nd page */
+   src_data_ptr += PAGE_SIZE;
+   dst_data_ptr += PAGE_SIZE;
+
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   /* Make a copy of the state structure in GuC log buffer (which
+* is uncached mapped) on the stack to avoid reading from it
+* multiple times.
+*/
+   memcpy(_buffer_state_local, log_buffer_state,
+  sizeof(struct guc_log_buffer_state));
+   buffer_size = log_buffer_state_local.size;
+
+   if (log_buffer_snapshot_state) {
+   /* First copy the state structure in snapshot buffer */
+   memcpy(log_buffer_snapshot_state, 
_buffer_state_local,
+  sizeof(struct guc_log_buffer_state));
+
+   /* The write pointer could have been updated by the GuC
+* firmware, after sending the flush interrupt to Host,
+* for consistency set the write pointer value to same
+* value of sampled_write_ptr in the snapshot buffer.
+*/
+   log_buffer_snapshot_state->write_ptr =
+   log_buffer_snapshot_state->sampled_write_ptr;
+
+   log_buffer_snapshot_state++;
+
+   /* Now copy the actual logs, but before that validate
+* the buffer size value retrieved from state structure.
+*/
+   if (type == GUC_ISR_LOG_BUFFER)
+   expected_size = (GUC_LOG_ISR_PAGES+1)*PAGE_SIZE;
+   else if (type == GUC_DPC_LOG_BUFFER)
+   expected_size = (GUC_LOG_DPC_PAGES+1)*PAGE_SIZE;
+   else
+   expected_size = 
(GUC_LOG_CRASH_PAGES+1)*PAGE_SIZE;
+
+   if (unlikely(buffer_size != expected_size)) {
+   DRM_ERROR("unexpected log buffer size\n");
+   /* Continue with further copying, already state
+* structure has been copied which is enough to
+* let Userspace know about the anomaly.
+*/
+   buffer_size = expected_size;


Urm, no.

You tell userspace one thing and then do another. This code should just
be a conduit and not apply its own outdated interpretation.

Userspace parser would get to know from the state structure about the 
anomalous buffer size.


Please suggest that what should be done here ideally.

Should the further copying (for this snapshot) be skipped ?


+   }
+
+   memcpy(dst_data_ptr, src_data_ptr, buffer_size);


Where do you validate that buffer_size is sane before copying?
Sorry didn't get you, the check for buffer_size is being done right 
before this memcpy.


Best regards
Akash

-Chris


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

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Chris Wilson]

On Mon, Aug 15, 2016 at 10:08:15PM +0530, Goel, Akash wrote:
> 
> 
> On 8/15/2016 9:42 PM, Chris Wilson wrote:
> >On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote:
> >>On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote:
> >>>+void i915_guc_register(struct drm_i915_private *dev_priv)
> >>>+{
> >>>+  if (!i915.enable_guc_submission)
> >>>+  return;
> >>
> >>The final state of i915.enable_guc_submission is not known at this time.
> 
> As per the below sequence, i915.enable_guc_submission would have
> been set to its final value by this time,
> 
> i915_driver_load
>   i915_load_modeset_init
>   i915_gem_init_hw
>   intel_guc_setup
>   i915_guc_submission_init
>   i915_guc_submission_enable
>   i915_driver_register
>   i915_debugfs_register
>   i915_guc_register

I was under the impression that intel_guc_setup() was asynchronous, that
it waited for the firmware to be loaded.
-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 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Goel, Akash]

On 8/15/2016 9:42 PM, Chris Wilson wrote:

On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote:

On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote:

+void i915_guc_register(struct drm_i915_private *dev_priv)
+{
+   if (!i915.enable_guc_submission)
+   return;


The final state of i915.enable_guc_submission is not known at this time.


As per the below sequence, i915.enable_guc_submission would have been 
set to its final value by this time,


i915_driver_load
i915_load_modeset_init
i915_gem_init_hw
intel_guc_setup
i915_guc_submission_init
i915_guc_submission_enable
i915_driver_register
i915_debugfs_register
i915_guc_register


Does it matter if you set up the log even though guc is not used?


I think it would be better to do setup only if guc submission is enabled.


Would this not be better driver from guc_submission_enable and
guc_submission_disable?





With the caveat that you probably need both. i.e. you have to wait for
both the GuC to be enabled and for sysfs to be available.

Sorry I am really confused.
Isn't this a right location ? creating the relay file after the debugfs 
registration has been done.

Other logging related setup is being done at i915_guc_submission_init().

Best regards
Akash


-Chris


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

Re: [Intel-gfx] [PATCH RFC 1/4] drm/i915: add create_context2 ioctl

[Chris Wilson]

On Mon, Aug 15, 2016 at 09:25:15AM -0700, Jesse Barnes wrote:
> On Mon, 2016-08-15 at 13:56 +0100, Chris Wilson wrote:
> > On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote:
> > > 
> > > Chris Wilson  writes:
> > > 
> > > > 
> > > > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
> > > > > 
> > > > > From: Jesse Barnes 
> > > > > 
> > > > > Add i915_gem_context_create2_ioctl for passing flags
> > > > > (e.g. SVM) when creating a context.
> > > > > 
> > > > > v2: check the pad on create_context
> > > > > v3: rebase
> > > > > v4: i915_dma is no more. create_gvt needs flags
> > > > > 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Chris Wilson 
> > > > > Cc: Joonas Lahtinen 
> > > > > Signed-off-by: Jesse Barnes  (v1)
> > > > > Signed-off-by: Mika Kuoppala 
> > > > 
> > > > Considering we can use deferred ppgtt creation and have setparam
> > > > do we
> > > > need a new create ioctl just to set a flag?
> > > 
> > > So like this:
> > > 
> > > - create ctx with the default create ioctl
> > > - set cxt param it for svm capable.
> > > - first submit deferred creates
> > > 
> > > And we use the setparam point for returning
> > > error if svm context are not there.
> > 
> > (and a call to set svm on a context after first use is illegal)
> > 
> > That's the outline I had in my head. I am not sure if the result is
> > cleaner - I just hope it is ;)
> > 
> 
> 
> I opted against that initially because creating the tables and setup
> after the fact for the process actually seemed messier.  Plus I thought
> we'd want more flags at context create later anyway...

I was half thinking of some of the silly microbenchmarks might be
improved if we deferred allocation until first use (and others will no
doubt get worse). Plus we already have an interface for making
arbitrarily complex adjustments to a context, so I was trying to avoid a
second.
-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] ✗ Ro.CI.BAT: failure for dma-buf: Wait on the reservation object when sync'ing before CPU access

[Patchwork]

== Series Details ==

Series: dma-buf: Wait on the reservation object when sync'ing before CPU access
URL   : https://patchwork.freedesktop.org/series/6/
State : failure

== Summary ==

Series 6v1 dma-buf: Wait on the reservation object when sync'ing before CPU 
access
http://patchwork.freedesktop.org/api/1.0/series/6/revisions/1/mbox

Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-snb-i7-2600)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-skl3-i5-6260u)
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (ro-bdw-i7-5600u)

fi-kbl-qkkr  total:244  pass:185  dwarn:29  dfail:0   fail:3   skip:27 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:3   dfail:0   fail:2   skip:17 
ro-bdw-i7-5600u  total:240  pass:205  dwarn:1   dfail:0   fail:2   skip:32 
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1878/

bc5705c drm-intel-nightly: 2016y-08m-15d-15h-16m-01s UTC integration manifest
a034e8e dma-buf: Wait on the reservation object when sync'ing before CPU access

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

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Chris Wilson]

On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote:
> > +void i915_guc_register(struct drm_i915_private *dev_priv)
> > +{
> > +   if (!i915.enable_guc_submission)
> > +   return;
> 
> The final state of i915.enable_guc_submission is not known at this time.
> Does it matter if you set up the log even though guc is not used?
> 
> Would this not be better driver from guc_submission_enable and
> guc_submission_disable?

With the caveat that you probably need both. i.e. you have to wait for
both the GuC to be enabled and for sysfs to be available.
-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 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

[Goel, Akash]

On 8/15/2016 9:06 PM, Tvrtko Ursulin wrote:


On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written data by GuC into the local
buffer, i.e. as per the read & write pointer values.
Moreover the flush interrupt would generally come for one type of log
buffer, when it becomes half full, so at that time the other 2 types of
log buffer would comparatively have much lesser unread data in them.
In case of overflow reported by GuC, Driver do need to copy the entire
buffer as the whole buffer would contain the unread data.

v2: Rebase.

v3: Fix the blooper of doing the copy twice. (Tvrtko)

Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 40
+-
  1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c7b4a57..b8d6313 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1003,6 +1003,8 @@ static void guc_read_update_log_buffer(struct
intel_guc *guc)
  void *src_data_ptr, *dst_data_ptr;
  unsigned int buffer_size, expected_size;
  enum guc_log_buffer_type type;
+unsigned int read_offset, write_offset, bytes_to_copy;
+bool new_overflow;

  if (WARN_ON(!guc->log.buf_addr))
  return;
@@ -1025,11 +1027,14 @@ static void guc_read_update_log_buffer(struct
intel_guc *guc)
  memcpy(_buffer_state_local, log_buffer_state,
 sizeof(struct guc_log_buffer_state));
  buffer_size = log_buffer_state_local.size;
+read_offset = log_buffer_state_local.read_ptr;
+write_offset = log_buffer_state_local.sampled_write_ptr;

  /* Bookkeeping stuff */
  guc->log.flush_count[type] +=
log_buffer_state_local.flush_to_file;
  if (log_buffer_state_local.buffer_full_cnt !=
  guc->log.prev_overflow_count[type]) {
+new_overflow = 1;
  guc->log.total_overflow_count[type] +=
  (log_buffer_state_local.buffer_full_cnt -
   guc->log.prev_overflow_count[type]);
@@ -1043,7 +1048,8 @@ static void guc_read_update_log_buffer(struct
intel_guc *guc)
  guc->log.prev_overflow_count[type] =
  log_buffer_state_local.buffer_full_cnt;
  DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
-}
+} else
+new_overflow = 0;


Nitpick: normally the rule is if one branch has curlies all of them have
to. Checkpatch I think warns about that, or maybe only in strict mode.


Did ran checkpatch with strict option.
Probably overlooked the warning. Will check again



  if (log_buffer_snapshot_state) {
  /* First copy the state structure in snapshot buffer */
@@ -1055,8 +1061,7 @@ static void guc_read_update_log_buffer(struct
intel_guc *guc)
   * for consistency set the write pointer value to same
   * value of sampled_write_ptr in the snapshot buffer.
   */
-log_buffer_snapshot_state->write_ptr =
-log_buffer_snapshot_state->sampled_write_ptr;
+log_buffer_snapshot_state->write_ptr = write_offset;

  log_buffer_snapshot_state++;

@@ -1079,7 +1084,31 @@ static void guc_read_update_log_buffer(struct
intel_guc *guc)
  buffer_size = expected_size;
  }

-memcpy(dst_data_ptr, src_data_ptr, buffer_size);
+if (unlikely(new_overflow)) {
+/* copy the whole buffer in case of overflow */
+read_offset = 0;
+write_offset = buffer_size;
+} else if (unlikely((read_offset > buffer_size) ||
+(write_offset > buffer_size))) {


Could also check for read_offset == write_offset for even more safety?

That is already handled implicitly, in this case we don't do any copy.
As per the below code bytes_to_copy will come as 0.

if (read_offset <= write_offset) {
bytes_to_copy = write_offset - read_offset;

Best regards
Akash

+DRM_ERROR("invalid log buffer state\n");
+/* copy whole buffer as offsets are unreliable */
+read_offset = 0;
+write_offset = buffer_size;
+}
+
+/* Just copy the newly written data */
+if (read_offset <= write_offset) {
+bytes_to_copy = write_offset - read_offset;
+memcpy(dst_data_ptr + read_offset,
+   src_data_ptr + read_offset, bytes_to_copy);
+} else {
+bytes_to_copy = buffer_size - read_offset;
+memcpy(dst_data_ptr + read_offset,
+   

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Chris Wilson]

On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote:
> +void i915_guc_register(struct drm_i915_private *dev_priv)
> +{
> + if (!i915.enable_guc_submission)
> + return;

The final state of i915.enable_guc_submission is not known at this time.
Does it matter if you set up the log even though guc is not used?

Would this not be better driver from guc_submission_enable and
guc_submission_disable?
-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 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Chris Wilson]

On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote:
> +static void guc_read_update_log_buffer(struct intel_guc *guc)
> +{
> + struct guc_log_buffer_state *log_buffer_state, 
> *log_buffer_snapshot_state;
> + struct guc_log_buffer_state log_buffer_state_local;
> + void *src_data_ptr, *dst_data_ptr;
> + unsigned int buffer_size, expected_size;
> + enum guc_log_buffer_type type;
> +
> + if (WARN_ON(!guc->log.buf_addr))
> + return;
> +
> + /* Get the pointer to shared GuC log buffer */
> + log_buffer_state = src_data_ptr = guc->log.buf_addr;
> +
> + /* Get the pointer to local buffer to store the logs */
> + dst_data_ptr = log_buffer_snapshot_state = guc_get_write_buffer(guc);
> +
> + /* Actual logs are present from the 2nd page */
> + src_data_ptr += PAGE_SIZE;
> + dst_data_ptr += PAGE_SIZE;
> +
> + for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + /* Make a copy of the state structure in GuC log buffer (which
> +  * is uncached mapped) on the stack to avoid reading from it
> +  * multiple times.
> +  */
> + memcpy(_buffer_state_local, log_buffer_state,
> +sizeof(struct guc_log_buffer_state));
> + buffer_size = log_buffer_state_local.size;
> +
> + if (log_buffer_snapshot_state) {
> + /* First copy the state structure in snapshot buffer */
> + memcpy(log_buffer_snapshot_state, 
> _buffer_state_local,
> +sizeof(struct guc_log_buffer_state));
> +
> + /* The write pointer could have been updated by the GuC
> +  * firmware, after sending the flush interrupt to Host,
> +  * for consistency set the write pointer value to same
> +  * value of sampled_write_ptr in the snapshot buffer.
> +  */
> + log_buffer_snapshot_state->write_ptr =
> + log_buffer_snapshot_state->sampled_write_ptr;
> +
> + log_buffer_snapshot_state++;
> +
> + /* Now copy the actual logs, but before that validate
> +  * the buffer size value retrieved from state structure.
> +  */
> + if (type == GUC_ISR_LOG_BUFFER)
> + expected_size = (GUC_LOG_ISR_PAGES+1)*PAGE_SIZE;
> + else if (type == GUC_DPC_LOG_BUFFER)
> + expected_size = (GUC_LOG_DPC_PAGES+1)*PAGE_SIZE;
> + else
> + expected_size = 
> (GUC_LOG_CRASH_PAGES+1)*PAGE_SIZE;
> +
> + if (unlikely(buffer_size != expected_size)) {
> + DRM_ERROR("unexpected log buffer size\n");
> + /* Continue with further copying, already state
> +  * structure has been copied which is enough to
> +  * let Userspace know about the anomaly.
> +  */
> + buffer_size = expected_size;

Urm, no.

You tell userspace one thing and then do another. This code should just
be a conduit and not apply its own outdated interpretation.

> + }
> +
> + memcpy(dst_data_ptr, src_data_ptr, buffer_size);

Where do you validate that buffer_size is sane before copying?
-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 15/18] drm/i915: Debugfs support for GuC logging control

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.
The value written to the file, should have bit 0 set to enable logging and
bits 4-7 should contain the verbosity info.

v2: Add a forceful flush, to collect left over logs, on disabling logging.
 Useful for Validation.

v3: Besides minor cleanup, implement read method for the debugfs file and
 set the guc_log_level to -1 when logging is disabled. (Tvrtko)

v4: Minor cleanup & rebase. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 44 -
  drivers/gpu/drm/i915/i915_guc_submission.c | 62 ++
  drivers/gpu/drm/i915/intel_guc.h   |  1 +
  3 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aaa51bc..bfc22bf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2626,6 +2626,47 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
  }

+static int i915_guc_log_control_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (!dev_priv->guc.log.vma)
+   return -EINVAL;
+
+   *val = i915.guc_log_level;
+
+   return 0;
+}
+
+static int i915_guc_log_control_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   int ret;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
+   if (!dev_priv->guc.log.vma) {
+   ret = -EINVAL;
+   goto end;
+   }
+
+   intel_runtime_pm_get(dev_priv);
+   ret = i915_guc_log_control(dev_priv, val);
+   intel_runtime_pm_put(dev_priv);
+
+end:
+   mutex_unlock(>struct_mutex);
+   return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
+   i915_guc_log_control_get, i915_guc_log_control_set,
+   "%lld\n");
+
  static int i915_edp_psr_status(struct seq_file *m, void *data)
  {
struct drm_info_node *node = m->private;
@@ -5436,7 +5477,8 @@ static const struct i915_debugfs_files {
{"i915_fbc_false_color", _fbc_fc_fops},
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
-   {"i915_dp_test_active", _displayport_test_active_fops}
+   {"i915_dp_test_active", _displayport_test_active_fops},
+   {"i915_guc_log_control", _guc_log_control_fops}
  };

  void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 85df2f3..be6c727 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -195,6 +195,16 @@ static int host2guc_force_logbuffer_flush(struct intel_guc 
*guc)
return host2guc_action(guc, data, 2);
  }

+static int host2guc_logging_control(struct intel_guc *guc, u32 control_val)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING;
+   data[1] = control_val;
+
+   return host2guc_action(guc, data, 2);
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -1585,3 +1595,55 @@ void i915_guc_register(struct drm_i915_private *dev_priv)
guc_log_late_setup(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
  }
+
+int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
+{
+   union guc_log_control log_param;
+   int ret;
+
+   log_param.value = control_val;
+
+   if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
+   log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
+   return -EINVAL;
+
+   /* This combination doesn't make sense & won't have any effect */
+   if (!log_param.logging_enabled && (i915.guc_log_level < 0))
+   return 0;
+
+   ret = host2guc_logging_control(_priv->guc, log_param.value);
+   if (ret < 0) {
+   DRM_DEBUG_DRIVER("host2guc action failed %d\n", ret);
+   return ret;
+   }
+
+   i915.guc_log_level = log_param.verbosity;
+
+   /* If log_level was set as -1 at boot time, then the relay channel file
+* wouldn't have been created by now and interrupts also would not have
+* been enabled.
+*/
+   if (!dev_priv->guc.log.relay_chan) {
+   ret = guc_log_late_setup(_priv->guc);
+   if (!ret)
+   gen9_enable_guc_interrupts(dev_priv);
+   

Re: [Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

[Daniel Vetter]

On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> Rendering operations to the dma-buf are tracked implicitly via the
> reservation_object (dmabuf->resv). This is used to allow poll() to
> wait upon outstanding rendering (or just query the current status of
> rendering). The dma-buf sync ioctl allows userspace to prepare the
> dma-buf for CPU access, which should include waiting upon rendering.
> (Some drivers may need to do more work to ensure that the dma-buf mmap
> is coherent as well as complete.)
> 
> v2: Always wait upon the reservation object implicitly. We choose to do
> it after the native handler in case it can do so more efficiently.
> 
> Testcase: igt/prime_vgem
> Testcase: igt/gem_concurrent_blit # *vgem*
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: Eric Anholt 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/dma-buf/dma-buf.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ddaee60ae52a..cf04d249a6a4 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> +   enum dma_data_direction direction)
> +{
> + bool write = (direction == DMA_BIDIRECTIONAL ||
> +   direction == DMA_TO_DEVICE);
> + struct reservation_object *resv = dmabuf->resv;
> + long ret;
> +
> + /* Wait on any implicit rendering fences */
> + ret = reservation_object_wait_timeout_rcu(resv, write, true,
> +   MAX_SCHEDULE_TIMEOUT);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
>  
>  /**
>   * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from 
> the
> @@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>   if (dmabuf->ops->begin_cpu_access)
>   ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
>  
> + /* Ensure that all fences are waited upon - but we first allow
> +  * the native handler the chance to do so more efficiently if it
> +  * chooses. A double invocation here will be reasonably cheap no-op.
> +  */
> + if (ret == 0)
> + ret = __dma_buf_begin_cpu_access(dmabuf, direction);

Not sure we should wait first and the flush or the other way round. But I
don't think it'll matter for any current dma-buf exporter, so meh.

Reviewed-by: Daniel Vetter 

Sumits, can you pls pick this one up and put into drm-misc?
-Daniel

> +
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> -- 
> 2.8.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Goel, Akash]

On 8/15/2016 8:59 PM, Tvrtko Ursulin wrote:


On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the GuC log buffer in the buffer managed by relay.
The snapshot will be taken when GuC firmware sends a log buffer flush
interrupt and up to four snapshots could be stored in the relay buffer.
The relay buffer will be operated in a mode where it will overwrite the
data not yet collected by User.
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the
'poll'
call on log file, User can come to know whenever a new snapshot of the
log buffer is taken by Driver, so can run in tandem with the Driver and
capture the logs in a sustained/streaming manner, without any loss of
data.

v2: Defer the creation of relay channel & associated debugfs file, as
 debugfs setup is now done at the end of i915 Driver load. (Chris)

v3:
- Switch to no-overwrite mode for relay.
- Fix the relay sub buffer switching sequence.

v4:
- Update i915 Kconfig to select RELAY config. (TvrtKo)
- Log a message when there is no sub buffer available to capture
   the GuC log buffer. (Tvrtko)
- Increase the number of relay sub buffers to 8 from 4, to have
   sufficient buffering for boot time logs

v5:
- Fix the alignment, indentation issues and some minor cleanup. (Tvrtko)
- Update the comment to elaborate on why a relay channel has to be
   associated with the debugfs file. (Tvrtko)

Suggested-by: Chris Wilson 
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/Kconfig   |   1 +
  drivers/gpu/drm/i915/i915_drv.c|   2 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 211
-
  drivers/gpu/drm/i915/intel_guc.h   |   3 +
  4 files changed, 215 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7769e46..fc900d2 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -11,6 +11,7 @@ config DRM_I915
  select DRM_KMS_HELPER
  select DRM_PANEL
  select DRM_MIPI_DSI
+select RELAY
  # i915 depends on ACPI_VIDEO when ACPI is enabled
  # but for select to work, need to select ACPI_VIDEO's
dependencies, ick
  select BACKLIGHT_LCD_SUPPORT if ACPI
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 13ae340..cdee60b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1133,6 +1133,7 @@ static void i915_driver_register(struct
drm_i915_private *dev_priv)
  /* Reveal our presence to userspace */
  if (drm_dev_register(dev, 0) == 0) {
  i915_debugfs_register(dev_priv);
+i915_guc_register(dev_priv);
  i915_setup_sysfs(dev);
  } else
  DRM_ERROR("Failed to register driver for userspace access!\n");
@@ -1171,6 +1172,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
  intel_opregion_unregister(dev_priv);

  i915_teardown_sysfs(_priv->drm);
+i915_guc_unregister(dev_priv);
  i915_debugfs_unregister(dev_priv);
  drm_dev_unregister(_priv->drm);

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2b27b87..9b1054c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -23,6 +23,8 @@
   */
  #include 
  #include 
+#include 
+#include 
  #include "i915_drv.h"
  #include "intel_guc.h"

@@ -837,13 +839,159 @@ err:
  return NULL;
  }

+/*
+ * Sub buffer switch callback. Called whenever relay has to switch to
a new
+ * sub buffer, relay stays on the same sub buffer if 0 is returned.
+ */
+static int subbuf_start_callback(struct rchan_buf *buf,
+ void *subbuf,
+ void *prev_subbuf,
+ size_t prev_padding)
+{
+/* Use no-overwrite mode by default, where relay will stop accepting
+ * new data if there are no empty sub buffers left.
+ * There is no strict synchronization enforced by relay between
Consumer
+ * and Producer. In overwrite mode, there is a possibility of
getting
+ * inconsistent/garbled data, the producer could be writing on to
the
+ * same sub buffer from which Consumer is reading. This can't be
avoided
+ * unless Consumer is fast enough and can always run in tandem with
+ * Producer.
+ */
+if (relay_buf_full(buf))
+return 0;
+
+return 1;
+}
+
+/*
+ * file_create() callback. Creates relay file in debugfs.
+ */
+static struct dentry *create_buf_file_callback(const char *filename,
+

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: make drm_get_format_name thread-safe (rev2)

[Patchwork]

== Series Details ==

Series: drm: make drm_get_format_name thread-safe (rev2)
URL   : https://patchwork.freedesktop.org/series/11069/
State : failure

== Summary ==

Applying: drm: remove `const` attribute to hint at caller that they now own the 
memory
fatal: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_display.c).
error: could not build fake ancestor
Patch failed at 0001 drm: remove `const` attribute to hint at caller that they 
now own the memory
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 18/18] drm/i915: Early creation of relay channel for capturing boot time logs

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC firmware
if there are flush interrupts from the GuC side.
Relay has a provision to support early logging where initially only relay
channel can be created, to have buffers for storing logs, and later on
channel can be associated with a debugfs file at appropriate time.
Have availed that, which allows Driver to capture boot time logs also,
which can be collected once Userspace comes up.

v2:
- Remove the couple of FIXMEs, as now the relay channel will be created
   early before enabling the flush interrupts, so no possibility of relay
   channel pointer being modified & read at the same time from 2 different
   execution contexts.
- Rebase.

Suggested-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 66 +-
  1 file changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8733c19..34e4335 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -937,13 +937,39 @@ static void guc_remove_log_relay_file(struct intel_guc 
*guc)
relay_close(guc->log.relay_chan);
  }

-static int guc_create_log_relay_file(struct intel_guc *guc)
+static int guc_create_relay_channel(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
-   struct dentry *log_dir;
size_t n_subbufs, subbuf_size;

+   /* Keep the size of sub buffers same as shared log buffer */
+   subbuf_size = guc->log.vma->obj->base.size;
+
+   /* Store up to 8 snapshots, which is large enough to buffer sufficient
+* boot time logs and provides enough leeway to User, in terms of
+* latency, for consuming the logs from relay. Also doesn't take
+* up too much memory.
+*/
+   n_subbufs = 8;
+
+   guc_log_relay_chan = relay_open(NULL, NULL, subbuf_size,
+   n_subbufs, _callbacks, dev_priv);
+   if (!guc_log_relay_chan) {
+   DRM_ERROR("Couldn't create relay chan for GuC logging\n");
+   return -ENOMEM;
+   }
+
+   guc->log.relay_chan = guc_log_relay_chan;
+   return 0;
+}
+
+static int guc_create_log_relay_file(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct dentry *log_dir;
+   int ret;
+
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
log_dir = dev_priv->drm.primary->debugfs_root;

@@ -963,25 +989,12 @@ static int guc_create_log_relay_file(struct intel_guc 
*guc)
return -ENODEV;
}

-   /* Keep the size of sub buffers same as shared log buffer */
-   subbuf_size = guc->log.vma->obj->base.size;
-
-   /* Store up to 8 snapshots, which is large enough to buffer sufficient
-* boot time logs and provides enough leeway to User, in terms of
-* latency, for consuming the logs from relay. Also doesn't take
-* up too much memory.
-*/
-   n_subbufs = 8;
-
-   guc_log_relay_chan = relay_open("guc_log", log_dir, subbuf_size,
-   n_subbufs, _callbacks, dev_priv);
-   if (!guc_log_relay_chan) {
-   DRM_ERROR("Couldn't create relay chan for GuC logging\n");
-   return -ENOMEM;
+   ret = relay_late_setup_files(guc->log.relay_chan, "guc_log", log_dir);
+   if (ret) {
+   DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
+   return ret;
}

-   /* FIXME: Cover the update under a lock ? */
-   guc->log.relay_chan = guc_log_relay_chan;
return 0;
  }

@@ -1001,7 +1014,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc)

  static void *guc_get_write_buffer(struct intel_guc *guc)
  {
-   /* FIXME: Cover the check under a lock ? */
if (!guc->log.relay_chan)
return NULL;

@@ -1227,6 +1239,16 @@ static int guc_create_log_extras(struct intel_guc *guc)
guc->log.buf_addr = vaddr;
}

+   if (!guc->log.relay_chan) {
+   /* Create a relay channel, so that we have buffers for storing
+* the GuC firmware logs, the channel will be linked with a file
+* later on when debugfs is registered.
+*/
+   ret = guc_create_relay_channel(guc);
+   if (ret)
+   return ret;
+   }
+
if 

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Goel, Akash]

On 8/15/2016 8:50 PM, Tvrtko Ursulin wrote:



On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consumed the
log buffer contents by copying them to a file or buffer.
Even if Host couldn't copy the contents, it can still update the
read pointer so that logging state is not disturbed on GuC side.

v2:
- Use a dedicated workqueue for handling flush interrupt. (Tvrtko)
- Reduce the overall log buffer copying time by skipping the copy of
   crash buffer area for regular cases and copying only the state
   structure data in first page.

v3:
  - Create a vmalloc mapping of log buffer. (Chris)
  - Cover the flush acknowledgment under rpm get & put.(Chris)
  - Revert the change of skipping the copy of crash dump area, as
not really needed, will be covered by subsequent patch.

v4:
  - Destroy the wq under the same condition in which it was created,
pass dev_piv pointer instead of dev to newly added GuC function,
add more comments & rename variable for clarity. (Tvrtko)

v5:
- Allocate & destroy the dedicated wq, for handling flush interrupt,
   from the setup/teardown routines of GuC logging. (Chris)
- Validate the log buffer size value retrieved from state structure
   and do some minor cleanup. (Tvrtko)
- Fix error/warnings reported by checkpatch. (Tvrtko)
- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 202
+
  drivers/gpu/drm/i915/i915_irq.c|  29 -
  drivers/gpu/drm/i915/intel_guc.h   |   4 +
  3 files changed, 234 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b062da6..2b27b87 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -172,6 +172,15 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
  return host2guc_action(guc, data, ARRAY_SIZE(data));
  }

+static int host2guc_logbuffer_flush_complete(struct intel_guc *guc)
+{
+u32 data[1];
+
+data[0] = HOST2GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE;
+
+return host2guc_action(guc, data, 1);
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -828,6 +837,179 @@ err:
  return NULL;
  }

+static void guc_move_to_next_buf(struct intel_guc *guc)
+{
+}
+
+static void *guc_get_write_buffer(struct intel_guc *guc)
+{
+return NULL;
+}
+
+static void guc_read_update_log_buffer(struct intel_guc *guc)
+{
+struct guc_log_buffer_state *log_buffer_state,
*log_buffer_snapshot_state;
+struct guc_log_buffer_state log_buffer_state_local;
+void *src_data_ptr, *dst_data_ptr;
+unsigned int buffer_size, expected_size;
+enum guc_log_buffer_type type;
+
+if (WARN_ON(!guc->log.buf_addr))
+return;
+
+/* Get the pointer to shared GuC log buffer */
+log_buffer_state = src_data_ptr = guc->log.buf_addr;
+
+/* Get the pointer to local buffer to store the logs */
+dst_data_ptr = log_buffer_snapshot_state =
guc_get_write_buffer(guc);
+
+/* Actual logs are present from the 2nd page */
+src_data_ptr += PAGE_SIZE;
+dst_data_ptr += PAGE_SIZE;
+
+for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+/* Make a copy of the state structure in GuC log buffer (which
+ * is uncached mapped) on the stack to avoid reading from it
+ * multiple times.
+ */
+memcpy(_buffer_state_local, log_buffer_state,
+   sizeof(struct guc_log_buffer_state));
+buffer_size = log_buffer_state_local.size;
+
+if (log_buffer_snapshot_state) {
+/* First copy the state structure in snapshot buffer */
+memcpy(log_buffer_snapshot_state, _buffer_state_local,
+   sizeof(struct guc_log_buffer_state));
+
+/* The write pointer could have been updated by the GuC
+ * firmware, after sending the flush interrupt to Host,
+ * for consistency set the write pointer value to same
+ * value of sampled_write_ptr in the snapshot buffer.
+ */
+log_buffer_snapshot_state->write_ptr =
+log_buffer_snapshot_state->sampled_write_ptr;
+
+log_buffer_snapshot_state++;
+
+/* Now copy the actual logs, but before that validate
+ * the buffer size value retrieved from state structure.
+ */
+if (type == GUC_ISR_LOG_BUFFER)
+expected_size = (GUC_LOG_ISR_PAGES+1)*PAGE_SIZE;
+else if (type == GUC_DPC_LOG_BUFFER)
+expected_size = (GUC_LOG_DPC_PAGES+1)*PAGE_SIZE;
+else
+

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

Before capturing the GuC logs as a part of error state, there should be a
force log buffer flush action sent to GuC before proceeding with GPU reset
and re-initializing GUC. There could be some data in the log buffer which
is yet to be captured and those logs would be particularly useful to
understand that why the GPU reset was initiated.

v2:
- Avoid the wait via flush_work, to serialize against an ongoing log
   buffer flush, from the error state capture path. (Chris)


Could you explain if the patch does anything now that the flush has been 
removed?


In fact I don't even understand what it was doing before. :)

If the idea is to send a flush command to GuC so it can raise an 
interrupt for a partially full buffer, then i915_guc_flush_logs should 
send the flush command and wait for that interrupt/work.


But the function is first waiting for the work item to complete and then 
sending the flush command to the GuC. So I am confused.


Regards,

Tvrtko


- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_gpu_error.c  |  2 ++
  drivers/gpu/drm/i915/i915_guc_submission.c | 30 ++
  drivers/gpu/drm/i915/intel_guc.h   |  1 +
  3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 94297aa..b73c671 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1301,6 +1301,8 @@ static void i915_gem_capture_guc_log_buffer(struct 
drm_i915_private *dev_priv,
if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
return;

+   i915_guc_flush_logs(dev_priv, false);
+
error->guc_log = i915_error_object_create(dev_priv,
  dev_priv->guc.log.vma);
  }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b8d6313..85df2f3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,6 +185,16 @@ static int host2guc_logbuffer_flush_complete(struct 
intel_guc *guc)
return host2guc_action(guc, data, 1);
  }

+static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_FORCE_LOG_BUFFER_FLUSH;
+   data[1] = 0;
+
+   return host2guc_action(guc, data, 2);
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -1536,6 +1546,26 @@ void i915_guc_capture_logs(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_put(dev_priv);
  }

+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool can_wait)
+{
+   if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
+   return;
+
+   /* First disable the interrupts, will be renabled afterwards */
+   gen9_disable_guc_interrupts(dev_priv);
+
+   /* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not happen, but wait
+* can't be done for some paths like error state capture in which case
+* take a chance & directly attempt the forceful flush.
+*/
+   if (can_wait)
+   flush_work(_priv->guc.log.flush_work);
+
+   /* Ask GuC to update the log buffer state */
+   host2guc_force_logbuffer_flush(_priv->guc);
+}
+
  void i915_guc_unregister(struct drm_i915_private *dev_priv)
  {
if (!i915.enable_guc_submission)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 8598f38..d7eda42 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -182,6 +182,7 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*rq);
  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
  void i915_guc_capture_logs(struct drm_i915_private *dev_priv);
+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool can_wait);
  void i915_guc_register(struct drm_i915_private *dev_priv);
  void i915_guc_unregister(struct drm_i915_private *dev_priv);



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

Re: [Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Chris Wilson]

On Mon, Aug 15, 2016 at 03:41:23PM +0100, Robert Bragg wrote:
>  int __must_check i915_gem_evict_something(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index bd13d08..b4de357 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -134,6 +134,24 @@ static int get_context_size(struct drm_i915_private 
> *dev_priv)
>   return ret;
>  }
>  
> +int i915_gem_context_pin_legacy_rcs_state(struct drm_i915_private *dev_priv,
> +   struct i915_gem_context *ctx)
> +{
> + int ret;
> +
> + lockdep_assert_held(>i915->drm.struct_mutex);
> +
> + ret = i915_gem_obj_ggtt_pin(ctx->engine[RCS].state,
> + ctx->ggtt_alignment,
> + 0);
> + if (ret)
> + return ret;
> +
> + i915_oa_legacy_context_pin_notify(dev_priv, ctx);
> +
> + return 0;
> +}

I am still not all at all happy with this. I hope the recent changes to
do the vma tracking make it clear.
-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 v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

[Chris Wilson]

Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). This is used to allow poll() to
wait upon outstanding rendering (or just query the current status of
rendering). The dma-buf sync ioctl allows userspace to prepare the
dma-buf for CPU access, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)

v2: Always wait upon the reservation object implicitly. We choose to do
it after the native handler in case it can do so more efficiently.

Testcase: igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: Eric Anholt 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ddaee60ae52a..cf04d249a6a4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
+{
+   bool write = (direction == DMA_BIDIRECTIONAL ||
+ direction == DMA_TO_DEVICE);
+   struct reservation_object *resv = dmabuf->resv;
+   long ret;
+
+   /* Wait on any implicit rendering fences */
+   ret = reservation_object_wait_timeout_rcu(resv, write, true,
+ MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
 
 /**
  * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from 
the
@@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
if (dmabuf->ops->begin_cpu_access)
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
 
+   /* Ensure that all fences are waited upon - but we first allow
+* the native handler the chance to do so more efficiently if it
+* chooses. A double invocation here will be reasonably cheap no-op.
+*/
+   if (ret == 0)
+   ret = __dma_buf_begin_cpu_access(dmabuf, direction);
+
return ret;
 }
 EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

[Chris Wilson]

Apolgies, I changed trees between resending after the first git-send-email
bounced off the wrong address.
-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 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.

v2:
- For uniformity use existing helper function print_error_obj() to
   dump out contents of GuC log buffer, pretty printing is better left
   to userspace. (Chris)
- Skip the dumping of GuC log buffer when logging is disabled as it
   won't be of any use.
- Rebase.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08553b9..de89596 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -734,6 +734,7 @@ struct drm_i915_error_state {
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
struct drm_i915_error_object *semaphore;
+   struct drm_i915_error_object *guc_log;

struct drm_i915_error_engine {
int engine_id;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0c3f30c..94297aa 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -572,6 +572,13 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
}
}

+   obj = error->guc_log;
+   if (obj) {
+   err_printf(m, "GuC log buffer = 0x%08x\n",
+  lower_32_bits(obj->gtt_offset));
+   print_error_obj(m, obj);
+   }
+
if (error->overlay)
intel_overlay_print_error_state(m, error->overlay);

@@ -651,6 +658,7 @@ static void i915_error_state_free(struct kref *error_ref)
}

i915_error_object_free(error->semaphore);
+   i915_error_object_free(error->guc_log);

for (i = 0; i < ARRAY_SIZE(error->active_bo); i++)
kfree(error->active_bo[i]);
@@ -1286,6 +1294,17 @@ static void i915_capture_pinned_buffers(struct 
drm_i915_private *dev_priv,
error->pinned_bo = bo;
  }

+static void i915_gem_capture_guc_log_buffer(struct drm_i915_private *dev_priv,
+   struct drm_i915_error_state *error)
+{
+   /* Capturing log buf contents won't be useful if logging was disabled */
+   if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
+   return;
+
+   error->guc_log = i915_error_object_create(dev_priv,
+ dev_priv->guc.log.vma);
+}
+
  /* Capture all registers which don't fit into another category. */
  static void i915_capture_reg_state(struct drm_i915_private *dev_priv,
   struct drm_i915_error_state *error)
@@ -1437,6 +1456,7 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
i915_gem_record_rings(dev_priv, error);
i915_capture_active_buffers(dev_priv, error);
i915_capture_pinned_buffers(dev_priv, error);
+   i915_gem_capture_guc_log_buffer(dev_priv, error);

do_gettimeofday(>time);




Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

[Chris Wilson]

Cherryview uses a custom static definition of its RPS parameters (for
automatically driving GPU frequency selection) - yet still couples into
the waitboosting scheme of the common RPS setup.

The rationale given in commit 8fb55197e64d ("drm/i915: Agressive
downclocking on Baytrail") was that Cherryview might have to take the
common powerwell (unlike Baytrail it has multiple powerwells) to read the
RPS registers more often. However, we have reports that the current values
are not working well for kodi (the frequency stays too low). Lets use the
common values and see if we can tune them appropriately to benefit
everyone.

Signed-off-by: Chris Wilson 
Cc: frit...@kodi.tv
Cc: Deepak S 
Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 20794804f3bb..a140fe075e1b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4837,8 +4837,7 @@ static void valleyview_set_rps(struct drm_i915_private 
*dev_priv, u8 val)
 
if (val != dev_priv->rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
-   if (!IS_CHERRYVIEW(dev_priv))
-   gen6_set_rps_thresholds(dev_priv, val);
+   gen6_set_rps_thresholds(dev_priv, val);
}
 
dev_priv->rps.cur_freq = val;
-- 
2.8.1

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

[Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

[Chris Wilson]

Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). This is used to allow poll() to
wait upon outstanding rendering (or just query the current status of
rendering). The dma-buf sync ioctl allows userspace to prepare the
dma-buf for CPU access, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)

v2: Always wait upon the reservation object implicitly. We choose to do
it after the native handler in case it can do so more efficiently.

Testcase: igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: Eric Anholt 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ddaee60ae52a..cf04d249a6a4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
+{
+   bool write = (direction == DMA_BIDIRECTIONAL ||
+ direction == DMA_TO_DEVICE);
+   struct reservation_object *resv = dmabuf->resv;
+   long ret;
+
+   /* Wait on any implicit rendering fences */
+   ret = reservation_object_wait_timeout_rcu(resv, write, true,
+ MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
 
 /**
  * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from 
the
@@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
if (dmabuf->ops->begin_cpu_access)
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
 
+   /* Ensure that all fences are waited upon - but we first allow
+* the native handler the chance to do so more efficiently if it
+* chooses. A double invocation here will be reasonably cheap no-op.
+*/
+   if (ret == 0)
+   ret = __dma_buf_begin_cpu_access(dmabuf, direction);
+
return ret;
 }
 EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written data by GuC into the local
buffer, i.e. as per the read & write pointer values.
Moreover the flush interrupt would generally come for one type of log
buffer, when it becomes half full, so at that time the other 2 types of
log buffer would comparatively have much lesser unread data in them.
In case of overflow reported by GuC, Driver do need to copy the entire
buffer as the whole buffer would contain the unread data.

v2: Rebase.

v3: Fix the blooper of doing the copy twice. (Tvrtko)

Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 40 +-
  1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c7b4a57..b8d6313 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1003,6 +1003,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
void *src_data_ptr, *dst_data_ptr;
unsigned int buffer_size, expected_size;
enum guc_log_buffer_type type;
+   unsigned int read_offset, write_offset, bytes_to_copy;
+   bool new_overflow;

if (WARN_ON(!guc->log.buf_addr))
return;
@@ -1025,11 +1027,14 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
memcpy(_buffer_state_local, log_buffer_state,
   sizeof(struct guc_log_buffer_state));
buffer_size = log_buffer_state_local.size;
+   read_offset = log_buffer_state_local.read_ptr;
+   write_offset = log_buffer_state_local.sampled_write_ptr;

/* Bookkeeping stuff */
guc->log.flush_count[type] += 
log_buffer_state_local.flush_to_file;
if (log_buffer_state_local.buffer_full_cnt !=
guc->log.prev_overflow_count[type]) {
+   new_overflow = 1;
guc->log.total_overflow_count[type] +=
(log_buffer_state_local.buffer_full_cnt -
 guc->log.prev_overflow_count[type]);
@@ -1043,7 +1048,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
guc->log.prev_overflow_count[type] =
log_buffer_state_local.buffer_full_cnt;
DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
-   }
+   } else
+   new_overflow = 0;


Nitpick: normally the rule is if one branch has curlies all of them have 
to. Checkpatch I think warns about that, or maybe only in strict mode.




if (log_buffer_snapshot_state) {
/* First copy the state structure in snapshot buffer */
@@ -1055,8 +1061,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 * for consistency set the write pointer value to same
 * value of sampled_write_ptr in the snapshot buffer.
 */
-   log_buffer_snapshot_state->write_ptr =
-   log_buffer_snapshot_state->sampled_write_ptr;
+   log_buffer_snapshot_state->write_ptr = write_offset;

log_buffer_snapshot_state++;

@@ -1079,7 +1084,31 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
buffer_size = expected_size;
}

-   memcpy(dst_data_ptr, src_data_ptr, buffer_size);
+   if (unlikely(new_overflow)) {
+   /* copy the whole buffer in case of overflow */
+   read_offset = 0;
+   write_offset = buffer_size;
+   } else if (unlikely((read_offset > buffer_size) ||
+   (write_offset > buffer_size))) {


Could also check for read_offset == write_offset for even more safety?


+   DRM_ERROR("invalid log buffer state\n");
+   /* copy whole buffer as offsets are unreliable 
*/
+   read_offset = 0;
+   write_offset = buffer_size;
+   }
+
+   /* Just copy the newly written data */
+   if (read_offset <= write_offset) {
+   bytes_to_copy = write_offset - read_offset;
+   memcpy(dst_data_ptr + read_offset,
+  src_data_ptr + 

[Intel-gfx] [FIXUP] drm: remove `const` attribute to hint at caller that they now own the memory

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   | 2 +-
 drivers/gpu/drm/drm_atomic.c| 2 +-
 drivers/gpu/drm/drm_crtc.c  | 8 
 drivers/gpu/drm/drm_fourcc.c| 4 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c   | 2 +-
 drivers/gpu/drm/i915/intel_display.c| 4 ++--
 drivers/gpu/drm/radeon/atombios_crtc.c  | 4 ++--
 include/drm/drm_fourcc.h| 2 +-
 12 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 0bf8959..741da36 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2071,7 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   const char *format_name;
+   char *format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 1558a97..2282eb6 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2046,7 +2046,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   const char *format_name;
+   char *format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 71a0375..8b7ad34 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1952,7 +1952,7 @@ static int dce_v8_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   const char *format_name;
+   char *format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 087391f..5cb2e22 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -837,7 +837,7 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
/* Check whether this plane supports the fb pixel format. */
ret = drm_plane_check_pixel_format(plane, state->fb->pixel_format);
if (ret) {
-   const char *format_name = 
drm_get_format_name(state->fb->pixel_format);
+   char *format_name = 
drm_get_format_name(state->fb->pixel_format);
DRM_DEBUG_ATOMIC("Invalid pixel format %s\n", format_name);
kfree(format_name);
return ret;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7da5d33..30ab28b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2592,7 +2592,7 @@ static int __setplane_internal(struct drm_plane *plane,
/* Check whether this plane supports the fb pixel format. */
ret = drm_plane_check_pixel_format(plane, fb->pixel_format);
if (ret) {
-   const char *format_name = drm_get_format_name(fb->pixel_format);
+   char *format_name = drm_get_format_name(fb->pixel_format);
DRM_DEBUG_KMS("Invalid pixel format %s\n", format_name);
kfree(format_name);
goto out;
@@ -2903,7 +2903,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
ret = drm_plane_check_pixel_format(crtc->primary,
   fb->pixel_format);
if (ret) {
-   const char *format_name = 
drm_get_format_name(fb->pixel_format);
+   char *format_name = 
drm_get_format_name(fb->pixel_format);
DRM_DEBUG_KMS("Invalid pixel format %s\n", 
format_name);
kfree(format_name);
goto out;
@@ -3281,7 +3281,7 @@ int drm_mode_addfb(struct drm_device *dev,
 static int format_check(const struct drm_mode_fb_cmd2 *r)
 {
uint32_t format = r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN;
-   const char *format_name;
+   char *format_name;
 
switch (format) {
case DRM_FORMAT_C8:
@@ -3359,7 +3359,7 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
 
ret = format_check(r);
if (ret) {
-   const char *format_name = drm_get_format_name(r->pixel_format);
+   char *format_name = 

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Akash Goel 

Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the GuC log buffer in the buffer managed by relay.
The snapshot will be taken when GuC firmware sends a log buffer flush
interrupt and up to four snapshots could be stored in the relay buffer.
The relay buffer will be operated in a mode where it will overwrite the
data not yet collected by User.
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the 'poll'
call on log file, User can come to know whenever a new snapshot of the
log buffer is taken by Driver, so can run in tandem with the Driver and
capture the logs in a sustained/streaming manner, without any loss of data.

v2: Defer the creation of relay channel & associated debugfs file, as
 debugfs setup is now done at the end of i915 Driver load. (Chris)

v3:
- Switch to no-overwrite mode for relay.
- Fix the relay sub buffer switching sequence.

v4:
- Update i915 Kconfig to select RELAY config. (TvrtKo)
- Log a message when there is no sub buffer available to capture
   the GuC log buffer. (Tvrtko)
- Increase the number of relay sub buffers to 8 from 4, to have
   sufficient buffering for boot time logs

v5:
- Fix the alignment, indentation issues and some minor cleanup. (Tvrtko)
- Update the comment to elaborate on why a relay channel has to be
   associated with the debugfs file. (Tvrtko)

Suggested-by: Chris Wilson 
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/Kconfig   |   1 +
  drivers/gpu/drm/i915/i915_drv.c|   2 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 211 -
  drivers/gpu/drm/i915/intel_guc.h   |   3 +
  4 files changed, 215 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7769e46..fc900d2 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -11,6 +11,7 @@ config DRM_I915
select DRM_KMS_HELPER
select DRM_PANEL
select DRM_MIPI_DSI
+   select RELAY
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_LCD_SUPPORT if ACPI
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 13ae340..cdee60b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1133,6 +1133,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
+   i915_guc_register(dev_priv);
i915_setup_sysfs(dev);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
@@ -1171,6 +1172,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);

i915_teardown_sysfs(_priv->drm);
+   i915_guc_unregister(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2b27b87..9b1054c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -23,6 +23,8 @@
   */
  #include 
  #include 
+#include 
+#include 
  #include "i915_drv.h"
  #include "intel_guc.h"

@@ -837,13 +839,159 @@ err:
return NULL;
  }

+/*
+ * Sub buffer switch callback. Called whenever relay has to switch to a new
+ * sub buffer, relay stays on the same sub buffer if 0 is returned.
+ */
+static int subbuf_start_callback(struct rchan_buf *buf,
+void *subbuf,
+void *prev_subbuf,
+size_t prev_padding)
+{
+   /* Use no-overwrite mode by default, where relay will stop accepting
+* new data if there are no empty sub buffers left.
+* There is no strict synchronization enforced by relay between Consumer
+* and Producer. In overwrite mode, there is a possibility of getting
+* inconsistent/garbled data, the producer could be writing on to the
+* same sub buffer from which Consumer is reading. This can't be avoided
+* unless Consumer is fast enough and can always run in tandem with
+* Producer.
+*/
+   if (relay_buf_full(buf))
+   return 0;
+
+   return 1;
+}
+
+/*
+ * file_create() callback. Creates relay file in debugfs.

Re: [Intel-gfx] [PATCH 02/10] drm/i915/userptr: Make gup errors stickier

[Chris Wilson]

On Mon, Aug 15, 2016 at 06:08:21PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > +   if (obj->userptr.work) {
> > /* active flag should still be held for the pending work */
> > -   return -EAGAIN;
> > +   if (IS_ERR(obj->userptr.work))
> > +   return PTR_ERR(obj->userptr.work);
> 
> Previously you did set the work to null before returning error,
> now you dont.
> 
> Is it the responsibility of cancel_userptr now, through mm notifier,
> that clears the pointer?

Yes. 

> > Keep any error reported by the gup_worker until we are notified that the
> > arena has changed (via the mmu-notifier). This has the importance of
> > making two consecutive calls to i915_gem_object_get_pages() reporting
> > the same error, and curtailing a loop of detecting a fault and requeueing
> > a gup_worker.

-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] linux-firmware-i915 pull request (restore skl dmc 1.23)

[Kyle McMartin]

On Thu, Aug 11, 2016 at 06:22:56PM +, Vivi, Rodrigo wrote:
> The following changes since commit
> c170c8d95794d6aedbaeea44674daaa96baf04f7:
> 
>   linux-firmware: intel: Update Skylake audio firmware (2016-08-04
> 16:09:21 +0530)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
> 
> for you to fetch changes up to
> 3d1020bb4006e21c4eeca368044f16c9c206394e:
> 
>   linux-firmware/i915: Restore DMC 1.23 (2016-08-11 11:16:09 -0700)
> 

applied, thanks rodrigo!

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

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consumed the
log buffer contents by copying them to a file or buffer.
Even if Host couldn't copy the contents, it can still update the
read pointer so that logging state is not disturbed on GuC side.

v2:
- Use a dedicated workqueue for handling flush interrupt. (Tvrtko)
- Reduce the overall log buffer copying time by skipping the copy of
   crash buffer area for regular cases and copying only the state
   structure data in first page.

v3:
  - Create a vmalloc mapping of log buffer. (Chris)
  - Cover the flush acknowledgment under rpm get & put.(Chris)
  - Revert the change of skipping the copy of crash dump area, as
not really needed, will be covered by subsequent patch.

v4:
  - Destroy the wq under the same condition in which it was created,
pass dev_piv pointer instead of dev to newly added GuC function,
add more comments & rename variable for clarity. (Tvrtko)

v5:
- Allocate & destroy the dedicated wq, for handling flush interrupt,
   from the setup/teardown routines of GuC logging. (Chris)
- Validate the log buffer size value retrieved from state structure
   and do some minor cleanup. (Tvrtko)
- Fix error/warnings reported by checkpatch. (Tvrtko)
- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 202 +
  drivers/gpu/drm/i915/i915_irq.c|  29 -
  drivers/gpu/drm/i915/intel_guc.h   |   4 +
  3 files changed, 234 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b062da6..2b27b87 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -172,6 +172,15 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
return host2guc_action(guc, data, ARRAY_SIZE(data));
  }

+static int host2guc_logbuffer_flush_complete(struct intel_guc *guc)
+{
+   u32 data[1];
+
+   data[0] = HOST2GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE;
+
+   return host2guc_action(guc, data, 1);
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -828,6 +837,179 @@ err:
return NULL;
  }

+static void guc_move_to_next_buf(struct intel_guc *guc)
+{
+}
+
+static void *guc_get_write_buffer(struct intel_guc *guc)
+{
+   return NULL;
+}
+
+static void guc_read_update_log_buffer(struct intel_guc *guc)
+{
+   struct guc_log_buffer_state *log_buffer_state, 
*log_buffer_snapshot_state;
+   struct guc_log_buffer_state log_buffer_state_local;
+   void *src_data_ptr, *dst_data_ptr;
+   unsigned int buffer_size, expected_size;
+   enum guc_log_buffer_type type;
+
+   if (WARN_ON(!guc->log.buf_addr))
+   return;
+
+   /* Get the pointer to shared GuC log buffer */
+   log_buffer_state = src_data_ptr = guc->log.buf_addr;
+
+   /* Get the pointer to local buffer to store the logs */
+   dst_data_ptr = log_buffer_snapshot_state = guc_get_write_buffer(guc);
+
+   /* Actual logs are present from the 2nd page */
+   src_data_ptr += PAGE_SIZE;
+   dst_data_ptr += PAGE_SIZE;
+
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   /* Make a copy of the state structure in GuC log buffer (which
+* is uncached mapped) on the stack to avoid reading from it
+* multiple times.
+*/
+   memcpy(_buffer_state_local, log_buffer_state,
+  sizeof(struct guc_log_buffer_state));
+   buffer_size = log_buffer_state_local.size;
+
+   if (log_buffer_snapshot_state) {
+   /* First copy the state structure in snapshot buffer */
+   memcpy(log_buffer_snapshot_state, 
_buffer_state_local,
+  sizeof(struct guc_log_buffer_state));
+
+   /* The write pointer could have been updated by the GuC
+* firmware, after sending the flush interrupt to Host,
+* for consistency set the write pointer value to same
+* value of sampled_write_ptr in the snapshot buffer.
+*/
+   log_buffer_snapshot_state->write_ptr =
+   log_buffer_snapshot_state->sampled_write_ptr;
+
+   log_buffer_snapshot_state++;
+
+   /* Now copy the actual logs, but before that validate
+* the buffer size value retrieved from state structure.
+*/
+  

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable Gen 7 Observation Architecture (rev5)

[Patchwork]

== Series Details ==

Series: Enable Gen 7 Observation Architecture (rev5)
URL   : https://patchwork.freedesktop.org/series/3024/
State : failure

== Summary ==

Applying: drm/i915: Add i915 perf infrastructure
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/Makefile
M   drivers/gpu/drm/i915/i915_drv.c
M   drivers/gpu/drm/i915/i915_drv.h
M   include/uapi/drm/i915_drm.h
Falling back to patching base and 3-way merge...
Auto-merging include/uapi/drm/i915_drm.h
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/i915_drv.c
Auto-merging drivers/gpu/drm/i915/Makefile
Applying: drm/i915: rename OACONTROL GEN7_OACONTROL
Applying: drm/i915: return EACCES for check_cmd() failures
Applying: drm/i915: don't whitelist oacontrol in cmd parser
Applying: drm/i915: Add 'render basic' Haswell OA unit config
Applying: drm/i915: Enable i915 perf stream for Haswell OA unit
fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h).
error: could not build fake ancestor
Patch failed at 0006 drm/i915: Enable i915 perf stream for Haswell OA unit
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev7)

[Patchwork]

== Series Details ==

Series: Support for sustained capturing of GuC firmware logs (rev7)
URL   : https://patchwork.freedesktop.org/series/7910/
State : failure

== Summary ==

Series 7910v7 Support for sustained capturing of GuC firmware logs
http://patchwork.freedesktop.org/api/1.0/series/7910/revisions/7/mbox

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
fail   -> PASS   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-byt-n2820)
fail   -> PASS   (ro-skl3-i5-6260u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-skl3-i5-6260u)
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_frontbuffer_tracking:
Subgroup basic:
dmesg-fail -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-kbl-qkkr  total:244  pass:186  dwarn:28  dfail:0   fail:3   skip:27 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:1   dfail:0   fail:2   skip:19 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1875/

79cf2f7 drm-intel-nightly: 2016y-08m-15d-13h-03m-14s UTC integration manifest
7f98724 drm/i915: Early creation of relay channel for capturing boot time logs
8531932 drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer
c89cb9e drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer
a820b63 drm/i915: Debugfs support for GuC logging control
874baf2 drm/i915: Forcefully flush GuC log buffer on reset
a3e5be5 drm/i915: Augment i915 error state to include the dump of GuC log buffer
d7d7036 drm/i915: Increase GuC log buffer size to reduce flush interrupts
8e48f14 drm/i915: Optimization to reduce the sampling time of GuC log buffer
80942ea drm/i915: Add stats for GuC log buffer flush interrupts
15db660 drm/i915: New lock to serialize the Host2GuC actions
9eaaa9d drm/i915: Add a relay backed debugfs interface for capturing GuC logs
2ce90fa relay: Use per CPU constructs for the relay channel buffer pointers
9e59754 drm/i915: Handle log buffer flush interrupt event from GuC
59f2ccf drm/i915: Support for GuC interrupts
6ee78e9 drm/i915: Add low level set of routines for programming PM IER/IIR/IMR 
register set
9e7c147 drm/i915: New structure to contain GuC logging related fields
b981ce9 drm/i915: Add GuC ukernel logging related fields to fw interface file
4054de6 drm/i915: Decouple GuC log setup from verbosity parameter

___
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/userptr: Make gup errors stickier

[Mika Kuoppala]

Chris Wilson  writes:

> Keep any error reported by the gup_worker until we are notified that the
> arena has changed (via the mmu-notifier). This has the importance of
> making two consecutive calls to i915_gem_object_get_pages() reporting
> the same error, and curtailing an loop of detecting a fault and requeueing
> a gup_worker.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 57218cca7e05..be54825ef3e8 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -542,8 +542,6 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
> *_work)
>   }
>   }
>   obj->userptr.work = ERR_PTR(ret);
> - if (ret)
> - __i915_gem_userptr_set_active(obj, false);
>   }
>  
>   obj->userptr.workers--;
> @@ -628,15 +626,14 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object 
> *obj)
>* to the vma (discard or cloning) which should prevent the more
>* egregious cases from causing harm.
>*/
> - if (IS_ERR(obj->userptr.work)) {
> - /* active flag will have been dropped already by the worker */
> - ret = PTR_ERR(obj->userptr.work);
> - obj->userptr.work = NULL;
> - return ret;
> - }
> - if (obj->userptr.work)
> +
> + if (obj->userptr.work) {
>   /* active flag should still be held for the pending work */
> - return -EAGAIN;
> + if (IS_ERR(obj->userptr.work))
> + return PTR_ERR(obj->userptr.work);

Previously you did set the work to null before returning error,
now you dont.

Is it the responsibility of cancel_userptr now, through mm notifier,
that clears the pointer?

-Mika


> + else
> + return -EAGAIN;
> + }
>  
>   /* Let the mmu-notifier know that we have begun and need cancellation */
>   ret = __i915_gem_userptr_set_active(obj, true);
> -- 
> 2.8.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

[Eric Engestrom]

On Mon, Aug 15, 2016 at 03:52:07PM +0200, Daniel Vetter wrote:
> On Mon, Aug 15, 2016 at 04:13:54PM +0300, Jani Nikula wrote:
> > On Mon, 15 Aug 2016, Eric Engestrom  wrote:
> > > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote:
> > >> On Mon, 15 Aug 2016, Eric Engestrom  wrote:
> > >> > Signed-off-by: Eric Engestrom 
> > >> > ---
> > >> >
> > >> > I moved the main bits to be the first diffs, shouldn't affect anything
> > >> > when applying the patch, but I wanted to ask:
> > >> > I don't like the hard-coded `32` the appears in both kmalloc() and
> > >> > snprintf(), what do you think? If you don't like it either, what would
> > >> > you suggest? Should I #define it?
> > >> >
> > >> > Second question is about the patch mail itself: should I send this kind
> > >> > of patch separated by module, with a note requesting them to be 
> > >> > squashed
> > >> > when applying? It has to land as a single patch, but for review it 
> > >> > might
> > >> > be easier if people only see the bits they each care about, as well as
> > >> > to collect ack's/r-b's.
> > >> >
> > >> > Cheers,
> > >> >   Eric
> > >> >
> > >> > ---
> > >> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 ++--
> > >> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 ++--
> > >> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 ++--
> > >> >  drivers/gpu/drm/drm_atomic.c|  5 ++--
> > >> >  drivers/gpu/drm/drm_crtc.c  | 21 -
> > >> >  drivers/gpu/drm/drm_fourcc.c| 17 ++-
> > >> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  6 ++--
> > >> >  drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
> > >> >  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 ++--
> > >> >  drivers/gpu/drm/i915/intel_display.c| 39 
> > >> > -
> > >> >  drivers/gpu/drm/radeon/atombios_crtc.c  | 12 +---
> > >> >  include/drm/drm_fourcc.h|  2 +-
> > >> >  12 files changed, 89 insertions(+), 48 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/drm_fourcc.c 
> > >> > b/drivers/gpu/drm/drm_fourcc.c
> > >> > index 0645c85..38216a1 100644
> > >> > --- a/drivers/gpu/drm/drm_fourcc.c
> > >> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > >> > @@ -39,16 +39,14 @@ static char printable_char(int c)
> > >> >   * drm_get_format_name - return a string for drm fourcc format
> > >> >   * @format: format to compute name of
> > >> >   *
> > >> > - * Note that the buffer used by this function is globally shared and 
> > >> > owned by
> > >> > - * the function itself.
> > >> > - *
> > >> > - * FIXME: This isn't really multithreading safe.
> > >> > + * Note that the buffer returned by this function is owned by the 
> > >> > caller
> > >> > + * and will need to be freed.
> > >> >   */
> > >> >  const char *drm_get_format_name(uint32_t format)
> > >> 
> > >> I find it surprising that a function that allocates a buffer returns a
> > >> const pointer. Some userspace libraries have conventions about the
> > >> ownership based on constness.
> > >> 
> > >> (I also find it suprising that kfree() takes a const pointer; arguably
> > >> that call changes the memory.)
> > >> 
> > >> Is there precedent for this?
> > >> 
> > >> BR,
> > >> Jani.
> > >
> > > It's not a const pointer, it's a normal pointer to a const char, i.e.
> > > you can do as you want with the pointer but you shouldn't change the
> > > chars it points to.
> > 
> > Ermh, that's what I meant even if I was sloppy in my reply. And arguably
> > freeing the bytes the pointer points at changes them, albeit subtly. And
> > having a function return a pointer to const data is often an indication
> > that the ownership of the data isn't transfered, i.e. you're not
> > supposed to free it yourself.
> 
> I already applied the patch, but yes dropping the const would be a good
> hint to callers that they now own that block of memory. Eric, can you pls
> follow up with a fix up patch - drm-misc is non-rebasing?
> -Daniel

I didn't know about that convention. I'll send a fixup patch, but it'll
have to wait until tomorrow night. I hope that's not an issue :(

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

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

[Chris Wilson]

On Mon, Aug 15, 2016 at 03:41:20PM +0100, Robert Bragg wrote:
> check_cmd() is checking whether a command adheres to certain
> restrictions that ensure it's safe to execute within a privileged batch
> buffer. Returning false implies a privilege problem, not that the
> command is invalid.
> 
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.

Ah, but you choose to actually execute it instead. We can't allow that
either.
-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 01/11] drm/i915: Add i915 perf infrastructure

[Chris Wilson]

On Mon, Aug 15, 2016 at 03:41:18PM +0100, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
> 
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls including read() to read typed and sized
> records; ioctl() to enable or disable capture and poll() to wait for
> data.
> 
> A stream is opened something like:
> 
>   uint64_t properties[] = {
>   /* Single context sampling */
>   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> 
>   /* Include OA reports in samples */
>   DRM_I915_PERF_PROP_SAMPLE_OA, true,
> 
>   /* OA unit configuration */
>   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
>   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
>   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
>};
>struct drm_i915_perf_open_param parm = {
>   .flags = I915_PERF_FLAG_FD_CLOEXEC |
>I915_PERF_FLAG_FD_NONBLOCK |
>I915_PERF_FLAG_DISABLED,
>   .properties_ptr = (uint64_t)properties,
>   .num_properties = sizeof(properties) / 16,
>};
>int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
> 
> Records read all start with a common { type, size } header with
> DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> contain an extensible number of fields and it's the
> DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> determine what's included in every sample.
> 
> No specific streams are supported yet so any attempt to open a stream
> will return an error.
> 
> Signed-off-by: Robert Bragg 
> ---
>  drivers/gpu/drm/i915/Makefile|   3 +
>  drivers/gpu/drm/i915/i915_drv.c  |   6 +
>  drivers/gpu/drm/i915/i915_drv.h  |  92 +
>  drivers/gpu/drm/i915/i915_perf.c | 430 
> +++
>  include/uapi/drm/i915_drm.h  |  67 ++
>  5 files changed, 598 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_perf.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6092f0e..9a2f1f9 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -106,6 +106,9 @@ i915-y += dvo_ch7017.o \
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> +# perf code
> +i915-y += i915_perf.o
> +
>  ifeq ($(CONFIG_DRM_I915_GVT),y)
>  i915-y += intel_gvt.o
>  include $(src)/gvt/Makefile
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 83afdd0..f5209ff 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1169,6 +1169,9 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>* cannot run before the connectors are registered.
>*/
>   intel_fbdev_initial_config_async(dev);
> +
> + /* Depends on sysfs having been initialized */
> + i915_perf_init(dev_priv);

Then please call it i915_perf_register() and i915_perf_unregister()
respectively.

> + struct {
> + bool initialized;

This is bogus. We simply cannot allow userspace to access internals
before we set them up. As it stands you have no serialisation here, so
the protect is moot.

i915_perf_init() needs to be split up into the early initialisation
function to setup internals, and the i915_perf_register() function to
enable userspace (with however many steps you need in between).

> + struct list_head streams;
> + } perf;
> +
>   /* Abstract the submission mechanism (legacy ringbuffer or execlists) 
> away */
>   struct {
>   int (*execbuf_submit)(struct i915_execbuffer_params *params,
> @@ -3421,6 +3506,9 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
> *dev, void *data,
>  int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file);
>  
> +int i915_perf_open_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file);
> +
>  /* i915_gem_evict.c */
>  int __must_check i915_gem_evict_something(struct drm_device *dev,
> struct i915_address_space *vm,
> @@ -3540,6 +3628,10 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
> *engine,
>   u32 batch_len,
>   bool is_master);
>  
> +/* i915_perf.c */
> +extern void i915_perf_init(struct drm_i915_private *dev_priv);
> +extern void i915_perf_fini(struct drm_i915_private *dev_priv);
> +
>  /* i915_suspend.c */
>  extern int i915_save_state(struct drm_device *dev);
>  extern int i915_restore_state(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> new file mode 100644
> index 000..d0ed645
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -0,0 +1,430 @@
> +/*

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

[Tvrtko Ursulin]

On 15/08/16 15:49, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

There are certain types of interrupts which Host can receive from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to receive interrupts from GuC but currently
enables & partially handles only the interrupt sent by GuC ukernel.
Future patches will add support for handling other interrupt types.

v2:
- Use common low level routines for PM IER/IIR programming (Chris)
- Rename interrupt functions to gen9_xxx from gen8_xxx (Chris)
- Replace disabling of wake ref asserts with rpm get/put (Chris)

v3:
- Update comments for more clarity. (Tvrtko)
- Remove the masking of GuC interrupt, which was kept masked till the
   start of bottom half, its not really needed as there is only a
   single instance of work item & wq is ordered. (Tvrtko)

v4:
- Rebase.
- Rename guc_events to pm_guc_events so as to be indicative of the
   register/control block it is associated with. (Chris)
- Add handling for back to back log buffer flush interrupts.

v5:
- Move the read & clearing of register, containing Guc2Host message
   bits, outside the irq spinlock. (Tvrtko)

v6:
- Move the log buffer flush interrupt related stuff to the following
   patch so as to do only generic bits in this patch. (Tvrtko)
- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.h|  1 +
  drivers/gpu/drm/i915/i915_guc_submission.c |  5 +++
  drivers/gpu/drm/i915/i915_irq.c| 63 --
  drivers/gpu/drm/i915/i915_reg.h| 11 ++
  drivers/gpu/drm/i915/intel_drv.h   |  3 ++
  drivers/gpu/drm/i915/intel_guc.h   |  3 ++
  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++
  7 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a187ea7..08553b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1783,6 +1783,7 @@ struct drm_i915_private {
u32 pm_imr;
u32 pm_ier;
u32 pm_rps_events;
+   u32 pm_guc_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];

struct i915_hotplug hotplug;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 34fb893..b062da6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1055,6 +1055,8 @@ int intel_guc_suspend(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;

+   gen9_disable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;

data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
@@ -1081,6 +1083,9 @@ int intel_guc_resume(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;

+   if (i915.guc_log_level >= 0)
+   gen9_enable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;

data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 83d708a..eb4774f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -170,6 +170,7 @@ static void gen5_assert_iir_is_zero(struct drm_i915_private 
*dev_priv,
  } while (0)

  static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);

  /* For display hotplug interrupt */
  static inline void
@@ -411,6 +412,38 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
gen6_reset_rps_interrupts(dev_priv);
  }

+void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   if (!dev_priv->guc.interrupts_enabled) {
+   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+  dev_priv->pm_guc_events);
+   dev_priv->guc.interrupts_enabled = true;
+   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+   }
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->guc.interrupts_enabled = false;
+
+   gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+
+   spin_unlock_irq(_priv->irq_lock);
+   synchronize_irq(dev_priv->drm.irq);
+
+   gen9_reset_guc_interrupts(dev_priv);
+}
+
  /**
   * 

[Intel-gfx] Current drm-intel-next status on broadwell platform

[Lukas Hejtmanek]

Hello,

I tested drm-intel-next published Aug 9th 2016. I'm facing two major bugs:

1) hard lockups with fbc enabled (neverending story it seems to be)
2) screen tearing in browsers and video players (I do not use any kind of
compositor)

Should I fire a bug report?

both of these two were OK in drm-intel-next published on May 23rd 2016 but in
that release, color calibration via LUTs (xcalib) was completely broken. 

-- 
Lukáš Hejtmánek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 05/11] drm/i915: Add 'render basic' Haswell OA unit config

[Robert Bragg]

Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:

  https://github.com/rib/gputop
  > gputop-data/oa-*.xml
  > scripts/i915-perf-kernelgen.py

  $ make -C gputop-data -f Makefile.xml SYSFS=0 WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 132 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9a2f1f9..0eb4c83 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,7 +107,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o
 
 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b801d9..95222f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1724,6 +1724,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_reg {
+   i915_reg_t addr;
+   u32 value;
+};
+
 struct i915_perf_read_state {
int count;
ssize_t read;
@@ -2097,6 +2102,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;
 
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..3e6006ec
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,132 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253a4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691c), 0x0800 },
+   { _MMIO(0x26aa0), 0x0150 },
+   { _MMIO(0x26b9c), 0x6000 },
+   { _MMIO(0x2791c), 0x0800 },
+   { _MMIO(0x27aa0), 0x0150 },
+   { _MMIO(0x27b9c), 0x6000 },
+   { _MMIO(0x2641c), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540c), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5c30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 

[Intel-gfx] [PATCH v3 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

[Robert Bragg]

Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 46 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5c7b70..a49801f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2115,6 +2115,7 @@ struct drm_i915_private {
bool initialized;
 
struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;
 
struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a943664..c9e7104 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -62,6 +62,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
 
+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1121,7 +1123,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}
 
-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1325,6 +1333,38 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
return ret;
 }
 
+
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = _perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_i915_private *dev_priv)
 {
if (!IS_HASWELL(dev_priv))
@@ -1369,6 +1409,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
return;
}
 
+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;
 
return;
@@ -1379,6 +1421,8 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
return;
 
+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
i915_perf_deinit_sysfs_hsw(dev_priv);
 
kobject_put(dev_priv->perf.metrics_kobj);
-- 
2.9.2

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use common RPS scheme for Cherryview

[Patchwork]

== Series Details ==

Series: drm/i915: Use common RPS scheme for Cherryview
URL   : https://patchwork.freedesktop.org/series/0/
State : failure

== Summary ==

Series 0v1 drm/i915: Use common RPS scheme for Cherryview
http://patchwork.freedesktop.org/api/1.0/series/0/revisions/1/mbox

Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-byt-n2820)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-skl3-i5-6260u)
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_frontbuffer_tracking:
Subgroup basic:
dmesg-fail -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

fi-kbl-qkkr  total:244  pass:187  dwarn:28  dfail:0   fail:3   skip:26 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:2   dfail:0   fail:2   skip:18 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1874/

79cf2f7 drm-intel-nightly: 2016y-08m-15d-13h-03m-14s UTC integration manifest
0df7949 drm/i915: Use common RPS scheme for Cherryview

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

[Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  68 ++-
 drivers/gpu/drm/i915/i915_gem_context.c |  22 +-
 drivers/gpu/drm/i915/i915_perf.c| 977 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |   7 +-
 include/uapi/drm/i915_drm.h |  70 ++-
 6 files changed, 1449 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95222f0..48595c9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1724,6 +1724,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1750,11 +1755,6 @@ struct i915_perf_stream_ops {
 */
void (*disable)(struct i915_perf_stream *stream);
 
-   /* Return: true if any i915 perf records are ready to read()
-* for this stream.
-*/
-   bool (*can_read)(struct i915_perf_stream *stream);
-
/* Call poll_wait, passing a wait queue that will be woken
 * once there is something ready to read() for the stream
 */
@@ -1764,9 +1764,7 @@ struct i915_perf_stream_ops {
 
/* For handling a blocking read, wait until there is something
 * to ready to read() for the stream. E.g. wait on the same
-* wait queue that would be passed to poll_wait() until
-* ->can_read() returns true (if its safe to call ->can_read()
-* without the i915 perf lock held).
+* wait queue that would be passed to poll_wait().
 */
int (*wait_unlocked)(struct i915_perf_stream *stream);
 
@@ -1801,11 +1799,26 @@ struct i915_perf_stream {
struct list_head link;
 
u32 sample_flags;
+   int sample_size;
 
struct i915_gem_context *ctx;
bool enabled;
 
-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   struct i915_perf_read_state *read_state);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };
 
 struct drm_i915_private {
@@ -2100,16 +2113,47 @@ struct drm_i915_private {
 
struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;
 
+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+   atomic_t pollin;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;
 
const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;
 
@@ -3476,6 +3520,8 @@ struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
 struct i915_gem_context *
 i915_gem_context_create_gvt(struct drm_device *dev);
+int 

[Intel-gfx] [PATCH v3 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

[Robert Bragg]

In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 163 +++
 1 file changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 18cb651..54ddf74 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -24,6 +24,169 @@
  *   Robert Bragg 
  */
 
+
+/**
+ * DOC: i915 Perf, streaming API for GPU metrics
+ *
+ * Gen graphics supports a large number of performance counters that can help
+ * driver and application developers understand and optimize their use of the
+ * GPU.
+ *
+ * This i915 perf interface enables userspace to configure and open a file
+ * descriptor representing a stream of GPU metrics which can then be read() as
+ * a stream of sample records.
+ *
+ * The interface is particularly suited to exposing buffered metrics that are
+ * captured by DMA from the GPU, unsynchronized with and unrelated to the CPU.
+ *
+ * Streams representing a single context are accessible to applications with a
+ * corresponding drm file descriptor, such that OpenGL can use the interface
+ * without special privileges. Access to system-wide metrics requires root
+ * privileges by default, unless changed via the dev.i915.perf_event_paranoid
+ * sysctl option.
+ *
+ *
+ * The interface was initially inspired by the core Perf infrastructure but
+ * some notable differences are:
+ *
+ * i915 perf file descriptors represent a "stream" instead of an "event"; where
+ * a perf event primarily corresponds to a single 64bit value, while a stream
+ * might sample sets of tightly-coupled counters, depending on the
+ * configuration.  For example the Gen OA unit isn't designed to support
+ * orthogonal configurations of individual counters; it's configured for a set
+ * of related counters. Samples for an i915 perf stream capturing OA metrics
+ * will include a set of counter values packed in a compact HW specific format.
+ * The OA unit supports a number of different packing formats which can be
+ * selected by the user opening the stream. Perf has support for grouping
+ * events, but each event in the group is configured, validated and
+ * authenticated individually with separate system calls.
+ *
+ * i915 perf stream configurations are provided as an array of u64 (key,value)
+ * pairs, instead of a fixed struct with multiple miscellaneous config members,
+ * interleaved with event-type specific members.
+ *
+ * i915 perf doesn't support exposing metrics via an mmap'd circular buffer.
+ * The supported metrics are being written to memory by the GPU unsynchronized
+ * with the CPU, using HW specific packing formats for counter sets. Sometimes
+ * the constraints on HW configuration require reports to be filtered before it
+ * would be acceptable to expose them to unprivileged applications - to hide
+ * the metrics of other processes/contexts. For these use cases a read() based
+ * interface is a good fit, and provides an opportunity to filter data as it
+ * gets copied from the GPU mapped buffers to userspace buffers.
+ *
+ *
+ * Some notes regarding Linux Perf:
+ * 
+ *
+ * The first prototype of this driver was based on the core perf
+ * infrastructure, and while we did make that mostly work, with some changes to
+ * perf, we found we were breaking or working around too many assumptions baked
+ * into perf's currently cpu centric design.
+ *
+ * In the end we didn't see a clear benefit to making perf's implementation and
+ * interface more complex by changing design assumptions while we knew we still
+ * wouldn't be able to use any existing perf based userspace tools.
+ *
+ * Also considering the Gen specific nature of the Observability hardware and
+ * how userspace will sometimes need to combine i915 perf OA metrics with
+ * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're
+ * expecting the interface to be used by a platform specific userspace such as
+ * OpenGL or tools. This is to say; we aren't inherently missing out on having
+ * a standard vendor/architecture agnostic interface by not using perf.
+ *
+ *
+ * For posterity, in case we might re-visit trying to adapt core perf to be
+ * better suited to exposing i915 metrics these were the main pain points we
+ * hit:
+ *
+ * - The perf based OA PMU driver broke some significant design assumptions:
+ *
+ *   Existing perf pmus are used for profiling work on a cpu and we were
+ *   introducing the idea of _IS_DEVICE pmus with different security
+ *   implications, the need to fake cpu-related data (such as user/kernel
+ *   registers) to fit with perf's current design, and adding _DEVICE records
+ *   as a way 

[Intel-gfx] [PATCH v3 10/11] drm/i915: Add more Haswell OA metric sets

[Robert Bragg]

This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 484 -
 1 file changed, 483 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index c32b5f8..81e5628 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@
 
 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };
 
-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;
 
 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -118,6 +123,333 @@ static int select_render_basic_config(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271c), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272c), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274c), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275c), 0x },
+   { _MMIO(0x236c), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253a4), 0x },
+   { _MMIO(0x2681c), 0x01f00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781c), 0x01f00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265a0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x0030 },
+   { _MMIO(0x25384), 0xaa8a },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680c), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0c0701e0 },
+   { _MMIO(0x2780c), 0x000200a0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xaa86 },
+   { _MMIO(0x25420), 0x08320c83 },
+   { _MMIO(0x25424), 0x06820c83 },
+   { _MMIO(0x2541c), 0x },
+   { _MMIO(0x25428), 0x0c03 },
+};
+
+static int select_compute_basic_config(struct drm_i915_private *dev_priv)
+{
+   dev_priv->perf.oa.mux_regs =
+   mux_config_compute_basic;
+   dev_priv->perf.oa.mux_regs_len =
+   ARRAY_SIZE(mux_config_compute_basic);
+
+   dev_priv->perf.oa.b_counter_regs =
+   b_counter_config_compute_basic;
+   dev_priv->perf.oa.b_counter_regs_len =
+   ARRAY_SIZE(b_counter_config_compute_basic);
+
+   return 0;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681c), 0x3eb00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02aa },
+   { _MMIO(0x25404), 0x03ff },
+   { 

[Intel-gfx] [PATCH v3 04/11] drm/i915: don't whitelist oacontrol in cmd parser

[Robert Bragg]

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 38 ++
 1 file changed, 2 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 71e778b..ac03c71 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -446,7 +446,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1049,8 +1048,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs 
*engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_REJECT) {
DRM_DEBUG_DRIVER("CMD: Rejected command: 0x%08X\n", *cmd);
@@ -1088,31 +1086,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}
 
/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRR to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1202,7 +1175,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 {
u32 *cmd, *batch_base, *batch_end;
struct drm_i915_cmd_descriptor default_desc = { 0 };
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
int ret = 0;
 
batch_base = copy_batch(shadow_batch_obj, batch_obj,
@@ -1259,8 +1231,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
break;
}
 
-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  _set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1268,11 +1239,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
cmd += 

[Intel-gfx] [PATCH v3 00/11] Enable Gen 7 Observation Architecture

[Robert Bragg]

Mostly just a rebase on a more recent nightly, except for an update to how
POLLIN events are reported to reduce the CPU overhead that was otherwise seen
while running gputop.

The problem seen with poll was largely a fault with gputop having multiple
redundant 200ms, but out-of-phase, timers tracked in its mainloop resulting in
excessive poll wake ups due to timeouts. This was fixed, but still it
highlighted that the per-fd code that runs after a poll wait wakes (regardless
of the cause of the wake up) can easily become hot and i915 mmio reads here can
quickly jump to the top of a cpu profile.

The main value of the i915-perf poll implementation is for throttling more than
for having a quick notification of new data, so it works nicely to only rely on
the hrtimer callback that's polling for new data to be the thing that flags
POLLIN events and check for that after the wait without any mmio.


Just to plug gputop as a tool for visualising these metrics with, I'm now
automatically publishing a demo of the interface via Travis to
http://gputop.github.io which is also usable with local targets if you point a
browser at E.g.: http://gputop.github.io?target=localhost while you have the
gputop server running. Apologies that currently the demo site on its own (not
connected to real hardware) doesn't show much since it doesn't have any fake
metric values to graph, though it is possible to at least browse the different
platform metric sets and selecting individual counters will show the
description + normalization equation.  Having the web UI hosted on github
hopefully lowers the bar to trying it out since it avoids needing to set up
Emscripten first as a build dependency.

Regards,
- Robert

Robert Bragg (11):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: return EACCES for check_cmd() failures
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets
  drm/i915: Add a kerneldoc summary for i915_perf.c

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   40 +-
 drivers/gpu/drm/i915/i915_drv.c |6 +
 drivers/gpu/drm/i915/i915_drv.h |  157 +++
 drivers/gpu/drm/i915/i915_gem_context.c |   22 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  659 +
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1615 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |7 +-
 include/uapi/drm/i915_drm.h |  133 +++
 11 files changed, 2979 insertions(+), 42 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.9.2

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

[Intel-gfx] [PATCH v3 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   6 +
 drivers/gpu/drm/i915/i915_drv.h  |  92 +
 drivers/gpu/drm/i915/i915_perf.c | 430 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 598 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6092f0e..9a2f1f9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,6 +106,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o
 
+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83afdd0..f5209ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1169,6 +1169,9 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
 * cannot run before the connectors are registered.
 */
intel_fbdev_initial_config_async(dev);
+
+   /* Depends on sysfs having been initialized */
+   i915_perf_init(dev_priv);
 }
 
 /**
@@ -1177,6 +1180,8 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
  */
 static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
+
i915_audio_component_cleanup(dev_priv);
 
intel_gpu_ips_teardown();
@@ -2578,6 +2583,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d..7b801d9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1724,6 +1724,85 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_perf_read_state {
+   int count;
+   ssize_t read;
+   char __user *buf;
+};
+
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream *stream,
+ struct file *file,
+

[Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

[Robert Bragg]

check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index cfe3e7a..71e778b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1261,7 +1261,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 
if (!check_cmd(engine, desc, cmd, length, is_master,
   _set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}
 
-- 
2.9.2

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

[Intel-gfx] [PATCH v3 07/11] drm/i915: advertise available metrics via sysfs

[Robert Bragg]

Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit register configuration that can be reliably used by
userspace as a key to lookup corresponding counter meta data and
normalization equations.

The guid registry is currently maintained as part of gputop along with
the XML metric set descriptions and code generation scripts, ref:

 https://github.com/rib/gputop
 > gputop-data/guids.xml
 > scripts/update-guids.py
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 45 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 
 drivers/gpu/drm/i915/i915_perf.c   | 19 +++-
 4 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48595c9..d5c7b70 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2114,6 +2114,8 @@ struct drm_i915_private {
struct {
bool initialized;
 
+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;
 
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 3e6006ec..c32b5f8 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 
 enum metric_set_id {
@@ -130,3 +132,46 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   _attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+   if (ret)
+   goto error_render_basic;
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, _render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..e4ba89d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw;
 
 extern int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv);
 
+extern int i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv);
+
+extern void i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7c725b4..a943664 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1330,6 +1330,12 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
if (!IS_HASWELL(dev_priv))
return;
 
+   dev_priv->perf.metrics_kobj =
+   kobject_create_and_add("metrics",
+  _priv->drm.primary->kdev->kobj);
+   if (!dev_priv->perf.metrics_kobj)
+   return;
+
hrtimer_init(_priv->perf.oa.poll_check_timer,
 CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
@@ -1357,9 +1363,15 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;
 
-   dev_priv->perf.oa.oa_formats = hsw_oa_formats;
+   if (i915_perf_init_sysfs_hsw(dev_priv)) {
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+   return;
+   }
 
dev_priv->perf.initialized = true;
+
+   return;
 }
 
 void i915_perf_fini(struct drm_i915_private *dev_priv)
@@ -1367,6 +1379,11 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
  

[Intel-gfx] [PATCH v3 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

[Robert Bragg]

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 1db829c..cfe3e7a 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -446,7 +446,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1097,7 +1097,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9397dde..ba91eff 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -616,7 +616,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)
 
-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)
 
 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.9.2

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

[Intel-gfx] [PATCH v3 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 42 
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c9e7104..18cb651 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -74,6 +74,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31
 
+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1266,21 +1283,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}
 
-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}
 
@@ -1342,6 +1351,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = _oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = _exponent_max,
+},
{}
 };
 
-- 
2.9.2

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

[Intel-gfx] [PATCH 18/18] drm/i915: Early creation of relay channel for capturing boot time logs

[akash . goel]

From: Akash Goel 

As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC firmware
if there are flush interrupts from the GuC side.
Relay has a provision to support early logging where initially only relay
channel can be created, to have buffers for storing logs, and later on
channel can be associated with a debugfs file at appropriate time.
Have availed that, which allows Driver to capture boot time logs also,
which can be collected once Userspace comes up.

v2:
- Remove the couple of FIXMEs, as now the relay channel will be created
  early before enabling the flush interrupts, so no possibility of relay
  channel pointer being modified & read at the same time from 2 different
  execution contexts.
- Rebase.

Suggested-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 66 +-
 1 file changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8733c19..34e4335 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -937,13 +937,39 @@ static void guc_remove_log_relay_file(struct intel_guc 
*guc)
relay_close(guc->log.relay_chan);
 }
 
-static int guc_create_log_relay_file(struct intel_guc *guc)
+static int guc_create_relay_channel(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
-   struct dentry *log_dir;
size_t n_subbufs, subbuf_size;
 
+   /* Keep the size of sub buffers same as shared log buffer */
+   subbuf_size = guc->log.vma->obj->base.size;
+
+   /* Store up to 8 snapshots, which is large enough to buffer sufficient
+* boot time logs and provides enough leeway to User, in terms of
+* latency, for consuming the logs from relay. Also doesn't take
+* up too much memory.
+*/
+   n_subbufs = 8;
+
+   guc_log_relay_chan = relay_open(NULL, NULL, subbuf_size,
+   n_subbufs, _callbacks, dev_priv);
+   if (!guc_log_relay_chan) {
+   DRM_ERROR("Couldn't create relay chan for GuC logging\n");
+   return -ENOMEM;
+   }
+
+   guc->log.relay_chan = guc_log_relay_chan;
+   return 0;
+}
+
+static int guc_create_log_relay_file(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct dentry *log_dir;
+   int ret;
+
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
log_dir = dev_priv->drm.primary->debugfs_root;
 
@@ -963,25 +989,12 @@ static int guc_create_log_relay_file(struct intel_guc 
*guc)
return -ENODEV;
}
 
-   /* Keep the size of sub buffers same as shared log buffer */
-   subbuf_size = guc->log.vma->obj->base.size;
-
-   /* Store up to 8 snapshots, which is large enough to buffer sufficient
-* boot time logs and provides enough leeway to User, in terms of
-* latency, for consuming the logs from relay. Also doesn't take
-* up too much memory.
-*/
-   n_subbufs = 8;
-
-   guc_log_relay_chan = relay_open("guc_log", log_dir, subbuf_size,
-   n_subbufs, _callbacks, dev_priv);
-   if (!guc_log_relay_chan) {
-   DRM_ERROR("Couldn't create relay chan for GuC logging\n");
-   return -ENOMEM;
+   ret = relay_late_setup_files(guc->log.relay_chan, "guc_log", log_dir);
+   if (ret) {
+   DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
+   return ret;
}
 
-   /* FIXME: Cover the update under a lock ? */
-   guc->log.relay_chan = guc_log_relay_chan;
return 0;
 }
 
@@ -1001,7 +1014,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
 
 static void *guc_get_write_buffer(struct intel_guc *guc)
 {
-   /* FIXME: Cover the check under a lock ? */
if (!guc->log.relay_chan)
return NULL;
 
@@ -1227,6 +1239,16 @@ static int guc_create_log_extras(struct intel_guc *guc)
guc->log.buf_addr = vaddr;
}
 
+   if (!guc->log.relay_chan) {
+   /* Create a relay channel, so that we have buffers for storing
+* the GuC firmware logs, the channel will be linked with a file
+* later on when debugfs is registered.
+*/
+   ret = guc_create_relay_channel(guc);
+   if (ret)
+   return ret;
+   }
+
if (!guc->log.flush_wq) {

Re: [Intel-gfx] [PATCH 6/9] drm/i915/cmdparser: Compare against the previous command descriptor

[Chris Wilson]

On Mon, Aug 15, 2016 at 12:00:32PM +0100, Matthew Auld wrote:
> On 12 August 2016 at 16:07, Chris Wilson  wrote:
> > On the blitter (and in test code), we see long sequences of repeated
> > commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these,
> > we can skip the hashtable lookup by remembering the previous command
> > descriptor and doing a straightforward compare of the command header.
> > The corollary is that we need to do one extra comparison before lookup
> > up new commands.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_cmd_parser.c | 20 +---
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> > b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > index 274f2136a846..3b1100a0e0cb 100644
> > --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> > +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > @@ -350,6 +350,9 @@ static const struct drm_i915_cmd_descriptor 
> > hsw_blt_cmds[] = {
> > CMD(  MI_LOAD_SCAN_LINES_EXCL,  SMI,   !F,  0x3F,   R  ),
> >  };
> >
> > +static const struct drm_i915_cmd_descriptor noop_desc =
> > +   CMD(MI_NOOP, SMI, F, 1, S);
> > +
> >  #undef CMD
> >  #undef SMI
> >  #undef S3D
> > @@ -898,11 +901,14 @@ find_cmd_in_table(struct intel_engine_cs *engine,
> >  static const struct drm_i915_cmd_descriptor*
> >  find_cmd(struct intel_engine_cs *engine,
> >  u32 cmd_header,
> > +const struct drm_i915_cmd_descriptor *desc,
> >  struct drm_i915_cmd_descriptor *default_desc)
> >  {
> > -   const struct drm_i915_cmd_descriptor *desc;
> > u32 mask;
> >
> > +   if (((cmd_header ^ desc->cmd.value) & desc->cmd.mask) == 0)
> > +   return desc;
> > +
> > desc = find_cmd_in_table(engine, cmd_header);
> > if (desc)
> > return desc;
> > @@ -911,10 +917,10 @@ find_cmd(struct intel_engine_cs *engine,
> > if (!mask)
> > return NULL;
> >
> > -   BUG_ON(!default_desc);
> Why remove this, was it overkill?

The NULL dereference on the next line is all we need to debug this, i.e.
it gives us no more information and we know by construction it can never
be NULL.

> 
> > -   default_desc->flags = CMD_DESC_SKIP;
> > +   default_desc->cmd.value = cmd_header;
> > +   default_desc->cmd.mask = 0x;
> Where did you pluck this mask from?

It is the most general cmd header mask.

#define MIN_OPCODE_SHIFT 16
cmd.mask = ~0u << MIN_OPCODE_SHIFT
?
-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 15/18] drm/i915: Debugfs support for GuC logging control

[akash . goel]

From: Sagar Arun Kamble 

This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.
The value written to the file, should have bit 0 set to enable logging and
bits 4-7 should contain the verbosity info.

v2: Add a forceful flush, to collect left over logs, on disabling logging.
Useful for Validation.

v3: Besides minor cleanup, implement read method for the debugfs file and
set the guc_log_level to -1 when logging is disabled. (Tvrtko)

v4: Minor cleanup & rebase. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 44 -
 drivers/gpu/drm/i915/i915_guc_submission.c | 62 ++
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 3 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aaa51bc..bfc22bf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2626,6 +2626,47 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
 }
 
+static int i915_guc_log_control_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (!dev_priv->guc.log.vma)
+   return -EINVAL;
+
+   *val = i915.guc_log_level;
+
+   return 0;
+}
+
+static int i915_guc_log_control_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   int ret;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
+   if (!dev_priv->guc.log.vma) {
+   ret = -EINVAL;
+   goto end;
+   }
+
+   intel_runtime_pm_get(dev_priv);
+   ret = i915_guc_log_control(dev_priv, val);
+   intel_runtime_pm_put(dev_priv);
+
+end:
+   mutex_unlock(>struct_mutex);
+   return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
+   i915_guc_log_control_get, i915_guc_log_control_set,
+   "%lld\n");
+
 static int i915_edp_psr_status(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -5436,7 +5477,8 @@ static const struct i915_debugfs_files {
{"i915_fbc_false_color", _fbc_fc_fops},
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
-   {"i915_dp_test_active", _displayport_test_active_fops}
+   {"i915_dp_test_active", _displayport_test_active_fops},
+   {"i915_guc_log_control", _guc_log_control_fops}
 };
 
 void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 85df2f3..be6c727 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -195,6 +195,16 @@ static int host2guc_force_logbuffer_flush(struct intel_guc 
*guc)
return host2guc_action(guc, data, 2);
 }
 
+static int host2guc_logging_control(struct intel_guc *guc, u32 control_val)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING;
+   data[1] = control_val;
+
+   return host2guc_action(guc, data, 2);
+}
+
 /*
  * Initialise, update, or clear doorbell data shared with the GuC
  *
@@ -1585,3 +1595,55 @@ void i915_guc_register(struct drm_i915_private *dev_priv)
guc_log_late_setup(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
 }
+
+int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
+{
+   union guc_log_control log_param;
+   int ret;
+
+   log_param.value = control_val;
+
+   if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
+   log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
+   return -EINVAL;
+
+   /* This combination doesn't make sense & won't have any effect */
+   if (!log_param.logging_enabled && (i915.guc_log_level < 0))
+   return 0;
+
+   ret = host2guc_logging_control(_priv->guc, log_param.value);
+   if (ret < 0) {
+   DRM_DEBUG_DRIVER("host2guc action failed %d\n", ret);
+   return ret;
+   }
+
+   i915.guc_log_level = log_param.verbosity;
+
+   /* If log_level was set as -1 at boot time, then the relay channel file
+* wouldn't have been created by now and interrupts also would not have
+* been enabled.
+*/
+   if (!dev_priv->guc.log.relay_chan) {
+   ret = guc_log_late_setup(_priv->guc);
+   if (!ret)
+   gen9_enable_guc_interrupts(dev_priv);
+   } else if (!log_param.logging_enabled) {
+   

[Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

[akash . goel]

From: Akash Goel 

GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written data by GuC into the local
buffer, i.e. as per the read & write pointer values.
Moreover the flush interrupt would generally come for one type of log
buffer, when it becomes half full, so at that time the other 2 types of
log buffer would comparatively have much lesser unread data in them.
In case of overflow reported by GuC, Driver do need to copy the entire
buffer as the whole buffer would contain the unread data.

v2: Rebase.

v3: Fix the blooper of doing the copy twice. (Tvrtko)

Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 40 +-
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c7b4a57..b8d6313 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1003,6 +1003,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
void *src_data_ptr, *dst_data_ptr;
unsigned int buffer_size, expected_size;
enum guc_log_buffer_type type;
+   unsigned int read_offset, write_offset, bytes_to_copy;
+   bool new_overflow;
 
if (WARN_ON(!guc->log.buf_addr))
return;
@@ -1025,11 +1027,14 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
memcpy(_buffer_state_local, log_buffer_state,
   sizeof(struct guc_log_buffer_state));
buffer_size = log_buffer_state_local.size;
+   read_offset = log_buffer_state_local.read_ptr;
+   write_offset = log_buffer_state_local.sampled_write_ptr;
 
/* Bookkeeping stuff */
guc->log.flush_count[type] += 
log_buffer_state_local.flush_to_file;
if (log_buffer_state_local.buffer_full_cnt !=
guc->log.prev_overflow_count[type]) {
+   new_overflow = 1;
guc->log.total_overflow_count[type] +=
(log_buffer_state_local.buffer_full_cnt -
 guc->log.prev_overflow_count[type]);
@@ -1043,7 +1048,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
guc->log.prev_overflow_count[type] =
log_buffer_state_local.buffer_full_cnt;
DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
-   }
+   } else
+   new_overflow = 0;
 
if (log_buffer_snapshot_state) {
/* First copy the state structure in snapshot buffer */
@@ -1055,8 +1061,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 * for consistency set the write pointer value to same
 * value of sampled_write_ptr in the snapshot buffer.
 */
-   log_buffer_snapshot_state->write_ptr =
-   log_buffer_snapshot_state->sampled_write_ptr;
+   log_buffer_snapshot_state->write_ptr = write_offset;
 
log_buffer_snapshot_state++;
 
@@ -1079,7 +1084,31 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
buffer_size = expected_size;
}
 
-   memcpy(dst_data_ptr, src_data_ptr, buffer_size);
+   if (unlikely(new_overflow)) {
+   /* copy the whole buffer in case of overflow */
+   read_offset = 0;
+   write_offset = buffer_size;
+   } else if (unlikely((read_offset > buffer_size) ||
+   (write_offset > buffer_size))) {
+   DRM_ERROR("invalid log buffer state\n");
+   /* copy whole buffer as offsets are unreliable 
*/
+   read_offset = 0;
+   write_offset = buffer_size;
+   }
+
+   /* Just copy the newly written data */
+   if (read_offset <= write_offset) {
+   bytes_to_copy = write_offset - read_offset;
+   memcpy(dst_data_ptr + read_offset,
+  src_data_ptr + read_offset, 
bytes_to_copy);
+   } else {
+   bytes_to_copy = buffer_size - read_offset;
+   memcpy(dst_data_ptr + read_offset,
+  src_data_ptr + read_offset, 

[Intel-gfx] [PATCH 02/18] drm/i915: Add GuC ukernel logging related fields to fw interface file

[akash . goel]

From: Sagar Arun Kamble 

The first page of the GuC log buffer contains state info or meta data
which is required to parse the logs contained in the subsequent pages.
The structure representing the state info is added to interface file
as Driver would need to handle log buffer flush interrupts from GuC.
Added an enum for the different message/event types that can be send
by the GuC ukernel to Host.
Also added 2 new Host to GuC action types to inform GuC when Host has
flushed the log buffer and forcefuly cause the GuC to send a new
log buffer flush interrupt.

v2:
- Make documentation of log buffer state structure more elaborate &
  rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)

v3: Add GuC log buffer layout diagram for more clarity.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h | 78 +++
 1 file changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 944786d..47ef7e8 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -418,15 +418,87 @@ struct guc_ads {
u32 reserved2[4];
 } __packed;
 
+/* GuC logging structures */
+
+enum guc_log_buffer_type {
+   GUC_ISR_LOG_BUFFER,
+   GUC_DPC_LOG_BUFFER,
+   GUC_CRASH_DUMP_LOG_BUFFER,
+   GUC_MAX_LOG_BUFFER
+};
+
+/**
+ * DOC: GuC Log buffer Layout
+ *
+ * Page0  +---+
+ *|   ISR state header (32 bytes) |
+ *|  DPC state header |
+ *|   Crash dump state header |
+ * Page1  +---+
+ *|   ISR logs|
+ * Page5  +---+
+ *|   DPC logs|
+ * Page9  +---+
+ *| Crash Dump logs   |
+ *+---+
+ *
+ * Below state structure is used for coordination of retrieval of GuC firmware
+ * logs. Separate state is maintained for each log buffer type.
+ * read_ptr points to the location where i915 read last in log buffer and
+ * is read only for GuC firmware. write_ptr is incremented by GuC with number
+ * of bytes written for each log entry and is read only for i915.
+ * When any type of log buffer becomes half full, GuC sends a flush interrupt.
+ * GuC firmware expects that while it is writing to 2nd half of the buffer,
+ * first half would get consumed by Host and then get a flush completed
+ * acknowledgment from Host, so that it does not end up doing any overwrite
+ * causing loss of logs. So when buffer gets half filled & i915 has requested
+ * for interrupt, GuC will set flush_to_file field, set the sampled_write_ptr
+ * to the value of write_ptr and raise the interrupt.
+ * On receiving the interrupt i915 should read the buffer, clear flush_to_file
+ * field and also update read_ptr with the value of sample_write_ptr, before
+ * sending an acknowledgment to GuC. marker & version fields are for internal
+ * usage of GuC and opaque to i915. buffer_full_cnt field is incremented every
+ * time GuC detects the log buffer overflow.
+ */
+struct guc_log_buffer_state {
+   u32 marker[2];
+   u32 read_ptr;
+   u32 write_ptr;
+   u32 size;
+   u32 sampled_write_ptr;
+   union {
+   struct {
+   u32 flush_to_file:1;
+   u32 buffer_full_cnt:4;
+   u32 reserved:27;
+   };
+   u32 flags;
+   };
+   u32 version;
+} __packed;
+
+union guc_log_control {
+   struct {
+   u32 logging_enabled:1;
+   u32 reserved1:3;
+   u32 verbosity:4;
+   u32 reserved2:24;
+   };
+   u32 value;
+} __packed;
+
 /* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
 enum host2guc_action {
HOST2GUC_ACTION_DEFAULT = 0x0,
HOST2GUC_ACTION_SAMPLE_FORCEWAKE = 0x6,
HOST2GUC_ACTION_ALLOCATE_DOORBELL = 0x10,
HOST2GUC_ACTION_DEALLOCATE_DOORBELL = 0x20,
+   HOST2GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE = 0x30,
+   HOST2GUC_ACTION_FORCE_LOG_BUFFER_FLUSH = 0x302,
HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
+   HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
HOST2GUC_ACTION_LIMIT
 };
 
@@ -448,4 +520,10 @@ enum guc2host_status {
GUC2HOST_STATUS_GENERIC_FAIL = GUC2HOST_STATUS(0xF000)
 };
 
+/* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
+enum guc2host_message {
+   GUC2HOST_MSG_CRASH_DUMP_POSTED = (1 << 1),
+   GUC2HOST_MSG_FLUSH_LOG_BUFFER = (1 << 3)
+};
+
 #endif
-- 
1.9.2

[Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[akash . goel]

From: Akash Goel 

Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the GuC log buffer in the buffer managed by relay.
The snapshot will be taken when GuC firmware sends a log buffer flush
interrupt and up to four snapshots could be stored in the relay buffer.
The relay buffer will be operated in a mode where it will overwrite the
data not yet collected by User.
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the 'poll'
call on log file, User can come to know whenever a new snapshot of the
log buffer is taken by Driver, so can run in tandem with the Driver and
capture the logs in a sustained/streaming manner, without any loss of data.

v2: Defer the creation of relay channel & associated debugfs file, as
debugfs setup is now done at the end of i915 Driver load. (Chris)

v3:
- Switch to no-overwrite mode for relay.
- Fix the relay sub buffer switching sequence.

v4:
- Update i915 Kconfig to select RELAY config. (TvrtKo)
- Log a message when there is no sub buffer available to capture
  the GuC log buffer. (Tvrtko)
- Increase the number of relay sub buffers to 8 from 4, to have
  sufficient buffering for boot time logs

v5:
- Fix the alignment, indentation issues and some minor cleanup. (Tvrtko)
- Update the comment to elaborate on why a relay channel has to be
  associated with the debugfs file. (Tvrtko)

Suggested-by: Chris Wilson 
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/Kconfig   |   1 +
 drivers/gpu/drm/i915/i915_drv.c|   2 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 211 -
 drivers/gpu/drm/i915/intel_guc.h   |   3 +
 4 files changed, 215 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7769e46..fc900d2 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -11,6 +11,7 @@ config DRM_I915
select DRM_KMS_HELPER
select DRM_PANEL
select DRM_MIPI_DSI
+   select RELAY
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_LCD_SUPPORT if ACPI
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 13ae340..cdee60b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1133,6 +1133,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
+   i915_guc_register(dev_priv);
i915_setup_sysfs(dev);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
@@ -1171,6 +1172,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
 
i915_teardown_sysfs(_priv->drm);
+   i915_guc_unregister(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2b27b87..9b1054c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -23,6 +23,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 #include "i915_drv.h"
 #include "intel_guc.h"
 
@@ -837,13 +839,159 @@ err:
return NULL;
 }
 
+/*
+ * Sub buffer switch callback. Called whenever relay has to switch to a new
+ * sub buffer, relay stays on the same sub buffer if 0 is returned.
+ */
+static int subbuf_start_callback(struct rchan_buf *buf,
+void *subbuf,
+void *prev_subbuf,
+size_t prev_padding)
+{
+   /* Use no-overwrite mode by default, where relay will stop accepting
+* new data if there are no empty sub buffers left.
+* There is no strict synchronization enforced by relay between Consumer
+* and Producer. In overwrite mode, there is a possibility of getting
+* inconsistent/garbled data, the producer could be writing on to the
+* same sub buffer from which Consumer is reading. This can't be avoided
+* unless Consumer is fast enough and can always run in tandem with
+* Producer.
+*/
+   if (relay_buf_full(buf))
+   return 0;
+
+   return 1;
+}
+
+/*
+ * file_create() callback. Creates relay file in debugfs.
+ */
+static struct dentry *create_buf_file_callback(const 

[Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

[akash . goel]

From: Sagar Arun Kamble 

There are certain types of interrupts which Host can receive from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to receive interrupts from GuC but currently
enables & partially handles only the interrupt sent by GuC ukernel.
Future patches will add support for handling other interrupt types.

v2:
- Use common low level routines for PM IER/IIR programming (Chris)
- Rename interrupt functions to gen9_xxx from gen8_xxx (Chris)
- Replace disabling of wake ref asserts with rpm get/put (Chris)

v3:
- Update comments for more clarity. (Tvrtko)
- Remove the masking of GuC interrupt, which was kept masked till the
  start of bottom half, its not really needed as there is only a
  single instance of work item & wq is ordered. (Tvrtko)

v4:
- Rebase.
- Rename guc_events to pm_guc_events so as to be indicative of the
  register/control block it is associated with. (Chris)
- Add handling for back to back log buffer flush interrupts.

v5:
- Move the read & clearing of register, containing Guc2Host message
  bits, outside the irq spinlock. (Tvrtko)

v6:
- Move the log buffer flush interrupt related stuff to the following
  patch so as to do only generic bits in this patch. (Tvrtko)
- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  5 +++
 drivers/gpu/drm/i915/i915_irq.c| 63 --
 drivers/gpu/drm/i915/i915_reg.h| 11 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 ++
 drivers/gpu/drm/i915/intel_guc.h   |  3 ++
 drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++
 7 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a187ea7..08553b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1783,6 +1783,7 @@ struct drm_i915_private {
u32 pm_imr;
u32 pm_ier;
u32 pm_rps_events;
+   u32 pm_guc_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
struct i915_hotplug hotplug;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 34fb893..b062da6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1055,6 +1055,8 @@ int intel_guc_suspend(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
+   gen9_disable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;
 
data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
@@ -1081,6 +1083,9 @@ int intel_guc_resume(struct drm_device *dev)
if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
 
+   if (i915.guc_log_level >= 0)
+   gen9_enable_guc_interrupts(dev_priv);
+
ctx = dev_priv->kernel_context;
 
data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 83d708a..eb4774f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -170,6 +170,7 @@ static void gen5_assert_iir_is_zero(struct drm_i915_private 
*dev_priv,
 } while (0)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 
 /* For display hotplug interrupt */
 static inline void
@@ -411,6 +412,38 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
gen6_reset_rps_interrupts(dev_priv);
 }
 
+void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   if (!dev_priv->guc.interrupts_enabled) {
+   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+  dev_priv->pm_guc_events);
+   dev_priv->guc.interrupts_enabled = true;
+   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+   }
+   spin_unlock_irq(_priv->irq_lock);
+}
+
+void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->guc.interrupts_enabled = false;
+
+   gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+
+   spin_unlock_irq(_priv->irq_lock);
+   synchronize_irq(dev_priv->drm.irq);
+
+   gen9_reset_guc_interrupts(dev_priv);
+}
+
 /**
  * bdw_update_port_irq - update DE port interrupt
  * @dev_priv: 

[Intel-gfx] [PATCH 16/18] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

[akash . goel]

From: Akash Goel 

Host needs to sample the GuC log buffer on every flush interrupt from GuC.
To ensure that we always get the up-to-date data from log buffer, its
better to access the buffer through an uncached CPU mapping. Also the way
buffer is accessed from GuC & Host side, manually doing cache flush may
not be effective always if cached CPU mapping is used.
Though there could be some performance implication with Uncached read, but
reliability of data will be ensured.

v2: Rebase.

v3: Rebase.

v4: Rebase.

Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index be6c727..7bc75c8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1134,8 +1134,6 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
dst_data_ptr += buffer_size;
}
 
-   /* FIXME: invalidate/flush for log buffer needed */
-
/* Update the read pointer in the shared log buffer */
log_buffer_state->read_ptr = write_offset;
 
@@ -1212,8 +1210,11 @@ static int guc_create_log_extras(struct intel_guc *guc)
return 0;
 
if (!guc->log.buf_addr) {
-   /* Create a vmalloc mapping of log buffer pages */
-   vaddr = i915_gem_object_pin_map(guc->log.vma->obj, I915_MAP_WB);
+   /* Create a WC (Uncached for read) vmalloc mapping of log
+* buffer pages, so that we can directly get the data
+* (up-to-date) from memory.
+*/
+   vaddr = i915_gem_object_pin_map(guc->log.vma->obj, I915_MAP_WC);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
DRM_ERROR("Couldn't map log buffer pages %d\n", ret);
-- 
1.9.2

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

[Intel-gfx] [PATCH 10/18] drm/i915: Add stats for GuC log buffer flush interrupts

[akash . goel]

From: Akash Goel 

GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a statistics of how many flush
interrupts were received and for which type of log buffer,
along with the overflow count of each buffer type.
Augmented i915_log_info debugfs to report back these statistics.

v2:
- Update the logic to detect multiple overflows between the 2
  flush interrupts and also log a message for overflow (Tvrtko)
- Track the number of times there was no free sub buffer to capture
  the GuC log buffer. (Tvrtko)

v3:
- Fix the printf field width for overflow counter, set it to 10 as per the
  max value of u32, which takes 10 digits in decimal form. (Tvrtko)

Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 28 
 drivers/gpu/drm/i915/i915_guc_submission.c | 20 
 drivers/gpu/drm/i915/i915_irq.c|  2 ++
 drivers/gpu/drm/i915/intel_guc.h   |  7 +++
 4 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b2cfcf4..aaa51bc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2491,6 +2491,32 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
return 0;
 }
 
+static void i915_guc_log_info(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   seq_puts(m, "\nGuC logging stats:\n");
+
+   seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
+  guc->log.flush_count[GUC_ISR_LOG_BUFFER],
+  guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
+
+   seq_printf(m, "\tDPC:   flush count %10u, overflow count %10u\n",
+  guc->log.flush_count[GUC_DPC_LOG_BUFFER],
+  guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
+
+   seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n",
+  guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
+  guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+
+   seq_printf(m, "\tTotal flush interrupt count: %u\n",
+  guc->log.flush_interrupt_count);
+
+   seq_printf(m, "\tCapture miss count: %u\n",
+  guc->log.capture_miss_count);
+}
+
 static void i915_guc_client_info(struct seq_file *m,
 struct drm_i915_private *dev_priv,
 struct i915_guc_client *client)
@@ -2565,6 +2591,8 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
i915_guc_client_info(m, dev_priv, );
 
+   i915_guc_log_info(m, dev_priv);
+
/* Add more as required ... */
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index f4c5846..c7b4a57 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1026,6 +1026,25 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
   sizeof(struct guc_log_buffer_state));
buffer_size = log_buffer_state_local.size;
 
+   /* Bookkeeping stuff */
+   guc->log.flush_count[type] += 
log_buffer_state_local.flush_to_file;
+   if (log_buffer_state_local.buffer_full_cnt !=
+   guc->log.prev_overflow_count[type]) {
+   guc->log.total_overflow_count[type] +=
+   (log_buffer_state_local.buffer_full_cnt -
+guc->log.prev_overflow_count[type]);
+
+   if (log_buffer_state_local.buffer_full_cnt <
+   guc->log.prev_overflow_count[type]) {
+   /* buffer_full_cnt is a 4 bit counter */
+   guc->log.total_overflow_count[type] += 16;
+   }
+
+   guc->log.prev_overflow_count[type] =
+   log_buffer_state_local.buffer_full_cnt;
+   DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
+   }
+
if (log_buffer_snapshot_state) {
/* First copy the state structure in snapshot buffer */
memcpy(log_buffer_snapshot_state, 
_buffer_state_local,
@@ -1084,6 +1103,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 * getting consumed by User at a slow rate.
 */
DRM_ERROR_RATELIMITED("no sub-buffer to capture log buffer\n");
+   

[Intel-gfx] [PATCH v6 00/18] Support for sustained capturing of GuC firmware logs

[akash . goel]

From: Akash Goel 

GuC firmware log its debug messages into a Host-GuC shared memory buffer
and when the buffer is half full it sends a Flush interrupt to Host.
GuC firmware follows the half-full draining protocol where it expects that
while it is writing to 2nd half of the buffer, first half would get consumed
by Host and then get a flush completed acknowledgement from Host, so that it
does not end up doing any overwrite causing loss of logs.
So far flush interrupt wasn't enabled on Host side & User could capture the
contents/snapshot of log buffer through 'i915_guc_log_dump' debugfs iface.
But this couldn't meet couple of key requirements, especially of Validation,
first is to ensure capturing of all boot time logs even with high verbosity
level and second is to enable capturing of logs in a sustained manner like
for the entire duration of a workload.
Now Driver will enable flush interrupt and on receving it, would copy the
contents of log buffer into its local buffer. The size of local buffer would
be big enough to contain multiple snapshots of the log buffer giving ample
time to User to pull boot time messages.
Have added a debugfs interface '/sys/kernel/debug/dri/guc_log' for User to
collect the logs. Availed relay framework to implement this interface, where
Driver will have to just use a relay API to store snapshots of GuC log buffer
in a buffer managed by relay. The relay buffer can be operated in a mode,
equivalent to 'dmesg -c' where the old data, not yet collected by User, will
be overwritten if buffer becomes full or it can be operated in no-overwrite
mode where relay will stop accepting new data if all sub buffers are full.
Have used the latter mode to avoid the possibility of getting garbled data. 
Besides mmap method, through which User can directly access the relay
buffer contents, relay also supports the 'poll' method. Through the 'poll'
call on log file, User can come to know whenever a new snapshot of the log
buffer is taken by Driver, so can run in tandem with the Driver and thus
capture logs in a sustained/streaming manner, without any loss of data.

v2: Rebased to the latest drm-intel-nightly.

v3: Aligned with the modification of late debugfs registration, at the end of
i915 Driver load. Did cleanup as per Tvrtko's review comments, added 3
new patches to optimize the log-buffer flush interrupt handling, gather
and report the logging related stats.

v4: Added 2 new patches to further optimize the log-buffer flush interrupt
handling. Did cleanup as per Chris's review comments, fixed couple of
issues related to clearing of Guc2Host message register. Switched to
no-overwrite mode for the relay.

v5: Added a new patch to avail MOVNTDQA instruction based fast memcpy provided
by a patch from Chris. Dropped the rt priority kthread patch, after
evaluating all the optimizations with certain benchmarks like
synmark_oglmultithread, synmark_oglbatch5 which generates flush interupts
almost at every ms or less. Updated the older patches as per the review
comments from Tvrtko and Chris W. Added a new patch to augment i915 error
state with the GuC log buffer contents. Fixed the issue of User interrupt
getting disabled for VEBOX ring, causing failure for certain IGTs.
Also included 2 patches to support early logging for capturing boot
time logs and use per CPU constructs on the relay side so as to address
a WARNING issue with the call to relay_reserve(), without disabling
preemption.

v6: Mainly did the rebasing, refactoring, cleanup as per the review comments
and fixed error/warnings reported by checkpatch.

Akash Goel (12):
  drm/i915: New structure to contain GuC logging related fields
  drm/i915: Add low level set of routines for programming PM IER/IIR/IMR
register set
  relay: Use per CPU constructs for the relay channel buffer pointers
  drm/i915: Add a relay backed debugfs interface for capturing GuC logs
  drm/i915: New lock to serialize the Host2GuC actions
  drm/i915: Add stats for GuC log buffer flush interrupts
  drm/i915: Optimization to reduce the sampling time of GuC log buffer
  drm/i915: Increase GuC log buffer size to reduce flush interrupts
  drm/i915: Augment i915 error state to include the dump of GuC log
buffer
  drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer
  drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer
  drm/i915: Early creation of relay channel for capturing boot time logs

Sagar Arun Kamble (6):
  drm/i915: Decouple GuC log setup from verbosity parameter
  drm/i915: Add GuC ukernel logging related fields to fw interface file
  drm/i915: Support for GuC interrupts
  drm/i915: Handle log buffer flush interrupt event from GuC
  drm/i915: Forcefully flush GuC log buffer on reset
  drm/i915: Debugfs support for GuC logging control

 drivers/gpu/drm/i915/Kconfig   |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  76 

[Intel-gfx] [PATCH 01/18] drm/i915: Decouple GuC log setup from verbosity parameter

[akash . goel]

From: Sagar Arun Kamble 

GuC Log buffer allocation was tied up with verbosity level module param
i915.guc_log_level. User would be given a provision to enable firmware
logging at runtime, through a host2guc action, and not necessarily during
Driver load time. But the address of log buffer can be passed only in
init params, at firmware load time, so GuC has to be reset and firmware
needs to be reloaded to pass the log buffer address at runtime.
To avoid reset of GuC & reload of firmware, allocation of log buffer will
be done always but logging would be enabled initially on GuC side based on
the value of module parameter guc_log_level.

v2: Update commit message to describe the constraint with allocation of
log buffer at runtime. (Tvrtko)

v3: Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 3 ---
 drivers/gpu/drm/i915/intel_guc_loader.c| 6 --
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bb40792..fec5898 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -834,9 +834,6 @@ static void guc_create_log(struct intel_guc *guc)
unsigned long offset;
uint32_t size, flags;
 
-   if (i915.guc_log_level < GUC_LOG_VERBOSITY_MIN)
-   return;
-
if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 324812d..b3751c4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -187,11 +187,13 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
 
+   params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
+
if (i915.guc_log_level >= 0) {
-   params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
i915.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-   }
+   } else
+   params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
 
if (guc->ads_vma) {
u32 ads = i915_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-- 
1.9.2

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

[Intel-gfx] [PATCH 12/18] drm/i915: Increase GuC log buffer size to reduce flush interrupts

[akash . goel]

From: Akash Goel 

In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.
This also helps in reducing the output log file size, apart from
reducing the flush interrupt count. With the original settings,
44 KB was needed for one snapshot. With modified settings, 76 KB is
needed for a snapshot which will be equivalent to 2 snapshots of the
original setting. So 12KB saving, every 88 KB, over the original setting.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 47ef7e8..49dbe25 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -104,9 +104,9 @@
 #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
 #define   GUC_LOG_CRASH_PAGES  1
 #define   GUC_LOG_CRASH_SHIFT  4
-#define   GUC_LOG_DPC_PAGES3
+#define   GUC_LOG_DPC_PAGES7
 #define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_ISR_PAGES3
+#define   GUC_LOG_ISR_PAGES7
 #define   GUC_LOG_ISR_SHIFT9
 #define   GUC_LOG_BUF_ADDR_SHIFT   12
 
@@ -436,9 +436,9 @@ enum guc_log_buffer_type {
  *|   Crash dump state header |
  * Page1  +---+
  *|   ISR logs|
- * Page5  +---+
- *|   DPC logs|
  * Page9  +---+
+ *|   DPC logs|
+ * Page17 +---+
  *| Crash Dump logs   |
  *+---+
  *
-- 
1.9.2

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

[Intel-gfx] [PATCH 09/18] drm/i915: New lock to serialize the Host2GuC actions

[akash . goel]

From: Akash Goel 

With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other existing actions.

v2: Use mutex in place of spinlock to serialize, as sleep can happen
while waiting for the action's response from GuC. (Tvrtko)

v3: To conform to the general rules, acquire mutex before taking the
forcewake. (Tvrtko)

Signed-off-by: Akash Goel 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 3 +++
 drivers/gpu/drm/i915/intel_guc.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 9b1054c..f4c5846 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -87,6 +87,7 @@ static int host2guc_action(struct intel_guc *guc, u32 *data, 
u32 len)
if (WARN_ON(len < 1 || len > 15))
return -EINVAL;
 
+   mutex_lock(>action_lock);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
dev_priv->guc.action_count += 1;
@@ -127,6 +128,7 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
dev_priv->guc.action_status = status;
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   mutex_unlock(>action_lock);
 
return ret;
 }
@@ -1359,6 +1361,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
 
guc->ctx_pool_vma = vma;
ida_init(>ctx_ids);
+   mutex_init(>action_lock);
guc_create_log(guc);
guc_create_ads(guc);
 
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3299cce..1704495 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -155,6 +155,9 @@ struct intel_guc {
 
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
+
+   /* To serialize the Host2GuC actions */
+   struct mutex action_lock;
 };
 
 /* intel_guc_loader.c */
-- 
1.9.2

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

[Intel-gfx] [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

[akash . goel]

From: Sagar Arun Kamble 

Before capturing the GuC logs as a part of error state, there should be a
force log buffer flush action sent to GuC before proceeding with GPU reset
and re-initializing GUC. There could be some data in the log buffer which
is yet to be captured and those logs would be particularly useful to
understand that why the GPU reset was initiated.

v2:
- Avoid the wait via flush_work, to serialize against an ongoing log
  buffer flush, from the error state capture path. (Chris)
- Rebase.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 ++
 drivers/gpu/drm/i915/i915_guc_submission.c | 30 ++
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 94297aa..b73c671 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1301,6 +1301,8 @@ static void i915_gem_capture_guc_log_buffer(struct 
drm_i915_private *dev_priv,
if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
return;
 
+   i915_guc_flush_logs(dev_priv, false);
+
error->guc_log = i915_error_object_create(dev_priv,
  dev_priv->guc.log.vma);
 }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b8d6313..85df2f3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,6 +185,16 @@ static int host2guc_logbuffer_flush_complete(struct 
intel_guc *guc)
return host2guc_action(guc, data, 1);
 }
 
+static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
+{
+   u32 data[2];
+
+   data[0] = HOST2GUC_ACTION_FORCE_LOG_BUFFER_FLUSH;
+   data[1] = 0;
+
+   return host2guc_action(guc, data, 2);
+}
+
 /*
  * Initialise, update, or clear doorbell data shared with the GuC
  *
@@ -1536,6 +1546,26 @@ void i915_guc_capture_logs(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_put(dev_priv);
 }
 
+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool can_wait)
+{
+   if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
+   return;
+
+   /* First disable the interrupts, will be renabled afterwards */
+   gen9_disable_guc_interrupts(dev_priv);
+
+   /* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not happen, but wait
+* can't be done for some paths like error state capture in which case
+* take a chance & directly attempt the forceful flush.
+*/
+   if (can_wait)
+   flush_work(_priv->guc.log.flush_work);
+
+   /* Ask GuC to update the log buffer state */
+   host2guc_force_logbuffer_flush(_priv->guc);
+}
+
 void i915_guc_unregister(struct drm_i915_private *dev_priv)
 {
if (!i915.enable_guc_submission)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 8598f38..d7eda42 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -182,6 +182,7 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*rq);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 void i915_guc_capture_logs(struct drm_i915_private *dev_priv);
+void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool can_wait);
 void i915_guc_register(struct drm_i915_private *dev_priv);
 void i915_guc_unregister(struct drm_i915_private *dev_priv);
 
-- 
1.9.2

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

[Intel-gfx] [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

[akash . goel]

From: Akash Goel 

Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.

v2:
- For uniformity use existing helper function print_error_obj() to
  dump out contents of GuC log buffer, pretty printing is better left
  to userspace. (Chris)
- Skip the dumping of GuC log buffer when logging is disabled as it
  won't be of any use.
- Rebase.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08553b9..de89596 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -734,6 +734,7 @@ struct drm_i915_error_state {
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
struct drm_i915_error_object *semaphore;
+   struct drm_i915_error_object *guc_log;
 
struct drm_i915_error_engine {
int engine_id;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0c3f30c..94297aa 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -572,6 +572,13 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
}
}
 
+   obj = error->guc_log;
+   if (obj) {
+   err_printf(m, "GuC log buffer = 0x%08x\n",
+  lower_32_bits(obj->gtt_offset));
+   print_error_obj(m, obj);
+   }
+
if (error->overlay)
intel_overlay_print_error_state(m, error->overlay);
 
@@ -651,6 +658,7 @@ static void i915_error_state_free(struct kref *error_ref)
}
 
i915_error_object_free(error->semaphore);
+   i915_error_object_free(error->guc_log);
 
for (i = 0; i < ARRAY_SIZE(error->active_bo); i++)
kfree(error->active_bo[i]);
@@ -1286,6 +1294,17 @@ static void i915_capture_pinned_buffers(struct 
drm_i915_private *dev_priv,
error->pinned_bo = bo;
 }
 
+static void i915_gem_capture_guc_log_buffer(struct drm_i915_private *dev_priv,
+   struct drm_i915_error_state *error)
+{
+   /* Capturing log buf contents won't be useful if logging was disabled */
+   if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
+   return;
+
+   error->guc_log = i915_error_object_create(dev_priv,
+ dev_priv->guc.log.vma);
+}
+
 /* Capture all registers which don't fit into another category. */
 static void i915_capture_reg_state(struct drm_i915_private *dev_priv,
   struct drm_i915_error_state *error)
@@ -1437,6 +1456,7 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
i915_gem_record_rings(dev_priv, error);
i915_capture_active_buffers(dev_priv, error);
i915_capture_pinned_buffers(dev_priv, error);
+   i915_gem_capture_guc_log_buffer(dev_priv, error);
 
do_gettimeofday(>time);
 
-- 
1.9.2

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