[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Fix (most) pipe underruns, properly this time (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/skl: Fix (most) pipe underruns, properly this time (rev2)
URL   : https://patchwork.freedesktop.org/series/10059/
State : failure

== Summary ==

Applying: drm/i915/skl: Update plane watermarks atomically during plane updates
fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_pm.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/skl: Update plane watermarks atomically during 
plane updates
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 series starting with [v3,1/3] drm: extra printk() wrapper macros

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm: extra printk() wrapper macros
URL   : https://patchwork.freedesktop.org/series/10060/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (ro-ivb-i7-3770)
Test gem_sync:
Subgroup basic-store-each:
dmesg-fail -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
Test prime_vgem:
Subgroup basic-fence-flip:
dmesg-warn -> PASS   (ro-hsw-i3-4010u)
Subgroup basic-fence-read:
pass   -> FAIL   (ro-skl3-i5-6260u)
fail   -> PASS   (fi-snb-i7-2600)

fi-hsw-i7-4770k  total:244  pass:214  dwarn:0   dfail:0   fail:10  skip:20 
fi-kbl-qkkr  total:244  pass:178  dwarn:28  dfail:1   fail:10  skip:27 
fi-skl-i5-6260u  total:244  pass:222  dwarn:1   dfail:0   fail:9   skip:12 
fi-skl-i7-6700k  total:244  pass:209  dwarn:0   dfail:0   fail:9   skip:26 
fi-snb-i7-2600   total:244  pass:195  dwarn:0   dfail:0   fail:9   skip:40 
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13 
ro-bdw-i7-5600u  total:244  pass:202  dwarn:0   dfail:0   fail:10  skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:196  dwarn:0   dfail:0   fail:10  skip:38 
ro-hsw-i3-4010u  total:244  pass:210  dwarn:0   dfail:0   fail:10  skip:24 
ro-hsw-i7-4770r  total:244  pass:210  dwarn:0   dfail:0   fail:10  skip:24 
ro-ilk-i7-620lm  total:244  pass:170  dwarn:0   dfail:0   fail:11  skip:63 
ro-ilk1-i5-650   total:239  pass:171  dwarn:0   dfail:0   fail:10  skip:58 
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:10  skip:34 
ro-skl3-i5-6260u total:244  pass:222  dwarn:0   dfail:0   fail:10  skip:12 
ro-snb-i7-2620M  total:244  pass:191  dwarn:0   dfail:0   fail:11  skip:42 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1536/

3540447 drm-intel-nightly: 2016y-07m-19d-23h-18m-36s UTC integration manifest
fd82d1c drm/i915/guc: revisit GuC loader message levels
5dd62e6 drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
7022d4f drm: extra printk() wrapper macros

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

Re: [Intel-gfx] [ANNOUNCE] 2016-Q2 release of KVMGT (Was Re: KVMGT - the implementation of ...)

[Jike Song]

Hi all,

We are pleased to announce another update of Intel GVT-g for KVM.

Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core™ processors with 
Intel Graphics processors.  A virtual GPU instance is maintained for each VM, 
with part of performance critical resources directly assigned. The capability 
of running native graphics driver inside a VM, without hypervisor intervention 
in performance critical paths, achieves a good balance among performance, 
feature, and sharing capability.

Repositories:

   - Kernel: https://github.com/01org/igvtg-kernel (2016q2-4.3.0 branch)
   - Qemu: https://github.com/01org/igvtg-qemu (2016q2-2.3.0 branch)

This update consists of:
   - KVMGT stable release for Xeon E3 v4 (Broadwell), E3 v5(Skylake), Intel 
Core™ processors 5th generation (Boadwell) , 6th generation (Skylake)
   - 2D/3D/Media workloads can run simultaneously in multiple guests

Known issues:
   - At least 2GB memory is suggested for Guest Virtual Machine (VM) to run 
most 3D workloads.
   - Using Windows Media Player play videos may cause host crash. Using VLC to 
play .ogg file may cause mosaic or slow response.
   - Suggest to X window mode like xinit instead of lightdm to launch host if 
running heavy workload in both guest and host for more than 6 hours.
   - Change i915.preemption_policy=3 in host kernel cmdline, if you see problem 
when running heavy 3D workloads in multiple Guests (>=3) in some extreme stress 
configuration.


Please subscribe to join the mailing list:
   - https://lists.01.org/mailman/listinfo/igvt-g

Official iGVT-g portal:
   - https://01.org/igvt-g

More information about background, architecture and others about Intel GVT-g, 
can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:
The KVMGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the KVMGT project.


--
Thanks,
Jike

On 04/16/2016 02:31 PM, Jike Song wrote:
> Hi all,
> 
> We are pleased to announce another update of Intel GVT-g for KVM.
> 
> Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
> mediated pass-through, starting from 4th generation Intel Core(TM) processors 
> with Intel Graphics processors.  A virtual GPU instance is maintained for 
> each VM, with part of performance critical resources directly assigned. The 
> capability of running native graphics driver inside a VM, without hypervisor 
> intervention in performance critical paths, achieves a good balance among 
> performance, feature, and sharing capability.
> 
> 
> Repositories:
> 
> Kernel: https://github.com/01org/igvtg-kernel (2016q1-4.3.0 branch)
> Qemu: https://github.com/01org/igvtg-qemu (2016q1-2.3.0 branch)
> 
> 
> This update consists of:
> 
> - KVMGT now has better support for 5th generation (Broadwell) Intel Core(TM) 
> processors, Xeon(R) E3 v4
> - A new feature, QEMU compositor display is added to support display VM in 
> QEMU window. (use i915.enable_vgtbuffer=1 in kernel command line to enable 
> this feature, disabled by default, details please refer to the Setup Guide)
> - 2D/3D/Media workloads can be run simultaneously in multiple guests.
> - Support both Windows Guest and Linux Guest(Win7-32, Win7-64, Win8.1-64, 
> Ubuntu14.04-64)
> - Host Linux kernel has been upgraded from 4.2.0 to 4.3.0 (based on drm-intel)
> - KVMGT has preliminary support for 6th generation (Skylake) Intel Core(TM) 
> processors.
> 
> 
> Known issues:
> 
>- At least 2GB memory is suggested for VM to run most 3D workloads.
>- On some particular platform, assigning >2G memory to VM will cause Linux 
> VM failed to boot up and Windows VM failed to load GFX driver.
>- Using VLC to play .ogg file may cause mosaic or slow response.
>- Running heavy 3D workloads in multiple guests for couple of hours may 
> cause stability issue.(use i915.preemption_policy=3 in host kernel cmd line 
> can work around this stability issue)
> 
> 
> Please subscribe to join the mailing list: 
> https://lists.01.org/mailman/listinfo/igvt-g
> 
> Official iGVT-g portal: https://01.org/igvt-g
> 
> More information about background, architecture and others about Intel GVT-g, 
> can be found at:
> 
> 
> http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
> 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 
> 
> The upstreaming effort of iGVT-g project is ongoing elsewhere, not as a part 
> of this release.
> 
> 
> Note:
> 
> The KVMGT project should be considered a work in progress. As such it is not 
> a complete product nor should it be considered one. Extra care should be 
> taken when testing and configuring a system to use the KVMGT project.
> 
> 
> --
> 

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Debugfs support for GuC logging control

[Goel, Akash]

On 7/19/2016 4:54 PM, Tvrtko Ursulin wrote:


On 10/07/16 14:41, 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.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5e35565..3c9c7f7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2644,6 +2644,35 @@ static int i915_guc_log_dump(struct seq_file
*m, void *data)
  return 0;
  }

+static int
+i915_guc_log_control_set(void *data, u64 val)
+{
+struct drm_device *dev = data;
+struct drm_i915_private *dev_priv = dev->dev_private;


to_i915 should be used.

Sorry for missing this, need to use this at other places also.




+int ret;
+
+ret = mutex_lock_interruptible(>struct_mutex);
+if (ret)
+return ret;
+
+if (!i915.enable_guc_submission || !dev_priv->guc.log.obj) {


Wouldn't guc.log.obj be enough?


Actually failure in allocation of log buffer, at boot time, is not 
considered fatal and submission through GuC is still done.

So i915.enable_guc_submission could be 1 with guc.log.obj as NULL.




+ret = -EINVAL;
+goto end;
+}
+
+intel_runtime_pm_get(dev_priv);
+ret = i915_guc_log_control(dev, val);
+intel_runtime_pm_put(dev_priv);
+
+end:
+mutex_unlock(>struct_mutex);
+return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
+NULL, i915_guc_log_control_set,
+"0x%08llx\n");


Does the readback still work with no get method?


readback will give a 'Permission denied' error




+
  static int i915_edp_psr_status(struct seq_file *m, void *data)
  {
  struct drm_info_node *node = m->private;
@@ -5464,7 +5493,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 8cc31c6..2e3b723 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -193,6 +193,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
   *
@@ -1455,3 +1465,50 @@ void i915_guc_register(struct drm_device *dev)
  guc_log_late_setup(dev);
  mutex_unlock(>struct_mutex);
  }
+
+int i915_guc_log_control(struct drm_device *dev, uint64_t control_val)
+{
+struct drm_i915_private *dev_priv = dev->dev_private;


to_i915

Actually, function should take dev_priv if not even guc depending on the
established convention in the file.


Ok for all the new logging related exported functions, will use dev_priv.


+union guc_log_control log_param;
+int ret;
+
+log_param.logging_enabled = control_val & 0x1;
+log_param.verbosity = (control_val >> 4) & 0xF;
+
+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 -EINVAL;


Hm, disabling while already disabled - why should that return an error?
Might be annoying in scripts.


Just to make the User aware. Ok will suppress this and return 0.



+
+ret = host2guc_logging_control(_priv->guc, log_param.value);
+if (ret < 0) {
+DRM_DEBUG_DRIVER("host2guc action failed\n");


Add ret to the log since it is easy?


fine will do that.

+return ret;
+}
+
+i915.guc_log_level = log_param.verbosity;
+
+/* If log_level was 

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

[Goel, Akash]

On 7/19/2016 4:51 PM, Chris Wilson wrote:

On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote:


On 10/07/16 14:41, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding with GPU reset and re-initializing
GUC. Those logs would be useful to understand why the GPU reset was
initiated.

v2: Rebase.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 9b436fa..8cc31c6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -183,6 +183,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
  *
@@ -1404,6 +1414,28 @@ void i915_guc_capture_logs(struct drm_device *dev)
intel_runtime_pm_put(dev_priv);
 }

+void i915_guc_capture_logs_on_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   mutex_lock(>struct_mutex);


Not sure what are the repercussion of taking the mutex on the
i915_reset_and_wakeup and path (error capture, hangcheck, dont' know
this area well). Check with Chris and Mika I suppose (cc-ed)?




Took the struct_mutex, just to avoid a very remote possibility where
i915_guc_capture_logs_on_reset & debugfs function i915_guc_log_control 
executes concurrently.



Flat out invalid to take struct_mutex on the error capture path, or any
lock at all really (just in case of driver bugs). Consider it to be an
atomic context that may preempt the driver at any point.


Actually I see that i915_reset() too takes the struct_mutex right at the 
beginning and I have plugged the call to 
i915_guc_capture_logs_on_reset() just before that.


Also it is being called after i915_error_wake_up(), so any client 
waiting on a request would have backed off and any new attempt by 
clients to lock the struct_mutex should see i915_reset_in_progress as

true.

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 07/17] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

[Goel, Akash]

On 7/19/2016 5:01 PM, Tvrtko Ursulin wrote:


On 10/07/16 14:41, 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 snaphots 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.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 25c6b9b..43c9900 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1177,6 +1177,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);
  i915_setup_sysfs(dev);
  } else
  DRM_ERROR("Failed to register driver for userspace access!\n");
@@ -1215,6 +1216,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(_priv->drm);
  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 d3dbb8e..9b436fa 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"

@@ -836,12 +838,33 @@ err:

  static void guc_move_to_next_buf(struct intel_guc *guc)
  {
-return;
+/* Make sure our updates are in the sub buffer are visible when
+ * Consumer sees a newly produced sub buffer.
+ */
+smp_wmb();
+
+/* All data has been written, so now move the offset of sub
buffer. */
+relay_reserve(guc->log.relay_chan, guc->log.obj->base.size);
+
+/* Switch to the next sub buffer */
+relay_flush(guc->log.relay_chan);
  }

  static void* guc_get_write_buffer(struct intel_guc *guc)
  {
-return NULL;
+/* FIXME: Cover the check under a lock ? */
+if (!guc->log.relay_chan)
+return NULL;
+
+/* Just get the base address of a new sub buffer and copy data
into it
+ * ourselves. NULL will be returned in no-overwrite mode, if all sub
+ * buffers are full. Could have used the relay_write() to indirectly
+ * copy the data, but that would have been bit convoluted, as we
need to
+ * write to only certain locations inside a sub buffer which
cannot be
+ * done without using relay_reserve() along with relay_write().
So its
+ * better to use relay_reserve() alone.
+ */
+return relay_reserve(guc->log.relay_chan, 0);
  }

  static void guc_read_update_log_buffer(struct drm_device *dev)
@@ -906,6 +929,119 @@ static void guc_read_update_log_buffer(struct
drm_device *dev)
  guc_move_to_next_buf(guc);
  }

+/*
+ * 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 

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

[Goel, Akash]

On 7/19/2016 4:28 PM, Tvrtko Ursulin wrote:


On 10/07/16 14:41, 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.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.c|  13 +++
  drivers/gpu/drm/i915/i915_guc_submission.c | 148
+
  drivers/gpu/drm/i915/i915_irq.c|   5 +-
  drivers/gpu/drm/i915/intel_guc.h   |   3 +
  4 files changed, 167 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index b9a8117..25c6b9b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -791,8 +791,20 @@ static int i915_workqueues_init(struct
drm_i915_private *dev_priv)
  if (dev_priv->hotplug.dp_wq == NULL)
  goto out_free_wq;

+if (HAS_GUC_SCHED(dev_priv)) {
+/* Need a dedicated wq to process log buffer flush interrupts
+ * from GuC without much delay so as to avoid any loss of logs.
+ */
+dev_priv->guc.log.wq =
+alloc_ordered_workqueue("i915-guc_log", 0);
+if (dev_priv->guc.log.wq == NULL)
+goto out_free_hotplug_dp_wq;
+}
+
  return 0;

+out_free_hotplug_dp_wq:
+destroy_workqueue(dev_priv->hotplug.dp_wq);
  out_free_wq:
  destroy_workqueue(dev_priv->wq);
  out_err:
@@ -803,6 +815,7 @@ out_err:

  static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
  {
+destroy_workqueue(dev_priv->guc.log.wq);


I am ignoring the wq parts of the patch since the next series may look
different in this respect.

However you may need to have wq destruction under the same HAS_GUC_SCHED
condition as when you create it.


Thanks, will do.
Sorry, my bad.



  destroy_workqueue(dev_priv->hotplug.dp_wq);
  destroy_workqueue(dev_priv->wq);
  }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 0bac172..d3dbb8e 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
   *
@@ -825,6 +834,123 @@ err:
  return NULL;
  }

+static void guc_move_to_next_buf(struct intel_guc *guc)
+{
+return;
+}
+
+static void* guc_get_write_buffer(struct intel_guc *guc)
+{
+return NULL;
+}
+
+static void guc_read_update_log_buffer(struct drm_device *dev)


dev_priv should be passed in for driver internal functions.


+{
+struct drm_i915_private *dev_priv = dev->dev_private;
+struct intel_guc *guc = _priv->guc;
+struct guc_log_buffer_state *log_buffer_state,
*log_buffer_copy_state;
+struct guc_log_buffer_state log_buffer_state_local;
+void *src_data_ptr, *dst_data_ptr;
+u32 i, buffer_size;
+
+if (!guc->log.obj || !guc->log.buf_addr)
+return;
+
+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_copy_state = guc_get_write_buffer(guc);


This will return NULL so the loop below doesn't do anything much. I
assume at this point in the patch series things are not wired up yet?

The below loop will still update the state structures, lying in the 
first page of GuC log buffer.

There is no local buffer yet to store the logs.


+
+/* Actual logs are present from the 2nd page */
+src_data_ptr += PAGE_SIZE;
+dst_data_ptr += PAGE_SIZE;
+
+for (i = 0; i < GUC_MAX_LOG_BUFFER; i++) {
+log_buffer_state_local = *log_buffer_state;
+buffer_size = log_buffer_state_local.size;
+
+if (log_buffer_copy_state) {
+/* First copy the state structure */
+ 

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Jonathan Corbet]

On Tue, 19 Jul 2016 13:42:54 +0200
Daniel Vetter  wrote:

> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
> 
> The only way to get useful output out of sphinx to be able to root
> cause the error seems to be enabling keep_warnings, which inserts
> a System Message into the actual output. Not pretty at all, but I
> don't really want to fix up core rst/sphinx code, and this gets the job
> done meanwhile.

I'll go ahead and apply this.  It *would* be nice, someday, to figure out
how to get proper info out for warnings directly, but until somebody gets
there...

Thanks,

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

[Intel-gfx] [PATCH i-g-t] tools/intel_reg: enable quiet option for mmio

[clinton . a . taylor]

From: Clint Taylor 

Skip decode options and formatting when the quiet option is used during
mmio reads. Makes intel_reg usable by scripts to return MMIO values.

Signed-off-by: Clint Taylor 
---
 tools/intel_reg.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/intel_reg.c b/tools/intel_reg.c
index 73fbd6d..e869292 100644
--- a/tools/intel_reg.c
+++ b/tools/intel_reg.c
@@ -202,7 +202,9 @@ static void dump_decode(struct config *config, struct reg 
*reg, uint32_t val)
 
if (reg->port_desc.port == PORT_MMIO) {
/* Omit port name for MMIO, optionally include MMIO offset. */
-   if (reg->mmio_offset)
+   if (config->verbosity < 0)
+   printf("0x%08x\n", val);
+   else if (reg->mmio_offset)
printf("%24s (0x%08x:0x%08x): 0x%08x%s",
   reg->name ?: "",
   reg->mmio_offset, reg->addr,
@@ -706,6 +708,9 @@ static int read_reg_spec(struct config *config)
struct stat st;
int r;
 
+   if (config->verbosity < 0)
+   goto builtin;
+
path = config->specfile;
if (!path)
path = getenv("INTEL_REG_SPEC");
-- 
2.1.2

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

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

[Vivi, Rodrigo]

Marc kicked me to the other side of the fence. I'm now cheering for the
symbolic links back again.

We cannot block users to use some new firmware version if they
like/want/need. 

Also, also as Chris highlighted the hardcoded version doesn't help the
bisect but make it unlikely. I don't believe any users out there will
save and install all firmware versions when bisecting.

This is not a new problem and we can use the linux libraries as an
example here. like libmeh.so.2.1, libmeh.so.2 link and libmeh.so link.

We don't hardcode all userspace libraries in the userspace side for the 
graphics stack and we do not validate all possible combinations of libdrm, 
mesa, ddx, libva, etc... Why should we need this with firmware?

Also I'd like to take this libmeh.so example here and go even further with the 
symbolic link fixing https://bugs.freedesktop.org/show_bug.cgi?id=96800 in the 
right way:

- providing a firmware_platform.bin that is a symbolic link to the lastest 
firmware_platform_.bin (our soname) that is a symbolic link to 
firmware_platform__.bin 

Our driver should also search for the firmware_platform.bin and have a
check for the minimal version like userspace libraries does.

In any case our drm_debug should have the information of the version
loaded and version expected, in case users find issues that leads us to
blame the firmware versions.

Thoughts?


On Tue, 2016-07-19 at 14:58 -0700, Herbert, Marc wrote:
> Versioning dependencies isn't exactly a new problem outside the
> kernel,
> so please allow me to share my experience below. Thanks to Rodrigo
> for
> glancing over this email and preventing me from writing anything too
> stupid or that was said already.
> 
> 
> > 
> > > 
> > > The firmware should be side-ways compatible for
> > > everything with the same minor version (thus resolvable from the
> > > same
> > > symlink), right?
> > From the same major version I guess it should, but the reason
> > things
> > don't work that way is why we introduced version white listing.
> In an ideal world you look only at the major version of your
> dependencies
> since they mark ABI changes. This is what the firmware symbolic links
> do.
> 
> Back to the real world, some minor versions are so bad that you
> really don't want to inflict them on your users. So you go and
> blacklist at
> the hardest level: in the source code itself. Fine.
> However keep in mind blacklisting should stay exceptional since
> leaking
> system configuration into source code means taking away from users
> control
> they normally have. You need a pretty strong reason for this like
> some very
> obscure bugs that can't be Googled easily or some "less than alpha"
> version.
> Please keep in mind it's a hack/workaround: blacklisting shouldn't
> never become a normal policy.
> 
> On the other hand, never WHITE-list since it blocks users from
> *UPGRADING*
> the dependency.
> 
> If you're tempted to white-list the most current version then just
> blacklist
> all versions older than today and job done. White-listing is making a
> very bold
> and most likely wrong statement about the future: that no future
> revision
> of the dependency will ever be a pure bugfix and fully compatible
> with the
> current revision.
> 
> Please don't try to abstract away the independent versioning of the
> firmware and make it look like firmware and kernel are developed,
> versioned,
> released and validated on the same cycles and by the same team.
> Granted: it's important to publish which versions
> were validated together. However most software projects don't embed
> their validation results in their source code as a default policy,
> there are better ways to document things like this.
> 
> > 
> > > 
> > > No. You want to be changing exactly one variable, which means
> > > leaving
> > > the firmware constant.
> Yes! Constant at least for a range large enough for bisections to be
> practical (ABI changes happen too).
> 
> > 
> > Hm, not sure. When looking for a working snapshot you also want to
> > consider bugs introduced by the firmware itself. This is in a way
> > the
> > exact reason why we want stricter control on the firmware version
> > and
> > introduced a white list. This also means that loading a firmware
> > version other than what the driver allows (at a given commit) won't
> > work anyway.
> Please trust and respect your users. If someone is technical and
> motivated
> enough to bisect the kernel and/or the firmware then please don't get
> in her way and trust that she will: 1. try the latest releases first,
> and 2. more generally have some clue about what she's doing. Or at
> least learn quickly enough.
> 
> Again feel free to blacklist the known broken past but don't block
> the
> unknown future, thanks!
> 
> Marc
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

[Herbert, Marc]

Versioning dependencies isn't exactly a new problem outside the kernel,
so please allow me to share my experience below. Thanks to Rodrigo for
glancing over this email and preventing me from writing anything too
stupid or that was said already.


>> The firmware should be side-ways compatible for
>> everything with the same minor version (thus resolvable from the same
>> symlink), right?
> 
> From the same major version I guess it should, but the reason things
> don't work that way is why we introduced version white listing.

In an ideal world you look only at the major version of your dependencies
since they mark ABI changes. This is what the firmware symbolic links do.

Back to the real world, some minor versions are so bad that you
really don't want to inflict them on your users. So you go and blacklist at
the hardest level: in the source code itself. Fine.
However keep in mind blacklisting should stay exceptional since leaking
system configuration into source code means taking away from users control
they normally have. You need a pretty strong reason for this like some very
obscure bugs that can't be Googled easily or some "less than alpha" version.
Please keep in mind it's a hack/workaround: blacklisting shouldn't
never become a normal policy.

On the other hand, never WHITE-list since it blocks users from *UPGRADING*
the dependency.

If you're tempted to white-list the most current version then just blacklist
all versions older than today and job done. White-listing is making a very bold
and most likely wrong statement about the future: that no future revision
of the dependency will ever be a pure bugfix and fully compatible with the
current revision.

Please don't try to abstract away the independent versioning of the
firmware and make it look like firmware and kernel are developed, versioned,
released and validated on the same cycles and by the same team.
Granted: it's important to publish which versions
were validated together. However most software projects don't embed
their validation results in their source code as a default policy,
there are better ways to document things like this.

>> No. You want to be changing exactly one variable, which means leaving
>> the firmware constant.

Yes! Constant at least for a range large enough for bisections to be
practical (ABI changes happen too).

> Hm, not sure. When looking for a working snapshot you also want to
> consider bugs introduced by the firmware itself. This is in a way the
> exact reason why we want stricter control on the firmware version and
> introduced a white list. This also means that loading a firmware
> version other than what the driver allows (at a given commit) won't
> work anyway.

Please trust and respect your users. If someone is technical and motivated
enough to bisect the kernel and/or the firmware then please don't get
in her way and trust that she will: 1. try the latest releases first,
and 2. more generally have some clue about what she's doing. Or at
least learn quickly enough.

Again feel free to blacklist the known broken past but don't block the
unknown future, thanks!

Marc

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove misleading CSR firmware loading docs

[Daniel Vetter]

On Tue, Jul 19, 2016 at 07:43:56PM +0100, Dave Gordon wrote:
> On 14/07/16 15:15, Daniel Vetter wrote:
> > I forgot to remove these when reworking the firmware loading sequence
> > last year. The new sequence is that we load firmware, and if it's not
> > there we entirely (and permanently) fail dmc setup.
> > 
> > Reported-by: Dave Gordon 
> > Signed-off-by: Daniel Vetter 
> > ---
> >   drivers/gpu/drm/i915/intel_csr.c | 7 ---
> >   1 file changed, 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index c3b33a10c15c..1ea0e1f43397 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -32,13 +32,6 @@
> >* onwards to drive newly added DMC (Display microcontroller) in display
> >* engine to save and restore the state of display engine when it enter 
> > into
> >* low-power state and comes back to normal.
> > - *
> > - * Firmware loading status will be one of the below states: 
> > FW_UNINITIALIZED,
> > - * FW_LOADED, FW_FAILED.
> > - *
> > - * Once the firmware is written into the registers status will be moved 
> > from
> > - * FW_UNINITIALIZED to FW_LOADED and for any erroneous condition status 
> > will
> > - * be moved to FW_FAILED.
> >*/
> > 
> >   #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
> 
> LGTM.
> 
> Reviewed-by: Dave Gordon 

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

Which is more of a step in the right direction to fixing all of the
underrun issues we're currently seeing with skl

Changes since v1:
- Remove mutex_lock/mutex_unlock since they don't do anything and we're
  not touching global state
- Move skl_write_cursor_wm/skl_write_plane_wm functions into intel_pm.c, make
  externally visible
- Add skl_write_plane_wm calls to skl_update_plane
- Fix conditional for for loop in skl_write_plane_wm (level < max_level
  should be level <= max_level)
- Make diagram in commit more accurate to what's actually happening

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c |  5 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 48 +---
 drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
 4 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb7d8fc5..1481b2b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = x_offset;
intel_crtc->adjusted_y = y_offset;
 
+   skl_write_plane_wm(intel_crtc, 0);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
@@ -10242,6 +10244,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
+   if (IS_SKYLAKE(dev_priv))
+   skl_write_cursor_wm(intel_crtc);
+
if (plane_state && plane_state->visible) {
cntl = MCURSOR_GAMMA_ENABLE;
switch (plane_state->base.crtc_w) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851..f1f54d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1709,6 +1709,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void skl_write_cursor_wm(struct intel_crtc *intel_crtc);
+void skl_write_plane_wm(struct intel_crtc *intel_crtc, int plane);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c 

Re: [Intel-gfx] [PATCH] drm/i915: Remove misleading CSR firmware loading docs

[Dave Gordon]

On 14/07/16 15:15, Daniel Vetter wrote:

I forgot to remove these when reworking the firmware loading sequence
last year. The new sequence is that we load firmware, and if it's not
there we entirely (and permanently) fail dmc setup.

Reported-by: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_csr.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index c3b33a10c15c..1ea0e1f43397 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -32,13 +32,6 @@
   * onwards to drive newly added DMC (Display microcontroller) in display
   * engine to save and restore the state of display engine when it enter into
   * low-power state and comes back to normal.
- *
- * Firmware loading status will be one of the below states: FW_UNINITIALIZED,
- * FW_LOADED, FW_FAILED.
- *
- * Once the firmware is written into the registers status will be moved from
- * FW_UNINITIALIZED to FW_LOADED and for any erroneous condition status will
- * be moved to FW_FAILED.
   */

  #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"


LGTM.

Reviewed-by: Dave Gordon 

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

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

[Dave Gordon]

On 15/07/16 14:13, Tvrtko Ursulin wrote:


On 29/06/16 17:00, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote:


On 29/06/16 16:34, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Replace per-engine initialization with a common half-programatic,
half-data driven code for ease of maintenance and compactness.

Signed-off-by: Tvrtko Ursulin 


This is the biggest pill to swallow (since our 5x5 table is only
sparsely populated), but it looks correct, and more importantly
easier to
read.


Yeah I was out of ideas on how to improve it. Fresh mind needed to
try and spot a pattern in how MI_SEMAPHORE_SYNC_* and GEN6_*SYNC map
to bits and registers respectively, and write it as a function.


It's actually a very simple cyclic function based on register
offset = base + (signaler hw_id - waiter hw_id - 1) % num_rings.

(The only real challenge is picking the direction.)

commit c8c99b0f0dea1ced5d0e10cdb9143356cc16b484
Author: Ben Widawsky 
Date:   Wed Sep 14 20:32:47 2011 -0700

 drm/i915: Dumb down the semaphore logic

 While I think the previous code is correct, it was hard to follow
and
 hard to debug. Since we already have a ring abstraction, might as
well
 use it to handle the semaphore updates and compares.


Doesn't seem to fit, or I just can't figure it out. Needs two functions
to get rid of the table:

f1(0, 1) = 2
f1(0, 2) = 0
f1(0, 3) = 2
f1(1, 0) = 0
f1(1, 2) = 2
f1(1, 3) = 1
f1(2, 0) = 2
f1(2, 1) = 0
f1(2, 3) = 0
f1(3, 0) = 1
f1(3, 1) = 1
f1(3, 2) = 1

and:

f2(0, 1) = 1
f2(0, 2) = 0
f2(0, 3) = 1
f2(1, 0) = 0
f2(1, 2) = 1
f2(1, 3) = 2
f2(2, 0) = 1
f2(2, 1) = 0
f2(2, 3) = 0
f2(3, 0) = 2
f2(3, 1) = 2
f2(3, 2) = 2

A weekend math puzzle for someone? :)

Regards,
Tvrtko


Here's the APL expression for (the transpose of) f2, with -1's filled in 
along the leading diagonal (you need ⎕io←0 so the ⍳-vectors are in origin 0)


  {¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

┌┬┬┬┐
│¯1 0 1 2│1 ¯1 0 2│0 1 ¯1 2│1 2 0 ¯1│
└┴┴┴┘

or transposed back so that the first argument is the row index and the 
second is the column index:


  ⍉↑{¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

¯1  1  0  1
 0 ¯1  1  2
 1  0 ¯1  0
 2  2  2 ¯1

http://tryapl.org/?a=%u2349%u2191%7B%AF1+%28%u2375%u2260%u23734%29%u2340%282%7C%u2375%29%u233D%28%u233D%u2363%281%3D%u2375%29%291+%u23733%7D%A8%u23734

f1 is trivially derived from this by the observation that f1 is just f2 
with the 1's and 2's interchanged.


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

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/bxt: Fix performance due to bogus MOCS entry

[Imre Deak]

On pe, 2016-07-01 at 14:54 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/bxt: Fix performance due to bogus MOCS entry
> URL   : https://patchwork.freedesktop.org/series/9377/
> State : warning
> 
> == Summary ==
> 
> Series 9377v1 drm/i915/bxt: Fix performance due to bogus MOCS entry
> http://patchwork.freedesktop.org/api/1.0/series/9377/revisions/1/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> fail   -> PASS   (ro-byt-n2820)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)

Unrelated platform.

I pushed the patches to drm-intel-next-queued, thanks for the reviews
and tests.

--Imre

> Subgroup suspend-read-crc-pipe-c:
> skip   -> PASS   (fi-skl-i5-6260u)
> 
> fi-kbl-
> qkkr  total:229  pass:160  dwarn:29  dfail:0   fail:0   skip:40 
> fi-skl-i5-
> 6260u  total:229  pass:204  dwarn:0   dfail:0   fail:0   skip:25 
> fi-skl-i7-
> 6700k  total:229  pass:190  dwarn:0   dfail:0   fail:0   skip:39 
> ro-bdw-i5-
> 5250u  total:229  pass:204  dwarn:4   dfail:1   fail:0   skip:20 
> ro-bdw-i7-
> 5557U  total:229  pass:204  dwarn:1   dfail:1   fail:0   skip:23 
> ro-bdw-i7-
> 5600u  total:229  pass:190  dwarn:0   dfail:1   fail:0   skip:38 
> ro-bsw-
> n3050 total:229  pass:177  dwarn:0   dfail:1   fail:2   skip:49 
> ro-byt-
> n2820 total:229  pass:181  dwarn:0   dfail:1   fail:2   skip:45 
> ro-hsw-i3-
> 4010u  total:229  pass:197  dwarn:0   dfail:1   fail:0   skip:31 
> ro-hsw-i7-
> 4770r  total:229  pass:197  dwarn:0   dfail:1   fail:0   skip:31 
> ro-ilk-i7-
> 620lm  total:229  pass:157  dwarn:0   dfail:1   fail:1   skip:70 
> ro-ilk1-i5-
> 650   total:224  pass:157  dwarn:0   dfail:1   fail:1   skip:65 
> ro-ivb-i7-
> 3770   total:229  pass:188  dwarn:0   dfail:1   fail:0   skip:40 
> ro-skl3-i5-6260u
> total:229  pass:208  dwarn:1   dfail:1   fail:0   skip:19 
> ro-snb-i7-
> 2620M  total:229  pass:179  dwarn:0   dfail:1   fail:1   skip:48 
> fi-hsw-i7-4770k failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1361/
> 
> a755d6c drm-intel-nightly: 2016y-07m-01d-13h-54m-24s UTC integration
> manifest
> dedf573 drm/i915: Give proper names to MOCS entries
> ab3eabf drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect
> MOCS config
> c73e12a drm/i915/gen9: Clean up MOCS table definitions
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

[Rob Clark]

On Tue, Jul 19, 2016 at 1:19 PM, Matt Roper  wrote:
> On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
>> Now that we update the watermark values atomically, we still need to fix
>> the case of how we update watermarks when we haven't added or removed
>> pipes.
>>
>> When we haven't added or removed any pipes, we don't need to worry about
>> the ddb allocation changing. As such there's no order of flushing pipes
>> we have to guarantee; e.g. each pipe can be flushed at the earliest
>> given oppurtunity. This means all we have to do is:
>>
>>  - Calculate the new wm values
>>  - Update each plane's settings and wm values
>>  - Arm the plane's registers to update at the next vblank
>>
>> Right now the watermark code takes an additional few steps:
>>  - Rewrite the ddb allocations
>>  - Arm all of the planes for another update at the start of the next
>>vblank
>>  - *Potentially underrun later if we update the wm registers before the
>>start of the next vblank*
>>
>> This patch prevents us from marking pipes as dirty unless the number of
>> pipes, and with that the ddb allocation, has actually changed. This
>> results in us skipping the additional steps, preventing the hardware
>> from using any intermediate values during each wm update.
>>
>> This also fixes cursors causing monitors to flicker on Skylake. Finally.
>>
>
> This doesn't look right to me.  It's true that we don't need to worry
> about *inter*-pipe DDB allocation changing, but *intra*-pipe DDB
> allocations can still change.  We may be resizing planes, changing
> scalers, enabling/disabling new planes, etc.  Those operations change
> the DDB allocations for the planes within the fixed pipe allocation.
> The watermark values will also change accordingly in that case.
>

fwiw, msm/mdp5 has potentially similar constraints w/ SMP block
allocation (which seems like basically the same thing as DDB)..  we
just disallow changing width/bpp/etc on an active plane, so userspace
would pick a different plane (or skip the plane for one frame of
composition)..

not sure if that would help.. maybe we are more limited in not
actually being able to safely change SMP allocation on an active
plane/pipe.  But treating it as a disable of current pipe and switch
to new pipe is convenient, rather than dealing with all the cases that
could effect SMP block assignment.

BR,
-R

>
> Matt
>
>> Signed-off-by: Lyude Paul 
>> Cc: sta...@vger.kernel.org
>> Cc: Ville Syrjälä 
>> Cc: Daniel Vetter 
>> Cc: Radhakrishna Sripada 
>> Cc: Hans de Goede 
>> Cc: Matt Roper 
>> ---
>>  drivers/gpu/drm/i915/intel_pm.c | 16 +++-
>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 3a7709c..92158e3 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -4086,12 +4086,18 @@ skl_compute_wm(struct drm_atomic_state *state)
>>   if (ret)
>>   return ret;
>>
>> - if (changed)
>> - results->dirty_pipes |= drm_crtc_mask(crtc);
>> + /*
>> +  * We don't need to do any additional setup for the pipes if we
>> +  * haven't changed the number of active crtcs
>> +  */
>> + if (intel_state->active_pipe_changes) {
>> + if (changed)
>> + results->dirty_pipes |= drm_crtc_mask(crtc);
>>
>> - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>> - /* This pipe's WM's did not change */
>> - continue;
>> + if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>> + /* This pipe's WM's did not change */
>> + continue;
>> + }
>>
>>   intel_cstate->update_wm_pre = true;
>>   skl_compute_wm_results(crtc->dev, pipe_wm, results, 
>> intel_crtc);
>> --
>> 2.7.4
>>
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

[Matt Roper]

On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
> Now that we update the watermark values atomically, we still need to fix
> the case of how we update watermarks when we haven't added or removed
> pipes.
> 
> When we haven't added or removed any pipes, we don't need to worry about
> the ddb allocation changing. As such there's no order of flushing pipes
> we have to guarantee; e.g. each pipe can be flushed at the earliest
> given oppurtunity. This means all we have to do is:
> 
>  - Calculate the new wm values
>  - Update each plane's settings and wm values
>  - Arm the plane's registers to update at the next vblank
> 
> Right now the watermark code takes an additional few steps:
>  - Rewrite the ddb allocations
>  - Arm all of the planes for another update at the start of the next
>vblank
>  - *Potentially underrun later if we update the wm registers before the
>start of the next vblank*
> 
> This patch prevents us from marking pipes as dirty unless the number of
> pipes, and with that the ddb allocation, has actually changed. This
> results in us skipping the additional steps, preventing the hardware
> from using any intermediate values during each wm update.
> 
> This also fixes cursors causing monitors to flicker on Skylake. Finally.
> 

This doesn't look right to me.  It's true that we don't need to worry
about *inter*-pipe DDB allocation changing, but *intra*-pipe DDB
allocations can still change.  We may be resizing planes, changing
scalers, enabling/disabling new planes, etc.  Those operations change
the DDB allocations for the planes within the fixed pipe allocation.
The watermark values will also change accordingly in that case.


Matt

> Signed-off-by: Lyude Paul 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3a7709c..92158e3 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4086,12 +4086,18 @@ skl_compute_wm(struct drm_atomic_state *state)
>   if (ret)
>   return ret;
>  
> - if (changed)
> - results->dirty_pipes |= drm_crtc_mask(crtc);
> + /*
> +  * We don't need to do any additional setup for the pipes if we
> +  * haven't changed the number of active crtcs
> +  */
> + if (intel_state->active_pipe_changes) {
> + if (changed)
> + results->dirty_pipes |= drm_crtc_mask(crtc);
>  
> - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
> - /* This pipe's WM's did not change */
> - continue;
> + if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
> + /* This pipe's WM's did not change */
> + continue;
> + }
>  
>   intel_cstate->update_wm_pre = true;
>   skl_compute_wm_results(crtc->dev, pipe_wm, results, intel_crtc);
> -- 
> 2.7.4
> 

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

[Matt Roper]

On Tue, Jul 19, 2016 at 12:30:55PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
> 
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
> 
> With this in mind, up until now we've been updating watermarks on skl
> like this:
> 
>  - Calculate new watermark values in skl_compute_wm()
> 
>  - Update non-watermark settings for each plane in
>skylake_update_primary_plane()/i9xx_update_cursor()
> 
>  - Arm plane registers to update at the start of the next vblank in
>skylake_update_primary_plane()/i9xx_update_cursor()
> 
>  - *Possibly underrun here, since the plane may now have updated it's
>settings using the old and insufficient watermark values*
> 
>  - Update watermark settings in skl_write_wm_values()
> 
>  - *Possibly underrun here as well if we've passed a vblank,
>causing the hardware to get stuck running on intermediate wm values*
> 
>  - Finally arm plane registers so they update to the correct values at
>the start of the next vblank in skl_wm_flush_pipe()

I think you're on the right track with this patch, but I don't think the
sequence of events is quite what you describe in the commit message
here.  The calls to skylake_update_primary_plane()/i9xx_update_cursor()
are while we're under vblank evasion, which happens during

  finish_atomic_commit() -> drm_atomic_helper_commit_planes_on_crtc()

Then gen9 watermarks get written during intel_pre_plane_update() for
non-modesets or during crtc_enable for modesets.  So I believe the
actual sequence of events is:

non-modeset {
 - calculate (during atomic check phase)
 - finish_atomic_commit:
   - intel_pre_plane_update:
  - intel_update_watermarks()
   - {vblank happens; new watermarks + old plane values => underrun }
   - drm_atomic_helper_commit_planes_on_crtc:
  - start vblank evasion
  - write new plane registers
  - end vblank evasion
}

or

modeset {
 - calculate (during atomic check phase)
 - finish_atomic_commit:
   - crtc_enable:
  - intel_update_watermarks()
   - {vblank happens; new watermarks + old plane values => underrun }
   - drm_atomic_helper_commit_planes_on_crtc:
  - start vblank evasion
  - write new plane registers
  - end vblank evasion
}

So you're right that fundamentally the problem arises from the
watermarks not being updated under vblank evasion when the corresponding
plane updates happen (so we might wind up with new watermarks before
we've actually switched our plane registers if a vblank sneaks in in the
meantime).  The sequence is just slightly different from the way you'd
listed it out.

> 
> Now we update watermarks atomically like this:
> 
>  - Calculate new watermark values in skl_compute_wm()
> 
>  - Update watermark values for each plane in
>skylake_write_plane_wm()/skylake_write_cursor_wm()
> 
>  - Update all the other values for the plane (position, address, etc.)
>in skylake_update_primary_plane()/i9xx_update_cursor()

Do we also need it in skl_update_plane() (from intel_sprite.c)?

> 
>  - Arm plane registers (including the watermark settings) to update at
>the start of the next vblank in
>skylake_update_primary_plane()/i9xx_update_cursor()
> 
> Which is more of a step in the right direction to fixing all of the
> underrun issues we're currently seeing with skl
> 
> Signed-off-by: Lyude Paul 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede  
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47 
> 
>  drivers/gpu/drm/i915/intel_pm.c  | 15 +---
>  2 files changed, 48 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index fb7d8fc5..3d2c125 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2971,6 +2971,27 @@ u32 skl_plane_ctl_rotation(unsigned int rotation)
>   return 0;
>  }
>  
> +static void skylake_write_plane_wm(struct intel_crtc *intel_crtc,
> +int plane)
> +{
> + struct drm_crtc *crtc = _crtc->base;
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct skl_wm_values *wm = 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Fix (most) pipe underruns, properly this time

[Patchwork]

== Series Details ==

Series: drm/i915/skl: Fix (most) pipe underruns, properly this time
URL   : https://patchwork.freedesktop.org/series/10059/
State : failure

== Summary ==

Applying: drm/i915/skl: Update plane watermarks atomically during plane updates
fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_pm.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/skl: Update plane watermarks atomically during 
plane updates
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: success for drm: drm_connector->s/connector_id/index/ for consistency (rev2)

[Patchwork]

== Series Details ==

Series: drm: drm_connector->s/connector_id/index/ for consistency (rev2)
URL   : https://patchwork.freedesktop.org/series/10029/
State : success

== Summary ==

Series 10029v2 drm: drm_connector->s/connector_id/index/ for consistency
http://patchwork.freedesktop.org/api/1.0/series/10029/revisions/2/mbox

Test gem_sync:
Subgroup basic-store-each:
fail   -> DMESG-FAIL (ro-bdw-i7-5600u)

fi-hsw-i7-4770k  total:243  pass:213  dwarn:0   dfail:0   fail:10  skip:20 
fi-kbl-qkkr  total:243  pass:177  dwarn:27  dfail:2   fail:9   skip:28 
fi-skl-i5-6260u  total:243  pass:222  dwarn:0   dfail:0   fail:9   skip:12 
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26 
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40 
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13 
ro-bdw-i7-5557U  total:244  pass:218  dwarn:2   dfail:0   fail:10  skip:14 
ro-bdw-i7-5600u  total:244  pass:201  dwarn:0   dfail:1   fail:10  skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:194  dwarn:0   dfail:0   fail:12  skip:38 
ro-hsw-i3-4010u  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24 
ro-hsw-i7-4770r  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24 
ro-ilk-i7-620lm  total:244  pass:169  dwarn:0   dfail:0   fail:12  skip:63 
ro-ilk1-i5-650   total:239  pass:170  dwarn:0   dfail:0   fail:11  skip:58 
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:11  skip:33 
ro-snb-i7-2620M  total:244  pass:190  dwarn:0   dfail:0   fail:12  skip:42 
ro-skl3-i5-6260u failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1534/

63a drm-intel-nightly: 2016y-07m-19d-13h-02m-39s UTC integration manifest
0b87802 drm: drm_connector->s/connector_id/index/ for consistency

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

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..e299b64 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -726,8 +724,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
i915_reg_t drbreg = GEN8_DRBREGL(i);
@@ -819,8 +817,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -998,7 +994,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 1/3] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon 
Reviewed-by: Eric Engestrom 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865..3669cdd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -162,6 +162,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -187,12 +207,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 3/3] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2:
different permutation of levels :)
v3:
convert a couple of "this shouldn't happen" messages to WARN()
[Tvrtko Ursulin].

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..a7901a6 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -571,7 +571,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -583,7 +583,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -593,7 +593,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -602,14 +602,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTE("Firmware is 

[Intel-gfx] [PATCH 0/2] drm/i915/skl: Fix (most) pipe underruns, properly this time

[Lyude]

Unfortunately as a few of you are aware, Skylake is still very prone to pipe
underruns. Most of this comes from not doing things atomically enough (e.g.
needing to ensure that we update watermarks with other plane attributes, not
forcefully flushing pipes until we need to, etc.). Now that I've finally got a
grasp on how double buffered registers, arming registers, etc. works on skl,
I've written up patches that fix most of the pipe underruns on Skylake.

When I say "most", I'm referring to the fact that I still seem to be able to
reproduce pipe underruns, but this seems to be strictly exclusive to when pipes
are being disabled. This means things *still* need to be made more atomic
(sigh), but at least this is a start.

Testing this series with a chamelium[1], mainly so I could heavily stress test
the hotplugging of displays, I'm no longer able to reproduce pipe underruns
when enabling another pipe. I've also tried reproducing underruns using xdotool
to move the cursor in X from one monitor to another as quickly as possible
(e.g. > 60 fps), and am no longer able to reproduce underruns there either with
this patch series.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 

[1]: https://www.chromium.org/chromium-os/testing/chamelium

Lyude (2):
  drm/i915/skl: Update plane watermarks atomically during plane updates
  drm/i915/skl: Don't mark pipes as dirty unless we've added/removed
pipes

 drivers/gpu/drm/i915/intel_display.c | 47 
 drivers/gpu/drm/i915/intel_pm.c  | 31 +---
 2 files changed, 59 insertions(+), 19 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

[Lyude]

Now that we update the watermark values atomically, we still need to fix
the case of how we update watermarks when we haven't added or removed
pipes.

When we haven't added or removed any pipes, we don't need to worry about
the ddb allocation changing. As such there's no order of flushing pipes
we have to guarantee; e.g. each pipe can be flushed at the earliest
given oppurtunity. This means all we have to do is:

 - Calculate the new wm values
 - Update each plane's settings and wm values
 - Arm the plane's registers to update at the next vblank

Right now the watermark code takes an additional few steps:
 - Rewrite the ddb allocations
 - Arm all of the planes for another update at the start of the next
   vblank
 - *Potentially underrun later if we update the wm registers before the
   start of the next vblank*

This patch prevents us from marking pipes as dirty unless the number of
pipes, and with that the ddb allocation, has actually changed. This
results in us skipping the additional steps, preventing the hardware
from using any intermediate values during each wm update.

This also fixes cursors causing monitors to flicker on Skylake. Finally.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3a7709c..92158e3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4086,12 +4086,18 @@ skl_compute_wm(struct drm_atomic_state *state)
if (ret)
return ret;
 
-   if (changed)
-   results->dirty_pipes |= drm_crtc_mask(crtc);
+   /*
+* We don't need to do any additional setup for the pipes if we
+* haven't changed the number of active crtcs
+*/
+   if (intel_state->active_pipe_changes) {
+   if (changed)
+   results->dirty_pipes |= drm_crtc_mask(crtc);
 
-   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
-   /* This pipe's WM's did not change */
-   continue;
+   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
+   /* This pipe's WM's did not change */
+   continue;
+   }
 
intel_cstate->update_wm_pre = true;
skl_compute_wm_results(crtc->dev, pipe_wm, results, intel_crtc);
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

 - Calculate new watermark values in skl_compute_wm()

 - Update non-watermark settings for each plane in
   skylake_update_primary_plane()/i9xx_update_cursor()

 - Arm plane registers to update at the start of the next vblank in
   skylake_update_primary_plane()/i9xx_update_cursor()

 - *Possibly underrun here, since the plane may now have updated it's
   settings using the old and insufficient watermark values*

 - Update watermark settings in skl_write_wm_values()

 - *Possibly underrun here as well if we've passed a vblank,
   causing the hardware to get stuck running on intermediate wm values*

 - Finally arm plane registers so they update to the correct values at
   the start of the next vblank in skl_wm_flush_pipe()

Now we update watermarks atomically like this:

 - Calculate new watermark values in skl_compute_wm()

 - Update watermark values for each plane in
   skylake_write_plane_wm()/skylake_write_cursor_wm()

 - Update all the other values for the plane (position, address, etc.)
   in skylake_update_primary_plane()/i9xx_update_cursor()

 - Arm plane registers (including the watermark settings) to update at
   the start of the next vblank in
   skylake_update_primary_plane()/i9xx_update_cursor()

Which is more of a step in the right direction to fixing all of the
underrun issues we're currently seeing with skl

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 47 
 drivers/gpu/drm/i915/intel_pm.c  | 15 +---
 2 files changed, 48 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb7d8fc5..3d2c125 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2971,6 +2971,27 @@ u32 skl_plane_ctl_rotation(unsigned int rotation)
return 0;
 }
 
+static void skylake_write_plane_wm(struct intel_crtc *intel_crtc,
+  int plane)
+{
+   struct drm_crtc *crtc = _crtc->base;
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct skl_wm_values *wm = _priv->wm.skl_results;
+   int level, max_level = ilk_wm_max_level(dev);
+   enum pipe pipe = intel_crtc->pipe;
+
+   mutex_lock(_priv->wm.wm_mutex);
+
+   for (level = 0; level < max_level; level++) {
+   I915_WRITE(PLANE_WM(pipe, plane, level),
+  wm->plane[pipe][plane][level]);
+   }
+   I915_WRITE(PLANE_WM_TRANS(pipe, plane), wm->plane_trans[pipe][plane]);
+
+   mutex_unlock(_priv->wm.wm_mutex);
+}
+
 static void skylake_update_primary_plane(struct drm_plane *plane,
 const struct intel_crtc_state 
*crtc_state,
 const struct intel_plane_state 
*plane_state)
@@ -3031,6 +3052,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = x_offset;
intel_crtc->adjusted_y = y_offset;
 
+   skylake_write_plane_wm(intel_crtc, 0);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
@@ -10233,6 +10256,27 @@ static void i845_update_cursor(struct drm_crtc *crtc, 
u32 base,
}
 }
 
+static void skl_write_cursor_wm(struct intel_crtc *intel_crtc)
+{
+   struct drm_crtc *crtc = _crtc->base;
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct skl_wm_values *wm = _priv->wm.skl_results;
+   int level, max_level = ilk_wm_max_level(dev);
+   enum pipe pipe = intel_crtc->pipe;
+
+   mutex_lock(_priv->wm.wm_mutex);
+
+   for (level = 0; level <= max_level; level++) {
+   I915_WRITE(CUR_WM(pipe, level),
+  wm->plane[pipe][PLANE_CURSOR][level]);
+   }
+   I915_WRITE(CUR_WM_TRANS(pipe),
+  wm->plane_trans[pipe][PLANE_CURSOR]);
+
+   mutex_unlock(_priv->wm.wm_mutex);
+}
+
 static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
   

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

[Daniel Vetter]

connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.

While at it also improve/align the kerneldoc comment.

v2: Mention where those ids are from ...

v3: Add -ing to supporting and try to not break the world.

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Acked-by: Chris Wilson 
Acked-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 12 ++--
 include/drm/drm_crtc.h | 13 ++---
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c456628740dd..da9bbe0fdb1e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -934,11 +934,11 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
 
-   connector->connector_id = ida_simple_get(>connector_ida, 0, 0, 
GFP_KERNEL);
-   if (connector->connector_id < 0) {
-   ret = connector->connector_id;
+   ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
+   if (ret < 0)
goto out_put;
-   }
+   connector->index = ret;
+   ret = 0;
 
connector->connector_type = connector_type;
connector->connector_type_id =
@@ -986,7 +986,7 @@ out_put_type_id:
ida_remove(connector_ida, connector->connector_type_id);
 out_put_id:
if (ret)
-   ida_remove(>connector_ida, connector->connector_id);
+   ida_remove(>connector_ida, connector->index);
 out_put:
if (ret)
drm_mode_object_unregister(dev, >base);
@@ -1030,7 +1030,7 @@ void drm_connector_cleanup(struct drm_connector 
*connector)
   connector->connector_type_id);
 
ida_remove(>mode_config.connector_ida,
-  connector->connector_id);
+  connector->index);
 
kfree(connector->display_info.bus_formats);
drm_mode_object_unregister(dev, >base);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f8ba5aab5d28..3edeaf88ebc0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1246,7 +1246,6 @@ struct drm_encoder {
  * @head: list management
  * @base: base KMS object
  * @name: human readable name, can be overwritten by the driver
- * @connector_id: compacted connector id useful indexing arrays
  * @connector_type: one of the %DRM_MODE_CONNECTOR_ types from drm_mode.h
  * @connector_type_id: index into connector type enum
  * @interlace_allowed: can this connector handle interlaced modes?
@@ -1303,7 +1302,15 @@ struct drm_connector {
struct drm_mode_object base;
 
char *name;
-   int connector_id;
+
+   /**
+* @index: Compacted connector index, which matches the position inside
+* the mode_config.list for drivers not supporting hot-add/removing. Can
+* be used as an array index. It is invariant over the lifetime of the
+* connector.
+*/
+   unsigned index;
+
int connector_type;
int connector_type_id;
bool interlace_allowed;
@@ -2764,7 +2771,7 @@ void drm_connector_unregister(struct drm_connector 
*connector);
 extern void drm_connector_cleanup(struct drm_connector *connector);
 static inline unsigned drm_connector_index(struct drm_connector *connector)
 {
-   return connector->connector_id;
+   return connector->index;
 }
 
 extern __printf(5, 6)
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

[Ville Syrjälä]

On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote:
> > On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> > > num_levels should be level+1, not level, else num_levels - 1 becomes
> > > negative. This resulted in bogus watermarks being written to the first
> > > 255 levels like below:
> > > 
> > > [drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, 
> > > sprite1=0, SR: plane=0, cursor=0 level=255 cxsr=0
> > > [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR 
> > > DVFS request
> > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO 
> > > underrun
> > > [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR 
> > > DVFS request
> > > 
> > > Testcase: kms_atomic_transition
> > > Fixes: 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another 
> > > watermark rewrite")
> > > Cc: sta...@vger.kernel.org
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Maarten Lankhorst 
> > > ---
> > > Urgent fix for watermark support. This is definitely a pre-requisite for 
> > > this series.
> > > With this I've noticed that patch "[RFC 3/8] drm/i915/vlv: Move fifo_size 
> > > from
> > > intel_plane_wm_parameters to vlv_wm_state" introduces a regression with 
> > > invalid FIFO split.
> > > 
> > > I need to find out what's going wrong in that patch before this series 
> > > can be applied.
> > > 
> > >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 376c60b98515..8defdcc54529 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -1148,7 +1148,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> > >   }
> > >   }
> > >  
> > > - wm_state->num_levels = level;
> > > + wm_state->num_levels = level + 1;
> > 
> > Nope. The loop above breaks when the current level is bad, hence level-1
> > is actually the higher usable level.
> 
> Without knowing the limits of plane->wm.fifo_size, it looks like it can
> break on level == 0 though.

Hmm. That shouldn't be possible. So looks like a bug snuck in.

> Might as well set that hack to paranoid levels:
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 630b116988f6..e8c2874b8629 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1124,11 +1124,13 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> /* normal watermarks */
> for (level = 0; level < wm_state->num_levels; level++) {
> int wm = vlv_compute_wm_level(plane, crtc, state, 
> level);
> -   int max_wm = plane->base.type == 
> DRM_PLANE_TYPE_CURSOR ? 63 : 511;
> -
> /* hack */
> -   if (WARN_ON(level == 0 && wm > max_wm))
> -   wm = max_wm;

Actually this should just be 

if (WARN_ON(level == 0 && wm > fifo_size))
wm = fifo_size;

assuming we want to keep the hack around for now.

Eventually we'll want to make it just return an error though.

> +   if (level == 0) {
> +   int plane_wm = plane->base.type == 
> DRM_PLANE_TYPE_CURSOR ? 63 : 511;
> +   int max_wm = min(plane->wm.fifo_size, 
> plane_wm);
> +   if (WARN_ON(wm > max_wm))
> +   wm = max_wm;
> +   }
>  
> if (wm > plane->wm.fifo_size)
> break;
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

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

Re: [Intel-gfx] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

On 19/07/16 15:26, Tvrtko Ursulin wrote:


On 19/07/16 13:20, Dave Gordon wrote:

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/intel_guc_loader.c | 34
-
  1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..a2f4fa4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private
*dev_priv)

  static u32 get_core_family(struct drm_i915_private *dev_priv)
  {
-switch (INTEL_INFO(dev_priv)->gen) {
+u32 gen = INTEL_GEN(dev_priv);
+
+switch (gen) {
  case 9:
  return GFXCORE_FAMILY_GEN9;

  default:
-DRM_ERROR("GUC: unsupported core family\n");
+DRM_WARN("GEN%d does not support GuC operation\n", gen);


This looks more like a WARN_ON condition to me, something developers
need to notice extremely easily in development and will never happen in
deployment.


OK; the check in the caller below should have prevented us reaching this 
code if the hardware ID isn't known to the driver. Changed to WARN(1, ...).



  return GFXCORE_FAMILY_UNKNOWN;
  }
  }
@@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
  goto fail;
  } else if (*fw_path == '\0') {
  /* Device has a GuC but we don't know what f/w to load? */
-DRM_INFO("No GuC firmware known for this platform\n");
+DRM_WARN("No GuC firmware known for this platform\n");


This looks the same to me (WARN_ON), it can only happen if someone
messes up things in development.


Maybe. This is the outer check that protects the code above, and as such 
it's the first place we report unrecognised hardware. But we don't want 
to prevent the driver from working (via fallback to execlists) so 
developers can at least boot new hardware and not just get a blank 
screen. So a WARNING of some type is right, but does the stack trace 
from WARN() add any value? If not -- and I think not -- DRM_WARN() is 
what we want.



  err = -ENODEV;
  goto fail;
  }
@@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
   * that the state and timing are fairly predictable
   */
  err = i915_reset_guc(dev_priv);
-if (err) {
-DRM_ERROR("GuC reset failed: %d\n", err);
+if (err)
  goto fail;
-}

  err = guc_ucode_xfer(dev_priv);
  if (!err)
@@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
  else if (err == 0)
  DRM_INFO("GuC firmware load skipped\n");
  else if (ret != -EIO)
-DRM_INFO("GuC firmware load failed: %d\n", err);
+DRM_NOTE("GuC firmware load failed: %d\n", err);
  else
-DRM_ERROR("GuC firmware load failed: %d\n", err);
+DRM_WARN("GuC firmware load failed: %d\n", err);

  if (i915.enable_guc_submission) {
  if (fw_path == NULL)
  DRM_INFO("GuC submission without firmware not
supported\n");
  if (ret == 0)
-DRM_INFO("Falling back from GuC submission to execlist
mode\n");
+DRM_NOTE("Falling back from GuC submission to execlist
mode\n");
  else
  DRM_ERROR("GuC init failed: %d\n", ret);
  }
@@ -571,7 +571,7 @@ static void guc_fw_fetch(struct drm_device *dev,
struct intel_guc_fw *guc_fw)

  /* Check the size of the blob before examining buffer contents */
  if (fw->size < sizeof(struct guc_css_header)) {
-DRM_ERROR("Firmware header is missing\n");
+DRM_NOTE("Firmware header is missing\n");
  goto fail;
  }

@@ -583,7 +583,7 @@ static void guc_fw_fetch(struct drm_device *dev,
struct intel_guc_fw *guc_fw)
  css->key_size_dw - css->exponent_size_dw) * sizeof(u32);

  if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-DRM_ERROR("CSS header definition mismatch\n");
+DRM_NOTE("CSS header definition mismatch\n");
  goto fail;
  }

@@ -593,7 +593,7 @@ static void guc_fw_fetch(struct drm_device *dev,
struct intel_guc_fw *guc_fw)

  /* now RSA */
  if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-DRM_ERROR("RSA key size is bad\n");
+DRM_NOTE("RSA key size is bad\n");
  goto fail;
  }
  guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -602,14 +602,14 @@ static void guc_fw_fetch(struct drm_device *dev,
struct intel_guc_fw *guc_fw)
  /* At least, it should have header, uCode and RSA. Size of all
three. */
  size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
  if (fw->size < size) {
-

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

[Chris Wilson]

On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> > num_levels should be level+1, not level, else num_levels - 1 becomes
> > negative. This resulted in bogus watermarks being written to the first
> > 255 levels like below:
> > 
> > [drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, sprite1=0, 
> > SR: plane=0, cursor=0 level=255 cxsr=0
> > [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR 
> > DVFS request
> > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO 
> > underrun
> > [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR 
> > DVFS request
> > 
> > Testcase: kms_atomic_transition
> > Fixes: 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark 
> > rewrite")
> > Cc: sta...@vger.kernel.org
> > Cc: Ville Syrjälä 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> > Urgent fix for watermark support. This is definitely a pre-requisite for 
> > this series.
> > With this I've noticed that patch "[RFC 3/8] drm/i915/vlv: Move fifo_size 
> > from
> > intel_plane_wm_parameters to vlv_wm_state" introduces a regression with 
> > invalid FIFO split.
> > 
> > I need to find out what's going wrong in that patch before this series can 
> > be applied.
> > 
> >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 376c60b98515..8defdcc54529 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1148,7 +1148,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> > }
> > }
> >  
> > -   wm_state->num_levels = level;
> > +   wm_state->num_levels = level + 1;
> 
> Nope. The loop above breaks when the current level is bad, hence level-1
> is actually the higher usable level.

Without knowing the limits of plane->wm.fifo_size, it looks like it can
break on level == 0 though. Might as well set that hack to paranoid levels:

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 630b116988f6..e8c2874b8629 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1124,11 +1124,13 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
/* normal watermarks */
for (level = 0; level < wm_state->num_levels; level++) {
int wm = vlv_compute_wm_level(plane, crtc, state, 
level);
-   int max_wm = plane->base.type == DRM_PLANE_TYPE_CURSOR 
? 63 : 511;
-
/* hack */
-   if (WARN_ON(level == 0 && wm > max_wm))
-   wm = max_wm;
+   if (level == 0) {
+   int plane_wm = plane->base.type == 
DRM_PLANE_TYPE_CURSOR ? 63 : 511;
+   int max_wm = min(plane->wm.fifo_size, plane_wm);
+   if (WARN_ON(wm > max_wm))
+   wm = max_wm;
+   }
 
if (wm > plane->wm.fifo_size)
break;

-- 
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 1/2] doc/sphinx: Enable keep_warnings

[Daniel Vetter]

On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter  wrote:
> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
>  wrote:
>>
>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>>
>>> Unfortunately warnings generated after parsing in sphinx can end up
>>> with entirely bogus files and line numbers as sources. Strangely for
>>> outright errors this is not a problem. Trying to convert warnings to
>>> errors also doesn't fix it.
>>>
>>> The only way to get useful output out of sphinx to be able to root
>>> cause the error seems to be enabling keep_warnings, which inserts
>>> a System Message into the actual output. Not pretty at all, but I
>>> don't really want to fix up core rst/sphinx code, and this gets the job
>>> done meanwhile.
>>
>> Hi Daniel,
>>
>> may I misunderstood you. Did you really get more or different warnings
>> if you include them into the output with "keep_warnings"?
>>
>> The documentation says:
>>
>>   "Regardless of this setting, warnings are always written
>>to the standard error stream when sphinx-build is run."
>>
>> see http://www.sphinx-doc.org/en/stable/config.html#confval-keep_warnings
>>
>> Or did you not run "make cleandoc" first? Sphinx caches the doctrees
>> and reports markup errors only when you rebuild the cache.
>> The cache is also rebuild if you touch one of the source, e.g.
>> the drivers/gpu/drm/drm_crtc.c or the rst-file where the drm_crtc.c
>> is referred by a kernel-doc directive .. these dependence sometimes
>> confuse me .. when I missed log messages, I clean the cache e.g. by
>> target cleandocs.
>
> Yes I'm aware that sphinx it's WARNINGs when doing a partially
> rebuild, this is something entirely different. I didn't get more or
> less warnings this way, but keep_warning = True seems to be the only
> way to get reasonable information about them. Without that I get
> warnings (for included kernel-doc) where the source file is the .rst
> file that pulls in the kernel doc, and the line number is entirely
> bogus (often past the end of the containing .rst).
>
> With this I can at least then open the generated .html file, search
> for the System Message and figure out (by looking at the surrounding
> context) where the error really is from.
>
> Strangely this only happens for WARNING. If I manged the kerneldoc
> enough to upset sphinx into generating an ERROR, the line numbers and
> source files are correct.
>
> See patch 2/2 in this series for examples of such WARNINGs: Mostly
> it's unbalanced _ * or `` annotations that confuse sphinx/rst a bit.
> If you want to play around with the gpu sphinx conversion to reproduce
> these locall you can grab the drm-intel-nightly branch from
>
> https://cgit.freedesktop.org/drm-intel
>
> It already includes Jon's latest docs-next branch.

btw, I couldn't check this since I didn't figure out how to intercept
the parsed rst tree and view it, but I think what's going on is:
- The source file for these warnings is .rst file containing the
kernel-doc directive. This seems to be a bug in sphinx/docutils since
we never use that file name when appending files at all.
- The line number looks like it's just counting the inserted
kernel-doc lines as part of the containing .rst file. At least
changing the content_offset in nested_parse seems to suggest that this
is the start line (e.g. adding 10k there results in all bogus WARNING
line numbers being increased by 10k). And adding more blank lines at
the beginning of the inserted kernel-doc rst also increases the
reported lines. But not when inserting blank lines at the end (i.e. it
seems like it's being reset after each directive again).

All that suggest to me this is a sphinx-internal issue, and google
sugggests there's lots of errata around line reporting. Hence why I
went with this. But of course a proper fix would be awesome! Just a
bit outside of what I think I can pull off ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

[Ville Syrjälä]

On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> num_levels should be level+1, not level, else num_levels - 1 becomes
> negative. This resulted in bogus watermarks being written to the first
> 255 levels like below:
> 
> [drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, sprite1=0, 
> SR: plane=0, cursor=0 level=255 cxsr=0
> [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR DVFS 
> request
> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO 
> underrun
> [drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR DVFS 
> request
> 
> Testcase: kms_atomic_transition
> Fixes: 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark 
> rewrite")
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
> Urgent fix for watermark support. This is definitely a pre-requisite for this 
> series.
> With this I've noticed that patch "[RFC 3/8] drm/i915/vlv: Move fifo_size from
> intel_plane_wm_parameters to vlv_wm_state" introduces a regression with 
> invalid FIFO split.
> 
> I need to find out what's going wrong in that patch before this series can be 
> applied.
> 
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 376c60b98515..8defdcc54529 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1148,7 +1148,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
>   }
>   }
>  
> - wm_state->num_levels = level;
> + wm_state->num_levels = level + 1;

Nope. The loop above breaks when the current level is bad, hence level-1
is actually the higher usable level.

>  
>   if (!wm_state->cxsr)
>   continue;
> -- 
> 2.7.4
> 

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

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Daniel Vetter]

On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
 wrote:
>
> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>
>> Unfortunately warnings generated after parsing in sphinx can end up
>> with entirely bogus files and line numbers as sources. Strangely for
>> outright errors this is not a problem. Trying to convert warnings to
>> errors also doesn't fix it.
>>
>> The only way to get useful output out of sphinx to be able to root
>> cause the error seems to be enabling keep_warnings, which inserts
>> a System Message into the actual output. Not pretty at all, but I
>> don't really want to fix up core rst/sphinx code, and this gets the job
>> done meanwhile.
>
> Hi Daniel,
>
> may I misunderstood you. Did you really get more or different warnings
> if you include them into the output with "keep_warnings"?
>
> The documentation says:
>
>   "Regardless of this setting, warnings are always written
>to the standard error stream when sphinx-build is run."
>
> see http://www.sphinx-doc.org/en/stable/config.html#confval-keep_warnings
>
> Or did you not run "make cleandoc" first? Sphinx caches the doctrees
> and reports markup errors only when you rebuild the cache.
> The cache is also rebuild if you touch one of the source, e.g.
> the drivers/gpu/drm/drm_crtc.c or the rst-file where the drm_crtc.c
> is referred by a kernel-doc directive .. these dependence sometimes
> confuse me .. when I missed log messages, I clean the cache e.g. by
> target cleandocs.

Yes I'm aware that sphinx it's WARNINGs when doing a partially
rebuild, this is something entirely different. I didn't get more or
less warnings this way, but keep_warning = True seems to be the only
way to get reasonable information about them. Without that I get
warnings (for included kernel-doc) where the source file is the .rst
file that pulls in the kernel doc, and the line number is entirely
bogus (often past the end of the containing .rst).

With this I can at least then open the generated .html file, search
for the System Message and figure out (by looking at the surrounding
context) where the error really is from.

Strangely this only happens for WARNING. If I manged the kerneldoc
enough to upset sphinx into generating an ERROR, the line numbers and
source files are correct.

See patch 2/2 in this series for examples of such WARNINGs: Mostly
it's unbalanced _ * or `` annotations that confuse sphinx/rst a bit.
If you want to play around with the gpu sphinx conversion to reproduce
these locall you can grab the drm-intel-nightly branch from

https://cgit.freedesktop.org/drm-intel

It already includes Jon's latest docs-next branch.

Cheers, Daniel
>
> -- Markus --
>>
>> Cc: Markus Heiser 
>> Cc: Jonathan Corbet 
>> Cc: linux-...@vger.kernel.org
>> Signed-off-by: Daniel Vetter 
>> ---
>> Documentation/conf.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/conf.py b/Documentation/conf.py
>> index 6cc41a0555a3..a131139675cc 100644
>> --- a/Documentation/conf.py
>> +++ b/Documentation/conf.py
>> @@ -125,7 +125,7 @@ pygments_style = 'sphinx'
>> #modindex_common_prefix = []
>>
>> # If true, keep warnings as "system message" paragraphs in the built 
>> documents.
>> -#keep_warnings = False
>> +keep_warnings = True
>>
>> # If true, `todo` and `todoList` produce output, else they produce nothing.
>> todo_include_todos = False
>> --
>> 2.8.1
>>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

[Maarten Lankhorst]

num_levels should be level+1, not level, else num_levels - 1 becomes
negative. This resulted in bogus watermarks being written to the first
255 levels like below:

[drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, sprite1=0, SR: 
plane=0, cursor=0 level=255 cxsr=0
[drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR DVFS 
request
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO 
underrun
[drm:chv_set_memory_dvfs [i915]] *ERROR* timed out waiting for Punit DDR DVFS 
request

Testcase: kms_atomic_transition
Fixes: 262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark 
rewrite")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
Urgent fix for watermark support. This is definitely a pre-requisite for this 
series.
With this I've noticed that patch "[RFC 3/8] drm/i915/vlv: Move fifo_size from
intel_plane_wm_parameters to vlv_wm_state" introduces a regression with invalid 
FIFO split.

I need to find out what's going wrong in that patch before this series can be 
applied.

 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 376c60b98515..8defdcc54529 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1148,7 +1148,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
}
}
 
-   wm_state->num_levels = level;
+   wm_state->num_levels = level + 1;
 
if (!wm_state->cxsr)
continue;
-- 
2.7.4


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

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

[Dave Gordon]

On 19/07/16 16:02, Tvrtko Ursulin wrote:


On 19/07/16 13:59, Dave Gordon wrote:

When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theory, this could lead to the single queue becoming a bottleneck in
which an excess of outstanding work for one or more engines might
prevent work for an idle engine reaching the hardware.

To reduce this risk, we can create one GuC client per engine. Each will
have its own workqueue, to be used only for work targeting a single
engine, so there will be no cross-engine contention for workqueue slots.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 25 -
  drivers/gpu/drm/i915/i915_guc_submission.c | 35
+++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  3 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 90aef45..5cbb8ef 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2570,20 +2570,26 @@ static int i915_guc_info(struct seq_file *m,
void *data)
  struct drm_device *dev = node->minor->dev;
  struct drm_i915_private *dev_priv = to_i915(dev);
  struct intel_guc guc;
-struct i915_guc_client client = {};
+struct i915_guc_client *clients;
  struct intel_engine_cs *engine;
+enum intel_engine_id id;
  u64 total = 0;

  if (!HAS_GUC_SCHED(dev_priv))
  return 0;

+clients = kcalloc(I915_NUM_ENGINES, sizeof(*clients), GFP_KERNEL);
+if (clients == NULL)
+return -ENOMEM;
+
  if (mutex_lock_interruptible(>struct_mutex))
-return 0;
+goto done;

  /* Take a local copy of the GuC data, so we can dump it at
leisure */
  guc = dev_priv->guc;
-if (guc.execbuf_client)
-client = *guc.execbuf_client;
+for_each_engine_id(engine, dev_priv, id)
+if (guc.exec_clients[id])
+clients[id] = *guc.exec_clients[id];

  mutex_unlock(>struct_mutex);

@@ -2606,11 +2612,18 @@ static int i915_guc_info(struct seq_file *m,
void *data)
  }
  seq_printf(m, "\t%s: %llu\n", "Total", total);

-seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
-i915_guc_client_info(m, dev_priv, );
+for_each_engine_id(engine, dev_priv, id) {
+seq_printf(m, "\nGuC exec_client[%d] @ %p:\n",
+id, guc.exec_clients[id]);


Minor and not a blocker for this patch, but I would potentially
re-consider if printing out the client pointer is useful.


It's really only useful to know whether it's NULL or not; but printing 
the pointer itself is simpler than printing a message saying that. This 
is a debugfs interface, so the content is pretty much ad-hoc.


.Dave.


+if (guc.exec_clients[id])
+i915_guc_client_info(m, dev_priv, [id]);
+}

  /* Add more as required ... */

+done:
+kfree(clients);
+
  return 0;
  }

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index dc5f485..b0f9945 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -434,7 +434,9 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
  int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
  {
  const size_t wqi_size = sizeof(struct guc_wq_item);
-struct i915_guc_client *gc = request->i915->guc.execbuf_client;
+enum intel_engine_id engine_id = request->engine->id;
+struct intel_guc *guc = >i915->guc;
+struct i915_guc_client *gc = guc->exec_clients[engine_id];
  struct guc_process_desc *desc;
  u32 freespace;

@@ -589,7 +591,7 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
  {
  unsigned int engine_id = rq->engine->id;
  struct intel_guc *guc = >i915->guc;
-struct i915_guc_client *client = guc->execbuf_client;
+struct i915_guc_client *client = guc->exec_clients[engine_id];
  int b_ret;

  guc_add_workqueue_item(client, rq);
@@ -723,7 +725,7 @@ static bool guc_doorbell_check(struct intel_guc
*guc, uint16_t db_id)
   */
  static void guc_init_doorbell_hw(struct intel_guc *guc)
  {
-struct i915_guc_client *client = guc->execbuf_client;
+struct i915_guc_client *client = guc->exec_clients[RCS];
  uint16_t db_id;
  int i, err;

@@ -1004,17 +1006,21 @@ int i915_guc_submission_enable(struct
drm_i915_private *dev_priv)
  {
  struct intel_guc *guc = _priv->guc;
  struct i915_guc_client *client;
+struct intel_engine_cs *engine;

-/* client for execbuf submission */
-client = guc_client_alloc(dev_priv,
-  GUC_CTX_PRIORITY_KMD_NORMAL,
-  dev_priv->kernel_context);
-if (!client) {
-DRM_ERROR("Failed to create execbuf 

Re: [Intel-gfx] [PATCH 5/5] drm/i915/guc: use for_each_engine_id() where appropriate

[Tvrtko Ursulin]

On 19/07/16 13:59, Dave Gordon wrote:

Now that host structures are indexed by host engine-id rather than
guc_id, we can usefully convert some for_each_engine() loops to use
for_each_engine_id() and avoid multiple dereferences of engine->id.

Also a few related tweaks to cache structure members locally wherever
they're used more than once or twice, hopefully eliminating memory
references.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 17 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 22 +-
  2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5cbb8ef..76918ab 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2541,6 +2541,7 @@ static void i915_guc_client_info(struct seq_file *m,
 struct i915_guc_client *client)
  {
struct intel_engine_cs *engine;
+   enum intel_engine_id id;
uint64_t tot = 0;

seq_printf(m, "\tPriority %d, GuC ctx index: %u, PD offset 0x%x\n",
@@ -2555,11 +2556,11 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);

-   for_each_engine(engine, dev_priv) {
+   for_each_engine_id(engine, dev_priv, id) {
+   u64 submissions = client->submissions[id];
+   tot += submissions;
seq_printf(m, "\tSubmissions: %llu %s\n",
-   client->submissions[engine->id],
-   engine->name);
-   tot += client->submissions[engine->id];
+   submissions, engine->name);
}
seq_printf(m, "\tTotal: %llu\n", tot);
  }
@@ -2604,11 +2605,11 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "GuC last action error code: %d\n", guc.action_err);

seq_printf(m, "\nGuC submissions:\n");
-   for_each_engine(engine, dev_priv) {
+   for_each_engine_id(engine, dev_priv, id) {
+   u64 submissions = guc.submissions[id];
+   total += submissions;
seq_printf(m, "\t%-24s: %10llu, last seqno 0x%08x\n",
-   engine->name, guc.submissions[engine->id],
-   guc.last_seqno[engine->id]);
-   total += guc.submissions[engine->id];
+   engine->name, submissions, guc.last_seqno[id]);
}
seq_printf(m, "\t%s: %llu\n", "Total", total);

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4daba77..5beed1b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -342,7 +342,8 @@ static void guc_init_ctx_desc(struct intel_guc *guc,

for_each_engine_masked(engine, dev_priv, client->engines) {
struct intel_context *ce = >engine[engine->id];
-   struct guc_execlist_context *lrc = [engine->guc_id];
+   uint32_t guc_engine_id = engine->guc_id;
+   struct guc_execlist_context *lrc = [guc_engine_id];
struct drm_i915_gem_object *obj;

/* TODO: We have a design issue to be solved here. Only when we
@@ -361,7 +362,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
-   (engine->guc_id << GUC_ELC_ENGINE_OFFSET);
+   (guc_engine_id << GUC_ELC_ENGINE_OFFSET);

obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
@@ -371,7 +372,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
lrc->ring_next_free_location = gfx_addr;
lrc->ring_current_tail_pointer_value = 0;

-   desc.engines_used |= (1 << engine->guc_id);
+   desc.engines_used |= (1 << guc_engine_id);
}

DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",
@@ -461,6 +462,7 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
/* wqi_len is in DWords, and does not include the one-word header */
const size_t wqi_size = sizeof(struct guc_wq_item);
const u32 wqi_len = wqi_size/sizeof(u32) - 1;
+   struct intel_engine_cs *engine = rq->engine;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
@@ -502,12 +504,11 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
/* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
  

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

[Tvrtko Ursulin]

On 19/07/16 13:59, Dave Gordon wrote:

When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theory, this could lead to the single queue becoming a bottleneck in
which an excess of outstanding work for one or more engines might
prevent work for an idle engine reaching the hardware.

To reduce this risk, we can create one GuC client per engine. Each will
have its own workqueue, to be used only for work targeting a single
engine, so there will be no cross-engine contention for workqueue slots.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 25 -
  drivers/gpu/drm/i915/i915_guc_submission.c | 35 +++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  3 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 90aef45..5cbb8ef 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2570,20 +2570,26 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_guc guc;
-   struct i915_guc_client client = {};
+   struct i915_guc_client *clients;
struct intel_engine_cs *engine;
+   enum intel_engine_id id;
u64 total = 0;

if (!HAS_GUC_SCHED(dev_priv))
return 0;

+   clients = kcalloc(I915_NUM_ENGINES, sizeof(*clients), GFP_KERNEL);
+   if (clients == NULL)
+   return -ENOMEM;
+
if (mutex_lock_interruptible(>struct_mutex))
-   return 0;
+   goto done;

/* Take a local copy of the GuC data, so we can dump it at leisure */
guc = dev_priv->guc;
-   if (guc.execbuf_client)
-   client = *guc.execbuf_client;
+   for_each_engine_id(engine, dev_priv, id)
+   if (guc.exec_clients[id])
+   clients[id] = *guc.exec_clients[id];

mutex_unlock(>struct_mutex);

@@ -2606,11 +2612,18 @@ static int i915_guc_info(struct seq_file *m, void *data)
}
seq_printf(m, "\t%s: %llu\n", "Total", total);

-   seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
-   i915_guc_client_info(m, dev_priv, );
+   for_each_engine_id(engine, dev_priv, id) {
+   seq_printf(m, "\nGuC exec_client[%d] @ %p:\n",
+   id, guc.exec_clients[id]);


Minor and not a blocker for this patch, but I would potentially 
re-consider if printing out the client pointer is useful.



+   if (guc.exec_clients[id])
+   i915_guc_client_info(m, dev_priv, [id]);
+   }

/* Add more as required ... */

+done:
+   kfree(clients);
+
return 0;
  }

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index dc5f485..b0f9945 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -434,7 +434,9 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
  int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
  {
const size_t wqi_size = sizeof(struct guc_wq_item);
-   struct i915_guc_client *gc = request->i915->guc.execbuf_client;
+   enum intel_engine_id engine_id = request->engine->id;
+   struct intel_guc *guc = >i915->guc;
+   struct i915_guc_client *gc = guc->exec_clients[engine_id];
struct guc_process_desc *desc;
u32 freespace;

@@ -589,7 +591,7 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
  {
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
-   struct i915_guc_client *client = guc->execbuf_client;
+   struct i915_guc_client *client = guc->exec_clients[engine_id];
int b_ret;

guc_add_workqueue_item(client, rq);
@@ -723,7 +725,7 @@ static bool guc_doorbell_check(struct intel_guc *guc, 
uint16_t db_id)
   */
  static void guc_init_doorbell_hw(struct intel_guc *guc)
  {
-   struct i915_guc_client *client = guc->execbuf_client;
+   struct i915_guc_client *client = guc->exec_clients[RCS];
uint16_t db_id;
int i, err;

@@ -1004,17 +1006,21 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  {
struct intel_guc *guc = _priv->guc;
struct i915_guc_client *client;
+   struct intel_engine_cs *engine;

-   /* client for execbuf submission */
-   client = guc_client_alloc(dev_priv,
- GUC_CTX_PRIORITY_KMD_NORMAL,
- dev_priv->kernel_context);
-   if (!client) {
-   DRM_ERROR("Failed to create execbuf 

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells

[Dave Gordon]

On 19/07/16 15:16, Patchwork wrote:

== Series Details ==

Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid 
used doorbells
URL   : https://patchwork.freedesktop.org/series/10040/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
 pass   -> SKIP   (ro-hsw-i3-4010u)
Test gem_sync:
 Subgroup basic-store-each:
 fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
 Subgroup basic-cursor-vs-flip:
 pass   -> FAIL   (ro-ilk1-i5-650)


Wibble? The test log for this says:

+ Results for igt@kms_cursor_legacy@basic-flip-vs-cursor
+ Result: pass
+
+ IGT-Version: 1.15-g4d03467 (x86_64) (Linux: 
4.7.0-rc7-gfxbench-RO_Patchwork_1532+ x86_64)
+ Test requirement not met in function __real_main427, file 
kms_cursor_legacy.c:448:

+ Test requirement: !(n >= data.resources->count_crtcs)
+ Subtest basic-flip-vs-cursor: SUCCESS (1.156s)
+
+ Command /opt/igt/tests/kms_cursor_legacy --run-subtest 
basic-flip-vs-cursor


So whatever that unfulfilled test requirement is, the result should be PASS.


Test kms_pipe_crc_basic:
 Subgroup read-crc-pipe-c-frame-sequence:
 pass   -> DMESG-WARN (fi-hsw-i7-4770k)


[  436.687908] [drm:drm_edid_block_valid] *ERROR* EDID checksum is 
invalid, remainder is 122
[  436.688345] [drm:drm_edid_block_valid] *ERROR* EDID checksum is 
invalid, remainder is 122


which looks like
https://bugzilla.kernel.org/show_bug.cgi?id=85951
[hsw] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
remainder is 46

(which was closed as unreproducible)

.Dave.


 Subgroup suspend-read-crc-pipe-c:
 pass   -> SKIP   (fi-hsw-i7-4770k)
Test prime_vgem:
 Subgroup basic-fence-read:
 fail   -> PASS   (ro-byt-n2820)

fi-hsw-i7-4770k  total:243  pass:211  dwarn:1   dfail:0   fail:10  skip:21
fi-kbl-qkkr  total:243  pass:177  dwarn:26  dfail:1   fail:10  skip:29
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13
ro-bdw-i7-5557U  total:244  pass:219  dwarn:1   dfail:0   fail:9   skip:15
ro-bdw-i7-5600u  total:244  pass:202  dwarn:0   dfail:0   fail:10  skip:32
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42
ro-byt-n2820 total:244  pass:195  dwarn:0   dfail:0   fail:11  skip:38
ro-hsw-i3-4010u  total:244  pass:208  dwarn:0   dfail:0   fail:11  skip:25
ro-hsw-i7-4770r  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24
ro-ilk1-i5-650   total:239  pass:169  dwarn:0   dfail:0   fail:12  skip:58
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:11  skip:33
ro-skl3-i5-6260u total:244  pass:221  dwarn:1   dfail:0   fail:10  skip:12
ro-snb-i7-2620M  total:244  pass:190  dwarn:0   dfail:0   fail:12  skip:42
fi-skl-i5-6260u failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1532/

63a drm-intel-nightly: 2016y-07m-19d-13h-02m-39s UTC integration manifest
207ec9d drm/i915/guc: use for_each_engine_id() where appropriate
5982c52 drm/i915/guc: add engine mask to GuC client & pass to GuC
b1f5991 drm/i915/guc: use a separate GuC client for each engine
89623f4 drm/i915/guc: refactor guc_init_doorbell_hw()
b9c0a41 drm/i915/guc: doorbell reset should avoid used doorbells



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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: add engine mask to GuC client & pass to GuC

[Tvrtko Ursulin]

On 19/07/16 13:59, Dave Gordon wrote:

The Context Descriptor passed by the kernel to the GuC contains a field
specifying which engine(s) the context will use. Historically, this was
always set to "all of them", but now that we have one client per engine,
we can be more precise, and set only the single bit for the engine that
the client is associated with.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++-
  drivers/gpu/drm/i915/intel_guc.h   |  3 ++-
  2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b0f9945..4daba77 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -340,7 +340,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;

-   for_each_engine(engine, dev_priv) {
+   for_each_engine_masked(engine, dev_priv, client->engines) {
struct intel_context *ce = >engine[engine->id];
struct guc_execlist_context *lrc = [engine->guc_id];
struct drm_i915_gem_object *obj;
@@ -374,6 +374,8 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.engines_used |= (1 << engine->guc_id);
}

+   DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",
+   client->engines, desc.engines_used);
WARN_ON(desc.engines_used == 0);

/*
@@ -768,6 +770,7 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
   */
  static struct i915_guc_client *
  guc_client_alloc(struct drm_i915_private *dev_priv,
+uint32_t engines,
 uint32_t priority,
 struct i915_gem_context *ctx)
  {
@@ -780,10 +783,11 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
if (!client)
return NULL;

-   client->doorbell_id = GUC_INVALID_DOORBELL_ID;
-   client->priority = priority;
client->owner = ctx;
client->guc = guc;
+   client->engines = engines;
+   client->priority = priority;
+   client->doorbell_id = GUC_INVALID_DOORBELL_ID;

client->ctx_index = (uint32_t)ida_simple_get(>ctx_ids, 0,
GUC_MAX_GPU_CONTEXTS, GFP_KERNEL);
@@ -825,8 +829,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
if (guc_init_doorbell(guc, client, db_id))
goto err;

-   DRM_DEBUG_DRIVER("new priority %u client %p: ctx_index %u\n",
-   priority, client, client->ctx_index);
+   DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x: ctx_index 
%u\n",
+   priority, client, client->engines, client->ctx_index);
DRM_DEBUG_DRIVER("doorbell id %u, cacheline offset 0x%x\n",
client->doorbell_id, client->doorbell_offset);

@@ -1011,6 +1015,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
for_each_engine(engine, dev_priv) {
/* client for execbuf submission */
client = guc_client_alloc(dev_priv,
+ intel_engine_flag(engine),
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 7b4cc4d..53d41b5 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -67,6 +67,8 @@ struct i915_guc_client {
void *client_base;  /* first page (only) of above   */
struct i915_gem_context *owner;
struct intel_guc *guc;
+
+   uint32_t engines;   /* bitmap of (host) engine ids  */
uint32_t priority;
uint32_t ctx_index;

@@ -79,7 +81,6 @@ struct i915_guc_client {
uint32_t wq_offset;
uint32_t wq_size;
uint32_t wq_tail;
-   uint32_t unused;/* Was 'wq_head'*/

uint32_t no_wq_space;
uint32_t q_fail;/* No longer used   */



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: refactor guc_init_doorbell_hw()

[Tvrtko Ursulin]

On 19/07/16 13:59, Dave Gordon wrote:

Commit message missing! :)


Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
  1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d8402e4..dc5f485 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -698,32 +698,47 @@ static void gem_release_guc_obj(struct 
drm_i915_gem_object *obj)
kfree(client);
  }

+/* Check that a doorbell register is in the expected state */
+static bool guc_doorbell_check(struct intel_guc *guc, uint16_t db_id)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   i915_reg_t drbreg = GEN8_DRBREGL(db_id);
+   uint32_t value = I915_READ(drbreg);
+   bool enabled = (value & GUC_DOORBELL_ENABLED) != 0;
+   bool expected = test_bit(db_id, guc->doorbell_bitmap);
+
+   if (enabled == expected)
+   return true;
+
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) 0x%x, should be %s\n",
+db_id, drbreg.reg, value,
+expected ? "active" : "inactive");
+
+   return false;
+}
+
  /*
   * Borrow the first client to set up & tear down each unused doorbell
   * in turn, to ensure that all doorbell h/w is (re)initialised.
   */
  static void guc_init_doorbell_hw(struct intel_guc *guc)
  {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct i915_guc_client *client = guc->execbuf_client;
-   uint16_t db_id, i;
-   int err;
+   uint16_t db_id;
+   int i, err;

+   /* Save client's original doorbell selection */
db_id = client->doorbell_id;

for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
-   i915_reg_t drbreg = GEN8_DRBREGL(i);
-   u32 value = I915_READ(drbreg);
-
-   if (test_bit(i, guc->doorbell_bitmap))
+   /* Skip if doorbell is OK */
+   if (guc_doorbell_check(guc, i))
continue;

err = guc_update_doorbell_id(guc, client, i);
-
-   /* Report update failure or unexpectedly active doorbell */
-   if (err || (i != db_id && (value & GUC_DOORBELL_ENABLED)))
-   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) was 0x%x, err 
%d\n",
- i, drbreg.reg, value, err);
+   if (err)
+   DRM_DEBUG_DRIVER("Doorbell %d update failed, err %d\n",
+   i, err);
}

/* Restore to original value */
@@ -732,18 +747,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
db_id, err);

-   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
-   i915_reg_t drbreg = GEN8_DRBREGL(i);
-   u32 value = I915_READ(drbreg);
-
-   if (test_bit(i, guc->doorbell_bitmap))
-   continue;
-
-   if (i != db_id && (value & GUC_DOORBELL_ENABLED))
-   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
- i, drbreg.reg, value);
-
-   }
+   /* Read back & verify all doorbell registers */
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
+   (void)guc_doorbell_check(guc, i);
  }

  /**



Otherwise looks fine.

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: doorbell reset should avoid used doorbells

[Tvrtko Ursulin]

On 19/07/16 13:59, Dave Gordon wrote:

guc_init_doorbell_hw() borrows the (currently single) GuC client to use
in reinitialising ALL the doorbell registers (as the hardware doesn't
reset them when the GuC is reset). As a prerequisite for accommodating
multiple clients, it should only reset doorbells that are supposed to be
disabled, avoiding those that are marked as in use by any client.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..d8402e4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -699,7 +699,7 @@ static void gem_release_guc_obj(struct drm_i915_gem_object 
*obj)
  }

  /*
- * Borrow the first client to set up & tear down every doorbell
+ * Borrow the first client to set up & tear down each unused doorbell
   * in turn, to ensure that all doorbell h/w is (re)initialised.
   */
  static void guc_init_doorbell_hw(struct intel_guc *guc)
@@ -715,6 +715,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
i915_reg_t drbreg = GEN8_DRBREGL(i);
u32 value = I915_READ(drbreg);

+   if (test_bit(i, guc->doorbell_bitmap))
+   continue;
+
err = guc_update_doorbell_id(guc, client, i);

/* Report update failure or unexpectedly active doorbell */
@@ -733,6 +736,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
i915_reg_t drbreg = GEN8_DRBREGL(i);
u32 value = I915_READ(drbreg);

+   if (test_bit(i, guc->doorbell_bitmap))
+   continue;
+
if (i != db_id && (value & GUC_DOORBELL_ENABLED))
DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
  i, drbreg.reg, value);



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros

[Dave Gordon]

On 19/07/16 14:53, Patchwork wrote:

== Series Details ==

Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros
URL   : https://patchwork.freedesktop.org/series/10036/
State : success

== Summary ==

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

Test drv_module_reload_basic:
 dmesg-warn -> PASS   (ro-skl3-i5-6260u)
Test gem_sync:
 Subgroup basic-store-each:
 fail   -> DMESG-FAIL (ro-bdw-i7-5600u)


This is (now) Bug 96974
https://bugs.freedesktop.org/show_bug.cgi?id=96974
[BAT BDW] gem_sync / basic-store-each fails sporadically

I filed this too, but Villa beat me by a couple of minutes,
so my bug 96975 is now a dup of 96974.

Maybe we should get another identical machine and see whether
the results are consistent, 'cos the other BDWs aren't showing
this at all.

.Dave.


fi-hsw-i7-4770k  total:243  pass:213  dwarn:0   dfail:0   fail:10  skip:20
fi-kbl-qkkr  total:243  pass:178  dwarn:27  dfail:1   fail:10  skip:27
fi-skl-i5-6260u  total:243  pass:222  dwarn:0   dfail:0   fail:9   skip:12
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13
ro-bdw-i7-5557U  total:244  pass:219  dwarn:1   dfail:0   fail:9   skip:15
ro-bdw-i7-5600u  total:244  pass:201  dwarn:0   dfail:1   fail:10  skip:32
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42
ro-byt-n2820 total:244  pass:194  dwarn:0   dfail:0   fail:12  skip:38
ro-hsw-i3-4010u  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24
ro-hsw-i7-4770r  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24
ro-ilk-i7-620lm  total:244  pass:169  dwarn:0   dfail:0   fail:12  skip:63
ro-ilk1-i5-650   total:239  pass:170  dwarn:0   dfail:0   fail:11  skip:58
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:11  skip:33
ro-skl3-i5-6260u total:244  pass:222  dwarn:0   dfail:0   fail:10  skip:12
ro-snb-i7-2620M  total:244  pass:190  dwarn:0   dfail:0   fail:12  skip:42

Results at /archive/results/CI_IGT_test/RO_Patchwork_1531/

63a drm-intel-nightly: 2016y-07m-19d-13h-02m-39s UTC integration manifest
b23d573 drm/i915/guc: revisit GuC loader message levels
950c1a4 drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
5e8e33b drm: extra printk() wrapper macros



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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

[Chris Wilson]

On Tue, Jul 19, 2016 at 05:12:22PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> > +   resv = i915_gem_object_get_dmabuf_resv(obj);
> > +   if (resv) {
> > +   long err;
> 
> We already have ret in the function scope.

ret is int, we need a long. At least I can attest to our test coverage!

> > @@ -3402,13 +3414,13 @@ i915_gem_object_set_to_gtt_domain(struct 
> > drm_i915_gem_object *obj, bool write)
> >     struct i915_vma *vma;
> >     int ret;
> >  
> > -   if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
> > -   return 0;
> > -
> >     ret = i915_gem_object_wait_rendering(obj, !write);
> >     if (ret)
> >     return ret;
> >  
> > +   if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
> > +   return 0;
> > +
> 
> Not sure I follow this change, wait rendering would only be issued if
> DOMAIN_CPU was in place, this function was about moving to gtt_domain
> so should really be NOP if in GTT domain already, no? Maybe calling
> site should do an explicit wait_rendering if needed.

No, this is where we do the wait rendering. The API says
set-to-gtt-domain implies that it is out of the GPU domain (no
rendering) and out of the CPU domain. (Similarly for set-to-cpu-domain.)
The relaxation I've applied here is to try and catch third parties that
have not updated our domain tracking for their access.

Moving the wait_rendering to the parent is a fair amount of burden.

> >     vma->pin_count = 0;
> > -   ret = i915_vma_unbind(vma);
> 
> Maybe add a comment/TODO/FIXME: about the potential WARN.

__i915_vma_unbind_no_wait() is itself an automatic FIXME - it only
exists to cover up a WARN. (I wish we had this series in place first so
that such a hack wasn't applied.)
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

[Daniel Vetter]

On Tue, Jul 19, 2016 at 09:28:34AM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > > Even after adding individual page support for GTT mmaping, we can still
> > > fail to find any space within the mappable region, and
> > > drm_mm_insert_node() will then report ENOSPC. We have to then handle
> > > this error by using the shmem access to the pages.
> > > 
> > > Fixes: b50a53715f09 ("drm/i915: Support for pread/pwrite ... objects")
> > > Testcase: igt/gem_concurrent_blit
> > > Signed-off-by: Chris Wilson 
> > > Cc: Ankitprasad Sharma 
> > > Cc: Tvrtko Ursulin  > 
> > Reviewed-by: Daniel Vetter 
> 
> Thanks for the review, pushed.
> 
> Ideas for how we can stress this a bit directly than
> gem_concurrent_blit?
> 
> We need to have many threads all pinning and then hitting the slow path
> in the read (thus allowing another thread to come in and fail to claim
> some aperture space for itself). Tricksy.
> 
> Hmm, how about fault-injection under I915_DEBUG?

I think fault injection is the only feasible way for such a fallback for a
fallback case. We need to entirely exhaust mmap gtt afaics at aleast.
-Daniel
-- 
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 i-g-t] tests: make color management tests part of the BAT

[Daniel Vetter]

On Tue, Jul 19, 2016 at 12:42:36PM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> > > Signed-off-by: Lionel Landwerlin 
> > 
> > Do we have the time for those in the BAT budget?
> 
> Do we not? It has been demonstrated that people notice when gamma is
> broken, can we afford to risk repeating this bug?
> 
> (Or in other news, where are all the new QA bugs from failing tests?
> Seems like we are missing some bug reports from igt added to show off
> bugs.)

We don't run enough test, don't report the bugs we do catch and don't
handle it. It's all sad, but unfortunately just piling even more onto the
BAT pile is not going to help anyone - as is the results are already
pretty close to useless. The idea behind BAT really is that it runs real
fast, and that it's a gate for a more extended testcase. If we add tests
until it's real slow and still broken, no one wins at all.


Unfortunately I can't tell you how to get out of this mess either :(
-Daniel
-- 
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] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

[Tvrtko Ursulin]

On 19/07/16 13:20, Dave Gordon wrote:

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
  1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..a2f4fa4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)

  static u32 get_core_family(struct drm_i915_private *dev_priv)
  {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;

default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   DRM_WARN("GEN%d does not support GuC operation\n", gen);


This looks more like a WARN_ON condition to me, something developers 
need to notice extremely easily in development and will never happen in 
deployment.



return GFXCORE_FAMILY_UNKNOWN;
}
  }
@@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   DRM_WARN("No GuC firmware known for this platform\n");


This looks the same to me (WARN_ON), it can only happen if someone 
messes up things in development.



err = -ENODEV;
goto fail;
}
@@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }

err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);

if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -571,7 +571,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)

/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}

@@ -583,7 +583,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);

if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}

@@ -593,7 +593,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)

/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -602,14 +602,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}

/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;

Re: [Intel-gfx] [PATCH v2] i915: fix build error with -Werror

[Dave Gordon]

On 19/07/16 08:05, Daniel Vetter wrote:

On Mon, Jul 04, 2016 at 11:30:06AM -0400, Jeff Mahoney wrote:

This fixes the following build error with -Werror and gcc 6.1:

drivers/gpu/drm/i915/i915_debugfs.c:2103:6: error: suggest explicit braces to 
avoid ambiguous 'else' [-Werror=parentheses]

Signed-off-by: Jeff Mahoney 


This doesn't apply on -next any more ... Is this still an issue on latest
kernels?
-Daniel

---
  drivers/gpu/drm/i915/i915_debugfs.c |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2100,9 +2100,10 @@ static int i915_dump_lrc(struct seq_file
return ret;

list_for_each_entry(ctx, _priv->context_list, link)
-   if (ctx != dev_priv->kernel_context)
+   if (ctx != dev_priv->kernel_context) {
for_each_engine(engine, dev_priv)
i915_dump_lrc_obj(m, ctx, engine);
+   }

mutex_unlock(>struct_mutex);


That's a curious warning. Ever since

commit 373701b1fc7d7c0013ae4fffd8103615c150751e
drm: fix potential dangling else problems in for_each_ macros
Author: Jani Nikula 
Date: Tue Nov 24 21:21:55 2015 +0200
Link: 
http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-1-git-send-email-jani.nik...@intel.com


we've avoided leaving a dangling else; the code should expand as

for ( /* each entry */ )
if (ctx != dev_priv->kernel_context)
for ( /* each engine */ )
if (!intel_engine_initialized(engine))
{}
else
i915_dump_lrc_obj(m, ctx, engine);

... so that the (hidden) else is clearly matched with the (hidden) if() 
generated by the macro expansion. Surely the compiler can't think that 
an else inside a for-loop could be mistakenly paired with one outside 
the loop?


Of course we did *have* a proposal for an alternative iterator strategy 
that didn't expose any if/else at all, but some people didn't like it :L


Oh well, it just shows that using macros to rewrite C syntax is still an 
abomination, Stephen Bourne notwithstanding. If you want iterators and 
blocks, use Ruby ;)


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

Re: [Intel-gfx] [CI-RESEND 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Tvrtko Ursulin]

On 19/07/16 13:20, Dave Gordon wrote:

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
  1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..e299b64 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;

-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));

dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;

-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);

/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -726,8 +724,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);

for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
i915_reg_t drbreg = GEN8_DRBREGL(i);
@@ -819,8 +817,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;

  err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
  }
@@ -998,7 +994,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}




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] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid 
used doorbells
URL   : https://patchwork.freedesktop.org/series/10040/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (ro-hsw-i3-4010u)
Test gem_sync:
Subgroup basic-store-each:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip:
pass   -> FAIL   (ro-ilk1-i5-650)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (fi-hsw-i7-4770k)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (fi-hsw-i7-4770k)
Test prime_vgem:
Subgroup basic-fence-read:
fail   -> PASS   (ro-byt-n2820)

fi-hsw-i7-4770k  total:243  pass:211  dwarn:1   dfail:0   fail:10  skip:21 
fi-kbl-qkkr  total:243  pass:177  dwarn:26  dfail:1   fail:10  skip:29 
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26 
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40 
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13 
ro-bdw-i7-5557U  total:244  pass:219  dwarn:1   dfail:0   fail:9   skip:15 
ro-bdw-i7-5600u  total:244  pass:202  dwarn:0   dfail:0   fail:10  skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:195  dwarn:0   dfail:0   fail:11  skip:38 
ro-hsw-i3-4010u  total:244  pass:208  dwarn:0   dfail:0   fail:11  skip:25 
ro-hsw-i7-4770r  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24 
ro-ilk1-i5-650   total:239  pass:169  dwarn:0   dfail:0   fail:12  skip:58 
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:11  skip:33 
ro-skl3-i5-6260u total:244  pass:221  dwarn:1   dfail:0   fail:10  skip:12 
ro-snb-i7-2620M  total:244  pass:190  dwarn:0   dfail:0   fail:12  skip:42 
fi-skl-i5-6260u failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1532/

63a drm-intel-nightly: 2016y-07m-19d-13h-02m-39s UTC integration manifest
207ec9d drm/i915/guc: use for_each_engine_id() where appropriate
5982c52 drm/i915/guc: add engine mask to GuC client & pass to GuC
b1f5991 drm/i915/guc: use a separate GuC client for each engine
89623f4 drm/i915/guc: refactor guc_init_doorbell_hw()
b9c0a41 drm/i915/guc: doorbell reset should avoid used doorbells

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

[Joonas Lahtinen]

On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> When transitioning to the GTT or CPU domain we wait on all rendering
> from i915 to complete (with the optimisation of allowing concurrent read
> access by both the GPU and client). We don't yet ensure all rendering
> from third parties (tracked by implicit fences on the dma-buf) is
> complete. Since implicitly tracked rendering by third parties will
> ignore our cache-domain tracking, we have to always wait upon rendering
> from third-parties when transitioning to direct access to the backing
> store. We still rely on clients notifying us of cache domain changes
> (i.e. they need to move to the GTT read or write domain after doing a CPU
> access before letting the third party render again).
> 
> v2:
> This introduces a potential WARN_ON into i915_gem_object_free() as the
> current i915_vma_unbind() calls i915_gem_object_wait_rendering(). To
> hit this path we first need to render with the GPU, have a dma-buf
> attached with an unsignaled fence and then interrupt the wait. It does
> get fixed later in the series (when i915_vma_unbind() only waits on the
> active VMA and not all, including third-party, rendering.
> 
> To offset that risk, use the __i915_vma_unbind_no_wait hack.
> 
> Testcase: igt/prime_vgem/basic-fence-read
> Testcase: igt/prime_vgem/basic-fence-mmap
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 44 
> ++---
>  1 file changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 079e09cee16a..37868cc594cb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -29,10 +29,12 @@
>  #include 
>  #include 
>  #include "i915_drv.h"
> +#include "i915_gem_dmabuf.h"
>  #include "i915_vgpu.h"
>  #include "i915_trace.h"
>  #include "intel_drv.h"
>  #include "intel_mocs.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -511,6 +513,10 @@ int i915_gem_obj_prepare_shmem_read(struct 
> drm_i915_gem_object *obj,
>   if (WARN_ON(!i915_gem_object_has_struct_page(obj)))
>   return -EINVAL;
>  
> + ret = i915_gem_object_wait_rendering(obj, true);
> + if (ret)
> + return ret;
> +
>   if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
>   /* If we're not in the cpu read domain, set ourself into the gtt
>    * read domain and manually flush cachelines (if required). This
> @@ -518,9 +524,6 @@ int i915_gem_obj_prepare_shmem_read(struct 
> drm_i915_gem_object *obj,
>    * anyway again before the next pread happens. */
>   *needs_clflush = !cpu_cache_is_coherent(obj->base.dev,
>   obj->cache_level);
> - ret = i915_gem_object_wait_rendering(obj, true);
> - if (ret)
> - return ret;
>   }
>  
>   ret = i915_gem_object_get_pages(obj);
> @@ -1132,15 +1135,16 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
>  
>   obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
>  
> + ret = i915_gem_object_wait_rendering(obj, false);
> + if (ret)
> + return ret;
> +
>   if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
>   /* If we're not in the cpu write domain, set ourself into the 
> gtt
>    * write domain and manually flush cachelines (if required). 
> This
>    * optimizes for the case when the gpu will use the data
>    * right away and we therefore have to clflush anyway. */
>   needs_clflush_after = cpu_write_needs_clflush(obj);
> - ret = i915_gem_object_wait_rendering(obj, false);
> - if (ret)
> - return ret;
>   }
>   /* Same trick applies to invalidate partially written cachelines read
>    * before writing. */
> @@ -1335,11 +1339,9 @@ int
>  i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
>      bool readonly)
>  {
> + struct reservation_object *resv;
>   int ret, i;
>  
> - if (!obj->active)
> - return 0;
> -
>   if (readonly) {
>   if (obj->last_write_req != NULL) {
>   ret = i915_wait_request(obj->last_write_req);
> @@ -1366,6 +1368,16 @@ i915_gem_object_wait_rendering(struct 
> drm_i915_gem_object *obj,
>   GEM_BUG_ON(obj->active);
>   }
>  
> + resv = i915_gem_object_get_dmabuf_resv(obj);
> + if (resv) {
> + long err;

We already have ret in the function scope.

> +
> + err = reservation_object_wait_timeout_rcu(resv, !readonly, true,
> +   MAX_SCHEDULE_TIMEOUT);
> + if (err < 0)
> + return err;
> + }
> +
>   return 0;
>  }
>  
> @@ -3402,13 +3414,13 @@ 

Re: [Intel-gfx] [PATCH i-g-t v2 03/15] kms_psr_sink_crc: Use for_each_pipe_with_valid_output to find a valid config.

[Ander Conselvan De Oliveira]

On Fri, 2016-07-15 at 14:15 +0300, Ander Conselvan De Oliveira wrote:
> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> > 
> > This is the only time PIPE_ANY was used to mean something other than
> > unassign this output from a pipe. Without this PIPE_ANY can be aliased
> > to PIPE_NONE.
> > 
> > Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Ander Conselvan de Oliveira 

Actually, kms_sink_crc_basic needs the same treatment.

Ander

> 
> > 
> > ---
> >  tests/kms_psr_sink_crc.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> > index b18e426303e3..d7bce3bb7855 100644
> > --- a/tests/kms_psr_sink_crc.c
> > +++ b/tests/kms_psr_sink_crc.c
> > @@ -103,15 +103,16 @@ static void setup_output(data_t *data)
> >  {
> >     igt_display_t *display = >display;
> >     igt_output_t *output;
> > +   enum pipe pipe;
> >  
> > -   for_each_connected_output(display, output) {
> > +   for_each_pipe_with_valid_output(display, pipe, output) {
> >     drmModeConnectorPtr c = output->config.connector;
> >  
> >     if (c->connector_type != DRM_MODE_CONNECTOR_eDP ||
> >     c->connection != DRM_MODE_CONNECTED)
> >     continue;
> >  
> > -   igt_output_set_pipe(output, PIPE_ANY);
> > +   igt_output_set_pipe(output, pipe);
> >     data->crtc_id = output->config.crtc->crtc_id;
> >     data->output = output;
> >     data->mode = igt_output_get_mode(output);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests: add some color management tests to BAT

[Lionel Landwerlin]

We only enable pipe A tests and basic size fuzzing tests to minimize
the amount of time spend. From experience color management issues
tends to trigger failures on all pipes so only testing one seems
reasonable.

Signed-off-by: Lionel Landwerlin 
---
 tests/kms_pipe_color.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
index 9f7ac7e..eea70b9 100644
--- a/tests/kms_pipe_color.c
+++ b/tests/kms_pipe_color.c
@@ -830,6 +830,13 @@ static void test_pipe_limited_range_ctm(data_t *data,
 }
 #endif
 
+static const char *
+test_prefix_for_pipe(enum pipe p)
+{
+   // Only make the first pipe part of the BAT.
+   return p == PIPE_A ? "basic-" : "";
+}
+
 static void
 run_tests_for_pipe(data_t *data, enum pipe p)
 {
@@ -879,7 +886,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
data->color_depth = 8;
delta = 1.0 / (1 << data->color_depth);
 
-   igt_subtest_f("ctm-red-to-blue-pipe%d", p) {
+   igt_subtest_f("%sctm-red-to-blue-pipe%d", test_prefix_for_pipe(p), p) {
color_t blue_green_blue[] = {
{ 0.0, 0.0, 1.0 },
{ 0.0, 1.0, 0.0 },
@@ -892,7 +899,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
 blue_green_blue, ctm));
}
 
-   igt_subtest_f("ctm-green-to-red-pipe%d", p) {
+   igt_subtest_f("%sctm-green-to-red-pipe%d", test_prefix_for_pipe(p), p) {
color_t red_red_blue[] = {
{ 1.0, 0.0, 0.0 },
{ 1.0, 0.0, 0.0 },
@@ -905,7 +912,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
 red_red_blue, ctm));
}
 
-   igt_subtest_f("ctm-blue-to-red-pipe%d", p) {
+   igt_subtest_f("%sctm-blue-to-red-pipe%d", test_prefix_for_pipe(p), p) {
color_t red_green_red[] = {
{ 1.0, 0.0, 0.0 },
{ 0.0, 1.0, 0.0 },
@@ -922,7 +929,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
 * the it depends on the hardware we're dealing with, we can
 * either get clamped or rounded values and we also need to
 * account for odd number of items in the LUTs. */
-   igt_subtest_f("ctm-0-25-pipe%d", p) {
+   igt_subtest_f("%sctm-0-25-pipe%d", test_prefix_for_pipe(p), p) {
color_t expected_colors[] = {
{ 0.0, }, { 0.0, }, { 0.0, }
};
@@ -943,7 +950,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
igt_assert(success);
}
 
-   igt_subtest_f("ctm-0-5-pipe%d", p) {
+   igt_subtest_f("%sctm-0-5-pipe%d", test_prefix_for_pipe(p), p) {
color_t expected_colors[] = {
{ 0.0, }, { 0.0, }, { 0.0, }
};
@@ -964,7 +971,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
igt_assert(success);
}
 
-   igt_subtest_f("ctm-0-75-pipe%d", p) {
+   igt_subtest_f("%sctm-0-75-pipe%d", test_prefix_for_pipe(p), p) {
color_t expected_colors[] = {
{ 0.0, }, { 0.0, }, { 0.0, }
};
@@ -985,7 +992,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
igt_assert(success);
}
 
-   igt_subtest_f("ctm-max-pipe%d", p) {
+   igt_subtest_f("%sctm-max-pipe%d", test_prefix_for_pipe(p), p) {
color_t full_rgb[] = {
{ 1.0, 0.0, 0.0 },
{ 0.0, 1.0, 0.0 },
@@ -1003,7 +1010,7 @@ run_tests_for_pipe(data_t *data, enum pipe p)
 full_rgb, ctm));
}
 
-   igt_subtest_f("ctm-negative-pipe%d", p) {
+   igt_subtest_f("%sctm-negative-pipe%d", test_prefix_for_pipe(p), p) {
color_t all_black[] = {
{ 0.0, 0.0, 0.0 },
{ 0.0, 0.0, 0.0 },
@@ -1017,20 +1024,20 @@ run_tests_for_pipe(data_t *data, enum pipe p)
}
 
 #if 0
-   igt_subtest_f("ctm-limited-range-pipe%d", p)
+   igt_subtest_f("%sctm-limited-range-pipe%d", test_prefix_for_pipe(p), p)
test_pipe_limited_range_ctm(data, primary);
 #endif
 
-   igt_subtest_f("degamma-pipe%d", p)
+   igt_subtest_f("%sdegamma-pipe%d", test_prefix_for_pipe(p), p)
test_pipe_degamma(data, primary);
 
-   igt_subtest_f("gamma-pipe%d", p)
+   igt_subtest_f("%sgamma-pipe%d", test_prefix_for_pipe(p), p)
test_pipe_gamma(data, primary);
 
-   igt_subtest_f("legacy-gamma-pipe%d", p)
+   igt_subtest_f("%slegacy-gamma-pipe%d", test_prefix_for_pipe(p), p)
test_pipe_legacy_gamma(data, primary);
 
-   igt_subtest_f("legacy-gamma-reset-pipe%d", p)
+   igt_subtest_f("%slegacy-gamma-reset-pipe%d", test_prefix_for_pipe(p), p)

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros

[Patchwork]

== Series Details ==

Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros
URL   : https://patchwork.freedesktop.org/series/10036/
State : success

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ro-skl3-i5-6260u)
Test gem_sync:
Subgroup basic-store-each:
fail   -> DMESG-FAIL (ro-bdw-i7-5600u)

fi-hsw-i7-4770k  total:243  pass:213  dwarn:0   dfail:0   fail:10  skip:20 
fi-kbl-qkkr  total:243  pass:178  dwarn:27  dfail:1   fail:10  skip:27 
fi-skl-i5-6260u  total:243  pass:222  dwarn:0   dfail:0   fail:9   skip:12 
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26 
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40 
ro-bdw-i5-5250u  total:244  pass:217  dwarn:4   dfail:0   fail:10  skip:13 
ro-bdw-i7-5557U  total:244  pass:219  dwarn:1   dfail:0   fail:9   skip:15 
ro-bdw-i7-5600u  total:244  pass:201  dwarn:0   dfail:1   fail:10  skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:194  dwarn:0   dfail:0   fail:12  skip:38 
ro-hsw-i3-4010u  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24 
ro-hsw-i7-4770r  total:244  pass:209  dwarn:0   dfail:0   fail:11  skip:24 
ro-ilk-i7-620lm  total:244  pass:169  dwarn:0   dfail:0   fail:12  skip:63 
ro-ilk1-i5-650   total:239  pass:170  dwarn:0   dfail:0   fail:11  skip:58 
ro-ivb-i7-3770   total:244  pass:200  dwarn:0   dfail:0   fail:11  skip:33 
ro-skl3-i5-6260u total:244  pass:222  dwarn:0   dfail:0   fail:10  skip:12 
ro-snb-i7-2620M  total:244  pass:190  dwarn:0   dfail:0   fail:12  skip:42 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1531/

63a drm-intel-nightly: 2016y-07m-19d-13h-02m-39s UTC integration manifest
b23d573 drm/i915/guc: revisit GuC loader message levels
950c1a4 drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
5e8e33b drm: extra printk() wrapper macros

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Mark imported dma-buf objects as being coherent

[Joonas Lahtinen]

On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> A foreign dma-buf does not share our cache domain tracking, and we rely
> on the producer ensuring cache coherency. Marking them as being in the
> CPU domain is incorrect.
> 
> Signed-off-by: Chris Wilson 

Maybe even add a comment above the assignment that _GTT is used in the
purpose of being coherent.

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 80bbe43a2e92..c7d734248ed0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -299,6 +299,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
> drm_device *dev,
>   drm_gem_private_object_init(dev, >base, dma_buf->size);
>   i915_gem_object_init(obj, _gem_object_dmabuf_ops);
>   obj->base.import_attach = attach;
> + obj->base.read_domains = I915_GEM_DOMAIN_GTT;
> + obj->base.write_domain = 0;
>  
>   return >base;
>  
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

[Lionel Landwerlin]

On 19/07/16 13:49, Chris Wilson wrote:

On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote:

On 19/07/16 12:42, Chris Wilson wrote:

On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:

On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:

Signed-off-by: Lionel Landwerlin 

Do we have the time for those in the BAT budget?

Do we not? It has been demonstrated that people notice when gamma is
broken, can we afford to risk repeating this bug?

(Or in other news, where are all the new QA bugs from failing tests?
Seems like we are missing some bug reports from igt added to show off
bugs.)
-Chris


It's about 35s to run this test :
real0m34.352s
user0m0.972s
sys0m1.626s

Knowing that we repeat the same tests across different pipes (so for
it would only take a third of that time if we were to just test pipe
A).

If one test is likely to catch 99.999% of the bugs, then just add that
one test to bat.
  

I don't have a sense of the budget, is that too much already?

Oh, we've overshot the budget by 200%. Deciding which tests are more
important than others, or whether that budget is unrealistic requires
holistic knowledge i.e. our maintainer overlords.
-Chris


Right,


Let me resend a patch for just pipe-A then.

I haven't seen failures on one pipe but not the other.


-

Lionel

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

[Intel-gfx] [PATCH 5/5] drm/i915/guc: use for_each_engine_id() where appropriate

[Dave Gordon]

Now that host structures are indexed by host engine-id rather than
guc_id, we can usefully convert some for_each_engine() loops to use
for_each_engine_id() and avoid multiple dereferences of engine->id.

Also a few related tweaks to cache structure members locally wherever
they're used more than once or twice, hopefully eliminating memory
references.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 17 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 22 +-
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5cbb8ef..76918ab 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2541,6 +2541,7 @@ static void i915_guc_client_info(struct seq_file *m,
 struct i915_guc_client *client)
 {
struct intel_engine_cs *engine;
+   enum intel_engine_id id;
uint64_t tot = 0;
 
seq_printf(m, "\tPriority %d, GuC ctx index: %u, PD offset 0x%x\n",
@@ -2555,11 +2556,11 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
 
-   for_each_engine(engine, dev_priv) {
+   for_each_engine_id(engine, dev_priv, id) {
+   u64 submissions = client->submissions[id];
+   tot += submissions;
seq_printf(m, "\tSubmissions: %llu %s\n",
-   client->submissions[engine->id],
-   engine->name);
-   tot += client->submissions[engine->id];
+   submissions, engine->name);
}
seq_printf(m, "\tTotal: %llu\n", tot);
 }
@@ -2604,11 +2605,11 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "GuC last action error code: %d\n", guc.action_err);
 
seq_printf(m, "\nGuC submissions:\n");
-   for_each_engine(engine, dev_priv) {
+   for_each_engine_id(engine, dev_priv, id) {
+   u64 submissions = guc.submissions[id];
+   total += submissions;
seq_printf(m, "\t%-24s: %10llu, last seqno 0x%08x\n",
-   engine->name, guc.submissions[engine->id],
-   guc.last_seqno[engine->id]);
-   total += guc.submissions[engine->id];
+   engine->name, submissions, guc.last_seqno[id]);
}
seq_printf(m, "\t%s: %llu\n", "Total", total);
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4daba77..5beed1b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -342,7 +342,8 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 
for_each_engine_masked(engine, dev_priv, client->engines) {
struct intel_context *ce = >engine[engine->id];
-   struct guc_execlist_context *lrc = [engine->guc_id];
+   uint32_t guc_engine_id = engine->guc_id;
+   struct guc_execlist_context *lrc = [guc_engine_id];
struct drm_i915_gem_object *obj;
 
/* TODO: We have a design issue to be solved here. Only when we
@@ -361,7 +362,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
-   (engine->guc_id << GUC_ELC_ENGINE_OFFSET);
+   (guc_engine_id << GUC_ELC_ENGINE_OFFSET);
 
obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
@@ -371,7 +372,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
lrc->ring_next_free_location = gfx_addr;
lrc->ring_current_tail_pointer_value = 0;
 
-   desc.engines_used |= (1 << engine->guc_id);
+   desc.engines_used |= (1 << guc_engine_id);
}
 
DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",
@@ -461,6 +462,7 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
/* wqi_len is in DWords, and does not include the one-word header */
const size_t wqi_size = sizeof(struct guc_wq_item);
const u32 wqi_len = wqi_size/sizeof(u32) - 1;
+   struct intel_engine_cs *engine = rq->engine;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
@@ -502,12 +504,11 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
/* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
(wqi_len << WQ_LEN_SHIFT) 

[Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

[Dave Gordon]

When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theory, this could lead to the single queue becoming a bottleneck in
which an excess of outstanding work for one or more engines might
prevent work for an idle engine reaching the hardware.

To reduce this risk, we can create one GuC client per engine. Each will
have its own workqueue, to be used only for work targeting a single
engine, so there will be no cross-engine contention for workqueue slots.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 25 -
 drivers/gpu/drm/i915/i915_guc_submission.c | 35 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 3 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 90aef45..5cbb8ef 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2570,20 +2570,26 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_guc guc;
-   struct i915_guc_client client = {};
+   struct i915_guc_client *clients;
struct intel_engine_cs *engine;
+   enum intel_engine_id id;
u64 total = 0;
 
if (!HAS_GUC_SCHED(dev_priv))
return 0;
 
+   clients = kcalloc(I915_NUM_ENGINES, sizeof(*clients), GFP_KERNEL);
+   if (clients == NULL)
+   return -ENOMEM;
+
if (mutex_lock_interruptible(>struct_mutex))
-   return 0;
+   goto done;
 
/* Take a local copy of the GuC data, so we can dump it at leisure */
guc = dev_priv->guc;
-   if (guc.execbuf_client)
-   client = *guc.execbuf_client;
+   for_each_engine_id(engine, dev_priv, id)
+   if (guc.exec_clients[id])
+   clients[id] = *guc.exec_clients[id];
 
mutex_unlock(>struct_mutex);
 
@@ -2606,11 +2612,18 @@ static int i915_guc_info(struct seq_file *m, void *data)
}
seq_printf(m, "\t%s: %llu\n", "Total", total);
 
-   seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
-   i915_guc_client_info(m, dev_priv, );
+   for_each_engine_id(engine, dev_priv, id) {
+   seq_printf(m, "\nGuC exec_client[%d] @ %p:\n",
+   id, guc.exec_clients[id]);
+   if (guc.exec_clients[id])
+   i915_guc_client_info(m, dev_priv, [id]);
+   }
 
/* Add more as required ... */
 
+done:
+   kfree(clients);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index dc5f485..b0f9945 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -434,7 +434,9 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
 int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
 {
const size_t wqi_size = sizeof(struct guc_wq_item);
-   struct i915_guc_client *gc = request->i915->guc.execbuf_client;
+   enum intel_engine_id engine_id = request->engine->id;
+   struct intel_guc *guc = >i915->guc;
+   struct i915_guc_client *gc = guc->exec_clients[engine_id];
struct guc_process_desc *desc;
u32 freespace;
 
@@ -589,7 +591,7 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
 {
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
-   struct i915_guc_client *client = guc->execbuf_client;
+   struct i915_guc_client *client = guc->exec_clients[engine_id];
int b_ret;
 
guc_add_workqueue_item(client, rq);
@@ -723,7 +725,7 @@ static bool guc_doorbell_check(struct intel_guc *guc, 
uint16_t db_id)
  */
 static void guc_init_doorbell_hw(struct intel_guc *guc)
 {
-   struct i915_guc_client *client = guc->execbuf_client;
+   struct i915_guc_client *client = guc->exec_clients[RCS];
uint16_t db_id;
int i, err;
 
@@ -1004,17 +1006,21 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = _priv->guc;
struct i915_guc_client *client;
+   struct intel_engine_cs *engine;
 
-   /* client for execbuf submission */
-   client = guc_client_alloc(dev_priv,
- GUC_CTX_PRIORITY_KMD_NORMAL,
- dev_priv->kernel_context);
-   if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
-   return -ENOMEM;
+   for_each_engine(engine, dev_priv) {
+   /* client for execbuf submission */
+   client = 

[Intel-gfx] [PATCH 4/5] drm/i915/guc: add engine mask to GuC client & pass to GuC

[Dave Gordon]

The Context Descriptor passed by the kernel to the GuC contains a field
specifying which engine(s) the context will use. Historically, this was
always set to "all of them", but now that we have one client per engine,
we can be more precise, and set only the single bit for the engine that
the client is associated with.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++-
 drivers/gpu/drm/i915/intel_guc.h   |  3 ++-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b0f9945..4daba77 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -340,7 +340,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
 
-   for_each_engine(engine, dev_priv) {
+   for_each_engine_masked(engine, dev_priv, client->engines) {
struct intel_context *ce = >engine[engine->id];
struct guc_execlist_context *lrc = [engine->guc_id];
struct drm_i915_gem_object *obj;
@@ -374,6 +374,8 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.engines_used |= (1 << engine->guc_id);
}
 
+   DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",
+   client->engines, desc.engines_used);
WARN_ON(desc.engines_used == 0);
 
/*
@@ -768,6 +770,7 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
  */
 static struct i915_guc_client *
 guc_client_alloc(struct drm_i915_private *dev_priv,
+uint32_t engines,
 uint32_t priority,
 struct i915_gem_context *ctx)
 {
@@ -780,10 +783,11 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
if (!client)
return NULL;
 
-   client->doorbell_id = GUC_INVALID_DOORBELL_ID;
-   client->priority = priority;
client->owner = ctx;
client->guc = guc;
+   client->engines = engines;
+   client->priority = priority;
+   client->doorbell_id = GUC_INVALID_DOORBELL_ID;
 
client->ctx_index = (uint32_t)ida_simple_get(>ctx_ids, 0,
GUC_MAX_GPU_CONTEXTS, GFP_KERNEL);
@@ -825,8 +829,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
if (guc_init_doorbell(guc, client, db_id))
goto err;
 
-   DRM_DEBUG_DRIVER("new priority %u client %p: ctx_index %u\n",
-   priority, client, client->ctx_index);
+   DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x: 
ctx_index %u\n",
+   priority, client, client->engines, client->ctx_index);
DRM_DEBUG_DRIVER("doorbell id %u, cacheline offset 0x%x\n",
client->doorbell_id, client->doorbell_offset);
 
@@ -1011,6 +1015,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
for_each_engine(engine, dev_priv) {
/* client for execbuf submission */
client = guc_client_alloc(dev_priv,
+ intel_engine_flag(engine),
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 7b4cc4d..53d41b5 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -67,6 +67,8 @@ struct i915_guc_client {
void *client_base;  /* first page (only) of above   */
struct i915_gem_context *owner;
struct intel_guc *guc;
+
+   uint32_t engines;   /* bitmap of (host) engine ids  */
uint32_t priority;
uint32_t ctx_index;
 
@@ -79,7 +81,6 @@ struct i915_guc_client {
uint32_t wq_offset;
uint32_t wq_size;
uint32_t wq_tail;
-   uint32_t unused;/* Was 'wq_head'*/
 
uint32_t no_wq_space;
uint32_t q_fail;/* No longer used   */
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/5] drm/i915/guc: refactor guc_init_doorbell_hw()

[Dave Gordon]

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d8402e4..dc5f485 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -698,32 +698,47 @@ static void gem_release_guc_obj(struct 
drm_i915_gem_object *obj)
kfree(client);
 }
 
+/* Check that a doorbell register is in the expected state */
+static bool guc_doorbell_check(struct intel_guc *guc, uint16_t db_id)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   i915_reg_t drbreg = GEN8_DRBREGL(db_id);
+   uint32_t value = I915_READ(drbreg);
+   bool enabled = (value & GUC_DOORBELL_ENABLED) != 0;
+   bool expected = test_bit(db_id, guc->doorbell_bitmap);
+
+   if (enabled == expected)
+   return true;
+
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) 0x%x, should be %s\n",
+db_id, drbreg.reg, value,
+expected ? "active" : "inactive");
+
+   return false;
+}
+
 /*
  * Borrow the first client to set up & tear down each unused doorbell
  * in turn, to ensure that all doorbell h/w is (re)initialised.
  */
 static void guc_init_doorbell_hw(struct intel_guc *guc)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct i915_guc_client *client = guc->execbuf_client;
-   uint16_t db_id, i;
-   int err;
+   uint16_t db_id;
+   int i, err;
 
+   /* Save client's original doorbell selection */
db_id = client->doorbell_id;
 
for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
-   i915_reg_t drbreg = GEN8_DRBREGL(i);
-   u32 value = I915_READ(drbreg);
-
-   if (test_bit(i, guc->doorbell_bitmap))
+   /* Skip if doorbell is OK */
+   if (guc_doorbell_check(guc, i))
continue;
 
err = guc_update_doorbell_id(guc, client, i);
-
-   /* Report update failure or unexpectedly active doorbell */
-   if (err || (i != db_id && (value & GUC_DOORBELL_ENABLED)))
-   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) was 0x%x, err 
%d\n",
- i, drbreg.reg, value, err);
+   if (err)
+   DRM_DEBUG_DRIVER("Doorbell %d update failed, err %d\n",
+   i, err);
}
 
/* Restore to original value */
@@ -732,18 +747,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
db_id, err);
 
-   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
-   i915_reg_t drbreg = GEN8_DRBREGL(i);
-   u32 value = I915_READ(drbreg);
-
-   if (test_bit(i, guc->doorbell_bitmap))
-   continue;
-
-   if (i != db_id && (value & GUC_DOORBELL_ENABLED))
-   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
- i, drbreg.reg, value);
-
-   }
+   /* Read back & verify all doorbell registers */
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
+   (void)guc_doorbell_check(guc, i);
 }
 
 /**
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/5] drm/i915/guc: doorbell reset should avoid used doorbells

[Dave Gordon]

guc_init_doorbell_hw() borrows the (currently single) GuC client to use
in reinitialising ALL the doorbell registers (as the hardware doesn't
reset them when the GuC is reset). As a prerequisite for accommodating
multiple clients, it should only reset doorbells that are supposed to be
disabled, avoiding those that are marked as in use by any client.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..d8402e4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -699,7 +699,7 @@ static void gem_release_guc_obj(struct drm_i915_gem_object 
*obj)
 }
 
 /*
- * Borrow the first client to set up & tear down every doorbell
+ * Borrow the first client to set up & tear down each unused doorbell
  * in turn, to ensure that all doorbell h/w is (re)initialised.
  */
 static void guc_init_doorbell_hw(struct intel_guc *guc)
@@ -715,6 +715,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
i915_reg_t drbreg = GEN8_DRBREGL(i);
u32 value = I915_READ(drbreg);
 
+   if (test_bit(i, guc->doorbell_bitmap))
+   continue;
+
err = guc_update_doorbell_id(guc, client, i);
 
/* Report update failure or unexpectedly active doorbell */
@@ -733,6 +736,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
i915_reg_t drbreg = GEN8_DRBREGL(i);
u32 value = I915_READ(drbreg);
 
+   if (test_bit(i, guc->doorbell_bitmap))
+   continue;
+
if (i != db_id && (value & GUC_DOORBELL_ENABLED))
DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
  i, drbreg.reg, value);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH i-g-t v2 01/15] igt_kms: Remove kmstest_connector_config.crtc_idx

[Maarten Lankhorst]

Hey,

Op 13-07-16 om 14:13 schreef Daniel Vetter:
> On Wed, Jul 06, 2016 at 11:55:41AM +0200, Maarten Lankhorst wrote:
>> This is the same as using config.pipe because the order of crtcs will
>> never change.
>>
>> Signed-off-by: Maarten Lankhorst 
> In the interest of generic igt, I'm somewhat inclined to instead nuke
> crtc->pipe (it's an Intelism) instead of crtc->idx. I also thought there's
> some work from Robert Foss (still uncommented) to reorganize this.
config->pipe is mostly used as argument to kmstest_pipe_name, so I think this 
commit is fine.
it's named display->pipes in the tests, not display->crtcs.

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

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

[Daniel Vetter]

connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.

While at it also improve/align the kerneldoc comment.

v2: Mention where those ids are from ...

v3: Add -ing to supporting and try to not break the world.

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Acked-by: Chris Wilson 
Acked-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 12 ++--
 include/drm/drm_crtc.h | 13 ++---
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c456628740dd..da9bbe0fdb1e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -934,11 +934,11 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
 
-   connector->connector_id = ida_simple_get(>connector_ida, 0, 0, 
GFP_KERNEL);
-   if (connector->connector_id < 0) {
-   ret = connector->connector_id;
+   ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
+   if (ret < 0)
goto out_put;
-   }
+   connector->index = ret;
+   ret = 0;
 
connector->connector_type = connector_type;
connector->connector_type_id =
@@ -986,7 +986,7 @@ out_put_type_id:
ida_remove(connector_ida, connector->connector_type_id);
 out_put_id:
if (ret)
-   ida_remove(>connector_ida, connector->connector_id);
+   ida_remove(>connector_ida, connector->index);
 out_put:
if (ret)
drm_mode_object_unregister(dev, >base);
@@ -1030,7 +1030,7 @@ void drm_connector_cleanup(struct drm_connector 
*connector)
   connector->connector_type_id);
 
ida_remove(>mode_config.connector_ida,
-  connector->connector_id);
+  connector->index);
 
kfree(connector->display_info.bus_formats);
drm_mode_object_unregister(dev, >base);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f8ba5aab5d28..3edeaf88ebc0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1246,7 +1246,6 @@ struct drm_encoder {
  * @head: list management
  * @base: base KMS object
  * @name: human readable name, can be overwritten by the driver
- * @connector_id: compacted connector id useful indexing arrays
  * @connector_type: one of the %DRM_MODE_CONNECTOR_ types from drm_mode.h
  * @connector_type_id: index into connector type enum
  * @interlace_allowed: can this connector handle interlaced modes?
@@ -1303,7 +1302,15 @@ struct drm_connector {
struct drm_mode_object base;
 
char *name;
-   int connector_id;
+
+   /**
+* @index: Compacted connector index, which matches the position inside
+* the mode_config.list for drivers not supporting hot-add/removing. Can
+* be used as an array index. It is invariant over the lifetime of the
+* connector.
+*/
+   unsigned index;
+
int connector_type;
int connector_type_id;
bool interlace_allowed;
@@ -2764,7 +2771,7 @@ void drm_connector_unregister(struct drm_connector 
*connector);
 extern void drm_connector_cleanup(struct drm_connector *connector);
 static inline unsigned drm_connector_index(struct drm_connector *connector)
 {
-   return connector->connector_id;
+   return connector->index;
 }
 
 extern __printf(5, 6)
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

[Chris Wilson]

On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote:
> On 19/07/16 12:42, Chris Wilson wrote:
> >On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> >>On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> >>>Signed-off-by: Lionel Landwerlin 
> >>Do we have the time for those in the BAT budget?
> >Do we not? It has been demonstrated that people notice when gamma is
> >broken, can we afford to risk repeating this bug?
> >
> >(Or in other news, where are all the new QA bugs from failing tests?
> >Seems like we are missing some bug reports from igt added to show off
> >bugs.)
> >-Chris
> >
> It's about 35s to run this test :
> real0m34.352s
> user0m0.972s
> sys0m1.626s
> 
> Knowing that we repeat the same tests across different pipes (so for
> it would only take a third of that time if we were to just test pipe
> A).

If one test is likely to catch 99.999% of the bugs, then just add that
one test to bat.
 
> I don't have a sense of the budget, is that too much already?

Oh, we've overshot the budget by 200%. Deciding which tests are more
important than others, or whether that budget is unrealistic requires
holistic knowledge i.e. our maintainer overlords.
-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 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

[Daniel Vetter]

On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> These are the leftovers I could only track down using keep_warnings =
> True. For some of them we might want to update our style guide on how
> to reference structures and constants, not sure ...
> 
> Cc: Markus Heiser 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

Aside: With this and the latest docs-next branch from Jon it's possible to
compile test doc changes (e.g. with git rebase -x) using:

$ make IGNORE_DOCBOOKS=1 SPHINXOPTS=-W htmldocs

To make this easier I've quickly pulled in the latest docs-next into
drm-intel-nightly.

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c  |  4 ++--
>  drivers/gpu/drm/drm_fb_helper.c |  2 +-
>  drivers/gpu/drm/drm_irq.c   |  8 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
>  drivers/gpu/drm/i915/i915_vgpu.c| 42 
> -
>  drivers/gpu/drm/i915/intel_audio.c  |  6 ++---
>  drivers/gpu/drm/i915/intel_guc_fwif.h   |  5 ++--
>  include/drm/drm_crtc.h  |  8 +++
>  include/drm/drm_gem.h   |  4 ++--
>  9 files changed, 41 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f9f2506b1855..420f4fc8e6a7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1273,7 +1273,7 @@ static unsigned int drm_num_planes(struct drm_device 
> *dev)
>   * @plane: plane object to init
>   * @possible_crtcs: bitmask of possible CRTCs
>   * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
>   * @type: type of plane (overlay, primary, cursor)
>   * @name: printf style format string for the plane name, or NULL for default 
> name
> @@ -1388,7 +1388,7 @@ static void drm_plane_unregister_all(struct drm_device 
> *dev)
>   * @plane: plane object to init
>   * @possible_crtcs: bitmask of possible CRTCs
>   * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
>   * @is_primary: plane type (primary vs overlay)
>   *
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e985d91b..95f405e04f5f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2194,7 +2194,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>   * @fb_helper: the drm_fb_helper
>   *
>   * Scan the connectors attached to the fb_helper and try to put together a
> - * setup after *notification of a change in output configuration.
> + * setup after notification of a change in output configuration.
>   *
>   * Called at runtime, takes the mode config locks to be able to check/change 
> the
>   * modeset configuration. Must be run from process context (which usually 
> means
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index b49a4a6e97cd..a33465d8e133 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -713,10 +713,10 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
>   * Negative value on error, failure or if not supported in current
>   * video mode:
>   *
> - * -EINVAL   - Invalid CRTC.
> - * -EAGAIN   - Temporary unavailable, e.g., called before initial modeset.
> - * -ENOTSUPP - Function not supported in current display mode.
> - * -EIO  - Failed, e.g., due to failed scanout position query.
> + * -EINVALInvalid CRTC.
> + * -EAGAINTemporary unavailable, e.g., called before initial modeset.
> + * -ENOTSUPP  Function not supported in current display mode.
> + * -EIO   Failed, e.g., due to failed scanout position query.
>   *
>   * Returns or'ed positive status flags on success:
>   *
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0db36d27e90b..4e1de31f072b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -152,7 +152,7 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>   * @dev: DRM device
>   * @pipe: simple display pipe object to initialize
>   * @funcs: callbacks for the display pipe (optional)
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
>   * @connector: connector to attach and register
>   *
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 142bac976919..ca2e91259948 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -156,27 +156,27 @@ static int 

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

[Lionel Landwerlin]

On 19/07/16 12:42, Chris Wilson wrote:

On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:

On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:

Signed-off-by: Lionel Landwerlin 

Do we have the time for those in the BAT budget?

Do we not? It has been demonstrated that people notice when gamma is
broken, can we afford to risk repeating this bug?

(Or in other news, where are all the new QA bugs from failing tests?
Seems like we are missing some bug reports from igt added to show off
bugs.)
-Chris


It's about 35s to run this test :
real0m34.352s
user0m0.972s
sys0m1.626s

Knowing that we repeat the same tests across different pipes (so for it 
would only take a third of that time if we were to just test pipe A).


I don't have a sense of the budget, is that too much already?

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

[Intel-gfx] [CI-RESEND 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..e299b64 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -726,8 +724,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
i915_reg_t drbreg = GEN8_DRBREGL(i);
@@ -819,8 +817,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -998,7 +994,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..a2f4fa4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   DRM_WARN("GEN%d does not support GuC operation\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   DRM_WARN("No GuC firmware known for this platform\n");
err = -ENODEV;
goto fail;
}
@@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -571,7 +571,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -583,7 +583,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -593,7 +593,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -602,14 +602,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTE("Firmware is too large to fit in WOPCM\n");
goto fail;
}
 
@@ -624,7 +624,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 

[Intel-gfx] [CI-RESEND 1/3] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon 
Reviewed-by: Eric Engestrom 
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865..3669cdd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -162,6 +162,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -187,12 +207,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

[Daniel Vetter]

On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote:
> connector_id in the uapi actually means drm_connector->base.id, which
> is something entirely different. And ->index is also consistent with
> plane/encoder/CRTCS and the various drm_*_index() functions.
> 
> While at it also improve/align the kerneldoc comment.
> 
> v2: Mention where those ids are from ...
> 
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Acked-by: Chris Wilson 
> Acked-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 

fixed up the s/support/supporting/ that somehow escape git add and then
pushed to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 11 +--
>  include/drm/drm_crtc.h | 13 ++---
>  2 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index c456628740dd..f9f2506b1855 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -934,11 +934,10 @@ int drm_connector_init(struct drm_device *dev,
>   connector->dev = dev;
>   connector->funcs = funcs;
>  
> - connector->connector_id = ida_simple_get(>connector_ida, 0, 0, 
> GFP_KERNEL);
> - if (connector->connector_id < 0) {
> - ret = connector->connector_id;
> + ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
> + if (ret < 0)
>   goto out_put;
> - }
> + connector->index = ret;
>  
>   connector->connector_type = connector_type;
>   connector->connector_type_id =
> @@ -986,7 +985,7 @@ out_put_type_id:
>   ida_remove(connector_ida, connector->connector_type_id);
>  out_put_id:
>   if (ret)
> - ida_remove(>connector_ida, connector->connector_id);
> + ida_remove(>connector_ida, connector->index);
>  out_put:
>   if (ret)
>   drm_mode_object_unregister(dev, >base);
> @@ -1030,7 +1029,7 @@ void drm_connector_cleanup(struct drm_connector 
> *connector)
>  connector->connector_type_id);
>  
>   ida_remove(>mode_config.connector_ida,
> -connector->connector_id);
> +connector->index);
>  
>   kfree(connector->display_info.bus_formats);
>   drm_mode_object_unregister(dev, >base);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f8ba5aab5d28..4aa4c4341d01 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1246,7 +1246,6 @@ struct drm_encoder {
>   * @head: list management
>   * @base: base KMS object
>   * @name: human readable name, can be overwritten by the driver
> - * @connector_id: compacted connector id useful indexing arrays
>   * @connector_type: one of the %DRM_MODE_CONNECTOR_ types from 
> drm_mode.h
>   * @connector_type_id: index into connector type enum
>   * @interlace_allowed: can this connector handle interlaced modes?
> @@ -1303,7 +1302,15 @@ struct drm_connector {
>   struct drm_mode_object base;
>  
>   char *name;
> - int connector_id;
> +
> + /**
> +  * @index: Compacted connector index, which matches the position inside
> +  * the mode_config.list for drivers not support hot-add/removing. Can be
> +  * used as an array index. It is invariant over the lifetime of the
> +  * connector.
> +  */
> + unsigned index;
> +
>   int connector_type;
>   int connector_type_id;
>   bool interlace_allowed;
> @@ -2764,7 +2771,7 @@ void drm_connector_unregister(struct drm_connector 
> *connector);
>  extern void drm_connector_cleanup(struct drm_connector *connector);
>  static inline unsigned drm_connector_index(struct drm_connector *connector)
>  {
> - return connector->connector_id;
> + return connector->index;
>  }
>  
>  extern __printf(5, 6)
> -- 
> 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] drm: drm_connector->s/connector_id/index/ for consistency

[Chris Wilson]

On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote:
> connector_id in the uapi actually means drm_connector->base.id, which
> is something entirely different. And ->index is also consistent with
> plane/encoder/CRTCS and the various drm_*_index() functions.
> 
> While at it also improve/align the kerneldoc comment.
> 
> v2: Mention where those ids are from ...
> 
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Acked-by: Chris Wilson 
> Acked-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 11 +--
>  include/drm/drm_crtc.h | 13 ++---
>  2 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index c456628740dd..f9f2506b1855 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -934,11 +934,10 @@ int drm_connector_init(struct drm_device *dev,
>   connector->dev = dev;
>   connector->funcs = funcs;
>  
> - connector->connector_id = ida_simple_get(>connector_ida, 0, 0, 
> GFP_KERNEL);
> - if (connector->connector_id < 0) {
> - ret = connector->connector_id;
> + ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
> + if (ret < 0)
>   goto out_put;
> - }
> + connector->index = ret;

Oh, that is glorious!

>  out_put_id:
>   if (ret)
> - ida_remove(>connector_ida, connector->connector_id);
> + ida_remove(>connector_ida, connector->index);

ret == connector->index (it's only otherwise set on failure).
-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 series starting with [1/2] doc/sphinx: Enable keep_warnings

[Patchwork]

== Series Details ==

Series: series starting with [1/2] doc/sphinx: Enable keep_warnings
URL   : https://patchwork.freedesktop.org/series/10033/
State : failure

== Summary ==

Applying: doc/sphinx: Enable keep_warnings
Applying: drm/doc: Fix more kerneldoc/sphinx warnings
fatal: sha1 information is lacking or useless (drivers/gpu/drm/drm_crtc.c).
error: could not build fake ancestor
Patch failed at 0002 drm/doc: Fix more kerneldoc/sphinx warnings
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 drm: drm_connector->s/connector_id/index/ for consistency

[Patchwork]

== Series Details ==

Series: drm: drm_connector->s/connector_id/index/ for consistency
URL   : https://patchwork.freedesktop.org/series/10029/
State : failure

== Summary ==

Series 10029v1 drm: drm_connector->s/connector_id/index/ for consistency
http://patchwork.freedesktop.org/api/1.0/series/10029/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> DMESG-WARN (ro-bdw-i7-5557U)
pass   -> DMESG-WARN (ro-ilk1-i5-650)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
skip   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (ro-snb-i7-2620M)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (fi-hsw-i7-4770k)
pass   -> DMESG-WARN (fi-snb-i7-2600)
pass   -> DMESG-WARN (ro-ivb-i7-3770)
pass   -> DMESG-WARN (ro-byt-n2820)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
dmesg-warn -> PASS   (ro-bdw-i5-5250u)
Test gem_sync:
Subgroup basic-store-each:
pass   -> DMESG-FAIL (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-skl3-i5-6260u)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (fi-hsw-i7-4770k)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-byt-n2820)
Subgroup basic-flip-vs-cursor:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-skl3-i5-6260u)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (fi-hsw-i7-4770k)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> FAIL   (ro-bdw-i7-5557U)
pass   -> FAIL   (ro-ilk1-i5-650)
pass   -> FAIL   (ro-hsw-i3-4010u)
pass   -> FAIL   (fi-skl-i5-6260u)
pass   -> FAIL   (ro-bdw-i7-5600u)
pass   -> FAIL   (ro-snb-i7-2620M)
pass   -> FAIL   (ro-bdw-i5-5250u)
pass   -> FAIL   (ro-hsw-i7-4770r)
pass   -> FAIL   (fi-hsw-i7-4770k)
pass   -> FAIL   (fi-snb-i7-2600)
pass   -> FAIL   (ro-ivb-i7-3770)
pass   -> FAIL   (ro-byt-n2820)
pass   -> FAIL   (fi-skl-i7-6700k)
pass   -> FAIL   (ro-skl3-i5-6260u)
Subgroup basic-flip-vs-modeset:
pass   -> FAIL   (ro-bdw-i7-5557U)
pass   -> FAIL   (ro-ilk1-i5-650)
pass   -> FAIL   (ro-hsw-i3-4010u)
pass   -> FAIL   (fi-skl-i5-6260u)
pass   -> FAIL   (ro-bdw-i7-5600u)
pass   -> FAIL   (ro-snb-i7-2620M)
pass   -> FAIL   (ro-bdw-i5-5250u)
pass   -> FAIL   (ro-hsw-i7-4770r)
pass   -> FAIL   (fi-hsw-i7-4770k)
pass   -> FAIL   (fi-snb-i7-2600)
pass   -> FAIL   (ro-ivb-i7-3770)
pass   -> FAIL   (ro-byt-n2820)
pass   -> FAIL   (fi-skl-i7-6700k)
pass   -> FAIL   (ro-skl3-i5-6260u)
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-bdw-i7-5557U)
pass   -> FAIL   (ro-ilk1-i5-650)
pass   -> FAIL   (ro-hsw-i3-4010u)
pass   -> FAIL   (fi-skl-i5-6260u)
pass   -> FAIL   (ro-bdw-i7-5600u)
pass   -> FAIL   (ro-snb-i7-2620M)
pass   -> FAIL   (ro-bdw-i5-5250u)
pass   -> FAIL   (ro-hsw-i7-4770r)
pass   -> FAIL   (fi-hsw-i7-4770k)
pass   -> FAIL   (fi-snb-i7-2600)
pass   -> FAIL   (ro-ivb-i7-3770)
pass   -> FAIL   (ro-byt-n2820)
pass   -> FAIL   (fi-skl-i7-6700k)
pass   -> FAIL   (ro-skl3-i5-6260u)
Subgroup basic-plain-flip:
pass   -> FAIL   

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

[Chris Wilson]

On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> > Signed-off-by: Lionel Landwerlin 
> 
> Do we have the time for those in the BAT budget?

Do we not? It has been demonstrated that people notice when gamma is
broken, can we afford to risk repeating this bug?

(Or in other news, where are all the new QA bugs from failing tests?
Seems like we are missing some bug reports from igt added to show off
bugs.)
-Chris

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

[Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Daniel Vetter]

Unfortunately warnings generated after parsing in sphinx can end up
with entirely bogus files and line numbers as sources. Strangely for
outright errors this is not a problem. Trying to convert warnings to
errors also doesn't fix it.

The only way to get useful output out of sphinx to be able to root
cause the error seems to be enabling keep_warnings, which inserts
a System Message into the actual output. Not pretty at all, but I
don't really want to fix up core rst/sphinx code, and this gets the job
done meanwhile.

Cc: Markus Heiser 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 Documentation/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 6cc41a0555a3..a131139675cc 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -125,7 +125,7 @@ pygments_style = 'sphinx'
 #modindex_common_prefix = []
 
 # If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
+keep_warnings = True
 
 # If true, `todo` and `todoList` produce output, else they produce nothing.
 todo_include_todos = False
-- 
2.8.1

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

[Intel-gfx] [PATCH 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

[Daniel Vetter]

These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...

Cc: Markus Heiser 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c  |  4 ++--
 drivers/gpu/drm/drm_fb_helper.c |  2 +-
 drivers/gpu/drm/drm_irq.c   |  8 +++
 drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
 drivers/gpu/drm/i915/i915_vgpu.c| 42 -
 drivers/gpu/drm/i915/intel_audio.c  |  6 ++---
 drivers/gpu/drm/i915/intel_guc_fwif.h   |  5 ++--
 include/drm/drm_crtc.h  |  8 +++
 include/drm/drm_gem.h   |  4 ++--
 9 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f9f2506b1855..420f4fc8e6a7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1273,7 +1273,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
  * @plane: plane object to init
  * @possible_crtcs: bitmask of possible CRTCs
  * @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
  * @format_count: number of elements in @formats
  * @type: type of plane (overlay, primary, cursor)
  * @name: printf style format string for the plane name, or NULL for default 
name
@@ -1388,7 +1388,7 @@ static void drm_plane_unregister_all(struct drm_device 
*dev)
  * @plane: plane object to init
  * @possible_crtcs: bitmask of possible CRTCs
  * @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
  * @format_count: number of elements in @formats
  * @is_primary: plane type (primary vs overlay)
  *
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ce54e985d91b..95f405e04f5f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2194,7 +2194,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
  * @fb_helper: the drm_fb_helper
  *
  * Scan the connectors attached to the fb_helper and try to put together a
- * setup after *notification of a change in output configuration.
+ * setup after notification of a change in output configuration.
  *
  * Called at runtime, takes the mode config locks to be able to check/change 
the
  * modeset configuration. Must be run from process context (which usually means
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b49a4a6e97cd..a33465d8e133 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -713,10 +713,10 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  * Negative value on error, failure or if not supported in current
  * video mode:
  *
- * -EINVAL   - Invalid CRTC.
- * -EAGAIN   - Temporary unavailable, e.g., called before initial modeset.
- * -ENOTSUPP - Function not supported in current display mode.
- * -EIO  - Failed, e.g., due to failed scanout position query.
+ * -EINVALInvalid CRTC.
+ * -EAGAINTemporary unavailable, e.g., called before initial modeset.
+ * -ENOTSUPP  Function not supported in current display mode.
+ * -EIO   Failed, e.g., due to failed scanout position query.
  *
  * Returns or'ed positive status flags on success:
  *
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0db36d27e90b..4e1de31f072b 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -152,7 +152,7 @@ static const struct drm_plane_funcs 
drm_simple_kms_plane_funcs = {
  * @dev: DRM device
  * @pipe: simple display pipe object to initialize
  * @funcs: callbacks for the display pipe (optional)
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
  * @format_count: number of elements in @formats
  * @connector: connector to attach and register
  *
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 142bac976919..ca2e91259948 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -156,27 +156,27 @@ static int vgt_balloon_space(struct drm_mm *mm,
  * host point of view, the graphic address space is partitioned by multiple
  * vGPUs in different VMs. ::
  *
- *vGPU1 view Host view
- * 0 --> +---+ +---+
- *   ^   |###| |   vGPU3   |
- *   |   |###| +---+
- *   |   |###| |   vGPU2   |
- *   |   +---+ +---+
- *mappable GM| available | ==> |   vGPU1   |
- *

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

[Tvrtko Ursulin]

On 10/07/16 14:41, 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 snaphots 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.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 25c6b9b..43c9900 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1177,6 +1177,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);
i915_setup_sysfs(dev);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
@@ -1215,6 +1216,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(_priv->drm);
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 d3dbb8e..9b436fa 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"

@@ -836,12 +838,33 @@ err:

  static void guc_move_to_next_buf(struct intel_guc *guc)
  {
-   return;
+   /* Make sure our updates are in the sub buffer are visible when
+* Consumer sees a newly produced sub buffer.
+*/
+   smp_wmb();
+
+   /* All data has been written, so now move the offset of sub buffer. */
+   relay_reserve(guc->log.relay_chan, guc->log.obj->base.size);
+
+   /* Switch to the next sub buffer */
+   relay_flush(guc->log.relay_chan);
  }

  static void* guc_get_write_buffer(struct intel_guc *guc)
  {
-   return NULL;
+   /* FIXME: Cover the check under a lock ? */
+   if (!guc->log.relay_chan)
+   return NULL;
+
+   /* Just get the base address of a new sub buffer and copy data into it
+* ourselves. NULL will be returned in no-overwrite mode, if all sub
+* buffers are full. Could have used the relay_write() to indirectly
+* copy the data, but that would have been bit convoluted, as we need to
+* write to only certain locations inside a sub buffer which cannot be
+* done without using relay_reserve() along with relay_write(). So its
+* better to use relay_reserve() alone.
+*/
+   return relay_reserve(guc->log.relay_chan, 0);
  }

  static void guc_read_update_log_buffer(struct drm_device *dev)
@@ -906,6 +929,119 @@ static void guc_read_update_log_buffer(struct drm_device 
*dev)
guc_move_to_next_buf(guc);
  }

+/*
+ * 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 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/8] drm/i915: Move GEM request routines to i915_gem_request.c

[Patchwork]

== Series Details ==

Series: series starting with [1/8] drm/i915: Move GEM request routines to 
i915_gem_request.c
URL   : https://patchwork.freedesktop.org/series/10028/
State : failure

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor:
pass   -> FAIL   (ro-skl3-i5-6260u)
Test prime_vgem:
Subgroup basic-fence-mmap:
fail   -> PASS   (ro-bdw-i7-5557U)
fail   -> PASS   (ro-ilk1-i5-650)
fail   -> PASS   (ro-hsw-i3-4010u)
fail   -> PASS   (ro-bdw-i7-5600u)
fail   -> PASS   (ro-snb-i7-2620M)
fail   -> PASS   (ro-bdw-i5-5250u)
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-ivb-i7-3770)
fail   -> PASS   (ro-byt-n2820)
fail   -> PASS   (ro-skl3-i5-6260u)
Subgroup basic-fence-read:
fail   -> PASS   (ro-bdw-i7-5557U)
fail   -> PASS   (ro-hsw-i3-4010u)
fail   -> PASS   (ro-bdw-i7-5600u)
fail   -> PASS   (ro-bdw-i5-5250u)
fail   -> PASS   (ro-snb-i7-2620M)
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-ivb-i7-3770)

fi-hsw-i7-4770k  total:243  pass:213  dwarn:0   dfail:0   fail:10  skip:20 
fi-kbl-qkkr  total:243  pass:177  dwarn:27  dfail:1   fail:9   skip:29 
fi-skl-i5-6260u  total:243  pass:221  dwarn:0   dfail:0   fail:9   skip:13 
fi-skl-i7-6700k  total:243  pass:208  dwarn:0   dfail:0   fail:9   skip:26 
fi-snb-i7-2600   total:243  pass:193  dwarn:0   dfail:0   fail:10  skip:40 
ro-bdw-i5-5250u  total:244  pass:219  dwarn:4   dfail:0   fail:8   skip:13 
ro-bdw-i7-5557U  total:244  pass:220  dwarn:0   dfail:0   fail:8   skip:16 
ro-bdw-i7-5600u  total:244  pass:204  dwarn:0   dfail:0   fail:8   skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:196  dwarn:0   dfail:0   fail:10  skip:38 
ro-hsw-i3-4010u  total:244  pass:211  dwarn:0   dfail:0   fail:9   skip:24 
ro-hsw-i7-4770r  total:244  pass:211  dwarn:0   dfail:0   fail:9   skip:24 
ro-ilk-i7-620lm  total:244  pass:171  dwarn:0   dfail:0   fail:10  skip:63 
ro-ilk1-i5-650   total:239  pass:171  dwarn:0   dfail:0   fail:10  skip:58 
ro-ivb-i7-3770   total:244  pass:202  dwarn:0   dfail:0   fail:9   skip:33 
ro-skl3-i5-6260u total:244  pass:222  dwarn:1   dfail:0   fail:9   skip:12 
ro-snb-i7-2620M  total:244  pass:192  dwarn:0   dfail:0   fail:10  skip:42 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1528/

d59b92b drm-intel-nightly: 2016y-07m-19d-09h-52m-15s UTC integration manifest
df3db81 drm/i915: Wait on external rendering for GEM objects
bb2bf15 drm/i915: Mark imported dma-buf objects as being coherent
7c1ac1d drm/i915: Disable waitboosting for mmioflips/semaphores
3982e8f drm/i915: Disable waitboosting for fence_wait()
8cb6bb1 drm/i915: Derive GEM requests from dma-fence
62d55fd drm/i915: Mark all current requests as complete before resetting them
c52ae09 drm/i915: Retire oldest completed request before allocating next
4111c02 drm/i915: Move GEM request routines to i915_gem_request.c

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

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Debugfs support for GuC logging control

[Tvrtko Ursulin]

On 10/07/16 14:41, 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.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5e35565..3c9c7f7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2644,6 +2644,35 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
  }

+static int
+i915_guc_log_control_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;


to_i915 should be used.


+   int ret;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
+   if (!i915.enable_guc_submission || !dev_priv->guc.log.obj) {


Wouldn't guc.log.obj be enough?


+   ret = -EINVAL;
+   goto end;
+   }
+
+   intel_runtime_pm_get(dev_priv);
+   ret = i915_guc_log_control(dev, val);
+   intel_runtime_pm_put(dev_priv);
+
+end:
+   mutex_unlock(>struct_mutex);
+   return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
+   NULL, i915_guc_log_control_set,
+   "0x%08llx\n");


Does the readback still work with no get method?


+
  static int i915_edp_psr_status(struct seq_file *m, void *data)
  {
struct drm_info_node *node = m->private;
@@ -5464,7 +5493,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 8cc31c6..2e3b723 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -193,6 +193,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
   *
@@ -1455,3 +1465,50 @@ void i915_guc_register(struct drm_device *dev)
guc_log_late_setup(dev);
mutex_unlock(>struct_mutex);
  }
+
+int i915_guc_log_control(struct drm_device *dev, uint64_t control_val)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;


to_i915

Actually, function should take dev_priv if not even guc depending on the 
established convention in the file.



+   union guc_log_control log_param;
+   int ret;
+
+   log_param.logging_enabled = control_val & 0x1;
+   log_param.verbosity = (control_val >> 4) & 0xF;
+
+   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 -EINVAL;


Hm, disabling while already disabled - why should that return an error? 
Might be annoying in scripts.



+
+   ret = host2guc_logging_control(_priv->guc, log_param.value);
+   if (ret < 0) {
+   DRM_DEBUG_DRIVER("host2guc action failed\n");


Add ret to the log since it is easy?


+   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(dev);
+   if (!ret)
+   

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

[Chris Wilson]

On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote:
> 
> On 10/07/16 14:41, akash.g...@intel.com wrote:
> >From: Sagar Arun Kamble 
> >
> >If GuC logs are being captured, there should be a force log buffer flush
> >action sent to GuC before proceeding with GPU reset and re-initializing
> >GUC. Those logs would be useful to understand why the GPU reset was
> >initiated.
> >
> >v2: Rebase.
> >
> >Signed-off-by: Sagar Arun Kamble 
> >Signed-off-by: Akash Goel 
> >---
> >  drivers/gpu/drm/i915/i915_guc_submission.c | 32 
> > ++
> >  drivers/gpu/drm/i915/i915_irq.c|  2 ++
> >  drivers/gpu/drm/i915/intel_guc.h   |  1 +
> >  3 files changed, 35 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index 9b436fa..8cc31c6 100644
> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >@@ -183,6 +183,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
> >   *
> >@@ -1404,6 +1414,28 @@ void i915_guc_capture_logs(struct drm_device *dev)
> > intel_runtime_pm_put(dev_priv);
> >  }
> >
> >+void i915_guc_capture_logs_on_reset(struct drm_device *dev)
> >+{
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+
> >+mutex_lock(>struct_mutex);
> 
> Not sure what are the repercussion of taking the mutex on the
> i915_reset_and_wakeup and path (error capture, hangcheck, dont' know
> this area well). Check with Chris and Mika I suppose (cc-ed)?

Flat out invalid to take struct_mutex on the error capture path, or any
lock at all really (just in case of driver bugs). Consider it to be an
atomic context that may preempt the driver at any point.
-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/17] drm/i915: Forcefully flush GuC log buffer on reset

[Tvrtko Ursulin]

On 10/07/16 14:41, akash.g...@intel.com wrote:

From: Sagar Arun Kamble 

If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding with GPU reset and re-initializing
GUC. Those logs would be useful to understand why the GPU reset was
initiated.

v2: Rebase.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 9b436fa..8cc31c6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -183,6 +183,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
   *
@@ -1404,6 +1414,28 @@ void i915_guc_capture_logs(struct drm_device *dev)
intel_runtime_pm_put(dev_priv);
  }

+void i915_guc_capture_logs_on_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   mutex_lock(>struct_mutex);


Not sure what are the repercussion of taking the mutex on the 
i915_reset_and_wakeup and path (error capture, hangcheck, dont' know 
this area well). Check with Chris and Mika I suppose (cc-ed)?



+
+   if (!i915.enable_guc_submission || (i915.guc_log_level < 0))


It would be cool if guc_log_level could be guaranteed to be disabled 
when guc submission is not on. I think it would be more maintainable.



+   goto end;
+
+   /* First disable the interrupts, will be renabled after reset */
+   gen9_disable_guc_interrupts(dev_priv);
+
+   /* Ask GuC to update the log buffer state */
+   host2guc_force_logbuffer_flush(_priv->guc);
+
+   /* GuC would have updated the log buffer by now, so capture it */
+   i915_guc_capture_logs(dev);
+
+end:
+   mutex_unlock(>struct_mutex);
+}
+
  void i915_guc_unregister(struct drm_device *dev)
  {
if (!i915.enable_guc_submission)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f90d3c6..bdd7a67 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2640,6 +2640,8 @@ static void i915_reset_and_wakeup(struct drm_i915_private 
*dev_priv)
 */
intel_runtime_pm_get(dev_priv);

+   i915_guc_capture_logs_on_reset(_priv->drm);
+
intel_prepare_reset(dev_priv);

/*
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index a784cf8..ed773b5 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -175,6 +175,7 @@ int i915_guc_submit(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_device *dev);
+void i915_guc_capture_logs_on_reset(struct drm_device *dev);
  void i915_guc_register(struct drm_device *dev);
  void i915_guc_unregister(struct drm_device *dev);




Regards,

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

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

[Tvrtko Ursulin]

On 10/07/16 14:41, 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.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.c|  13 +++
  drivers/gpu/drm/i915/i915_guc_submission.c | 148 +
  drivers/gpu/drm/i915/i915_irq.c|   5 +-
  drivers/gpu/drm/i915/intel_guc.h   |   3 +
  4 files changed, 167 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b9a8117..25c6b9b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -791,8 +791,20 @@ static int i915_workqueues_init(struct drm_i915_private 
*dev_priv)
if (dev_priv->hotplug.dp_wq == NULL)
goto out_free_wq;

+   if (HAS_GUC_SCHED(dev_priv)) {
+   /* Need a dedicated wq to process log buffer flush interrupts
+* from GuC without much delay so as to avoid any loss of logs.
+*/
+   dev_priv->guc.log.wq =
+   alloc_ordered_workqueue("i915-guc_log", 0);
+   if (dev_priv->guc.log.wq == NULL)
+   goto out_free_hotplug_dp_wq;
+   }
+
return 0;

+out_free_hotplug_dp_wq:
+   destroy_workqueue(dev_priv->hotplug.dp_wq);
  out_free_wq:
destroy_workqueue(dev_priv->wq);
  out_err:
@@ -803,6 +815,7 @@ out_err:

  static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
  {
+   destroy_workqueue(dev_priv->guc.log.wq);


I am ignoring the wq parts of the patch since the next series may look 
different in this respect.


However you may need to have wq destruction under the same HAS_GUC_SCHED 
condition as when you create it.



destroy_workqueue(dev_priv->hotplug.dp_wq);
destroy_workqueue(dev_priv->wq);
  }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 0bac172..d3dbb8e 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
   *
@@ -825,6 +834,123 @@ err:
return NULL;
  }

+static void guc_move_to_next_buf(struct intel_guc *guc)
+{
+   return;
+}
+
+static void* guc_get_write_buffer(struct intel_guc *guc)
+{
+   return NULL;
+}
+
+static void guc_read_update_log_buffer(struct drm_device *dev)


dev_priv should be passed in for driver internal functions.


+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct guc_log_buffer_state *log_buffer_state, *log_buffer_copy_state;
+   struct guc_log_buffer_state log_buffer_state_local;
+   void *src_data_ptr, *dst_data_ptr;
+   u32 i, buffer_size;
+
+   if (!guc->log.obj || !guc->log.buf_addr)
+   return;
+
+   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_copy_state = guc_get_write_buffer(guc);


This will return NULL so the loop below doesn't do anything much. I 
assume at this point in the patch series things are not wired up yet?



+
+   /* Actual logs are present from the 2nd page */
+   src_data_ptr += PAGE_SIZE;
+   dst_data_ptr += PAGE_SIZE;
+
+   for (i = 0; i < GUC_MAX_LOG_BUFFER; i++) {
+   log_buffer_state_local = *log_buffer_state;
+   buffer_size = log_buffer_state_local.size;
+
+   if (log_buffer_copy_state) {
+   /* First copy the state structure */
+   

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

[Daniel Vetter]

connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.

While at it also improve/align the kerneldoc comment.

v2: Mention where those ids are from ...

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Acked-by: Chris Wilson 
Acked-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 11 +--
 include/drm/drm_crtc.h | 13 ++---
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c456628740dd..f9f2506b1855 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -934,11 +934,10 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
 
-   connector->connector_id = ida_simple_get(>connector_ida, 0, 0, 
GFP_KERNEL);
-   if (connector->connector_id < 0) {
-   ret = connector->connector_id;
+   ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
+   if (ret < 0)
goto out_put;
-   }
+   connector->index = ret;
 
connector->connector_type = connector_type;
connector->connector_type_id =
@@ -986,7 +985,7 @@ out_put_type_id:
ida_remove(connector_ida, connector->connector_type_id);
 out_put_id:
if (ret)
-   ida_remove(>connector_ida, connector->connector_id);
+   ida_remove(>connector_ida, connector->index);
 out_put:
if (ret)
drm_mode_object_unregister(dev, >base);
@@ -1030,7 +1029,7 @@ void drm_connector_cleanup(struct drm_connector 
*connector)
   connector->connector_type_id);
 
ida_remove(>mode_config.connector_ida,
-  connector->connector_id);
+  connector->index);
 
kfree(connector->display_info.bus_formats);
drm_mode_object_unregister(dev, >base);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f8ba5aab5d28..4aa4c4341d01 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1246,7 +1246,6 @@ struct drm_encoder {
  * @head: list management
  * @base: base KMS object
  * @name: human readable name, can be overwritten by the driver
- * @connector_id: compacted connector id useful indexing arrays
  * @connector_type: one of the %DRM_MODE_CONNECTOR_ types from drm_mode.h
  * @connector_type_id: index into connector type enum
  * @interlace_allowed: can this connector handle interlaced modes?
@@ -1303,7 +1302,15 @@ struct drm_connector {
struct drm_mode_object base;
 
char *name;
-   int connector_id;
+
+   /**
+* @index: Compacted connector index, which matches the position inside
+* the mode_config.list for drivers not support hot-add/removing. Can be
+* used as an array index. It is invariant over the lifetime of the
+* connector.
+*/
+   unsigned index;
+
int connector_type;
int connector_type_id;
bool interlace_allowed;
@@ -2764,7 +2771,7 @@ void drm_connector_unregister(struct drm_connector 
*connector);
 extern void drm_connector_cleanup(struct drm_connector *connector);
 static inline unsigned drm_connector_index(struct drm_connector *connector)
 {
-   return connector->connector_id;
+   return connector->index;
 }
 
 extern __printf(5, 6)
-- 
2.8.1

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

[Intel-gfx] [PATCH 7/8] drm/i915: Mark imported dma-buf objects as being coherent

[Chris Wilson]

A foreign dma-buf does not share our cache domain tracking, and we rely
on the producer ensuring cache coherency. Marking them as being in the
CPU domain is incorrect.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 80bbe43a2e92..c7d734248ed0 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -299,6 +299,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
drm_gem_private_object_init(dev, >base, dma_buf->size);
i915_gem_object_init(obj, _gem_object_dmabuf_ops);
obj->base.import_attach = attach;
+   obj->base.read_domains = I915_GEM_DOMAIN_GTT;
+   obj->base.write_domain = 0;
 
return >base;
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

[Chris Wilson]

When transitioning to the GTT or CPU domain we wait on all rendering
from i915 to complete (with the optimisation of allowing concurrent read
access by both the GPU and client). We don't yet ensure all rendering
from third parties (tracked by implicit fences on the dma-buf) is
complete. Since implicitly tracked rendering by third parties will
ignore our cache-domain tracking, we have to always wait upon rendering
from third-parties when transitioning to direct access to the backing
store. We still rely on clients notifying us of cache domain changes
(i.e. they need to move to the GTT read or write domain after doing a CPU
access before letting the third party render again).

v2:
This introduces a potential WARN_ON into i915_gem_object_free() as the
current i915_vma_unbind() calls i915_gem_object_wait_rendering(). To
hit this path we first need to render with the GPU, have a dma-buf
attached with an unsignaled fence and then interrupt the wait. It does
get fixed later in the series (when i915_vma_unbind() only waits on the
active VMA and not all, including third-party, rendering.

To offset that risk, use the __i915_vma_unbind_no_wait hack.

Testcase: igt/prime_vgem/basic-fence-read
Testcase: igt/prime_vgem/basic-fence-mmap
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 44 ++---
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 079e09cee16a..37868cc594cb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -29,10 +29,12 @@
 #include 
 #include 
 #include "i915_drv.h"
+#include "i915_gem_dmabuf.h"
 #include "i915_vgpu.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
 #include "intel_mocs.h"
+#include 
 #include 
 #include 
 #include 
@@ -511,6 +513,10 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
if (WARN_ON(!i915_gem_object_has_struct_page(obj)))
return -EINVAL;
 
+   ret = i915_gem_object_wait_rendering(obj, true);
+   if (ret)
+   return ret;
+
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
/* If we're not in the cpu read domain, set ourself into the gtt
 * read domain and manually flush cachelines (if required). This
@@ -518,9 +524,6 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
 * anyway again before the next pread happens. */
*needs_clflush = !cpu_cache_is_coherent(obj->base.dev,
obj->cache_level);
-   ret = i915_gem_object_wait_rendering(obj, true);
-   if (ret)
-   return ret;
}
 
ret = i915_gem_object_get_pages(obj);
@@ -1132,15 +1135,16 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
 
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
 
+   ret = i915_gem_object_wait_rendering(obj, false);
+   if (ret)
+   return ret;
+
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
/* If we're not in the cpu write domain, set ourself into the 
gtt
 * write domain and manually flush cachelines (if required). 
This
 * optimizes for the case when the gpu will use the data
 * right away and we therefore have to clflush anyway. */
needs_clflush_after = cpu_write_needs_clflush(obj);
-   ret = i915_gem_object_wait_rendering(obj, false);
-   if (ret)
-   return ret;
}
/* Same trick applies to invalidate partially written cachelines read
 * before writing. */
@@ -1335,11 +1339,9 @@ int
 i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
   bool readonly)
 {
+   struct reservation_object *resv;
int ret, i;
 
-   if (!obj->active)
-   return 0;
-
if (readonly) {
if (obj->last_write_req != NULL) {
ret = i915_wait_request(obj->last_write_req);
@@ -1366,6 +1368,16 @@ i915_gem_object_wait_rendering(struct 
drm_i915_gem_object *obj,
GEM_BUG_ON(obj->active);
}
 
+   resv = i915_gem_object_get_dmabuf_resv(obj);
+   if (resv) {
+   long err;
+
+   err = reservation_object_wait_timeout_rcu(resv, !readonly, true,
+ MAX_SCHEDULE_TIMEOUT);
+   if (err < 0)
+   return err;
+   }
+
return 0;
 }
 
@@ -3402,13 +3414,13 @@ i915_gem_object_set_to_gtt_domain(struct 
drm_i915_gem_object *obj, bool write)
struct i915_vma *vma;
int ret;
 
-   if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
-   return 0;
-
ret = 

[Intel-gfx] [PATCH 3/8] drm/i915: Mark all current requests as complete before resetting them

[Chris Wilson]

Following a GPU reset upon hang, we retire all the requests and then
mark them all as complete. If we mark them as complete first, we both
keep the normal retirement order (completed first then retired) and
provide a small optimisation for concurrent lookups.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6df14058b3fe..61729d6b4ecc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2486,6 +2486,12 @@ static void i915_gem_reset_engine_cleanup(struct 
intel_engine_cs *engine)
i915_gem_object_retire__read(obj, engine->id);
}
 
+   /* Mark all pending requests as complete so that any concurrent
+* (lockless) lookup doesn't try and wait upon the request as we
+* reset it.
+*/
+   intel_ring_init_seqno(engine, engine->last_submitted_seqno);
+
/*
 * Clear the execlists queue up before freeing the requests, as those
 * are the ones that keep the context and ringbuffer backing objects
@@ -2528,8 +2534,6 @@ static void i915_gem_reset_engine_cleanup(struct 
intel_engine_cs *engine)
intel_ring_update_space(buffer);
}
 
-   intel_ring_init_seqno(engine, engine->last_submitted_seqno);
-
engine->i915->gt.active_engines &= ~intel_engine_flag(engine);
 }
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 2/8] drm/i915: Retire oldest completed request before allocating next

[Chris Wilson]

In order to keep the memory allocated for requests reasonably tight, try
to reuse the oldest request (so long as it is completed and has no
external references) for the next allocation.

v2: Throw in a comment to hopefully make sure no one mistakes the
optimistic retirement of the oldest request for simply stealing it.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9e9aa6b725f7..5cbb11ece60a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -226,6 +226,14 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
if (ret)
return ret;
 
+   /* Move the oldest request to the slab-cache (if not in use!) */
+   if (!list_empty(>request_list)) {
+   req = list_first_entry(>request_list,
+  typeof(*req), list);
+   if (i915_gem_request_completed(req))
+   i915_gem_request_retire(req);
+   }
+
req = kmem_cache_zalloc(dev_priv->requests, GFP_KERNEL);
if (!req)
return -ENOMEM;
-- 
2.8.1

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

[Intel-gfx] [PATCH 5/8] drm/i915: Disable waitboosting for fence_wait()

[Chris Wilson]

We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.

v2: Hide the IS_ERR_OR_NULL testing for special clients

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 7 ---
 drivers/gpu/drm/i915/i915_gem_request.h | 3 +++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 6528536878f2..f483e605a715 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -70,7 +70,7 @@ static signed long i915_fence_wait(struct fence *fence,
 
ret = __i915_wait_request(to_request(fence),
  interruptible, timeout,
- NULL);
+ NO_WAITBOOST);
if (ret == -ETIME)
return 0;
 
@@ -642,7 +642,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 * forcing the clocks too high for the whole system, we only allow
 * each client to waitboost once in a busy period.
 */
-   if (INTEL_GEN(req->i915) >= 6)
+   if (IS_RPS_CLIENT(rps) && INTEL_GEN(req->i915) >= 6)
gen6_rps_boost(req->i915, rps, req->emitted_jiffies);
 
/* Optimistic spin for the next ~jiffie before touching IRQs */
@@ -713,7 +713,8 @@ complete:
*timeout = 0;
}
 
-   if (rps && req->fence.seqno == req->engine->last_submitted_seqno) {
+   if (IS_RPS_USER(rps) &&
+   req->fence.seqno == req->engine->last_submitted_seqno) {
/* The GPU is now idle and this client has stalled.
 * Since no other client has submitted a request in the
 * meantime, assume that this client is the only one
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 6f2c820785f3..0a01d01cac51 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -206,6 +206,9 @@ void __i915_add_request(struct drm_i915_gem_request *req,
__i915_add_request(req, NULL, false)
 
 struct intel_rps_client;
+#define NO_WAITBOOST ERR_PTR(-1)
+#define IS_RPS_CLIENT(p) (!IS_ERR(p))
+#define IS_RPS_USER(p) (!IS_ERR_OR_NULL(p))
 
 int __i915_wait_request(struct drm_i915_gem_request *req,
bool interruptible,
-- 
2.8.1

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

[Intel-gfx] [PATCH 6/8] drm/i915: Disable waitboosting for mmioflips/semaphores

[Chris Wilson]

Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
flip RPS boosts") we have limited the waitboosting for semaphores and
flips. Ideally we do not want to boost in either of these instances as no
userspace consumer is waiting upon the results (though a userspace producer
may be stalled trying to submit an execbuf - but in this case the
producer is being throttled due to the engine being saturated with
work). With the introduction of NO_WAITBOOST in the previous patch, we
can finally disable these needless boosts.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 8 +---
 drivers/gpu/drm/i915/i915_drv.h  | 2 --
 drivers/gpu/drm/i915/i915_gem.c  | 2 +-
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 2 --
 5 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 55fd3d9cc448..618f8cf210fc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2465,13 +2465,7 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
   list_empty(_priv->rps.link) ? "" : ", active");
rcu_read_unlock();
}
-   seq_printf(m, "Semaphore boosts: %d%s\n",
-  dev_priv->rps.semaphores.boosts,
-  list_empty(_priv->rps.semaphores.link) ? "" : ", 
active");
-   seq_printf(m, "MMIO flip boosts: %d%s\n",
-  dev_priv->rps.mmioflips.boosts,
-  list_empty(_priv->rps.mmioflips.link) ? "" : ", active");
-   seq_printf(m, "Kernel boosts: %d\n", dev_priv->rps.boosts);
+   seq_printf(m, "Kernel (anonymous) boosts: %d\n", dev_priv->rps.boosts);
spin_unlock(_priv->rps.client_lock);
mutex_unlock(>filelist_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c97a75597099..e163a9487750 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1195,8 +1195,6 @@ struct intel_gen6_power_mgmt {
struct delayed_work autoenable_work;
unsigned boosts;
 
-   struct intel_rps_client semaphores, mmioflips;
-
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 61729d6b4ecc..079e09cee16a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2849,7 +2849,7 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
ret = __i915_wait_request(from_req,
  i915->mm.interruptible,
  NULL,
- >rps.semaphores);
+ NO_WAITBOOST);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb7d8fc5b0e6..51fbca756cdb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11473,7 +11473,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
if (work->flip_queued_req)
WARN_ON(__i915_wait_request(work->flip_queued_req,
false, NULL,
-   _priv->rps.mmioflips));
+   NO_WAITBOOST));
 
/* For framebuffer backed by dmabuf, wait for fence */
resv = i915_gem_object_get_dmabuf_resv(obj);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa6b341c2792..a1bf5f8fbb1c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7810,8 +7810,6 @@ void intel_pm_setup(struct drm_device *dev)
INIT_DELAYED_WORK(_priv->rps.autoenable_work,
  __intel_autoenable_gt_powersave);
INIT_LIST_HEAD(_priv->rps.clients);
-   INIT_LIST_HEAD(_priv->rps.semaphores.link);
-   INIT_LIST_HEAD(_priv->rps.mmioflips.link);
 
dev_priv->pm.suspended = false;
atomic_set(_priv->pm.wakeref_count, 0);
-- 
2.8.1

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

[Intel-gfx] [PATCH 4/8] drm/i915: Derive GEM requests from dma-fence

[Chris Wilson]

dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the future, to pass those fences
back to userspace or between drivers.

v2: The fence_context needs to be globally unique, not just unique to
this device.

Signed-off-by: Chris Wilson 
Cc: Jesse Barnes 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
 drivers/gpu/drm/i915/i915_gem_request.c| 113 ++---
 drivers/gpu/drm/i915/i915_gem_request.h|  43 +++
 drivers/gpu/drm/i915/i915_gpu_error.c  |   2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/i915_trace.h  |  10 +--
 drivers/gpu/drm/i915/intel_breadcrumbs.c   |   7 +-
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +
 drivers/gpu/drm/i915/intel_lrc.c   |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|  10 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h|   1 +
 11 files changed, 150 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 90aef4540193..55fd3d9cc448 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -768,7 +768,7 @@ static int i915_gem_request_info(struct seq_file *m, void 
*data)
if (req->pid)
task = pid_task(req->pid, PIDTYPE_PID);
seq_printf(m, "%x @ %d: %s [%d]\n",
-  req->seqno,
+  req->fence.seqno,
   (int) (jiffies - req->emitted_jiffies),
   task ? task->comm : "",
   task ? task->pid : -1);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5cbb11ece60a..6528536878f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -24,6 +24,95 @@
 
 #include "i915_drv.h"
 
+static const char *i915_fence_get_driver_name(struct fence *fence)
+{
+   return "i915";
+}
+
+static const char *i915_fence_get_timeline_name(struct fence *fence)
+{
+   /* Timelines are bound by eviction to a VM. However, since
+* we only have a global seqno at the moment, we only have
+* a single timeline. Note that each timeline will have
+* multiple execution contexts (fence contexts) as we allow
+* engines within a single timeline to execute in parallel.
+*/
+   return "global";
+}
+
+static bool i915_fence_signaled(struct fence *fence)
+{
+   return i915_gem_request_completed(to_request(fence));
+}
+
+static bool i915_fence_enable_signaling(struct fence *fence)
+{
+   if (i915_fence_signaled(fence))
+   return false;
+
+   intel_engine_enable_signaling(to_request(fence));
+   return true;
+}
+
+static signed long i915_fence_wait(struct fence *fence,
+  bool interruptible,
+  signed long timeout_jiffies)
+{
+   s64 timeout_ns, *timeout;
+   int ret;
+
+   if (timeout_jiffies != MAX_SCHEDULE_TIMEOUT) {
+   timeout_ns = jiffies_to_nsecs(timeout_jiffies);
+   timeout = _ns;
+   } else {
+   timeout = NULL;
+   }
+
+   ret = __i915_wait_request(to_request(fence),
+ interruptible, timeout,
+ NULL);
+   if (ret == -ETIME)
+   return 0;
+
+   if (ret < 0)
+   return ret;
+
+   if (timeout_jiffies != MAX_SCHEDULE_TIMEOUT)
+   timeout_jiffies = nsecs_to_jiffies(timeout_ns);
+
+   return timeout_jiffies;
+}
+
+static void i915_fence_value_str(struct fence *fence, char *str, int size)
+{
+   snprintf(str, size, "%u", fence->seqno);
+}
+
+static void i915_fence_timeline_value_str(struct fence *fence, char *str,
+ int size)
+{
+   snprintf(str, size, "%u",
+intel_engine_get_seqno(to_request(fence)->engine));
+}
+
+static void i915_fence_release(struct fence *fence)
+{
+   struct drm_i915_gem_request *req = to_request(fence);
+
+   kmem_cache_free(req->i915->requests, req);
+}
+
+const struct fence_ops i915_fence_ops = {
+   .get_driver_name = i915_fence_get_driver_name,
+   .get_timeline_name = i915_fence_get_timeline_name,
+   .enable_signaling = i915_fence_enable_signaling,
+   .signaled = i915_fence_signaled,
+   .wait = i915_fence_wait,
+   .release = i915_fence_release,
+   .fence_value_str = i915_fence_value_str,
+   

[Intel-gfx] [PATCH 1/8] drm/i915: Move GEM request routines to i915_gem_request.c

[Chris Wilson]

Migrate the request operations out of the main body of i915_gem.c and
into their own C file for easier expansion.

v2: Move __i915_add_request() across as well

Signed-off-by: Chris Wilson 
Acked-by: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.h | 209 +-
 drivers/gpu/drm/i915/i915_gem.c | 655 +--
 drivers/gpu/drm/i915/i915_gem_request.c | 658 
 drivers/gpu/drm/i915/i915_gem_request.h | 238 
 5 files changed, 905 insertions(+), 856 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_request.c
 create mode 100644 drivers/gpu/drm/i915/i915_gem_request.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 75318ebb8d25..6092f0ea24df 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -33,6 +33,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_gtt.o \
  i915_gem.o \
  i915_gem_render_state.o \
+ i915_gem_request.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 27d9b2c374b3..c97a75597099 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -61,6 +61,7 @@
 #include "i915_gem.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_render_state.h"
+#include "i915_gem_request.h"
 
 #include "intel_gvt.h"
 
@@ -2365,171 +2366,6 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 (((__iter).curr += PAGE_SIZE) < (__iter).max) ||   \
 ((__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0))
 
-/**
- * Request queue structure.
- *
- * The request queue allows us to note sequence numbers that have been emitted
- * and may be associated with active buffers to be retired.
- *
- * By keeping this list, we can avoid having to do questionable sequence
- * number comparisons on buffer last_read|write_seqno. It also allows an
- * emission time to be associated with the request for tracking how far ahead
- * of the GPU the submission is.
- *
- * The requests are reference counted, so upon creation they should have an
- * initial reference taken using kref_init
- */
-struct drm_i915_gem_request {
-   struct kref ref;
-
-   /** On Which ring this request was generated */
-   struct drm_i915_private *i915;
-   struct intel_engine_cs *engine;
-   struct intel_signal_node signaling;
-
-/** GEM sequence number associated with the previous request,
- * when the HWS breadcrumb is equal to this the GPU is processing
- * this request.
- */
-   u32 previous_seqno;
-
-/** GEM sequence number associated with this request,
- * when the HWS breadcrumb is equal or greater than this the GPU
- * has finished processing this request.
- */
-   u32 seqno;
-
-   /** Position in the ringbuffer of the start of the request */
-   u32 head;
-
-   /**
-* Position in the ringbuffer of the start of the postfix.
-* This is required to calculate the maximum available ringbuffer
-* space without overwriting the postfix.
-*/
-u32 postfix;
-
-   /** Position in the ringbuffer of the end of the whole request */
-   u32 tail;
-
-   /** Preallocate space in the ringbuffer for the emitting the request */
-   u32 reserved_space;
-
-   /**
-* Context and ring buffer related to this request
-* Contexts are refcounted, so when this request is associated with a
-* context, we must increment the context's refcount, to guarantee that
-* it persists while any request is linked to it. Requests themselves
-* are also refcounted, so the request will only be freed when the last
-* reference to it is dismissed, and the code in
-* i915_gem_request_free() will then decrement the refcount on the
-* context.
-*/
-   struct i915_gem_context *ctx;
-   struct intel_ringbuffer *ringbuf;
-
-   /**
-* Context related to the previous request.
-* As the contexts are accessed by the hardware until the switch is
-* completed to a new context, the hardware may still be writing
-* to the context object after the breadcrumb is visible. We must
-* not unpin/unbind/prune that object whilst still active and so
-* we keep the previous context pinned until the following (this)
-* request is retired.
-*/
-   struct i915_gem_context *previous_context;
-
-   /** Batch buffer related to this request if any (used for
-   error state dump only) */
-   struct drm_i915_gem_object *batch_obj;
-
-   /** Time at 

Re: [Intel-gfx] [PATCH] drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory

[Tvrtko Ursulin]

On 18/07/16 16:06, Tvrtko Ursulin wrote:

On 18/07/16 14:46, Tvrtko Ursulin wrote:

[snip]


This version generates the smallest code:

static void __memcpy_ntdqa(struct qw2 *dst, const struct qw2 *src, unsigned 
long len)
{
unsigned long l4;

kernel_fpu_begin();

l4 = len / 4;
while (l4) {
asm("movntdqa   (%0), %%xmm0" :: "r" (src), "m" (src[0]));
asm("movntdqa 16(%0), %%xmm1" :: "r" (src), "m" (src[1]));
asm("movntdqa 32(%0), %%xmm2" :: "r" (src), "m" (src[2]));
asm("movntdqa 48(%0), %%xmm3" :: "r" (src), "m" (src[3]));
asm("movaps %%xmm0,   (%1)" : "=m" (dst[0]) : "r" (dst));
asm("movaps %%xmm1, 16(%1)" : "=m" (dst[1]) : "r" (dst));
asm("movaps %%xmm2, 32(%1)" : "=m" (dst[2]) : "r" (dst));
asm("movaps %%xmm3, 48(%1)" : "=m" (dst[3]) : "r" (dst));
src += 4;
dst += 4;
l4--;
}

len %= 4;
while (len) {
asm("movntdqa (%0), %%xmm0" :: "r" (src), "m" (src[0]));
asm("movaps %%xmm0, (%1)" : "=m" (dst[0]) : "r" (dst));
src++;
dst++;
len--;
}

kernel_fpu_end();
}

Although I still haven't figured out a way to convince it to use
the same registers for src and dest between the two loops.


I remembered one famous interview question, along the lines of, "what
is the code below doing". Translated to this example:

static void __memcpy_ntdqa(struct qw2 *dst, const struct qw2 *src, unsigned 
long len)
{
unsigned long n;

kernel_fpu_begin();



Bugfix here:

+   len /= 16;


n = (len + 3) / 4;
switch (len % 4) {
case 0: do { asm("movntdqa %1, %%xmm0\n"
  "movaps %%xmm0, %0\n" : "=m" (*dst): "m" (*src));
 src++; dst++;
case 3:  asm("movntdqa %1, %%xmm1\n"
  "movaps %%xmm1, %0\n" : "=m" (*dst): "m" (*src));
 src++; dst++;
case 2:  asm("movntdqa %1, %%xmm2\n"
  "movaps %%xmm2, %0\n" : "=m" (*dst): "m" (*src));
 src++; dst++;
case 1:  asm("movntdqa %1, %%xmm3\n"
  "movaps %%xmm3, %0\n" : "=m" (*dst): "m" (*src));
 src++; dst++;
} while (--n > 0);
}

kernel_fpu_end();
}

:D

No idea if loads/stores can run async in this case.


It seems to be equally fast as the unrolled loop. And it generates the 
smallest code. :)


I would also suggest a "likely (len)" in the original patch since zero 
length copies are not expected and that also manages to shrink the code 
a bit.


Regards,

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

[Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

[Peter Antoine]

On some platforms the MOCS values are not always saved and restored
on RC6 enter/exit. The rational is that the context with restore
these values. On these platforms the test will fail as it tests the
values by directly reading the MOCS registers.

So this change removes the direct testing of the values and adds a
test that specifically waits for the GPU to enter and then leave
RC6 and then tests the MOCS values.

Signed-off-by: Peter Antoine 
---
 tests/gem_mocs_settings.c | 136 ++
 1 file changed, 64 insertions(+), 72 deletions(-)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index bc553e9..e85dcda 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -132,65 +132,6 @@ static uint32_t get_engine_base(uint32_t engine)
}
 }
 
-static uint32_t get_mocs_register_value(int fd, uint64_t offset, uint32_t 
index)
-{
-   igt_assert(index < MAX_NUMBER_MOCS_REGISTERS);
-   return intel_register_read(offset + index * 4);
-}
-
-static void test_mocs_control_values(int fd, uint32_t engine)
-{
-   const uint32_t engine_base = get_engine_base(engine);
-   struct mocs_table table;
-   int local_fd;
-   int i;
-
-   local_fd = fd;
-   if (local_fd == -1)
-   local_fd = drm_open_driver_master(DRIVER_INTEL);
-
-   igt_assert(get_mocs_settings(local_fd, , false));
-
-   for (i = 0; i < table.size; i++)
-   igt_assert_eq_u32(get_mocs_register_value(local_fd,
- engine_base, i),
- table.table[i].control_value);
-
-   if (local_fd != fd)
-   close(local_fd);
-}
-
-static void test_mocs_l3cc_values(int fd)
-{
-   uint32_t reg_values[MAX_NUMBER_MOCS_REGISTERS/2];
-   struct mocs_table table;
-   int local_fd;
-   int i;
-
-   local_fd = fd;
-   if (local_fd == -1)
-   local_fd = drm_open_driver_master(DRIVER_INTEL);
-
-   for (i = 0; i < MAX_NUMBER_MOCS_REGISTERS / 2; i++)
-   reg_values[i] = intel_register_read(GEN9_LNCFCMOCS0 + (i * 4));
-
-   igt_assert(get_mocs_settings(local_fd, , false));
-
-   for (i = 0; i < table.size / 2; i++) {
-   igt_assert_eq_u32((reg_values[i] & 0x),
- table.table[i * 2].l3cc_value);
-   igt_assert_eq_u32((reg_values[i] >> 16),
- table.table[i * 2 + 1].l3cc_value);
-   }
-
-   if (table.size & 1)
-   igt_assert_eq_u32((reg_values[i] & 0x),
- table.table[i * 2].l3cc_value);
-
-   if (local_fd != fd)
-   close(local_fd);
-}
-
 #define MI_STORE_REGISTER_MEM_64_BIT_ADDR  ((0x24 << 23) | 2)
 
 static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
@@ -428,11 +369,8 @@ static void test_mocs_values(int fd)
continue;
 
igt_debug("Testing %s\n", e->name);
-   test_mocs_control_values(fd, engine);
test_context_mocs_values(fd, engine);
}
-
-   test_mocs_l3cc_values(fd);
 }
 
 static void default_context_tests(unsigned mode)
@@ -566,12 +504,73 @@ static void context_dirty_test(unsigned mode)
 
 static void run_tests(unsigned mode)
 {
+   struct pci_device *pci_dev;
+
+   pci_dev = intel_get_pci_device();
+   igt_require(pci_dev);
+   intel_register_access_init(pci_dev, 0);
+
default_context_tests(mode);
default_dirty_tests(mode);
context_save_restore_test(mode);
context_dirty_test(mode);
+
+   intel_register_access_fini();
+}
+
+static unsigned int readit(const char *path)
+{
+   unsigned int ret = 0;
+   int scanned = 0;
+   FILE *file;
+
+   file = fopen(path, "r");
+   igt_assert(file);
+   scanned = fscanf(file, "%u", );
+   igt_assert_eq(scanned, 1);
+
+   fclose(file);
+
+   return ret;
+}
+
+static int read_rc6_residency(void)
+{
+   unsigned int residency;
+   const int device = drm_get_card();
+   static const char path_format[] =
+   "/sys/class/drm/card%d/power/rc6_residency_ms";
+   char path[sizeof(path_format)];
+   int  ret;
+
+   ret = snprintf(path, sizeof(path)-1, path_format, device);
+
+   igt_assert_neq(ret, -1);
+   residency = readit(path);
+
+   return residency;
+}
+
+static void context_rc6_test(void)
+{
+   int fd = drm_open_driver(DRIVER_INTEL);
+   int res_ms;
+   uint32_t ctx_id = gem_context_create(fd);
+
+   igt_debug("RC6 Context Test\n");
+   check_control_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+   check_l3cc_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+
+   res_ms = read_rc6_residency();
+   sleep(3);
+   igt_assert_neq(res_ms, read_rc6_residency());
+
+   

Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict WaC6DisallowByGfxPause

[Gore, Tim]

Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ

> -Original Message-
> From: Kamble, Sagar A
> Sent: Tuesday, July 19, 2016 7:56 AM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict
> WaC6DisallowByGfxPause
> 
> 
> 
> On 7/15/2016 7:19 PM, tim.g...@intel.com wrote:
> > From: Tim Gore 
> >
> > WaC6DisallowByGfxPause is currently applied unconditionally but is not
> > required in all revisions.
> >
> > References: HSD#2133391
> > Signed-off-by: Tim Gore 
> > ---
> >   drivers/gpu/drm/i915/intel_guc_loader.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > index 605c696..173dcef 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > @@ -349,7 +349,9 @@ static int guc_ucode_xfer(struct drm_i915_private
> *dev_priv)
> > }
> >
> > /* WaC6DisallowByGfxPause*/
> > -   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
> > +   if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) ||
> > +   IS_BXT_REVID(dev, 0, BXT_REVID_A1))
> I see this is applicable till BXT B0 and SKL C0 in wa_database. Am I missing
> something?

  The HSD (ref'd above) indicates that this problem is fixed in Bxt B0 and Skl 
C0.
I wasn't sure whether to follow the HSD or prior art.?

> > +   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
> >
> > if (IS_BROXTON(dev))
> > I915_WRITE(GEN9LP_GT_PM_CONFIG,
> GT_DOORBELL_ENABLE);

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

Re: [Intel-gfx] [PATCH 01/11] drm/drm-kms.rst: Remove unused drm_fourcc.h include directive

[Daniel Vetter]

On Fri, Jul 15, 2016 at 09:47:58PM +0200, Daniel Vetter wrote:
> Right now there's nothing, and kernel-doc produces a warning because
> of that. Remove it until we need it for a clean build.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

Pulled in the entire pile with Chris' irc-ack, and the few things he
commented on polished.
-Daniel

> ---
>  Documentation/gpu/drm-kms.rst | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 0e1c80436c1d..675221f0a64b 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -67,9 +67,6 @@ drivers can manually clean up a framebuffer at module 
> unload time with
>  DRM Format Handling
>  ---
>  
> -.. kernel-doc:: include/drm/drm_fourcc.h
> -   :internal:
> -
>  .. kernel-doc:: drivers/gpu/drm/drm_fourcc.c
> :export:
>  
> -- 
> 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] drm/i915: Handle ENOSPC after failing to insert a mappable node

[Chris Wilson]

On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > Even after adding individual page support for GTT mmaping, we can still
> > fail to find any space within the mappable region, and
> > drm_mm_insert_node() will then report ENOSPC. We have to then handle
> > this error by using the shmem access to the pages.
> > 
> > Fixes: b50a53715f09 ("drm/i915: Support for pread/pwrite ... objects")
> > Testcase: igt/gem_concurrent_blit
> > Signed-off-by: Chris Wilson 
> > Cc: Ankitprasad Sharma 
> > Cc: Tvrtko Ursulin  
> Reviewed-by: Daniel Vetter 

Thanks for the review, pushed.

Ideas for how we can stress this a bit directly than
gem_concurrent_blit?

We need to have many threads all pinning and then hitting the slow path
in the read (thus allowing another thread to come in and fail to claim
some aperture space for itself). Tricksy.

Hmm, how about fault-injection under I915_DEBUG?
-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 drm/i915: Simplify shrinker_lock

[Patchwork]

== Series Details ==

Series: drm/i915: Simplify shrinker_lock
URL   : https://patchwork.freedesktop.org/series/10016/
State : failure

== Summary ==

Series 10016v1 drm/i915: Simplify shrinker_lock
http://patchwork.freedesktop.org/api/1.0/series/10016/revisions/1/mbox

Test gem_exec_gttfill:
Subgroup basic:
pass   -> DMESG-WARN (fi-snb-i7-2600)
Test gem_sync:
Subgroup basic-store-each:
pass   -> DMESG-FAIL (ro-bdw-i7-5600u)

fi-bsw-n3050 total:243  pass:188  dwarn:0   dfail:0   fail:11  skip:44 
fi-hsw-i7-4770k  total:243  pass:210  dwarn:0   dfail:0   fail:13  skip:20 
fi-kbl-qkkr  total:243  pass:175  dwarn:27  dfail:0   fail:13  skip:28 
fi-skl-i5-6260u  total:243  pass:219  dwarn:0   dfail:0   fail:12  skip:12 
fi-skl-i7-6700k  total:243  pass:205  dwarn:0   dfail:0   fail:12  skip:26 
fi-snb-i7-2600   total:243  pass:189  dwarn:1   dfail:0   fail:13  skip:40 
ro-bdw-i5-5250u  total:243  pass:214  dwarn:4   dfail:0   fail:12  skip:13 
ro-bdw-i7-5557U  total:243  pass:215  dwarn:0   dfail:0   fail:12  skip:16 
ro-bdw-i7-5600u  total:243  pass:199  dwarn:0   dfail:1   fail:11  skip:32 
ro-bsw-n3050 total:218  pass:172  dwarn:0   dfail:0   fail:2   skip:43 
ro-byt-n2820 total:243  pass:191  dwarn:0   dfail:0   fail:14  skip:38 
ro-hsw-i3-4010u  total:243  pass:206  dwarn:0   dfail:0   fail:13  skip:24 
ro-hsw-i7-4770r  total:243  pass:206  dwarn:0   dfail:0   fail:13  skip:24 
ro-ilk-i7-620lm  total:243  pass:166  dwarn:0   dfail:0   fail:14  skip:63 
ro-ilk1-i5-650   total:238  pass:166  dwarn:0   dfail:0   fail:14  skip:58 
ro-ivb-i7-3770   total:243  pass:197  dwarn:0   dfail:0   fail:13  skip:33 
ro-skl3-i5-6260u total:243  pass:218  dwarn:1   dfail:0   fail:12  skip:12 
ro-snb-i7-2620M  total:243  pass:188  dwarn:0   dfail:0   fail:13  skip:42 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1523/

3e14755 drm-intel-nightly: 2016y-07m-18d-14h-26m-21s UTC integration manifest
0856152 drm/i915: Simplify shrinker_lock

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: refactor eb_get_batch()

[Chris Wilson]

On Fri, Jul 15, 2016 at 09:03:40AM +0100, Dave Gordon wrote:
> On 14/07/16 15:03, Chris Wilson wrote:
> >On Thu, Jul 14, 2016 at 02:12:55PM +0100, Dave Gordon wrote:
> >>On 13/07/16 13:44, Chris Wilson wrote:
> >>>On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote:
> On Thu, Jun 30, 2016 at 04:12:49PM +0100, Dave Gordon wrote:
> >Precursor for fix to secure batch execution. We will need to be able to
> >retrieve the batch VMA (as well as the batch itself) from the eb list,
> >so this patch extracts that part of eb_get_batch() into a separate
> >function, and moves both parts to a more logical place in the file, near
> >where the eb list is created.
> >
> >Also, it may not be obvious, but the current execbuffer2 ioctl interface
> >requires that the buffer object containing the batch-to-be-executed be
> >the LAST entry in the exec2_list[] array (I expected it to be the 
> >first!).
> >
> >To clarify this, we can replace the rather obscure construct
> > "list_entry(eb->vmas.prev, ...)"
> >in the old version of eb_get_batch() with the equivalent but more 
> >explicit
> > "list_last_entry(>vmas,...)"
> >in the new eb_get_batch_vma() and of course add an explanatory comment.
> >
> >Signed-off-by: Dave Gordon 
> 
> I have no context on the secure batch fix you're talking about, but this
> here makes sense as an independent cleanup.
> >>>
> >>>It won't help though, so this is just churn for no purpose.
> >>>-Chris
> >>
> >>At the very least, it replaces a confusing construct with
> >>a comprehensible one annotated with an explanatory comment.
> >
> >No. It deepens a confusion in the code that I've been trying to get
> >removed over the last couple of years.
> 
> ?
> 
> I was referring to the list_{last_}entry() change. That's definitely
> a clarification as to how things work now. Of course, if you're
> planning to make the batch the first object rather than the last, I
> won't object. But whichever it is, let's use the
> most-appropriately-named of the available list functions when we
> pick an item from a list. And comment why or what it's doing.
> 
> >>Separating finding the VMA for the batch from finding the batch itself
> >>also improves clarity and costs nothing (compiler inlines it anyway).
> >
> >No. That's the confusion you have here. The object is irrelevant.
> 
> Ah, so we have a function to return an irrelevant object. Let's just
> delete it then ;)
> 
> Do you think we /should/ just get rid of eb_get_batch()? Maybe just
> have eb_get_batch_vma() return the VMA to the [single] caller
> i915_gem_do_execbuffer() instead, and then have /that/ do both
> the flag-setting ugliness and the indirection to the object (which
> evidently is not irrelevant to it) ?
> 
> >>Comprehensibility -- and hence maintainability -- is always
> >>a worthwhile purpose :)
> >
> >s/comprehensibility/greater confusion/
> 
> Spoken like a true Discordian ;)
> 
> >> BTW, do the comments in this code from patch
> >>
> >>d23db88 drm/i915: Prevent negative relocation deltas from wrapping
> >>
> >>still apply? 'Cos I think it's pretty ugly to be setting a flag
> >>on a VMA as a side-effect of a "lookup" type operation :( Surely
> >>cleaner to do that sort of think at the top level i.e. inside
> >>i915_gem_do_execbuffer() ?
> >
> >The comment is wrong since the practice is more widespread and it is
> >a particular hw bug on Ivybridge.
> >-Chris
> 
> Another reason to move it out to the caller and update the comments
> in the process!

Then review the patches that have already been posted several times on
the list to do everything above.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

[Chris Wilson]

On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > Even after adding individual page support for GTT mmaping, we can still
> > fail to find any space within the mappable region, and
> > drm_mm_insert_node() will then report ENOSPC. We have to then handle
> > this error by using the shmem access to the pages.
> > 
> > Fixes: b50a53715f09 ("drm/i915: Support for pread/pwrite ... objects")
> > Testcase: igt/gem_concurrent_blit
> > Signed-off-by: Chris Wilson 
> > Cc: Ankitprasad Sharma 
> > Cc: Tvrtko Ursulin  
> Reviewed-by: Daniel Vetter 
> 
> Aside: Anything anywhere in the pipeline to make gtt mmap more robust for
> ENOSPC?

Yes. They were on the list beginning of last year

Fence tracking gets moved to the vma (that tides up some ringbuffer and
execbuf logic, including fixing up some failure cases there) and in the
process that enables us to support partial tiled faulting as well as
fixup the current breakage. About 120 patches in.
-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] ✗ Ro.CI.BAT: failure for series starting with [CI,resend,1/2] drm/i915: compile-time consistency check on __EXEC_OBJECT flags

[Daniel Vetter]

On Fri, Jul 15, 2016 at 09:52:27AM +0100, Dave Gordon wrote:
> On 15/07/16 09:15, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: series starting with [CI,resend,1/2] drm/i915: compile-time 
> > consistency check on __EXEC_OBJECT flags
> > URL   : https://patchwork.freedesktop.org/series/9876/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 9876v1 Series without cover letter
> > http://patchwork.freedesktop.org/api/1.0/series/9876/revisions/1/mbox
> > 
> > Test drv_module_reload_basic:
> >  skip   -> PASS   (ro-ivb-i7-3770)
> > Test kms_cursor_legacy:
> >  Subgroup basic-flip-vs-cursor:
> >  dmesg-warn -> PASS   (ro-byt-n2820)
> > Test kms_pipe_crc_basic:
> >  Subgroup nonblocking-crc-pipe-b:
> >  skip   -> PASS   (fi-skl-i5-6260u)
> >  Subgroup read-crc-pipe-c:
> >  pass   -> SKIP   (fi-skl-i5-6260u)
> 
> "No connector found for pipe 2"
> See https://bugs.freedesktop.org/show_bug.cgi?id=93769

Applied, thanks for the patches.
-Daniel

> 
> .Dave.
> 
> >  Subgroup suspend-read-crc-pipe-a:
> >  pass   -> INCOMPLETE (fi-skl-i7-6700k)
> > Test vgem_basic:
> >  Subgroup debugfs:
> >  incomplete -> PASS   (ro-snb-i7-2620M)
> > 
> > fi-kbl-qkkr  total:241  pass:174  dwarn:29  dfail:1   fail:6   skip:31
> > fi-skl-i5-6260u  total:241  pass:217  dwarn:0   dfail:0   fail:7   skip:17
> > fi-skl-i7-6700k  total:195  pass:170  dwarn:0   dfail:0   fail:0   skip:24
> > fi-snb-i7-2600   total:241  pass:190  dwarn:0   dfail:0   fail:7   skip:44
> > ro-bdw-i5-5250u  total:241  pass:213  dwarn:4   dfail:0   fail:7   skip:17
> > ro-bdw-i7-5557U  total:241  pass:213  dwarn:1   dfail:0   fail:7   skip:20
> > ro-bdw-i7-5600u  total:241  pass:199  dwarn:0   dfail:0   fail:7   skip:35
> > ro-byt-n2820 total:241  pass:191  dwarn:0   dfail:0   fail:8   skip:42
> > ro-hsw-i3-4010u  total:241  pass:206  dwarn:0   dfail:0   fail:7   skip:28
> > ro-hsw-i7-4770r  total:241  pass:206  dwarn:0   dfail:0   fail:7   skip:28
> > ro-ilk-i7-620lm  total:241  pass:166  dwarn:0   dfail:0   fail:8   skip:67
> > ro-ilk1-i5-650   total:236  pass:166  dwarn:0   dfail:0   fail:8   skip:62
> > ro-ivb-i7-3770   total:241  pass:197  dwarn:0   dfail:0   fail:7   skip:37
> > ro-skl3-i5-6260u total:241  pass:217  dwarn:1   dfail:0   fail:7   skip:16
> > ro-snb-i7-2620M  total:241  pass:188  dwarn:0   dfail:0   fail:8   skip:45
> > 
> > Results at /archive/results/CI_IGT_test/RO_Patchwork_1493/
> > 
> > c01b445 drm-intel-nightly: 2016y-07m-15d-07h-02m-07s UTC integration 
> > manifest
> > ce44917 drm/i915: refactor eb_get_batch()
> > 46acffb drm/i915: compile-time consistency check on __EXEC_OBJECT flags
> > 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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