[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/skl: Fix redundant cursor update, fix cursor underruns

[Patchwork]

== Series Details ==

Series: drm/i915/skl: Fix redundant cursor update, fix cursor underruns
URL   : https://patchwork.freedesktop.org/series/9940/
State : success

== Summary ==

Series 9940v1 drm/i915/skl: Fix redundant cursor update, fix cursor underruns
http://patchwork.freedesktop.org/api/1.0/series/9940/revisions/1/mbox


fi-hsw-i7-4770k  total:242  pass:210  dwarn:0   dfail:0   fail:8   skip:24 
fi-kbl-qkkr  total:242  pass:176  dwarn:29  dfail:0   fail:7   skip:30 
fi-skl-i5-6260u  total:242  pass:219  dwarn:0   dfail:0   fail:7   skip:16 
fi-skl-i7-6700k  total:242  pass:205  dwarn:0   dfail:0   fail:7   skip:30 
fi-snb-i7-2600   total:242  pass:190  dwarn:0   dfail:0   fail:8   skip:44 
ro-bdw-i5-5250u  total:242  pass:214  dwarn:4   dfail:0   fail:7   skip:17 
ro-bdw-i7-5557U  total:242  pass:215  dwarn:0   dfail:0   fail:7   skip:20 
ro-bdw-i7-5600u  total:242  pass:199  dwarn:0   dfail:1   fail:7   skip:35 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:242  pass:191  dwarn:0   dfail:0   fail:9   skip:42 
ro-hsw-i3-4010u  total:242  pass:206  dwarn:0   dfail:0   fail:8   skip:28 
ro-hsw-i7-4770r  total:242  pass:206  dwarn:0   dfail:0   fail:8   skip:28 
ro-ilk-i7-620lm  total:242  pass:166  dwarn:0   dfail:0   fail:9   skip:67 
ro-ilk1-i5-650   total:237  pass:166  dwarn:0   dfail:0   fail:9   skip:62 
ro-ivb-i7-3770   total:242  pass:197  dwarn:0   dfail:0   fail:8   skip:37 
ro-skl3-i5-6260u total:242  pass:218  dwarn:1   dfail:0   fail:7   skip:16 
ro-snb-i7-2620M  total:242  pass:188  dwarn:0   dfail:0   fail:9   skip:45 
fi-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1506/

2fe098f drm-intel-nightly: 2016y-07m-15d-19h-42m-01s UTC integration manifest
2074255 drm/i915/skl: Fix redundant cursor update, fix cursor underruns

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

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

[kbuild test robot]

Hi,

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

url:
https://github.com/0day-ci/linux/commits/Lionel-Landwerlin/drm-i915-Set-legacy-properties-when-using-legacy-gamma-set-IOCTL/20160715-203721
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_display.c:13959:15: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .gamma_set = intel_atomic_legacy_gamma_set,
  ^
   drivers/gpu/drm/i915/intel_display.c:13959:15: note: (near initialization 
for 'intel_crtc_funcs.gamma_set')
   cc1: some warnings being treated as errors

vim +13959 drivers/gpu/drm/i915/intel_display.c

 13953config->gamma_lut_property,
 13954(state->gamma_lut) ?
 13955state->gamma_lut->base.id : 0);
 13956  }
 13957  
 13958  static const struct drm_crtc_funcs intel_crtc_funcs = {
 13959  .gamma_set = intel_atomic_legacy_gamma_set,
 13960  .set_config = drm_atomic_helper_set_config,
 13961  .set_property = drm_atomic_helper_crtc_set_property,
 13962  .destroy = intel_crtc_destroy,

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


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

[Intel-gfx] [PATCH] drm/i915/skl: Fix redundant cursor update, fix cursor underruns

[Lyude]

At long last, the time has finally come for Skylake users to plug their
external displays back in.

During intel_atomic_commit() on Skylake, we've actually been arming the
registers to update the cursor information twice instead of just once.
Once in i9xx_update_cursor(), and once in skl_wm_flush_pipe(). This
isn't actually necessary, and removing the later update in
skl_wm_flush_pipe() has completely stopped the underruns on this T460p
from occurring when moving the mouse cursor from one monitor to another.

Signed-off-by: Lyude 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7ac71ec..4771a03 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3860,7 +3860,6 @@ skl_wm_flush_pipe(struct drm_i915_private *dev_priv, enum 
pipe pipe, int pass)
I915_WRITE(PLANE_SURF(pipe, plane),
   I915_READ(PLANE_SURF(pipe, plane)));
}
-   I915_WRITE(CURBASE(pipe), I915_READ(CURBASE(pipe)));
 }
 
 static bool
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init

[Stephen J]

On Fri, Jul 15, 2016 at 3:08 AM, Shobhit Kumar  wrote:
>
> On Fri, Jul 15, 2016 at 2:33 PM, Shobhit Kumar  
> wrote:
> > On devices that have MIPI DSI panel control and PWM control comming from
> > CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
> > driver. Defer probing for later in case we fail to get these devices.
> >
> > v2: Rebased on latest drm-intel-nightly
> > Added failure check for pwm_get which got missed out
> >
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index b9a8117..9bfe0c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -648,6 +648,9 @@ static int i915_load_modeset_init(struct drm_device 
> > *dev)
> > /* Important: The output setup functions called by modeset_init need
> >  * working irqs for e.g. gmbus and dp aux transfers. */
> > intel_modeset_init(dev);
> > +   ret = intel_modeset_init(dev);
> > +   if (ret == -EPROBE_DEFER)
> > +   goto cleanup_deffered_probe;

Did you intend to call intel_modeset_init twice? In my tests, I
removed the first copy because it seemed like a mistake.

> >
> > intel_guc_init(dev);
> >
> > @@ -675,6 +678,7 @@ cleanup_gem:
> > i915_gem_fini(dev);
> >  cleanup_irq:
> > intel_guc_fini(dev);
> > +cleanup_deffered_probe:
> > drm_irq_uninstall(dev);
> > intel_teardown_gmbus(dev);
> >  cleanup_csr:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 03e1bfa..a9eed22 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3778,7 +3778,7 @@ void intel_device_info_dump(struct drm_i915_private 
> > *dev_priv);
> >
> >  /* modesetting */
> >  extern void intel_modeset_init_hw(struct drm_device *dev);
> > -extern void intel_modeset_init(struct drm_device *dev);
> > +extern int intel_modeset_init(struct drm_device *dev);
> >  extern void intel_modeset_gem_init(struct drm_device *dev);
> >  extern void intel_modeset_cleanup(struct drm_device *dev);
> >  extern int intel_connector_register(struct drm_connector *);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index be3b2ca..b1250f2 100644
> > [snip]

When testing on drm-intel-nightly, my system froze with your patch. I
can't get a full dmesg because I haven't yet found a way to trigger
the problem after I can get an ssh session up.

The relevant logs I see before freeze are:
[drm] Initialized drm 1.1.0 20060810
[drm] Memory usable by graphics device = 2048M
fb: switching to inteldrmfb from EFI VGA

console is stuck at this point, my guess is that modeset fails and
that isn't handled well. The screen does not go black, the log
messages just stay on screen indefinitely.

If I blacklist i915 and let X load the module (or manually load it
later), everything seems to run fine and backlight works, but that was
also true before applying the patch.

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

Re: [Intel-gfx] [PATCH 02/11] drm/doc: Add kerneldoc for @index

[Chris Wilson]

On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> Was forgotten when adding them all over. 0-day should complain about
> new missing kernel-doc, not sure why that wasn't caught/fixed.
> 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_crtc.h | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index ebf078685f86..656f189f1198 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -783,7 +783,10 @@ struct drm_crtc {
>   struct drm_plane *primary;
>   struct drm_plane *cursor;
>  
> - /* position inside the mode_config.list, can be used as a [] idx */
> + /**
> +  * @index: Position inside the mode_config.list, can be used as an array

For all:

@index: Fixed position inside the mode_config.list, can be used as an
array index. The @index is assigned when the crtc is inserted into the
list, and it will remain at that position inside the list until the
module is unloaded.

Just want to emphasis the unchanging nature of the @index. Second
sentence may be overkill.
-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 09/11] drm/i915: Clean up kerneldoc for intel_lrc.c

[Chris Wilson]

On Fri, Jul 15, 2016 at 09:48:06PM +0200, Daniel Vetter wrote:
> Fairly minimal, there's still lots of functions without any docs, and
> which aren't static. But probably we want to first clean this up some more.
> 
> - Drop the bogus const. Marking argument pointers themselves (instead of
>   what they point at) as const provides roughly 0 value. And it's confusing,
>   since the data the pointer points at _is_ being changed.

It served its purpose of getting the compiler to sanity check that batch
was unchanged as we passed it around the various obscuration macros.
-Chris

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

Re: [Intel-gfx] [PATCH 06/11] drm/dp-mst: Remove tx_down_in_progress

[Chris Wilson]

On Fri, Jul 15, 2016 at 09:48:03PM +0200, Daniel Vetter wrote:
> Just replicates whether the list is empty or not. Nuke code
> to avoid writing docs for it!
> 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Chris Wilson 

Unless Dave to planned to use it elsewhere, tx_msg_downq is indeed
redundant.
-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 04/11] drm: Extract drm_irq.h

[Daniel Vetter]

The drm_irq docs want one function from drmP.h, but that one is a
serious mess. Extract it, and while at it improve the docs a bit.
There's a bit a header loop issue since core data structures like
drm_device and drm_driver aren't in their own headers yet, which means
the drm_irq.h include in drmP.h needs to be in just the right spot :(

Also noticed that drm_vblank_crtc->last_wait is entirely unused,
remove it.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst |  4 +--
 drivers/gpu/drm/drm_irq.c |  1 -
 include/drm/drmP.h| 83 ++-
 3 files changed, 5 insertions(+), 83 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 675221f0a64b..8dfa4b214b96 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -649,5 +649,5 @@ Vertical Blanking and Interrupt Handling Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_irq.c
:export:
 
-.. kernel-doc:: include/drm/drmP.h
-   :functions: drm_crtc_vblank_waitqueue
+.. kernel-doc:: include/drm/drm_irq.h
+   :internal:
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 49e83b190e01..b49a4a6e97cd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1664,7 +1664,6 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 
DRM_DEBUG("waiting on vblank count %d, crtc %u\n",
  vblwait->request.sequence, pipe);
-   vblank->last_wait = vblwait->request.sequence;
DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
(((drm_vblank_count(dev, pipe) -
   vblwait->request.sequence) <= (1 << 23)) ||
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 19cbd7f8d302..5f9caf7ee949 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -52,7 +52,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -87,6 +86,7 @@ struct drm_device_dma;
 struct drm_dma_handle;
 struct drm_gem_object;
 struct drm_master;
+struct drm_vblank_crtc;
 
 struct device_node;
 struct videomode;
@@ -684,35 +684,6 @@ struct drm_minor {
struct mutex debugfs_lock; /* Protects debugfs_list. */
 };
 
-
-struct drm_pending_vblank_event {
-   struct drm_pending_event base;
-   unsigned int pipe;
-   struct drm_event_vblank event;
-};
-
-struct drm_vblank_crtc {
-   struct drm_device *dev; /* pointer to the drm_device */
-   wait_queue_head_t queue;/**< VBLANK wait queue */
-   struct timer_list disable_timer;/* delayed disable 
timer */
-
-   seqlock_t seqlock;  /* protects vblank count and time */
-
-   u32 count;  /* vblank counter */
-   struct timeval time;/* vblank timestamp */
-
-   atomic_t refcount;  /* number of users of vblank 
interruptsper crtc */
-   u32 last;   /* protected by dev->vbl_lock, used */
-   /* for wraparound handling */
-   u32 last_wait;  /* Last vblank seqno waited per CRTC */
-   unsigned int inmodeset; /* Display driver is setting mode */
-   unsigned int pipe;  /* crtc index */
-   int framedur_ns;/* frame/field duration in ns */
-   int linedur_ns; /* line duration in ns */
-   bool enabled;   /* so we don't call enable more than
-  once per disable */
-};
-
 /**
  * DRM device structure. This structure represent a complete card that
  * may contain multiple heads.
@@ -847,6 +818,8 @@ struct drm_device {
int switch_power_state;
 };
 
+#include 
+
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
@@ -933,56 +906,6 @@ void drm_clflush_virt_range(void *addr, unsigned long 
length);
  * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
  */
 
-   /* IRQ support (drm_irq.h) */
-extern int drm_irq_install(struct drm_device *dev, int irq);
-extern int drm_irq_uninstall(struct drm_device *dev);
-
-extern int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
-extern int drm_wait_vblank(struct drm_device *dev, void *data,
-  struct drm_file *filp);
-extern u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe);
-extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
-extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
- struct timeval *vblanktime);
-extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
-  struct drm_pending_vblank_event *e);
-extern void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
- struct drm_pending_vblank_event *e);
-extern bool 

[Intel-gfx] [PATCH 10/11] drm/i915: Update missing kerneldoc

[Daniel Vetter]

Not sure why so much slips through when 0day is catching these. Hopefully
the much faster sphinx toolchain helps in unlazying people.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c  | 2 +-
 drivers/gpu/drm/i915/i915_vgpu.c | 3 ++-
 drivers/gpu/drm/i915/intel_fbc.c | 2 ++
 drivers/gpu/drm/i915/intel_hotplug.c | 1 -
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf0e8aa8035c..0151c0ce037d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -916,7 +916,7 @@ fast_user_write(struct io_mapping *mapping,
 /**
  * This is the fast pwrite path, where we copy the data directly from the
  * user into the GTT, uncached.
- * @dev: drm device pointer
+ * @i915: i915 device private data
  * @obj: i915 gem object
  * @args: pwrite arguments structure
  * @file: drm file pointer
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index f6acb5a0e701..142bac976919 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -97,6 +97,7 @@ static struct _balloon_info_ bl_info;
 
 /**
  * intel_vgt_deballoon - deballoon reserved graphics address trunks
+ * @dev_priv: i915 device private data
  *
  * This function is called to deallocate the ballooned-out graphic memory, when
  * driver is unloaded or when ballooning fails.
@@ -138,7 +139,7 @@ static int vgt_balloon_space(struct drm_mm *mm,
 
 /**
  * intel_vgt_balloon - balloon out reserved graphics address trunks
- * @dev: drm device
+ * @dev_priv: i915 device private data
  *
  * This function is called at the initialization stage, to balloon out the
  * graphic address space allocated to other vGPUs, by marking these spaces as
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 6a7ad3ed1463..781e2f5f7cd8 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1075,6 +1075,8 @@ out:
 /**
  * intel_fbc_enable: tries to enable FBC on the CRTC
  * @crtc: the CRTC
+ * @crtc_state: corresponding _crtc_state for @crtc
+ * @plane_state: corresponding _plane_state for the primary plane of @crtc
  *
  * This function checks if the given CRTC was chosen for FBC, then enables it 
if
  * possible. Notice that it doesn't activate FBC. It is valid to call
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index f271f1452b98..40ce263d715f 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -527,7 +527,6 @@ void i915_hpd_poll_init_work(struct work_struct *work) {
 /**
  * intel_hpd_poll_init - enables/disables polling for connectors with hpd
  * @dev_priv: i915 device instance
- * @enabled: Whether to enable or disable polling
  *
  * This function enables polling for all connectors, regardless of whether or
  * not they support hotplug detection. Under certain conditions HPD may not be
-- 
2.8.1

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

[Intel-gfx] [PATCH 06/11] drm/dp-mst: Remove tx_down_in_progress

[Daniel Vetter]

Just replicates whether the list is empty or not. Nuke code
to avoid writing docs for it!

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
 include/drm/drm_dp_mst_helper.h   |  1 -
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6537908050d7..5020a2aaffeb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1493,11 +1493,8 @@ static void process_single_down_tx_qlock(struct 
drm_dp_mst_topology_mgr *mgr)
WARN_ON(!mutex_is_locked(>qlock));
 
/* construct a chunk from the first msg in the tx_msg queue */
-   if (list_empty(>tx_msg_downq)) {
-   mgr->tx_down_in_progress = false;
+   if (list_empty(>tx_msg_downq))
return;
-   }
-   mgr->tx_down_in_progress = true;
 
txmsg = list_first_entry(>tx_msg_downq, struct 
drm_dp_sideband_msg_tx, next);
ret = process_single_tx_qlock(mgr, txmsg, false);
@@ -1512,10 +1509,6 @@ static void process_single_down_tx_qlock(struct 
drm_dp_mst_topology_mgr *mgr)
txmsg->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
wake_up(>tx_waitq);
}
-   if (list_empty(>tx_msg_downq)) {
-   mgr->tx_down_in_progress = false;
-   return;
-   }
 }
 
 /* called holding qlock */
@@ -1538,7 +1531,7 @@ static void drm_dp_queue_down_tx(struct 
drm_dp_mst_topology_mgr *mgr,
 {
mutex_lock(>qlock);
list_add_tail(>next, >tx_msg_downq);
-   if (!mgr->tx_down_in_progress)
+   if (list_is_singular(>tx_msg_downq))
process_single_down_tx_qlock(mgr);
mutex_unlock(>qlock);
 }
@@ -2887,7 +2880,7 @@ static void drm_dp_tx_work(struct work_struct *work)
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
drm_dp_mst_topology_mgr, tx_work);
 
mutex_lock(>qlock);
-   if (mgr->tx_down_in_progress)
+   if (!list_empty(>tx_msg_downq))
process_single_down_tx_qlock(mgr);
mutex_unlock(>qlock);
 }
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index fdb47051d549..c49bbfaf3cbb 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -446,7 +446,6 @@ struct drm_dp_mst_topology_mgr {
   the mstb tx_slots and txmsg->state once they are queued */
struct mutex qlock;
struct list_head tx_msg_downq;
-   bool tx_down_in_progress;
 
/* payload info + lock for it */
struct mutex payload_lock;
-- 
2.8.1

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

[Intel-gfx] [PATCH 07/11] drm/dp-mst: Missing kernel doc

[Daniel Vetter]

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c |   1 +
 include/drm/drm_dp_mst_helper.h   | 140 --
 2 files changed, 117 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5020a2aaffeb..04e457117980 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2365,6 +2365,7 @@ EXPORT_SYMBOL(drm_dp_mst_hpd_irq);
 
 /**
  * drm_dp_mst_detect_port() - get connection status for an MST port
+ * @connector: DRM connector for this port
  * @mgr: manager for this port
  * @port: unverified pointer to a port
  *
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index c49bbfaf3cbb..003207670597 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -87,7 +87,15 @@ struct drm_dp_mst_port {
struct drm_connector *connector;
struct drm_dp_mst_topology_mgr *mgr;
 
-   struct edid *cached_edid; /* for DP logical ports - make tiling work */
+   /**
+* @cached_edid: for DP logical ports - make tiling work by ensuring
+* that the EDID for all connectors is read immediately.
+*/
+   struct edid *cached_edid;
+   /**
+* @has_audio: Tracks whether the sink connector to this port is
+* audio-capable.
+*/
bool has_audio;
 };
 
@@ -397,70 +405,154 @@ struct drm_dp_payload {
 
 /**
  * struct drm_dp_mst_topology_mgr - DisplayPort MST manager
- * @dev: device pointer for adding i2c devices etc.
- * @cbs: callbacks for connector addition and destruction.
- * @max_dpcd_transaction_bytes - maximum number of bytes to read/write in one 
go.
- * @aux: aux channel for the DP connector.
- * @max_payloads: maximum number of payloads the GPU can generate.
- * @conn_base_id: DRM connector ID this mgr is connected to.
- * @down_rep_recv: msg receiver state for down replies.
- * @up_req_recv: msg receiver state for up requests.
- * @lock: protects mst state, primary, dpcd.
- * @mst_state: if this manager is enabled for an MST capable port.
- * @mst_primary: pointer to the primary branch device.
- * @dpcd: cache of DPCD for primary port.
- * @pbn_div: PBN to slots divisor.
  *
  * This struct represents the toplevel displayport MST topology manager.
  * There should be one instance of this for every MST capable DP connector
  * on the GPU.
  */
 struct drm_dp_mst_topology_mgr {
-
+   /**
+* @dev: device pointer for adding i2c devices etc.
+*/
struct device *dev;
+   /**
+* @cbs: callbacks for connector addition and destruction.
+*/
const struct drm_dp_mst_topology_cbs *cbs;
+   /**
+* @max_dpcd_transaction_bytes: maximum number of bytes to read/write
+* in one go.
+*/
int max_dpcd_transaction_bytes;
-   struct drm_dp_aux *aux; /* auxch for this topology mgr to use */
+   /**
+* @aux: AUX channel for the DP MST connector this topolgy mgr is
+* controlling.
+*/
+   struct drm_dp_aux *aux;
+   /**
+* @max_payloads: maximum number of payloads the GPU can generate.
+*/
int max_payloads;
+   /**
+* @conn_base_id: DRM connector ID this mgr is connected to. Only used
+* to build the MST connector path value.
+*/
int conn_base_id;
 
-   /* only ever accessed from the workqueue - which should be serialised */
+   /**
+* @down_rep_recv: Message receiver state for down replies. This and
+* @up_req_recv are only ever access from the work item, which is
+* serialised.
+*/
struct drm_dp_sideband_msg_rx down_rep_recv;
+   /**
+* @up_req_recv: Message receiver state for up requests. This and
+* @down_rep_recv are only ever access from the work item, which is
+* serialised.
+*/
struct drm_dp_sideband_msg_rx up_req_recv;
 
-   /* pointer to info about the initial MST device */
-   struct mutex lock; /* protects mst_state + primary + dpcd */
+   /**
+* @lock: protects mst state, primary, dpcd.
+*/
+   struct mutex lock;
 
+   /**
+* @mst_state: If this manager is enabled for an MST capable port. False
+* if no MST sink/branch devices is connected.
+*/
bool mst_state;
+   /**
+* @mst_primary: Pointer to the primary/first branch device.
+*/
struct drm_dp_mst_branch *mst_primary;
 
+   /**
+* @dpcd: Cache of DPCD for primary port.
+*/
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+   /**
+* @sink_count: Sink count from DEVICE_SERVICE_IRQ_VECTOR_ESI0.
+*/
u8 sink_count;
+   /**
+* @pbn_div: PBN to slots divisor.
+*/
int pbn_div;
+   /**
+   

[Intel-gfx] [PATCH 05/11] drm/doc: Fix missing kerneldoc for drm_dp_helper.c

[Daniel Vetter]

Never added when the DP validation code was added.

Signed-off-by: Daniel Vetter 
---
 include/drm/drm_dp_helper.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4d85cf2874af..72dee1213268 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -747,7 +747,14 @@ struct drm_dp_aux {
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
-   unsigned i2c_nack_count, i2c_defer_count;
+   /**
+* @i2c_nack_count: Counts I2C NACKs, used for DP validation.
+*/
+   unsigned i2c_nack_count;
+   /**
+* @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
+*/
+   unsigned i2c_defer_count;
 };
 
 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
-- 
2.8.1

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

[Intel-gfx] [PATCH 03/11] drm/doc: document all the properties in drm_mode_config

[Daniel Vetter]

I'm fed up with the warning noise from kernel-doc.

Aside: I stumbled over dirty_info_property, which is only set by udl
and qxl. But we have a _lot_ more drivers implementing a dirty
callback on framebuffers. Not entirely sure what the ABI is supposed
to be here, but it seems confusing for sure.

Signed-off-by: Daniel Vetter 
---
 include/drm/drm_crtc.h | 196 +
 1 file changed, 180 insertions(+), 16 deletions(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 656f189f1198..6a702a484a23 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2351,18 +2351,8 @@ struct drm_mode_config_funcs {
  * @property_blob_list: list of all the blob property objects
  * @blob_lock: mutex for blob property allocation and management
  * @*_property: core property tracking
- * @degamma_lut_property: LUT used to convert the framebuffer's colors to 
linear
- * gamma
- * @degamma_lut_size_property: size of the degamma LUT as supported by the
- * driver (read-only)
- * @ctm_property: Matrix used to convert colors after the lookup in the
- * degamma LUT
- * @gamma_lut_property: LUT used to convert the colors, after the CSC matrix, 
to
- * the gamma space of the connected screen (read-only)
- * @gamma_lut_size_property: size of the gamma LUT as supported by the driver
  * @preferred_depth: preferred RBG pixel depth, used by fb helpers
  * @prefer_shadow: hint to userspace to prefer shadow-fb rendering
- * @async_page_flip: does this device support async flips on the primary plane?
  * @cursor_width: hint to userspace for max cursor width
  * @cursor_height: hint to userspace for max cursor height
  * @helper_private: mid-layer private data
@@ -2457,64 +2447,238 @@ struct drm_mode_config {
 
/* pointers to standard properties */
struct list_head property_blob_list;
+   /**
+* @edid_property: Default connector property to hold the EDID of the
+* currently connected sink, if any.
+*/
struct drm_property *edid_property;
+   /**
+* @dpms_property: Default connector property to control the
+* connector's DPMS state.
+*/
struct drm_property *dpms_property;
+   /**
+* @path_property: Default connector property to hold the DP MST path
+* for the port.
+*/
struct drm_property *path_property;
+   /**
+* @tile_property: Default connector property to store the tile
+* position of a tiled screen, for sinks which need to be driven with
+* multiple CRTCs.
+*/
struct drm_property *tile_property;
+   /**
+* @plane_type_property: Default plane property to differentiate
+* CURSOR, PRIMARY and OVERLAY legacy uses of planes.
+*/
struct drm_property *plane_type_property;
+   /**
+* @rotation_property: Optional property for planes or CRTCs to specifiy
+* rotation.
+*/
struct drm_property *rotation_property;
+   /**
+* @prop_src_x: Default atomic plane property for the plane source
+* position in the connected _framebuffer.
+*/
struct drm_property *prop_src_x;
+   /**
+* @prop_src_y: Default atomic plane property for the plane source
+* position in the connected _framebuffer.
+*/
struct drm_property *prop_src_y;
+   /**
+* @prop_src_w: Default atomic plane property for the plane source
+* position in the connected _framebuffer.
+*/
struct drm_property *prop_src_w;
+   /**
+* @prop_src_h: Default atomic plane property for the plane source
+* position in the connected _framebuffer.
+*/
struct drm_property *prop_src_h;
+   /**
+* @prop_crtc_x: Default atomic plane property for the plane destination
+* position in the _crtc is is being shown on.
+*/
struct drm_property *prop_crtc_x;
+   /**
+* @prop_crtc_y: Default atomic plane property for the plane destination
+* position in the _crtc is is being shown on.
+*/
struct drm_property *prop_crtc_y;
+   /**
+* @prop_crtc_w: Default atomic plane property for the plane destination
+* position in the _crtc is is being shown on.
+*/
struct drm_property *prop_crtc_w;
+   /**
+* @prop_crtc_h: Default atomic plane property for the plane destination
+* position in the _crtc is is being shown on.
+*/
struct drm_property *prop_crtc_h;
+   /**
+* @prop_fb_id: Default atomic plane property to specify the
+* _framebuffer.
+*/
struct drm_property *prop_fb_id;
+   /**
+* @prop_crtc_id: Default atomic plane property to specify the
+* _crtc.
+*/
struct drm_property *prop_crtc_id;
+   /**
+* @prop_active: 

[Intel-gfx] [PATCH 09/11] drm/i915: Clean up kerneldoc for intel_lrc.c

[Daniel Vetter]

Fairly minimal, there's still lots of functions without any docs, and
which aren't static. But probably we want to first clean this up some more.

- Drop the bogus const. Marking argument pointers themselves (instead of
  what they point at) as const provides roughly 0 value. And it's confusing,
  since the data the pointer points at _is_ being changed.

- Remove kerneldoc for static functions. Keep comments where they seem valuable.

- Indent and whitespace fixes.

- Blockquote the bit field definitions of the descriptor for correct layouting.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_lrc.c | 99 
 1 file changed, 30 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b6af635e3a0f..2e670f15881c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -288,7 +288,6 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
 /**
  * intel_lr_context_descriptor_update() - calculate & cache the descriptor
  *   descriptor for a pinned context
- *
  * @ctx: Context to work on
  * @engine: Engine the descriptor will be used with
  *
@@ -297,12 +296,13 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
  * expensive to calculate, we'll just do it once and cache the result,
  * which remains valid until the context is unpinned.
  *
- * This is what a descriptor looks like, from LSB to MSB:
- *bits  0-11:flags, GEN8_CTX_* (cached in ctx_desc_template)
- *bits 12-31:LRCA, GTT address of (the HWSP of) this context
- *bits 32-52:ctx ID, a globally unique tag
- *bits 53-54:mbz, reserved for use by hardware
- *bits 55-63:group ID, currently unused and set to 0
+ * This is what a descriptor looks like, from LSB to MSB::
+ *
+ *  bits  0-11:flags, GEN8_CTX_* (cached in ctx_desc_template)
+ *  bits 12-31:LRCA, GTT address of (the HWSP of) this context
+ *  bits 32-52:ctx ID, a globally unique tag
+ *  bits 53-54:mbz, reserved for use by hardware
+ *  bits 55-63:group ID, currently unused and set to 0
  */
 static void
 intel_lr_context_descriptor_update(struct i915_gem_context *ctx,
@@ -539,10 +539,7 @@ get_context_status(struct intel_engine_cs *engine, 
unsigned int read_pointer,
return status;
 }
 
-/**
- * intel_lrc_irq_handler() - handle Context Switch interrupts
- * @data: tasklet handler passed in unsigned long
- *
+/*
  * Check the unread Context Status Buffers and manage the submission of new
  * contexts to the ELSP accordingly.
  */
@@ -807,7 +804,7 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
 }
 
 /**
- * execlists_submission() - submit a batchbuffer for execution, Execlists style
+ * intel_execlists_submission() - submit a batchbuffer for execution, 
Execlists style
  * @params: execbuffer call parameters.
  * @args: execbuffer call arguments.
  * @vmas: list of vmas.
@@ -1094,7 +1091,7 @@ static int intel_logical_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
  * code duplication.
  */
 static inline int gen8_emit_flush_coherentl3_wa(struct intel_engine_cs *engine,
-   uint32_t *const batch,
+   uint32_t *batch,
uint32_t index)
 {
uint32_t l3sqc4_flush = (0x4040 | GEN8_LQSC_FLUSH_COHERENT_LINES);
@@ -1155,37 +1152,24 @@ static inline int wa_ctx_end(struct i915_wa_ctx_bb 
*wa_ctx,
return 0;
 }
 
-/**
- * gen8_init_indirectctx_bb() - initialize indirect ctx batch with WA
- *
- * @engine: only applicable for RCS
- * @wa_ctx: structure representing wa_ctx
- *  offset: specifies start of the batch, should be cache-aligned. This is 
updated
- *with the offset value received as input.
- *  size: size of the batch in DWORDS but HW expects in terms of cachelines
- * @batch: page in which WA are loaded
- * @offset: This field specifies the start of the batch, it should be
- *  cache-aligned otherwise it is adjusted accordingly.
- *  Typically we only have one indirect_ctx and per_ctx batch buffer which are
- *  initialized at the beginning and shared across all contexts but this field
- *  helps us to have multiple batches at different offsets and select them 
based
- *  on a criteria. At the moment this batch always start at the beginning of 
the page
- *  and at this point we don't have multiple wa_ctx batch buffers.
- *
- *  The number of WA applied are not known at the beginning; we use this field
- *  to return the no of DWORDS written.
+/*
+ * Typically we only have one indirect_ctx and per_ctx batch buffer which are
+ * initialized at the beginning and shared across all contexts but this field
+ * helps us to have multiple batches at different offsets and select them 

[Intel-gfx] [PATCH 02/11] drm/doc: Add kerneldoc for @index

[Daniel Vetter]

Was forgotten when adding them all over. 0-day should complain about
new missing kernel-doc, not sure why that wasn't caught/fixed.

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_crtc.h | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ebf078685f86..656f189f1198 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -783,7 +783,10 @@ struct drm_crtc {
struct drm_plane *primary;
struct drm_plane *cursor;
 
-   /* position inside the mode_config.list, can be used as a [] idx */
+   /**
+* @index: Position inside the mode_config.list, can be used as an array
+* index.
+*/
unsigned index;
 
/* position of cursor plane on crtc */
@@ -1210,7 +1213,10 @@ struct drm_encoder {
char *name;
int encoder_type;
 
-   /* position inside the mode_config.list, can be used as a [] idx */
+   /**
+* @index: Position inside the mode_config.list, can be used as an array
+* index.
+*/
unsigned index;
 
uint32_t possible_crtcs;
@@ -1713,7 +1719,10 @@ struct drm_plane {
 
enum drm_plane_type type;
 
-   /* position inside the mode_config.list, can be used as a [] idx */
+   /**
+* @index: Position inside the mode_config.list, can be used as an array
+* index.
+*/
unsigned index;
 
const struct drm_plane_helper_funcs *helper_private;
@@ -2321,8 +2330,6 @@ struct drm_mode_config_funcs {
  * @fb_lock: mutex to protect fb state and lists
  * @num_fb: number of fbs available
  * @fb_list: list of framebuffers available
- * @num_connector: number of connectors on this device
- * @connector_list: list of connector objects
  * @num_encoder: number of encoders on this device
  * @encoder_list: list of encoder objects
  * @num_overlay_plane: number of overlay planes on this device
@@ -2397,8 +2404,17 @@ struct drm_mode_config {
int num_fb;
struct list_head fb_list;
 
+   /**
+* @num_connector: Number of connectors on this device.
+*/
int num_connector;
+   /**
+* @connector_ida: ID allocator for connector indices.
+*/
struct ida connector_ida;
+   /**
+* @connector_list: List of connector objects.
+*/
struct list_head connector_list;
 
/**
-- 
2.8.1

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

[Intel-gfx] [PATCH 11/11] drm/doc: Spinx leftovers

[Daniel Vetter]

This is unfortunately not all the sphinx noise when building the gpu
documentations. But the remaining warnings have completely bogus line
and probably also file sources, and I just can't find them.

Probably some serious debuggging of the line annotations in the
sphinx/kernel-doc toolchain needed first.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 490d655cda20..3bb26135971f 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -188,7 +188,8 @@ Manual IRQ Registration
 Drivers that require multiple interrupt handlers can't use the managed
 IRQ registration functions. In that case IRQs must be registered and
 unregistered manually (usually with the :c:func:`request_irq()` and
-:c:func:`free_irq()` functions, or their devm_\* equivalent).
+:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and
+:c:func:`devm_free_irq()` equivalents).
 
 When manually registering IRQs, drivers must not set the
 DRIVER_HAVE_IRQ driver feature flag, and must not provide the
@@ -242,11 +243,13 @@ Open/Close, File Operations and IOCTLs
 Open and Close
 --
 
-int (\*firstopen) (struct drm_device \*); void (\*lastclose) (struct
-drm_device \*); int (\*open) (struct drm_device \*, struct drm_file
-\*); void (\*preclose) (struct drm_device \*, struct drm_file \*);
-void (\*postclose) (struct drm_device \*, struct drm_file \*);
-Open and close handlers. None of those methods are mandatory.
+Open and close handlers. None of those methods are mandatory::
+
+int (*firstopen) (struct drm_device *);
+void (*lastclose) (struct drm_device *);
+int (*open) (struct drm_device *, struct drm_file *);
+void (*preclose) (struct drm_device *, struct drm_file *);
+void (*postclose) (struct drm_device *, struct drm_file *);
 
 The firstopen method is called by the DRM core for legacy UMS (User Mode
 Setting) drivers only when an application opens a device that has no
-- 
2.8.1

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

[Intel-gfx] [PATCH 08/11] drm/i915: Fixup kerneldoc code snippets in intel_uncore.c

[Daniel Vetter]

We need :: before, blank lines around and indentation with 4 _additional_
spaces to make it work. Also, don't use @param in code snippets, it results
in confusion.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_uncore.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index eeb4cbce19ff..43f833901b8e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1618,8 +1618,10 @@ static int gen6_reset_engines(struct drm_i915_private 
*dev_priv,
  * @timeout_ms: timeout in millisecond
  *
  * This routine waits until the target register @reg contains the expected
- * @value after applying the @mask, i.e. it waits until
- *   (I915_READ_FW(@reg) & @mask) == @value
+ * @value after applying the @mask, i.e. it waits until ::
+ *
+ * (I915_READ_FW(reg) & mask) == value
+ *
  * Otherwise, the wait will timeout after @timeout_ms milliseconds.
  *
  * Note that this routine assumes the caller holds forcewake asserted, it is
@@ -1652,8 +1654,10 @@ int intel_wait_for_register_fw(struct drm_i915_private 
*dev_priv,
  * @timeout_ms: timeout in millisecond
  *
  * This routine waits until the target register @reg contains the expected
- * @value after applying the @mask, i.e. it waits until
- *   (I915_READ(@reg) & @mask) == @value
+ * @value after applying the @mask, i.e. it waits until ::
+ *
+ * (I915_READ(reg) & mask) == value
+ *
  * Otherwise, the wait will timeout after @timeout_ms milliseconds.
  *
  * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
-- 
2.8.1

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

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

[Daniel Vetter]

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

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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Larry Finger]

On 07/15/2016 11:36 AM, Bish, Jim wrote:

On Fri, 2016-07-15 at 10:34 -0500, Larry Finger wrote:

On 07/15/2016 09:43 AM, Ville Syrjälä wrote:


On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:


On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
 wrote:


On Thu, 14 Jul 2016, Larry Finger wrote:


To anyone keeping track of regressions in kernel 4.7, I call
your attention to
https://bugs.freedesktop.org/show_bug.cgi?id=96675.

This bug causes driver i915 to fail to connect to the
display, and results in
a blank screen as soon as the kernel is loaded. The only way
to operate with
kernel 4.7 is to add "nomodeset" to the command line. The
problem was bisected
to commit f21a21983ef13a ("drm/i915: Splitting
intel_dp_detect").

Daniel? Jani? Time to revert?

Yup. Means that I'll get to revert a pile of patches (plus even
more
in -next), but that's what we get for not handling regressions
timely.
Dave poked me about the same bug already too. But will take a few
days
until the pull is in your inbox I guess.

I attached a oneliner to the bug today, that I *think* should fix
the
problem.

After I checked out the problem commit and built that kernel with the
one-line
patch, the display works; however, mainline still fails. I am
currently
bisecting to find what other commit fails. At a minimum, we should be
able to
reduce the number of commits that need reverting.

Larry

I was seeing the same issue Linus reported but very sporadically.
 Assumed it was due to my wierd configuration - eDP + usb type c -> MST
hub -> DVI KVM -> dual head HDMI.  Checked out the one liner - works
for me but I guess there are still other failures.


I'm not sure what I did wrong before, but when I retested mainline with the one 
liner, it now works. Once that is pushed to mainline, the bug should be fixed.


Sorry for any confusion.

Larry


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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Bish, Jim]

On Fri, 2016-07-15 at 10:34 -0500, Larry Finger wrote:
> On 07/15/2016 09:43 AM, Ville Syrjälä wrote:
> > 
> > On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
> > > 
> > > On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
> > >  wrote:
> > > > 
> > > > On Thu, 14 Jul 2016, Larry Finger wrote:
> > > > > 
> > > > > To anyone keeping track of regressions in kernel 4.7, I call
> > > > > your attention to
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=96675.
> > > > > 
> > > > > This bug causes driver i915 to fail to connect to the
> > > > > display, and results in
> > > > > a blank screen as soon as the kernel is loaded. The only way
> > > > > to operate with
> > > > > kernel 4.7 is to add "nomodeset" to the command line. The
> > > > > problem was bisected
> > > > > to commit f21a21983ef13a ("drm/i915: Splitting
> > > > > intel_dp_detect").
> > > > Daniel? Jani? Time to revert?
> > > Yup. Means that I'll get to revert a pile of patches (plus even
> > > more
> > > in -next), but that's what we get for not handling regressions
> > > timely.
> > > Dave poked me about the same bug already too. But will take a few
> > > days
> > > until the pull is in your inbox I guess.
> > I attached a oneliner to the bug today, that I *think* should fix
> > the
> > problem.
> After I checked out the problem commit and built that kernel with the
> one-line 
> patch, the display works; however, mainline still fails. I am
> currently 
> bisecting to find what other commit fails. At a minimum, we should be
> able to 
> reduce the number of commits that need reverting.
> 
> Larry
I was seeing the same issue Linus reported but very sporadically.
 Assumed it was due to my wierd configuration - eDP + usb type c -> MST
hub -> DVI KVM -> dual head HDMI.  Checked out the one liner - works
for me but I guess there are still other failures.

Jim
> 
> 
> 
> ___
> 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 11/17] drm/i915: Support to create write combined type vmaps

[Goel, Akash]

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


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

From: Chris Wilson 

vmaps has a provision for controlling the page protection bits, with
which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their mapping type, we add a parameter to
i915_gem_object_pin_map - but we still only allow one vmap to be cached
per object. If the object is currently not pinned, then we recreate the
previous vmap with the new access type, but if it was pinned we report an
error. This effectively limits the access via i915_gem_object_pin_map
to a
single mapping type for the lifetime of the object. Not usually a
problem,
but something to be aware of when setting up the object's vmap.

We will want to vary the access type to enable WC mappings of ringbuffer
and context objects on !llc platforms, as well as other objects where we
need coherent access to the GPU's pages without going through the GTT

v2: Remove the redundant braces around pin count check and fix the marker
 in documentation (Chris)

Signed-off-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.h|  4 ++-
  drivers/gpu/drm/i915/i915_gem.c| 57
+++---
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  2 +-
  drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  8 ++---
  drivers/gpu/drm/i915/intel_ringbuffer.c|  2 +-
  6 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 6e2ddfa..84afa17 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3248,6 +3248,7 @@ static inline void
i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
  /**
   * i915_gem_object_pin_map - return a contiguous mapping of the
entire object
   * @obj - the object to map into kernel address space
+ * @use_wc - whether the mapping should be using WC or WB pgprot_t
   *
   * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
   * pages and then returns a contiguous mapping of the backing
storage into
@@ -3259,7 +3260,8 @@ static inline void
i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
   * Returns the pointer through which to access the mapped object, or an
   * ERR_PTR() on error.
   */
-void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object
*obj);
+void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
+ bool use_wc);


Could you make it an enum instead of a bool? Commit message suggests
more modes will potentially be added and if so, and we start with an
enum straight away, it will make for less churn in the future.

func(something, true) is always also quite unreadabe in the code because
one has to remember or remind himself what it really means.

Something like func(something, MAP_WC) would be simply self-documenting.


Thanks nice suggestion, will do that.
enum only or macros also will do ?
#define MAP_CACHED  0x1
#define MAP_WC  0x2



  /**
   * i915_gem_object_unpin_map - releases an earlier mapping
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 8f50919..c431b40 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2471,10 +2471,11 @@ i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
  list_del(>global_list);

  if (obj->mapping) {
-if (is_vmalloc_addr(obj->mapping))
-vunmap(obj->mapping);
+void *ptr = (void *)((uintptr_t)obj->mapping & ~1);


How many bits we have to play with here? Is there a suitable define
somewhere we could use for a mask instead of hardcoded "1" or we could
add one if you think that would be better?


As Chris said, will use PAGE_MASK.




+if (is_vmalloc_addr(ptr))
+vunmap(ptr);
  else
-kunmap(kmap_to_page(obj->mapping));
+kunmap(kmap_to_page(ptr));
  obj->mapping = NULL;
  }

@@ -2647,7 +2648,8 @@ i915_gem_object_get_pages(struct
drm_i915_gem_object *obj)
  }

  /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj,
+bool use_wc)
  {
  unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
  struct sg_table *sgt = obj->pages;
@@ -2659,7 +2661,7 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj)
  void *addr;

  /* A single page can always be kmapped */
-if (n_pages == 1)
+if (n_pages == 1 && !use_wc)
  return kmap(sg_page(sgt->sgl));

  if (n_pages > ARRAY_SIZE(stack_pages)) {
@@ -2675,7 +2677,8 @@ static void *i915_gem_object_map(const struct

Re: [Intel-gfx] [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce flush interrupts

[Goel, Akash]

On 7/15/2016 8:37 PM, Tvrtko Ursulin wrote:


On 15/07/16 15:42, Goel, Akash wrote:

On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 1de6928..7521ed5 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -104,9 +104,9 @@
  #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
  #define   GUC_LOG_CRASH_PAGES1
  #define   GUC_LOG_CRASH_SHIFT4
-#define   GUC_LOG_DPC_PAGES3
+#define   GUC_LOG_DPC_PAGES7
  #define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_ISR_PAGES3
+#define   GUC_LOG_ISR_PAGES7
  #define   GUC_LOG_ISR_SHIFT9
  #define   GUC_LOG_BUF_ADDR_SHIFT12

@@ -436,9 +436,9 @@ enum guc_log_buffer_type {
   *|   Crash dump state header |
   * Page1  +---+
   *|   ISR logs|
- * Page5  +---+
- *|   DPC logs|
   * Page9  +---+
+ *|   DPC logs|
+ * Page17 +---+
   *| Crash Dump logs   |
   *+---+
   *



I don't mind - but does it help? And how much and for what? Haven't you
later found that the uncached reads were the main issue?

This change along with kthread patch, helped reduce the overflow counts
and even eliminate them for some benchmarks.

Though with the impending optimization for Uncached reads there should
be further improvements but in my view, notwithstanding the improvement
w.r.t overflow count, its still a better configuration to work with as
flush interrupt frequency is cut down to half and not able to see any
apparent downsides to it.


I was primarily thinking to go with a minimal and simplest set of
patches to implement the feature.


I second that and working with the same intent.


Logic was that apparently none of the smart and complex optimisations
managed to solve the dropped interrupt issue, until the slowness of the
uncached read was discovered to be the real/main issue.

So it seems that is something that definitely needs to be implemented.
(Whether or not it will be possible to use SSE instructions to do the
read I don't know.)



log buffer resizing and rt priority kthread changes have definitely 
helped significantly.


Only of late we realized that there is a potential way to speed up 
Uncached reads also. Moreover I am yet to test that on kernel side.
So until that is tested & proves to be enough, we have to rely on the 
other optimizations & can't dismiss them



Assuming it is possible, then the question is whether there is need for
all the other optimisations. Ie. do we need the kthread with rtprio or
would a simple worker be enough?
I think we can take a call, once we have the results with Uncached read 
optimization.



Do we need the new i915 param for tweaking the relay sub-buffers?

In my opinion it will be really useful to have this provision, as I
tried to explain in the other mail.


Do we need the increase of the log buffer size?
Though this seems to be a benign change which is definitely good to 
have, but again can decide upon it once we have the results.


The extra patch to do smarter reads?


If we do not have the issue of the dropped interrupts with none of these
extra patches applied, then we could afford to not bother with them now.
Would make the series shorter and review easier and the feature in quicker.


Agree with you.
Had none of these optimizations in the initial version of the series, 
but was compelled to add them later when realized the rate at which GuC 
was generating the logs.


Best regards
Akash


Or maybe we do need all the advanced stuff, I don't know, I am just
asking the question and would like to see some data.

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

[Bob Paauwe]

On Fri, 15 Jul 2016 14:59:02 +0100
Lionel Landwerlin  wrote:

> From: Bob Paauwe 
> 
> The i915 driver is now using atomic properties and atomic commit
> to handle the legacy set gamma IOCTL. However, if the driver is
> configured without atomic (nuclear_pageflip = false), it won't
> update the legacy properties for degamma_lut, gamma_lut and ctm
> leaving them out of sync with the atomic version of the properties.
> 
> Until the driver is full atomic, make sure we update the non-atomic
> version of the properties.
> 
> v2: Update the comment with a FIXME.  (Daniel)
> 
> v3: Update arguments of the gamma_set vfunc (Lionel)
> 
> v4: Fixed vfunc prototype (Lionel)

Lionel,

The changes looks correct to me, thanks!  Is it appropriate for me to
add a reviewed-by for those changes?  

Bob

> 
> igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Signed-off-by: Bob Paauwe 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 44 
> +++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9337d3a..fb7d8fc5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13924,8 +13924,50 @@ out:
>  
>  #undef for_each_intel_crtc_masked
>  
> +/*
> + * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
> + *drm_atomic_helper_legacy_gamma_set() directly.
> + */
> +static int intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
> +  u16 *red, u16 *green, u16 *blue,
> +  uint32_t size)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> + struct drm_crtc_state *state;
> + int ret;
> +
> + ret = drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, size);
> + if (ret)
> + return ret;
> +
> + /*
> +  * Make sure we update the legacy properties so this works when
> +  * atomic is not enabled.
> +  */
> +
> + state = crtc->state;
> +
> + drm_object_property_set_value(>base,
> +   config->degamma_lut_property,
> +   (state->degamma_lut) ?
> +   state->degamma_lut->base.id : 0);
> +
> + drm_object_property_set_value(>base,
> +   config->ctm_property,
> +   (state->ctm) ?
> +   state->ctm->base.id : 0);
> +
> + drm_object_property_set_value(>base,
> +   config->gamma_lut_property,
> +   (state->gamma_lut) ?
> +   state->gamma_lut->base.id : 0);
> +
> + return 0;
> +}
> +
>  static const struct drm_crtc_funcs intel_crtc_funcs = {
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
> + .gamma_set = intel_atomic_legacy_gamma_set,
>   .set_config = drm_atomic_helper_set_config,
>   .set_property = drm_atomic_helper_crtc_set_property,
>   .destroy = intel_crtc_destroy,



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH 14/17] drm/i915: Add stats for GuC log buffer flush interrupts

[Goel, Akash]

On 7/15/2016 5:21 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

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

Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 26
++
  drivers/gpu/drm/i915/i915_guc_submission.c |  8 
  drivers/gpu/drm/i915/i915_irq.c|  1 +
  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
  4 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3c9c7f7..888a18a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2538,6 +2538,30 @@ static int i915_guc_load_status_info(struct
seq_file *m, void *data)
  return 0;
  }

+static void i915_guc_log_info(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+struct intel_guc *guc = _priv->guc;
+
+seq_printf(m, "\nGuC logging stats:\n");
+
+seq_printf(m, "\tISR:   flush count %10u, overflow count %8u\n",
+guc->log.flush_count[GUC_ISR_LOG_BUFFER],
+guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
+
+seq_printf(m, "\tDPC:   flush count %10u, overflow count %8u\n",
+guc->log.flush_count[GUC_DPC_LOG_BUFFER],
+guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
+
+seq_printf(m, "\tCRASH: flush count %10u, overflow count %8u\n",
+guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
+guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+
+seq_printf(m, "\tTotal flush interrupt count: %u\n",
+guc->log.flush_interrupt_count);
+
+}
+
  static void i915_guc_client_info(struct seq_file *m,
   struct drm_i915_private *dev_priv,
   struct i915_guc_client *client)
@@ -2611,6 +2635,8 @@ static int i915_guc_info(struct seq_file *m,
void *data)
  seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
  i915_guc_client_info(m, dev_priv, );

+i915_guc_log_info(m, dev_priv);
+
  /* Add more as required ... */

  return 0;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c1e637f..9c94a43 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -914,6 +914,14 @@ static void guc_read_update_log_buffer(struct
drm_device *dev)
  log_buffer_state_local = *log_buffer_state;
  buffer_size = log_buffer_state_local.size;

+guc->log.flush_count[i] += log_buffer_state_local.flush_to_file;
+if (log_buffer_state_local.buffer_full_cnt !=
+guc->log.prev_overflow_count[i]) {
+guc->log.prev_overflow_count[i] =
+log_buffer_state_local.buffer_full_cnt;
+guc->log.total_overflow_count[i]++;


Is log_buffer_state_local.buffer_full_cnt guaranteed to be one here? Or
you would need to increase total_overflow_count by its value?



buffer_full_cnt will not remain as one. Its a 4 bit counter, will be 
incremented monotonically by GuC firmware on every new detection of 
overflow, so will increase from 0 to 15 & then wrap around.

Hence have to use '!=' in the condition instead of '>'.

Best regards
Akash


+}
+
  if (log_buffer_copy_state) {
  /* First copy the state structure */
  memcpy(log_buffer_copy_state, _buffer_state_local,
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index bdd7a67..c3fb67e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1711,6 +1711,7 @@ static void gen9_guc_irq_handler(struct
drm_i915_private *dev_priv, u32 gt_iir)
  _priv->guc.events_work);
  }
  }
+dev_priv->guc.log.flush_interrupt_count++;
  spin_unlock(_priv->irq_lock);
  }
  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 611f4a7..e911a32 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -128,6 +128,12 @@ struct intel_guc_log {
  struct workqueue_struct *wq;
  void *buf_addr;
  struct rchan *relay_chan;
+
+/* logging related stats */
+u32 flush_interrupt_count;
+u32 prev_overflow_count[GUC_MAX_LOG_BUFFER];
+u32 total_overflow_count[GUC_MAX_LOG_BUFFER];
+u32 flush_count[GUC_MAX_LOG_BUFFER];
  };

  struct intel_guc {



Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 13/17] drm/i915: New lock to serialize the Host2GuC actions

[Goel, Akash]

On 7/15/2016 5:10 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

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


After which patch in this series is this required?

From patch 6 or 7 saw the problem, when enabled flush interrupts from 
boot (guc_log_level >= 0).


Also new HOST2GUC actions LOG_BUFFER_FILE_FLUSH_COMPLETE & 
UK_LOG_ENABLE_LOGGING can execute concurrently with each other.




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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6043166..c1e637f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -88,6 +88,7 @@ static int host2guc_action(struct intel_guc *guc,
u32 *data, u32 len)
  return -EINVAL;

  intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+spin_lock(>action_lock);


The code below can sleep waiting for a response from GuC so you cannot
use a spinlock. Mutex I suppose...


Sorry I missed the sleep.
Probably I did not see any problem, in spite of a spinlock, as _wait_for 
macro does not sleep when used in atomic context, does a busy wait instead.


Best Regards
Akash





  dev_priv->guc.action_count += 1;
  dev_priv->guc.action_cmd = data[0];
@@ -126,6 +127,7 @@ static int host2guc_action(struct intel_guc *guc,
u32 *data, u32 len)
  }
  dev_priv->guc.action_status = status;

+spin_unlock(>action_lock);
  intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);

  return ret;
@@ -1304,6 +1306,7 @@ int i915_guc_submission_init(struct
drm_i915_private *dev_priv)
  return -ENOMEM;

  ida_init(>ctx_ids);
+spin_lock_init(>action_lock);


I think this should go to guc_client_alloc which is where the guc client
object is allocated and initialized.


  guc_create_log(guc);
  guc_create_ads(guc);

diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index d56bde6..611f4a7 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -157,6 +157,9 @@ struct intel_guc {

  uint64_t submissions[I915_NUM_ENGINES];
  uint32_t last_seqno[I915_NUM_ENGINES];
+
+/* To serialize the Host2GuC actions */
+spinlock_t action_lock;
  };

  /* intel_guc_loader.c */



Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 10/17] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

[Goel, Akash]

On 7/15/2016 4:45 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Driver store, up to, 4 snapshots
of the log buffer in a local buffer (managed by relay).
Added a new module (read only) param, 'guc_log_size', through which User
can specify the number of snapshots of log buffer to be stored in local
buffer. This can be used to ensure capturing of all boot time logs even
with high verbosity level.

v2: Rename module param to more apt name 'guc_log_buffer_nr'. (Nikula)

Suggested-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
  drivers/gpu/drm/i915/i915_params.c | 5 +
  drivers/gpu/drm/i915/i915_params.h | 1 +
  3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2e3b723..009d7c0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1046,8 +1046,7 @@ static int guc_create_log_relay_file(struct
intel_guc *guc)

  /* Keep the size of sub buffers same as shared log buffer */
  subbuf_size = guc->log.obj->base.size;
-/* TODO: Decide based on the User's input */
-n_subbufs = 4;
+n_subbufs = i915.guc_log_buffer_nr;

  guc_log_relay_chan = relay_open("guc_log", log_dir,
  subbuf_size, n_subbufs, _callbacks, dev);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 8b13bfa..d30c972 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -57,6 +57,7 @@ struct i915_params i915 __read_mostly = {
  .enable_guc_loading = -1,
  .enable_guc_submission = -1,
  .guc_log_level = -1,
+.guc_log_buffer_nr = 4,
  .enable_dp_mst = true,
  .inject_load_failure = 0,
  .enable_dpcd_backlight = false,
@@ -214,6 +215,10 @@ module_param_named(guc_log_level,
i915.guc_log_level, int, 0400);
  MODULE_PARM_DESC(guc_log_level,
  "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");

+module_param_named(guc_log_buffer_nr, i915.guc_log_buffer_nr, int,
0400);
+MODULE_PARM_DESC(guc_log_buffer_nr,
+"Number of sub buffers to store GuC firmware logs (default: 4)");
+
  module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool,
0600);
  MODULE_PARM_DESC(enable_dp_mst,
  "Enable multi-stream transport (MST) for new DisplayPort sinks.
(default: true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 0ad020b..14ca855 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,6 +48,7 @@ struct i915_params {
  int enable_guc_loading;
  int enable_guc_submission;
  int guc_log_level;
+int guc_log_buffer_nr;
  int use_mmio_flip;
  int mmio_debug;
  int edp_vswing;



I did not figure out after a quick read of
Documentation/filesystems/relay.txt whether we really need this to be
configurable?

If I got it right number of sub-buffers here only has a relation to the
userspace relay consumer latency. If the userspace is responsive should
just two be enough? Or the existing default of four was shown in
practice that it is better and good enough?

Yes one of the use of this module parameter is to give User some leeway 
i.e. more time to collect logs from the relay buffer. User may not be 
always able to match the rate at which logs are being produced from the 
GuC side.


2 could be too less.
Even 4, when running a benchmark, was proving less and not able to match 
the Driver rate (this might change after some optimization is done from 
User space side also, like splice).


The other use is to ensure capturing of all boot time logs, even with 
maximum verbosity level. The default number of sub buffers may not 
always be sufficient to store all the logs from boot, by the time User 
is ready to capture the logs.

Saw about 8 flush interrupts coming from GuC during the boot.


I am just not sure this is a useful module parameter without some more
data.

Even if it is needed, as minimum I think the name should reflect this is
about the relay side of things and not the GuC log buffer itself. So
something like i915.guc_relay_log_subbuf_nr or something.

Fine will use this name.


With the matching description of course.


Is the current description not apt ?
"Number of sub buffers to store GuC firmware logs (default: 4)");"

Best regards
Akash


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

[Marius Vlad]

So, the issue is that i-g-t will not build on our builder system, with
the current version of librm-intel. It just happens to work because I
took the liberity of upgrading the entire system, a while ago.

No build, no newer i-g-t, no tests, no CI.

There are a few of _PINNED macros defined by Chris all over the
gem tests. Thought of doing just that, figured it would be better to
bump the library instead.

On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote:
> Hi Marius,
> 
> Just double-checking - this is an i-g-t patch, isn't it ?

Sorry, my bad!

> 
> On 14 July 2016 at 11:39, Marius Vlad  wrote:
> > Required by commit 2603b98ca (aubdump: Support softpin bos).
> >
> > Signed-off-by: Marius Vlad 
> > CC: Kristian Høgsberg Kristensen 
> > ---
> >  configure.ac | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index f05bcb0..ade9756 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -119,7 +119,7 @@ if test "x$GCC" = "xyes"; then
> >  fi
> >  AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> >
> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.64 libdrm])
> > +PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.68 libdrm])
> Yes please. As you do that one can nuke most/all the "define LOCAL_"
> and "struct local_" (in lib/ioctl_wrappers.h)
> and replace with with the official symbols. A very nice plus imho ;-)
> 
> Side note: this will conflict with Robert Foss's work to make
> libdrm_intel an optional dependency. Have you/others had the chance to
> look at the series ? What can we do to get that moving/accepted ?

Yes I've seen them. Someone to Ack'em :-).

> 
> Thanks
> Emil


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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Larry Finger]

On 07/15/2016 09:43 AM, Ville Syrjälä wrote:

On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:

On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
 wrote:

On Thu, 14 Jul 2016, Larry Finger wrote:

To anyone keeping track of regressions in kernel 4.7, I call your attention to
https://bugs.freedesktop.org/show_bug.cgi?id=96675.

This bug causes driver i915 to fail to connect to the display, and results in
a blank screen as soon as the kernel is loaded. The only way to operate with
kernel 4.7 is to add "nomodeset" to the command line. The problem was bisected
to commit f21a21983ef13a ("drm/i915: Splitting intel_dp_detect").


Daniel? Jani? Time to revert?


Yup. Means that I'll get to revert a pile of patches (plus even more
in -next), but that's what we get for not handling regressions timely.
Dave poked me about the same bug already too. But will take a few days
until the pull is in your inbox I guess.


I attached a oneliner to the bug today, that I *think* should fix the
problem.


After I checked out the problem commit and built that kernel with the one-line 
patch, the display works; however, mainline still fails. I am currently 
bisecting to find what other commit fails. At a minimum, we should be able to 
reduce the number of commits that need reverting.


Larry



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

Re: [Intel-gfx] [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce flush interrupts

[Tvrtko Ursulin]

On 15/07/16 15:42, Goel, Akash wrote:

On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 1de6928..7521ed5 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -104,9 +104,9 @@
  #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
  #define   GUC_LOG_CRASH_PAGES1
  #define   GUC_LOG_CRASH_SHIFT4
-#define   GUC_LOG_DPC_PAGES3
+#define   GUC_LOG_DPC_PAGES7
  #define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_ISR_PAGES3
+#define   GUC_LOG_ISR_PAGES7
  #define   GUC_LOG_ISR_SHIFT9
  #define   GUC_LOG_BUF_ADDR_SHIFT12

@@ -436,9 +436,9 @@ enum guc_log_buffer_type {
   *|   Crash dump state header |
   * Page1  +---+
   *|   ISR logs|
- * Page5  +---+
- *|   DPC logs|
   * Page9  +---+
+ *|   DPC logs|
+ * Page17 +---+
   *| Crash Dump logs   |
   *+---+
   *



I don't mind - but does it help? And how much and for what? Haven't you
later found that the uncached reads were the main issue?

This change along with kthread patch, helped reduce the overflow counts
and even eliminate them for some benchmarks.

Though with the impending optimization for Uncached reads there should
be further improvements but in my view, notwithstanding the improvement
w.r.t overflow count, its still a better configuration to work with as
flush interrupt frequency is cut down to half and not able to see any
apparent downsides to it.


I was primarily thinking to go with a minimal and simplest set of 
patches to implement the feature.


Logic was that apparently none of the smart and complex optimisations 
managed to solve the dropped interrupt issue, until the slowness of the 
uncached read was discovered to be the real/main issue.


So it seems that is something that definitely needs to be implemented. 
(Whether or not it will be possible to use SSE instructions to do the 
read I don't know.)


Assuming it is possible, then the question is whether there is need for 
all the other optimisations. Ie. do we need the kthread with rtprio or 
would a simple worker be enough? Do we need the new i915 param for 
tweaking the relay sub-buffers? Do we need the increase of the log 
buffer size? The extra patch to do smarter reads?


If we do not have the issue of the dropped interrupts with none of these 
extra patches applied, then we could afford to not bother with them now. 
Would make the series shorter and review easier and the feature in quicker.


Or maybe we do need all the advanced stuff, I don't know, I am just 
asking the question and would like to see some data.


Regards,

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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Larry Finger]

On 07/15/2016 09:43 AM, Ville Syrjälä wrote:

On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:

On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
 wrote:

On Thu, 14 Jul 2016, Larry Finger wrote:

To anyone keeping track of regressions in kernel 4.7, I call your attention to
https://bugs.freedesktop.org/show_bug.cgi?id=96675.

This bug causes driver i915 to fail to connect to the display, and results in
a blank screen as soon as the kernel is loaded. The only way to operate with
kernel 4.7 is to add "nomodeset" to the command line. The problem was bisected
to commit f21a21983ef13a ("drm/i915: Splitting intel_dp_detect").


Daniel? Jani? Time to revert?


Yup. Means that I'll get to revert a pile of patches (plus even more
in -next), but that's what we get for not handling regressions timely.
Dave poked me about the same bug already too. But will take a few days
until the pull is in your inbox I guess.


I attached a oneliner to the bug today, that I *think* should fix the
problem.


Unfortunately, that patch did not help. If you have any other patches, or a repo 
I can pull from for testing, please let me know.


Larry


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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Ville Syrjälä]

On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
>  wrote:
> > On Thu, 14 Jul 2016, Larry Finger wrote:
> >> To anyone keeping track of regressions in kernel 4.7, I call your 
> >> attention to
> >> https://bugs.freedesktop.org/show_bug.cgi?id=96675.
> >>
> >> This bug causes driver i915 to fail to connect to the display, and results 
> >> in
> >> a blank screen as soon as the kernel is loaded. The only way to operate 
> >> with
> >> kernel 4.7 is to add "nomodeset" to the command line. The problem was 
> >> bisected
> >> to commit f21a21983ef13a ("drm/i915: Splitting intel_dp_detect").
> >
> > Daniel? Jani? Time to revert?
> 
> Yup. Means that I'll get to revert a pile of patches (plus even more
> in -next), but that's what we get for not handling regressions timely.
> Dave poked me about the same bug already too. But will take a few days
> until the pull is in your inbox I guess.

I attached a oneliner to the bug today, that I *think* should fix the
problem.

-- 
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 15/17] drm/i915: Increase GuC log buffer size to reduce flush interrupts

[Goel, Akash]

On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:


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

From: Akash Goel 

In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 1de6928..7521ed5 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -104,9 +104,9 @@
  #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
  #define   GUC_LOG_CRASH_PAGES1
  #define   GUC_LOG_CRASH_SHIFT4
-#define   GUC_LOG_DPC_PAGES3
+#define   GUC_LOG_DPC_PAGES7
  #define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_ISR_PAGES3
+#define   GUC_LOG_ISR_PAGES7
  #define   GUC_LOG_ISR_SHIFT9
  #define   GUC_LOG_BUF_ADDR_SHIFT12

@@ -436,9 +436,9 @@ enum guc_log_buffer_type {
   *|   Crash dump state header |
   * Page1  +---+
   *|   ISR logs|
- * Page5  +---+
- *|   DPC logs|
   * Page9  +---+
+ *|   DPC logs|
+ * Page17 +---+
   *| Crash Dump logs   |
   *+---+
   *



I don't mind - but does it help? And how much and for what? Haven't you
later found that the uncached reads were the main issue?
This change along with kthread patch, helped reduce the overflow counts 
and even eliminate them for some benchmarks.


Though with the impending optimization for Uncached reads there should 
be further improvements but in my view, notwithstanding the improvement 
w.r.t overflow count, its still a better configuration to work with as 
flush interrupt frequency is cut down to half and not able to see any 
apparent downsides to it.


Best Regards
Akash


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 [CI,1/2] drm/i915/evict: Always switch away from the current context

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/evict: Always switch away from 
the current context
URL   : https://patchwork.freedesktop.org/series/9932/
State : failure

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-i7-4770k)
dmesg-warn -> PASS   (ro-bdw-i7-5557U)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-hsw-i7-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
fail   -> PASS   (ro-byt-n2820)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-snb-i7-2600)

fi-hsw-i7-4770k  total:207  pass:188  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-qkkr  total:241  pass:175  dwarn:27  dfail:2   fail:7   skip:30 
fi-skl-i5-6260u  total:241  pass:216  dwarn:0   dfail:0   fail:7   skip:18 
fi-skl-i7-6700k  total:241  pass:204  dwarn:0   dfail:0   fail:7   skip:30 
fi-snb-i7-2600   total:241  pass:190  dwarn:0   dfail:0   fail:7   skip:44 
ro-bdw-i5-5250u  total:242  pass:214  dwarn:4   dfail:0   fail:7   skip:17 
ro-bdw-i7-5557U  total:242  pass:215  dwarn:0   dfail:0   fail:7   skip:20 
ro-bdw-i7-5600u  total:242  pass:200  dwarn:0   dfail:0   fail:7   skip:35 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:242  pass:191  dwarn:0   dfail:0   fail:9   skip:42 
ro-hsw-i3-4010u  total:242  pass:206  dwarn:0   dfail:0   fail:8   skip:28 
ro-hsw-i7-4770r  total:242  pass:205  dwarn:0   dfail:0   fail:9   skip:28 
ro-ilk-i7-620lm  total:242  pass:166  dwarn:0   dfail:0   fail:9   skip:67 
ro-ilk1-i5-650   total:237  pass:166  dwarn:0   dfail:0   fail:9   skip:62 
ro-ivb-i7-3770   total:242  pass:197  dwarn:0   dfail:0   fail:8   skip:37 
ro-skl3-i5-6260u total:242  pass:218  dwarn:1   dfail:0   fail:7   skip:16 
ro-snb-i7-2620M  total:242  pass:188  dwarn:0   dfail:0   fail:9   skip:45 
fi-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1505/

26b8bdb drm-intel-nightly: 2016y-07m-15d-12h-47m-23s UTC integration manifest
e2d536a drm/i915: Flush logical context image out to memory upon suspend
bd36e98 drm/i915/evict: Always switch away from the current context

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

Re: [Intel-gfx] Critical regression in 4.7-rcX

[Daniel Vetter]

On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
 wrote:
> On Thu, 14 Jul 2016, Larry Finger wrote:
>> To anyone keeping track of regressions in kernel 4.7, I call your attention 
>> to
>> https://bugs.freedesktop.org/show_bug.cgi?id=96675.
>>
>> This bug causes driver i915 to fail to connect to the display, and results in
>> a blank screen as soon as the kernel is loaded. The only way to operate with
>> kernel 4.7 is to add "nomodeset" to the command line. The problem was 
>> bisected
>> to commit f21a21983ef13a ("drm/i915: Splitting intel_dp_detect").
>
> Daniel? Jani? Time to revert?

Yup. Means that I'll get to revert a pile of patches (plus even more
in -next), but that's what we get for not handling regressions timely.
Dave poked me about the same bug already too. But will take a few days
until the pull is in your inbox I guess.
-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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915:gen9: restrict WaC6DisallowByGfxPause

[Patchwork]

== Series Details ==

Series: drm/i915:gen9: restrict WaC6DisallowByGfxPause
URL   : https://patchwork.freedesktop.org/series/9930/
State : failure

== Summary ==

Series 9930v1 drm/i915:gen9: restrict WaC6DisallowByGfxPause
http://patchwork.freedesktop.org/api/1.0/series/9930/revisions/1/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-i7-4770k)
dmesg-warn -> PASS   (ro-bdw-i7-5557U)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
fail   -> PASS   (ro-byt-n2820)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-skl-i7-6700k)

fi-hsw-i7-4770k  total:241  pass:210  dwarn:0   dfail:0   fail:7   skip:24 
fi-kbl-qkkr  total:241  pass:174  dwarn:26  dfail:1   fail:9   skip:31 
fi-skl-i5-6260u  total:241  pass:218  dwarn:0   dfail:0   fail:7   skip:16 
fi-skl-i7-6700k  total:195  pass:170  dwarn:0   dfail:0   fail:0   skip:24 
fi-snb-i7-2600   total:195  pass:162  dwarn:0   dfail:0   fail:0   skip:32 
ro-bdw-i5-5250u  total:242  pass:214  dwarn:4   dfail:0   fail:7   skip:17 
ro-bdw-i7-5557U  total:242  pass:215  dwarn:0   dfail:0   fail:7   skip:20 
ro-bdw-i7-5600u  total:242  pass:200  dwarn:0   dfail:0   fail:7   skip:35 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:242  pass:191  dwarn:0   dfail:0   fail:9   skip:42 
ro-hsw-i3-4010u  total:242  pass:206  dwarn:0   dfail:0   fail:8   skip:28 
ro-hsw-i7-4770r  total:242  pass:206  dwarn:0   dfail:0   fail:8   skip:28 
ro-ilk-i7-620lm  total:242  pass:166  dwarn:0   dfail:0   fail:9   skip:67 
ro-ilk1-i5-650   total:237  pass:166  dwarn:0   dfail:0   fail:9   skip:62 
ro-ivb-i7-3770   total:242  pass:197  dwarn:0   dfail:0   fail:8   skip:37 
ro-skl3-i5-6260u total:242  pass:218  dwarn:1   dfail:0   fail:7   skip:16 
ro-snb-i7-2620M  total:242  pass:188  dwarn:0   dfail:0   fail:9   skip:45 
fi-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1504/

26b8bdb drm-intel-nightly: 2016y-07m-15d-12h-47m-23s UTC integration manifest
cc07d00 drm/i915:gen9: restrict WaC6DisallowByGfxPause

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

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

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 tests/Makefile.sources   |2 +-
 tests/kms_pipe_color.c   | 1184 --
 tests/kms_pipe_color_basic.c | 1184 ++
 3 files changed, 1185 insertions(+), 1185 deletions(-)
 delete mode 100644 tests/kms_pipe_color.c
 create mode 100644 tests/kms_pipe_color_basic.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 8a9a7ec..53afe3c 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -98,7 +98,7 @@ TESTS_progs_M = \
kms_legacy_colorkey \
kms_mmio_vs_cs_flip \
kms_pipe_b_c_ivb \
-   kms_pipe_color \
+   kms_pipe_color_basic \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
deleted file mode 100644
index 9f7ac7e..000
--- a/tests/kms_pipe_color.c
+++ /dev/null
@@ -1,1184 +0,0 @@
-/*
- * Copyright © 2015 Intel Corporation
- *
-  * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- */
-
-#include 
-#include 
-
-#include "drm.h"
-#include "drmtest.h"
-#include "igt.h"
-
-IGT_TEST_DESCRIPTION("Test Color Features at Pipe level");
-
-/* Data structures for gamma/degamma ramps & ctm matrix. */
-struct _drm_color_ctm {
-   /* Transformation matrix in S31.32 format. */
-   __s64 matrix[9];
-};
-
-struct _drm_color_lut {
-   /*
-* Data is U0.16 fixed point format.
-*/
-   __u16 red;
-   __u16 green;
-   __u16 blue;
-   __u16 reserved;
-};
-
-/* Internal */
-typedef struct {
-   double r, g, b;
-} color_t;
-
-typedef struct {
-   int drm_fd;
-   uint32_t devid;
-   igt_display_t display;
-   igt_pipe_crc_t *pipe_crc;
-
-   uint32_t color_depth;
-   uint64_t degamma_lut_size;
-   uint64_t gamma_lut_size;
-} data_t;
-
-
-static void paint_gradient_rectangles(data_t *data,
- drmModeModeInfo *mode,
- color_t *colors,
- struct igt_fb *fb)
-{
-   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
-   int i, l = mode->hdisplay / 3;
-
-   /* Paint 3 gradient rectangles with red/green/blue between 1.0 and
-* 0.5. We want to avoid 0 so each max LUTs only affect their own
-* rectangle.
-*/
-   for (i = 0 ; i < 3; i++) {
-   igt_paint_color_gradient_range(cr, i * l, 0, l, mode->vdisplay,
-  colors[i].r != 0 ? 0.2 : 0,
-  colors[i].g != 0 ? 0.2 : 0,
-  colors[i].b != 0 ? 0.2 : 0,
-  colors[i].r,
-  colors[i].g,
-  colors[i].b);
-   }
-
-   cairo_destroy(cr);
-}
-
-static void paint_rectangles(data_t *data,
-drmModeModeInfo *mode,
-color_t *colors,
-struct igt_fb *fb)
-{
-   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
-   int i, l = mode->hdisplay / 3;
-
-   /* Paint 3 solid rectangles. */
-   for (i = 0 ; i < 3; i++) {
-   igt_paint_color(cr, i * l, 0, l, mode->vdisplay,
-   colors[i].r, colors[i].g, colors[i].b);
-   }
-
-   cairo_destroy(cr);
-}
-
-static double *generate_table(uint32_t lut_size, double exp)
-{
-   double *coeffs = malloc(sizeof(double) * lut_size);
-   uint32_t i;
-
-   for (i = 0; i < lut_size; i++)
-   coeffs[i] = powf((double) i * 1.0 / (double) (lut_size - 1), 
exp);
-
-   return coeffs;
-}
-
-static double *generate_table_max(uint32_t lut_size)
-{
-   double *coeffs = 

[Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

[Lionel Landwerlin]

From: Bob Paauwe 

The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

v2: Update the comment with a FIXME.  (Daniel)

v3: Update arguments of the gamma_set vfunc (Lionel)

v4: Fixed vfunc prototype (Lionel)

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Signed-off-by: Bob Paauwe 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_display.c | 44 +++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9337d3a..fb7d8fc5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13924,8 +13924,50 @@ out:
 
 #undef for_each_intel_crtc_masked
 
+/*
+ * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
+ *drm_atomic_helper_legacy_gamma_set() directly.
+ */
+static int intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+u16 *red, u16 *green, u16 *blue,
+uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_crtc_state *state;
+   int ret;
+
+   ret = drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, size);
+   if (ret)
+   return ret;
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(>base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+
+   return 0;
+}
+
 static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,
-- 
2.8.1

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

[Intel-gfx] [CI 2/2] drm/i915: Flush logical context image out to memory upon suspend

[Chris Wilson]

Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will be complete. This leaves the kernel_context image as
incomplete, but fortunately that is disposable and we can do a quick
fixup of the logical state after resuming.

v2: Share the nearly identical code to switch to the kernel context with
eviction.
v3: Explain why we need the switch and reset.

Testcase: igt/gem_exec_suspend # bsw
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Tested-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 +---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 35 +++
 3 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15440123e38d..c5b7b8e0678a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_csr_ucode_resume(dev_priv);
 
-   mutex_lock(>struct_mutex);
-   i915_gem_restore_gtt_mappings(dev);
-   mutex_unlock(>struct_mutex);
+   i915_gem_resume(dev);
 
i915_restore_state(dev);
intel_opregion_setup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd1ccc47ee8b..27d9b2c374b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
 int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_suspend(struct drm_device *dev);
+void i915_gem_resume(struct drm_device *dev);
 void __i915_add_request(struct drm_i915_gem_request *req,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf0e8aa8035c..4644a7e67cf6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4983,12 +4983,30 @@ i915_gem_suspend(struct drm_device *dev)
intel_suspend_gt_powersave(dev_priv);
 
mutex_lock(>struct_mutex);
+
+   /* We have to flush all the executing contexts to main memory so
+* that they can saved in the hibernation image. To ensure the last
+* context image is coherent, we have to switch away from it. That
+* leaves the dev_priv->kernel_context still active when
+* we actually suspend, and its image in memory may not match the GPU
+* state. Fortunately, the kernel_context is disposable and we do
+* not rely on its state.
+*/
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err;
+
ret = i915_gem_wait_for_idle(dev_priv);
if (ret)
goto err;
 
i915_gem_retire_requests(dev_priv);
 
+   /* Note that rather than stopping the engines, all we have to do
+* is assert that every RING_HEAD == RING_TAIL (all execution complete)
+* and similar for all logical context images (to ensure they are
+* all ready for hibernation).
+*/
i915_gem_stop_engines(dev);
i915_gem_context_lost(dev_priv);
mutex_unlock(>struct_mutex);
@@ -5009,6 +5027,23 @@ err:
return ret;
 }
 
+void i915_gem_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   mutex_lock(>struct_mutex);
+   i915_gem_restore_gtt_mappings(dev);
+
+   /* As we didn't flush the kernel context before suspend, we cannot
+* guarantee that the context image is complete. So let's just reset
+* it and start again.
+*/
+   if (i915.enable_execlists)
+   intel_lr_context_reset(dev_priv, dev_priv->kernel_context);
+
+   mutex_unlock(>struct_mutex);
+}
+
 void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.8.1

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

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

[tim . gore]

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))
+   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
 
if (IS_BROXTON(dev))
I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);
-- 
1.9.1

___
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/evict: Always switch away from the current context

[Mika Kuoppala]

Chris Wilson  writes:

> Currently execlists is exempt from emitting a request to switch each
> ring away from the current context over to the dev_priv->kernel_context
> (for whatever reason, just under execlists the GGTT is unlikely to be as
> fragmented, however the switch may help in some extreme cases). Extract
> the switcher and enable it for execlsts as well, as we need to do so in
> a later patch to force the context switch before suspend. (And since for
> that switch we explicitly require the disposable kernel context, rename
> the extracted function.)
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem_context.c | 29 +++
>  drivers/gpu/drm/i915/i915_gem_evict.c   | 35 
> ++---
>  3 files changed, 32 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1ec523d29789..cd1ccc47ee8b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3525,6 +3525,7 @@ void i915_gem_context_reset(struct drm_device *dev);
>  int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
>  void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
>  int i915_switch_context(struct drm_i915_gem_request *req);
> +int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv);
>  void i915_gem_context_free(struct kref *ctx_ref);
>  struct drm_i915_gem_object *
>  i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 3c97f0e7a003..3b636161256c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -926,6 +926,35 @@ int i915_switch_context(struct drm_i915_gem_request *req)
>   return do_rcs_switch(req);
>  }
>  
> +int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv)
> +{
> + struct intel_engine_cs *engine;
> +
> + for_each_engine(engine, dev_priv) {
> + struct drm_i915_gem_request *req;
> + int ret;
> +
> + if (engine->last_context == NULL)
> + continue;
> +
> + if (engine->last_context == dev_priv->kernel_context)
> + continue;
> +
> + req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
> + if (IS_ERR(req))
> + return PTR_ERR(req);
> +
> + ret = 0;
> + if (!i915.enable_execlists)
> + ret = i915_switch_context(req);
> + i915_add_request_no_flush(req);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static bool contexts_enabled(struct drm_device *dev)
>  {
>   return i915.enable_execlists || to_i915(dev)->hw_context_size;
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 3c1280ec7ff6..b1194c7c0a48 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -33,37 +33,6 @@
>  #include "intel_drv.h"
>  #include "i915_trace.h"
>  
> -static int switch_to_pinned_context(struct drm_i915_private *dev_priv)
> -{
> - struct intel_engine_cs *engine;
> -
> - if (i915.enable_execlists)
> - return 0;
> -
> - for_each_engine(engine, dev_priv) {
> - struct drm_i915_gem_request *req;
> - int ret;
> -
> - if (engine->last_context == NULL)
> - continue;
> -
> - if (engine->last_context == dev_priv->kernel_context)
> - continue;
> -
> - req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
> - if (IS_ERR(req))
> - return PTR_ERR(req);
> -
> - ret = i915_switch_context(req);
> - i915_add_request_no_flush(req);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> -
>  static bool
>  mark_free(struct i915_vma *vma, struct list_head *unwind)
>  {
> @@ -184,7 +153,7 @@ none:
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   if (i915_is_ggtt(vm)) {
> - ret = switch_to_pinned_context(dev_priv);
> + ret = i915_gem_switch_to_kernel_context(dev_priv);
>   if (ret)
>   return ret;
>   }
> @@ -303,7 +272,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm, bool 
> do_idle)
>   struct drm_i915_private *dev_priv = to_i915(vm->dev);
>  
>   if (i915_is_ggtt(vm)) {
> - ret 

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

[Tvrtko Ursulin]

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

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Flush logical context image out to memory upon suspend

[Ville Syrjälä]

On Fri, Jul 15, 2016 at 01:03:40PM +0100, Chris Wilson wrote:
> Before suspend, and especially before building the hibernation image, we
> need to context image to be coherent in memory. To do this we require
> that we perform a context switch to a disposable context (i.e. the
> dev_priv->kernel_context) - when that switch is complete, all other
> context images will be complete. This leaves the kernel_context image as
> incomplete, but fortunately that is disposable and we can do a quick
> fixup of the logical state after resuming.
> 
> v2: Share the nearly identical code to switch to the kernel context with
> eviction.
> 
> Testcase: igt/gem_exec_suspend # bsw
> References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  4 +---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 17 +
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 15440123e38d..c5b7b8e0678a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_csr_ucode_resume(dev_priv);
>  
> - mutex_lock(>struct_mutex);
> - i915_gem_restore_gtt_mappings(dev);
> - mutex_unlock(>struct_mutex);
> + i915_gem_resume(dev);
>  
>   i915_restore_state(dev);
>   intel_opregion_setup(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index cd1ccc47ee8b..27d9b2c374b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
>  void i915_gem_cleanup_engines(struct drm_device *dev);
>  int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
>  int __must_check i915_gem_suspend(struct drm_device *dev);
> +void i915_gem_resume(struct drm_device *dev);
>  void __i915_add_request(struct drm_i915_gem_request *req,
>   struct drm_i915_gem_object *batch_obj,
>   bool flush_caches);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index cf0e8aa8035c..5a44ed9f4a33 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4983,6 +4983,10 @@ i915_gem_suspend(struct drm_device *dev)
>   intel_suspend_gt_powersave(dev_priv);
>  
>   mutex_lock(>struct_mutex);
> + ret = i915_gem_switch_to_kernel_context(dev_priv);
> + if (ret)
> + goto err;
> +
>   ret = i915_gem_wait_for_idle(dev_priv);
>   if (ret)
>   goto err;
> @@ -5009,6 +5013,19 @@ err:
>   return ret;
>  }
>  
> +void i915_gem_resume(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + mutex_lock(>struct_mutex);
> + i915_gem_restore_gtt_mappings(dev);
> +
> + if (i915.enable_execlists)
> + intel_lr_context_reset(dev_priv, dev_priv->kernel_context);

Maybe toss in a few comments as to why we do the switch and reset?

Should we do a sanity check here to make sure all contexts have
in fact HEAD==TAIL at this point? Might catch accidental breakage.

Anyways, patches look good to me, and my BSW seems happy as well, so
Reviewed-by: Ville Syrjälä 
Tested-by: Ville Syrjälä 


> +
> + mutex_unlock(>struct_mutex);
> +}
> +
>  void i915_gem_init_swizzling(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -- 
> 2.8.1

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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Disable waitboosting for mmioflips/semaphores

[Chris Wilson]

On Fri, Jul 15, 2016 at 02:08:17PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > 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
> > consumer is waiting upon the results. With the introduction of
> > NO_WAITBOOST
> 
> Is consumer a synonym for an userspace client in this context?

Yes, s/and consumer/no userspace consumer/

Technically there is a client waiting since we currently stall the
execbuf, so I was trying to distinguish between execbuf as the producer
and being throttled due to submitting to much work and somebody waiting
upon the result not being able to make progress on other tasks.

The flips are decoupled from the user, we just want to disable the
boosting as that is explicitly handled when we detect a missed flip.
-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] drm/i915/evict: Always switch away from the current context (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/evict: Always switch away from the 
current context (rev2)
URL   : https://patchwork.freedesktop.org/series/9926/
State : failure

== Summary ==

Series 9926v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9926/revisions/2/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
Test gem_sync:
Subgroup basic-store-each:
pass   -> DMESG-FAIL (ro-bdw-i7-5600u)
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)
Test vgem_basic:
Subgroup debugfs:
incomplete -> PASS   (ro-snb-i7-2620M)

fi-kbl-qkkr  total:241  pass:174  dwarn:28  dfail:1   fail:7   skip:31 
fi-skl-i5-6260u  total:241  pass:217  dwarn:1   dfail:0   fail:7   skip:16 
fi-skl-i7-6700k  total:241  pass:204  dwarn:0   dfail:0   fail:7   skip:30 
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:198  dwarn:0   dfail:1   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 
fi-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1503/

c01b445 drm-intel-nightly: 2016y-07m-15d-07h-02m-07s UTC integration manifest
cfa02fc drm/i915: Flush logical context image out to memory upon suspend
4c171cc drm/i915/evict: Always switch away from the current context

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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Disable waitboosting for mmioflips/semaphores

[Mika Kuoppala]

Chris Wilson  writes:

> 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
> consumer is waiting upon the results. 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 a4767c198413..08d9c081e9c8 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 40cc3da68611..2ec78aa7279e 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 9337d3a7b83d..813c9c3b32ca 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Mika Kuoppala]

Chris Wilson  writes:

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

Reviewed-by: Mika Kuoppala 

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Disable waitboosting for fence_wait()

[Joonas Lahtinen]

On pe, 2016-07-15 at 12:49 +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 12:08:05PM +0100, Chris Wilson wrote:
> > 
> > On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> > > 
> > > On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > > > 
> > > > +#define NO_WAITBOOST ERR_PTR(-1)
> > > This does not seem to be a very common idiom in kernel, just add flags
> > > maybe.
> > I find the special values for the client (including the existing NULL
> > client) much more informative.
> Is it more pleasant with...?
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index bfec4a88707d..aedc15d46463 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -713,7 +713,7 @@ complete:
> *timeout = 0;
> }
>  
> -   if (!IS_ERR_OR_NULL(rps) &&
> +   if (IS_RPS_CLIENT(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
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index f7f497a07893..b3fe80d4eb63 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -207,6 +207,7 @@ void __i915_add_request(struct drm_i915_gem_request *req,
>  
>  struct intel_rps_client;

I almost suggested #define RPS_CLIENT(n) ERR_PTR(-n), but this is
somewhat better already.

>  #define NO_WAITBOOST ERR_PTR(-1)
> +#define IS_RPS_CLIENT(p) (!IS_ERR_OR_NULL(p))
> 
-- 
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

[Intel-gfx] [PATCH v2] drm/i915: Flush logical context image out to memory upon suspend

[Chris Wilson]

Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will be complete. This leaves the kernel_context image as
incomplete, but fortunately that is disposable and we can do a quick
fixup of the logical state after resuming.

v2: Share the nearly identical code to switch to the kernel context with
eviction.

Testcase: igt/gem_exec_suspend # bsw
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 +---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 17 +
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15440123e38d..c5b7b8e0678a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_csr_ucode_resume(dev_priv);
 
-   mutex_lock(>struct_mutex);
-   i915_gem_restore_gtt_mappings(dev);
-   mutex_unlock(>struct_mutex);
+   i915_gem_resume(dev);
 
i915_restore_state(dev);
intel_opregion_setup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd1ccc47ee8b..27d9b2c374b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
 int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_suspend(struct drm_device *dev);
+void i915_gem_resume(struct drm_device *dev);
 void __i915_add_request(struct drm_i915_gem_request *req,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf0e8aa8035c..5a44ed9f4a33 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4983,6 +4983,10 @@ i915_gem_suspend(struct drm_device *dev)
intel_suspend_gt_powersave(dev_priv);
 
mutex_lock(>struct_mutex);
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err;
+
ret = i915_gem_wait_for_idle(dev_priv);
if (ret)
goto err;
@@ -5009,6 +5013,19 @@ err:
return ret;
 }
 
+void i915_gem_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   mutex_lock(>struct_mutex);
+   i915_gem_restore_gtt_mappings(dev);
+
+   if (i915.enable_execlists)
+   intel_lr_context_reset(dev_priv, dev_priv->kernel_context);
+
+   mutex_unlock(>struct_mutex);
+}
+
 void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.8.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/evict: Always switch away from the current context

[Chris Wilson]

Currently execlists is exempt from emitting a request to switch each
ring away from the current context over to the dev_priv->kernel_context
(for whatever reason, just under execlists the GGTT is unlikely to be as
fragmented, however the switch may help in some extreme cases). Extract
the switcher and enable it for execlsts as well, as we need to do so in
a later patch to force the context switch before suspend. (And since for
that switch we explicitly require the disposable kernel context, rename
the extracted function.)

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 29 +++
 drivers/gpu/drm/i915/i915_gem_evict.c   | 35 ++---
 3 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ec523d29789..cd1ccc47ee8b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3525,6 +3525,7 @@ void i915_gem_context_reset(struct drm_device *dev);
 int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
 void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
 int i915_switch_context(struct drm_i915_gem_request *req);
+int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv);
 void i915_gem_context_free(struct kref *ctx_ref);
 struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3c97f0e7a003..3b636161256c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -926,6 +926,35 @@ int i915_switch_context(struct drm_i915_gem_request *req)
return do_rcs_switch(req);
 }
 
+int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   struct drm_i915_gem_request *req;
+   int ret;
+
+   if (engine->last_context == NULL)
+   continue;
+
+   if (engine->last_context == dev_priv->kernel_context)
+   continue;
+
+   req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
+   if (IS_ERR(req))
+   return PTR_ERR(req);
+
+   ret = 0;
+   if (!i915.enable_execlists)
+   ret = i915_switch_context(req);
+   i915_add_request_no_flush(req);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 static bool contexts_enabled(struct drm_device *dev)
 {
return i915.enable_execlists || to_i915(dev)->hw_context_size;
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 3c1280ec7ff6..b1194c7c0a48 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -33,37 +33,6 @@
 #include "intel_drv.h"
 #include "i915_trace.h"
 
-static int switch_to_pinned_context(struct drm_i915_private *dev_priv)
-{
-   struct intel_engine_cs *engine;
-
-   if (i915.enable_execlists)
-   return 0;
-
-   for_each_engine(engine, dev_priv) {
-   struct drm_i915_gem_request *req;
-   int ret;
-
-   if (engine->last_context == NULL)
-   continue;
-
-   if (engine->last_context == dev_priv->kernel_context)
-   continue;
-
-   req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
-   if (IS_ERR(req))
-   return PTR_ERR(req);
-
-   ret = i915_switch_context(req);
-   i915_add_request_no_flush(req);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
-}
-
-
 static bool
 mark_free(struct i915_vma *vma, struct list_head *unwind)
 {
@@ -184,7 +153,7 @@ none:
struct drm_i915_private *dev_priv = to_i915(dev);
 
if (i915_is_ggtt(vm)) {
-   ret = switch_to_pinned_context(dev_priv);
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
if (ret)
return ret;
}
@@ -303,7 +272,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm, bool 
do_idle)
struct drm_i915_private *dev_priv = to_i915(vm->dev);
 
if (i915_is_ggtt(vm)) {
-   ret = switch_to_pinned_context(dev_priv);
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
if (ret)
return ret;
}
-- 
2.8.1

[Intel-gfx] [PATCH 2/2] drm/i915: Flush logical context image out to memory upon suspend

[Chris Wilson]

Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will be complete. This leaves the kernel_context image as
incomplete, but fortunately that is disposable and we can do a quick
fixup of the logical state after resuming.

v2: Share the nearly identical code to switch to the kernel context with
eviction.

Testcase: igt/gem_exec_suspend # bsw
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 +---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 17 +
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15440123e38d..c5b7b8e0678a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_csr_ucode_resume(dev_priv);
 
-   mutex_lock(>struct_mutex);
-   i915_gem_restore_gtt_mappings(dev);
-   mutex_unlock(>struct_mutex);
+   i915_gem_resume(dev);
 
i915_restore_state(dev);
intel_opregion_setup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd1ccc47ee8b..27d9b2c374b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
 int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_suspend(struct drm_device *dev);
+void i915_gem_resume(struct drm_device *dev);
 void __i915_add_request(struct drm_i915_gem_request *req,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf0e8aa8035c..e5fa4301d3df 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4983,6 +4983,10 @@ i915_gem_suspend(struct drm_device *dev)
intel_suspend_gt_powersave(dev_priv);
 
mutex_lock(>struct_mutex);
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err;
+
ret = i915_gem_wait_for_idle(dev_priv);
if (ret)
goto err;
@@ -5009,6 +5013,19 @@ err:
return ret;
 }
 
+void i915_gem_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   mutex_lock(>struct_mutex);
+
+   if (i915.enable_execlists)
+   intel_lr_context_reset(dev_priv, dev_priv->kernel_context);
+
+   i915_gem_restore_gtt_mappings(dev);
+   mutex_unlock(>struct_mutex);
+}
+
 void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce flush interrupts

[Tvrtko Ursulin]

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

From: Akash Goel 

In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 1de6928..7521ed5 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -104,9 +104,9 @@
  #define   GUC_LOG_ALLOC_IN_MEGABYTE   (1 << 3)
  #define   GUC_LOG_CRASH_PAGES 1
  #define   GUC_LOG_CRASH_SHIFT 4
-#define   GUC_LOG_DPC_PAGES3
+#define   GUC_LOG_DPC_PAGES7
  #define   GUC_LOG_DPC_SHIFT   6
-#define   GUC_LOG_ISR_PAGES3
+#define   GUC_LOG_ISR_PAGES7
  #define   GUC_LOG_ISR_SHIFT   9
  #define   GUC_LOG_BUF_ADDR_SHIFT  12

@@ -436,9 +436,9 @@ enum guc_log_buffer_type {
   *|   Crash dump state header |
   * Page1  +---+
   *|   ISR logs|
- * Page5  +---+
- *|   DPC logs|
   * Page9  +---+
+ *|   DPC logs|
+ * Page17 +---+
   *| Crash Dump logs   |
   *+---+
   *



I don't mind - but does it help? And how much and for what? Haven't you 
later found that the uncached reads were the main issue?


Regards,

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

[Intel-gfx] [PATCH v2] drm/i915: 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 
---
 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

Re: [Intel-gfx] [PATCH 14/17] drm/i915: Add stats for GuC log buffer flush interrupts

[Tvrtko Ursulin]

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

From: Akash Goel 

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

Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_debugfs.c| 26 ++
  drivers/gpu/drm/i915/i915_guc_submission.c |  8 
  drivers/gpu/drm/i915/i915_irq.c|  1 +
  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
  4 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3c9c7f7..888a18a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2538,6 +2538,30 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
return 0;
  }

+static void i915_guc_log_info(struct seq_file *m,
+struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   seq_printf(m, "\nGuC logging stats:\n");
+
+   seq_printf(m, "\tISR:   flush count %10u, overflow count %8u\n",
+   guc->log.flush_count[GUC_ISR_LOG_BUFFER],
+   guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
+
+   seq_printf(m, "\tDPC:   flush count %10u, overflow count %8u\n",
+   guc->log.flush_count[GUC_DPC_LOG_BUFFER],
+   guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
+
+   seq_printf(m, "\tCRASH: flush count %10u, overflow count %8u\n",
+   guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
+   guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+
+   seq_printf(m, "\tTotal flush interrupt count: %u\n",
+   guc->log.flush_interrupt_count);
+
+}
+
  static void i915_guc_client_info(struct seq_file *m,
 struct drm_i915_private *dev_priv,
 struct i915_guc_client *client)
@@ -2611,6 +2635,8 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
i915_guc_client_info(m, dev_priv, );

+   i915_guc_log_info(m, dev_priv);
+
/* Add more as required ... */

return 0;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c1e637f..9c94a43 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -914,6 +914,14 @@ static void guc_read_update_log_buffer(struct drm_device 
*dev)
log_buffer_state_local = *log_buffer_state;
buffer_size = log_buffer_state_local.size;

+   guc->log.flush_count[i] += log_buffer_state_local.flush_to_file;
+   if (log_buffer_state_local.buffer_full_cnt !=
+   guc->log.prev_overflow_count[i]) {
+   guc->log.prev_overflow_count[i] =
+   log_buffer_state_local.buffer_full_cnt;
+   guc->log.total_overflow_count[i]++;


Is log_buffer_state_local.buffer_full_cnt guaranteed to be one here? Or 
you would need to increase total_overflow_count by its value?



+   }
+
if (log_buffer_copy_state) {
/* First copy the state structure */
memcpy(log_buffer_copy_state, _buffer_state_local,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bdd7a67..c3fb67e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1711,6 +1711,7 @@ static void gen9_guc_irq_handler(struct drm_i915_private 
*dev_priv, u32 gt_iir)
_priv->guc.events_work);
}
}
+   dev_priv->guc.log.flush_interrupt_count++;
spin_unlock(_priv->irq_lock);
}
  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 611f4a7..e911a32 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -128,6 +128,12 @@ struct intel_guc_log {
struct workqueue_struct *wq;
void *buf_addr;
struct rchan *relay_chan;
+
+   /* logging related stats */
+   u32 flush_interrupt_count;
+   u32 prev_overflow_count[GUC_MAX_LOG_BUFFER];
+   u32 total_overflow_count[GUC_MAX_LOG_BUFFER];
+   u32 flush_count[GUC_MAX_LOG_BUFFER];
  };

  struct intel_guc {



Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Disable waitboosting for fence_wait()

[Chris Wilson]

On Fri, Jul 15, 2016 at 12:08:05PM +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> > On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > > +#define NO_WAITBOOST ERR_PTR(-1)
> > 
> > This does not seem to be a very common idiom in kernel, just add flags
> > maybe.
> 
> I find the special values for the client (including the existing NULL
> client) much more informative.

Is it more pleasant with...?

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index bfec4a88707d..aedc15d46463 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -713,7 +713,7 @@ complete:
*timeout = 0;
}
 
-   if (!IS_ERR_OR_NULL(rps) &&
+   if (IS_RPS_CLIENT(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
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index f7f497a07893..b3fe80d4eb63 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -207,6 +207,7 @@ void __i915_add_request(struct drm_i915_gem_request *req,
 
 struct intel_rps_client;
 #define NO_WAITBOOST ERR_PTR(-1)
+#define IS_RPS_CLIENT(p) (!IS_ERR_OR_NULL(p))

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

Re: [Intel-gfx] [PATCH 11/17] drm/i915: Support to create write combined type vmaps

[Chris Wilson]

On Fri, Jul 15, 2016 at 12:31:23PM +0100, Tvrtko Ursulin wrote:

[snip good ideas, leaving the questions]

> >  /**
> >   * i915_gem_object_unpin_map - releases an earlier mapping
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 8f50919..c431b40 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2471,10 +2471,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
> >*obj)
> > list_del(>global_list);
> >
> > if (obj->mapping) {
> >-if (is_vmalloc_addr(obj->mapping))
> >-vunmap(obj->mapping);
> >+void *ptr = (void *)((uintptr_t)obj->mapping & ~1);
> 
> How many bits we have to play with here? Is there a suitable define
> somewhere we could use for a mask instead of hardcoded "1" or we
> could add one if you think that would be better?

The mapping is always page-aligned, so bits 0-11 are available.

PAGE_MASK should do the trick

> >-addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
> >+addr = vmap(pages, n_pages, VM_NO_GUARD,
> >+use_wc ? pgprot_writecombine(PAGE_KERNEL_IO) : PAGE_KERNEL);
> 
> For educational benefit, what is the importance and difference
> between PAGE_KERNEL and PAGE_KERNEL_IO here?

One day I'll find out. We've always tagged our WC mmapings as
PAGE_KERNEL_IO, so cargo-culted it in.
 
> >
> > if (pages != stack_pages)
> > drm_free_large(pages);
> >@@ -2684,27 +2687,55 @@ static void *i915_gem_object_map(const struct 
> >drm_i915_gem_object *obj)
> >  }
> >
> >  /* get, pin, and map the pages of the object into kernel space */
> >-void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
> >+void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, bool use_wc)
> >  {
> >+void *ptr;
> >+bool has_wc;
> >+bool pinned;
> > int ret;
> >
> > lockdep_assert_held(>base.dev->struct_mutex);
> >+GEM_BUG_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0);
> >
> > ret = i915_gem_object_get_pages(obj);
> > if (ret)
> > return ERR_PTR(ret);
> >
> >+GEM_BUG_ON(obj->pages == NULL);
> 
> Looks like belongs to i915_gem_object_get_pages and not to callers.

This is from later where it did:

pinned = true;
if (!atomic_inc_not_zero(>mm.pages_pin_count)) {
ret = i915_gem_object_get_pages(obj);
if (ret)
goto err_unlock;

smp_mb__before_atomic();
GEM_BUG_ON(atomic_read(>mm.pages_pin_count));
atomic_set(>mm.pages_pin_count, 1);
pinned = false;
}

GEM_BUG_ON(obj->mm.pages == NULL);

Right now the BUG_ON is superfluous.
-Chris

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

Re: [Intel-gfx] [PATCH 13/17] drm/i915: New lock to serialize the Host2GuC actions

[Tvrtko Ursulin]

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

From: Akash Goel 

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


After which patch in this series is this required?



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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6043166..c1e637f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -88,6 +88,7 @@ static int host2guc_action(struct intel_guc *guc, u32 *data, 
u32 len)
return -EINVAL;

intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+   spin_lock(>action_lock);


The code below can sleep waiting for a response from GuC so you cannot 
use a spinlock. Mutex I suppose...




dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = data[0];
@@ -126,6 +127,7 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
}
dev_priv->guc.action_status = status;

+   spin_unlock(>action_lock);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);

return ret;
@@ -1304,6 +1306,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
return -ENOMEM;

ida_init(>ctx_ids);
+   spin_lock_init(>action_lock);


I think this should go to guc_client_alloc which is where the guc client 
object is allocated and initialized.



guc_create_log(guc);
guc_create_ads(guc);

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index d56bde6..611f4a7 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -157,6 +157,9 @@ struct intel_guc {

uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
+
+   /* To serialize the Host2GuC actions */
+   spinlock_t action_lock;
  };

  /* intel_guc_loader.c */



Regards,

Tvrtko

___
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: Fix compilation when some gcc configurations

[Chris Wilson]

On Fri, Jul 15, 2016 at 12:07:42PM +0100, Damien Lespiau wrote:
> Depending how the gcc was compiled it may be necessary to enable SSE4
> instructions explicitly. Otherwise:
> 
>   CC   gem_gtt_speed.o
> In file included from gem_gtt_speed.c:54:0:
> /usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error 
> "SSE4.1 instruction set not enabled"
>  # error "SSE4.1 instruction set not enabled"
>^
> 
> v2: Use a pragma directive (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Damien Lespiau 
> ---
>  tests/gem_exec_flush.c | 1 +
>  tests/gem_gtt_speed.c  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/tests/gem_exec_flush.c b/tests/gem_exec_flush.c
> index c81a977..b43d511 100644
> --- a/tests/gem_exec_flush.c
> +++ b/tests/gem_exec_flush.c
> @@ -41,6 +41,7 @@ IGT_TEST_DESCRIPTION("Basic check of flushing after 
> batches");
>  #define MOVNT 512
>  
>  #if defined(__x86_64__)
> +#pragma GCC target ("sse4.1")

I jumped ahead and did
#pragma GCC push_options
#pragma GCC target ("sse4.1")
..
#pragma GCC pop_options

Compiling with gcc 4.2 or even older will be fixed whenever...
-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 9/9] drm/i915: Mark imported dma-buf objects as being coherent

[Mika Kuoppala]

Chris Wilson  writes:

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

I was a confused about the coherency guarantees of this _GTT.

But after chatting with Chris I am convinced that what comes to
coherency for other guests and sharing, this is it.

Reviewed-by: Mika Kuoppala 

-Mika

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

Re: [Intel-gfx] [PATCH 11/17] drm/i915: Support to create write combined type vmaps

[Tvrtko Ursulin]

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

From: Chris Wilson 

vmaps has a provision for controlling the page protection bits, with which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their mapping type, we add a parameter to
i915_gem_object_pin_map - but we still only allow one vmap to be cached
per object. If the object is currently not pinned, then we recreate the
previous vmap with the new access type, but if it was pinned we report an
error. This effectively limits the access via i915_gem_object_pin_map to a
single mapping type for the lifetime of the object. Not usually a problem,
but something to be aware of when setting up the object's vmap.

We will want to vary the access type to enable WC mappings of ringbuffer
and context objects on !llc platforms, as well as other objects where we
need coherent access to the GPU's pages without going through the GTT

v2: Remove the redundant braces around pin count check and fix the marker
 in documentation (Chris)

Signed-off-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.h|  4 ++-
  drivers/gpu/drm/i915/i915_gem.c| 57 +++---
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  2 +-
  drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  8 ++---
  drivers/gpu/drm/i915/intel_ringbuffer.c|  2 +-
  6 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6e2ddfa..84afa17 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3248,6 +3248,7 @@ static inline void i915_gem_object_unpin_pages(struct 
drm_i915_gem_object *obj)
  /**
   * i915_gem_object_pin_map - return a contiguous mapping of the entire object
   * @obj - the object to map into kernel address space
+ * @use_wc - whether the mapping should be using WC or WB pgprot_t
   *
   * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
   * pages and then returns a contiguous mapping of the backing storage into
@@ -3259,7 +3260,8 @@ static inline void i915_gem_object_unpin_pages(struct 
drm_i915_gem_object *obj)
   * Returns the pointer through which to access the mapped object, or an
   * ERR_PTR() on error.
   */
-void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj);
+void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
+bool use_wc);


Could you make it an enum instead of a bool? Commit message suggests 
more modes will potentially be added and if so, and we start with an 
enum straight away, it will make for less churn in the future.


func(something, true) is always also quite unreadabe in the code because 
one has to remember or remind himself what it really means.


Something like func(something, MAP_WC) would be simply self-documenting.



  /**
   * i915_gem_object_unpin_map - releases an earlier mapping
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f50919..c431b40 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2471,10 +2471,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
list_del(>global_list);

if (obj->mapping) {
-   if (is_vmalloc_addr(obj->mapping))
-   vunmap(obj->mapping);
+   void *ptr = (void *)((uintptr_t)obj->mapping & ~1);


How many bits we have to play with here? Is there a suitable define 
somewhere we could use for a mask instead of hardcoded "1" or we could 
add one if you think that would be better?



+   if (is_vmalloc_addr(ptr))
+   vunmap(ptr);
else
-   kunmap(kmap_to_page(obj->mapping));
+   kunmap(kmap_to_page(ptr));
obj->mapping = NULL;
}

@@ -2647,7 +2648,8 @@ i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
  }

  /* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj,
+   bool use_wc)
  {
unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
struct sg_table *sgt = obj->pages;
@@ -2659,7 +2661,7 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
void *addr;

/* A single page can always be kmapped */
-   if (n_pages == 1)
+   if (n_pages == 1 && !use_wc)
return kmap(sg_page(sgt->sgl));

if (n_pages > ARRAY_SIZE(stack_pages)) {
@@ -2675,7 +2677,8 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
/* Check that we have the expected 

Re: [Intel-gfx] [PATCH 10/17] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

[Tvrtko Ursulin]

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

From: Akash Goel 

On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Driver store, up to, 4 snapshots
of the log buffer in a local buffer (managed by relay).
Added a new module (read only) param, 'guc_log_size', through which User
can specify the number of snapshots of log buffer to be stored in local
buffer. This can be used to ensure capturing of all boot time logs even
with high verbosity level.

v2: Rename module param to more apt name 'guc_log_buffer_nr'. (Nikula)

Suggested-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
  drivers/gpu/drm/i915/i915_params.c | 5 +
  drivers/gpu/drm/i915/i915_params.h | 1 +
  3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2e3b723..009d7c0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1046,8 +1046,7 @@ static int guc_create_log_relay_file(struct intel_guc 
*guc)

/* Keep the size of sub buffers same as shared log buffer */
subbuf_size = guc->log.obj->base.size;
-   /* TODO: Decide based on the User's input */
-   n_subbufs = 4;
+   n_subbufs = i915.guc_log_buffer_nr;

guc_log_relay_chan = relay_open("guc_log", log_dir,
subbuf_size, n_subbufs, _callbacks, dev);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 8b13bfa..d30c972 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -57,6 +57,7 @@ struct i915_params i915 __read_mostly = {
.enable_guc_loading = -1,
.enable_guc_submission = -1,
.guc_log_level = -1,
+   .guc_log_buffer_nr = 4,
.enable_dp_mst = true,
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
@@ -214,6 +215,10 @@ module_param_named(guc_log_level, i915.guc_log_level, int, 
0400);
  MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");

+module_param_named(guc_log_buffer_nr, i915.guc_log_buffer_nr, int, 0400);
+MODULE_PARM_DESC(guc_log_buffer_nr,
+   "Number of sub buffers to store GuC firmware logs (default: 4)");
+
  module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
  MODULE_PARM_DESC(enable_dp_mst,
"Enable multi-stream transport (MST) for new DisplayPort sinks. (default: 
true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 0ad020b..14ca855 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,6 +48,7 @@ struct i915_params {
int enable_guc_loading;
int enable_guc_submission;
int guc_log_level;
+   int guc_log_buffer_nr;
int use_mmio_flip;
int mmio_debug;
int edp_vswing;



I did not figure out after a quick read of 
Documentation/filesystems/relay.txt whether we really need this to be 
configurable?


If I got it right number of sub-buffers here only has a relation to the 
userspace relay consumer latency. If the userspace is responsive should 
just two be enough? Or the existing default of four was shown in 
practice that it is better and good enough?


I am just not sure this is a useful module parameter without some more data.

Even if it is needed, as minimum I think the name should reflect this is 
about the relay side of things and not the GuC log buffer itself. So 
something like i915.guc_relay_log_subbuf_nr or something. With the 
matching description of course.


Regards,

Tvrtko
___
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 03/15] kms_psr_sink_crc: Use for_each_pipe_with_valid_output to find a valid config.

[Ander Conselvan De Oliveira]

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 

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

Re: [Intel-gfx] [PATCH i-g-t v2 02/15] igt_kms: Find optimal encoder only after selecting pipe

[Ander Conselvan De Oliveira]

On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> This will allow us to find a matching encoder based on a pipe only.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  lib/igt_kms.c | 97 +-
> -
>  1 file changed, 61 insertions(+), 36 deletions(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index c16e40ea273b..ce8aa2455348 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -761,6 +761,59 @@ bool kmstest_get_connector_default_mode(int drm_fd,
> drmModeConnector *connector,
>   return true;
>  }
>  
> +static void
> +_kmstest_connector_config_crtc_mask(int drm_fd,
> + drmModeConnector *connector,
> + struct kmstest_connector_config *config)
> +{
> + int i;
> +
> + config->valid_crtc_idx_mask = 0;
> +
> + /* Now get a compatible encoder */
> + for (i = 0; i < connector->count_encoders; i++) {
> + drmModeEncoder *encoder = drmModeGetEncoder(drm_fd,
> + connector-
> >encoders[i]);
> +
> + if (!encoder) {
> + igt_warn("could not get encoder %d: %s\n",
> +  connector->encoders[i],
> +  strerror(errno));
> +
> + continue;
> + }
> +
> + config->valid_crtc_idx_mask |= encoder->possible_crtcs;
> + drmModeFreeEncoder(encoder);
> + }
> +}
> +
> +static drmModeEncoder *
> +_kmstest_connector_config_find_encoder(int drm_fd, drmModeConnector
> *connector, enum pipe pipe)
> +{
> + int i;
> +
> + for (i = 0; i < connector->count_encoders; i++) {
> + drmModeEncoder *encoder = drmModeGetEncoder(drm_fd,
> connector->encoders[i]);
> +
> + if (!encoder) {
> + igt_warn("could not get encoder %d: %s\n",
> +  connector->encoders[i],
> +  strerror(errno));
> +
> + continue;
> + }
> +
> + if (encoder->possible_crtcs & (1 << pipe))
> + return encoder;
> +
> + drmModeFreeEncoder(encoder);
> + }
> +
> + igt_assert(false);
> + return NULL;
> +}
> +
>  /**
>   * _kmstest_connector_config:
>   * @drm_fd: DRM fd
> @@ -779,8 +832,6 @@ static bool _kmstest_connector_config(int drm_fd, uint32_t
> connector_id,
>  {
>   drmModeRes *resources;
>   drmModeConnector *connector;
> - drmModeEncoder *encoder, *found = NULL;
> - int i, j, pipe;
>  
>   resources = drmModeGetResources(drm_fd);
>   if (!resources) {
> @@ -816,51 +867,25 @@ static bool _kmstest_connector_config(int drm_fd,
> uint32_t connector_id,
>    * In both cases find the first compatible encoder and skip the CRTC
>    * if there is non such.
>    */
> - config->valid_crtc_idx_mask = 0;
> - for (i = 0; i < resources->count_crtcs; i++) {
> - if (!resources->crtcs[i])
> - continue;

This patch looses the NULL check above, but if I understand correctly this can't
happen anyway, since we would have bailed on a GetResources failure. So,

Reviewed-by: Ander Conselvan de Oliveira 


> + _kmstest_connector_config_crtc_mask(drm_fd, connector, config);
>  
> - /* Now get a compatible encoder */
> - for (j = 0; j < connector->count_encoders; j++) {
> - encoder = drmModeGetEncoder(drm_fd,
> - connector->encoders[j]);
> -
> - if (!encoder) {
> - igt_warn("could not get encoder %d: %s\n",
> -  resources->encoders[j],
> -  strerror(errno));
> -
> - continue;
> - }
> -
> - config->valid_crtc_idx_mask |= encoder-
> >possible_crtcs;
> -
> - if (!found && (crtc_idx_mask & encoder-
> >possible_crtcs & (1 << i))) {
> - found = encoder;
> - pipe = i;
> - } else
> - drmModeFreeEncoder(encoder);
> - }
> - }
> -
> - if (!found)
> + crtc_idx_mask &= config->valid_crtc_idx_mask;
> + if (!crtc_idx_mask)
>   goto err3;
>  
> + config->pipe = ffs(crtc_idx_mask) - 1;
> +
>   if (!kmstest_get_connector_default_mode(drm_fd, connector,
>   >default_mode))
> - goto err4;
> + goto err3;
>  
> + config->encoder = _kmstest_connector_config_find_encoder(drm_fd,
> connector, config->pipe);
>   config->connector = connector;
> - config->encoder = found;
> - config->crtc = drmModeGetCrtc(drm_fd, 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Set legacy properties when using legacy gamma set IOCTL. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL. 
(rev3)
URL   : https://patchwork.freedesktop.org/series/5466/
State : failure

== Summary ==

  LD  drivers/tty/vt/built-in.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD [M]  drivers/gpu/drm/drm.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  drivers/tty/built-in.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
drivers/gpu/drm/i915/intel_display.c:13965:15: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
  .gamma_set = intel_atomic_legacy_gamma_set,
   ^
drivers/gpu/drm/i915/intel_display.c:13965:15: note: (near initialization for 
‘intel_crtc_funcs.gamma_set’)
cc1: some warnings being treated as errors
scripts/Makefile.build:289: recipe for target 
'drivers/gpu/drm/i915/intel_display.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:987: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Flush logical context image out to memory upon suspend

[Chris Wilson]

On Fri, Jul 15, 2016 at 01:41:33PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > Before suspend, and especially before building the hibernation image, we
> > need to context image to be coherent in memory. To do this we require
> > that we perform a context switch to a disposable context (i.e. the
> > dev_priv->kernel_context) - when that switch is complete, all other
> > context images will be complete. This leaves the kernel_context image as
> > incomplete, but fortunately that is disposable and we can do a quick
> > fixup of the logical state after resuming.
> >
> > Testcase: igt/gem_exec_suspend # bsw
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c |  4 +---
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_gem.c | 46 
> > +
> >  3 files changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 15440123e38d..c5b7b8e0678a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
> >  
> > intel_csr_ucode_resume(dev_priv);
> >  
> > -   mutex_lock(>struct_mutex);
> > -   i915_gem_restore_gtt_mappings(dev);
> > -   mutex_unlock(>struct_mutex);
> > +   i915_gem_resume(dev);
> >  
> > i915_restore_state(dev);
> > intel_opregion_setup(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1ec523d29789..e73c0fc84c73 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
> >  void i915_gem_cleanup_engines(struct drm_device *dev);
> >  int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
> >  int __must_check i915_gem_suspend(struct drm_device *dev);
> > +void i915_gem_resume(struct drm_device *dev);
> >  void __i915_add_request(struct drm_i915_gem_request *req,
> > struct drm_i915_gem_object *batch_obj,
> > bool flush_caches);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index cf0e8aa8035c..8b42a5101f11 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4974,6 +4974,35 @@ i915_gem_stop_engines(struct drm_device *dev)
> > dev_priv->gt.stop_engine(engine);
> >  }
> >  
> > +static int switch_to_kernel_context(struct drm_i915_private *dev_priv)
> > +{
> > +   struct intel_engine_cs *engine;
> > +
> > +   for_each_engine(engine, dev_priv) {
> > +   struct drm_i915_gem_request *req;
> > +   int ret;
> > +
> > +   if (engine->last_context == NULL)
> > +   continue;
> > +
> > +   if (engine->last_context == dev_priv->kernel_context)
> > +   continue;
> > +
> > +   req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
> > +   if (IS_ERR(req))
> > +   return PTR_ERR(req);
> > +
> > +   ret = 0;
> > +   if (!i915.enable_execlists)
> > +   ret = i915_switch_context(req);
> > +   i915_add_request_no_flush(req);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> 
> Why do you want keep this separate? Altho the evict one is a little
> bit different and as I didn't see any perf implications: Why not
> consolidate the evict one and this one and have i915_gem_idle which
> would park to default and wait for idle.

I found i915_gem_idle() to be easily confused with the idle functions we
call upon idling. And later on you will see that i915_gem_park() itself
is not common to anything but suspend. So I don't feel like introducing
that as nebulous concept. But with a functional change to evict noted,
we can share the switch-context code...
-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 i-g-t] tests: Fix compilation when some gcc configurations

[Damien Lespiau]

On Thu, Jul 14, 2016 at 06:48:26PM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 06:44:59PM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 06:31:37PM +0100, Damien Lespiau wrote:
> > > Depending how the gcc was compiled it may be necessary to enable SSE4
> > > instructions explicitly. Otherwise:
> > > 
> > >   CC   gem_gtt_speed.o
> > > In file included from gem_gtt_speed.c:54:0:
> > > /usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error 
> > > "SSE4.1 instruction set not enabled"
> > >  # error "SSE4.1 instruction set not enabled"
> > 
> > So the challenge is getting the function attribute applied to the
> > include.
> > 
> > Ah, can you try
> > #pragma GCC target ("sse4.1")
> > in those blocks instead?

Yup, that also seems to enable sse4.1 for the rest of the compilation
unit.

> Oh, and we probably need an #if GCC > 4.y to be fully backwards
> compatible.

Couldn't find in less than 5 mins this information, gave up. Someone
exhibiting the problem will have to fix it :)

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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Disable waitboosting for mmioflips/semaphores

[Mika Kuoppala]

Chris Wilson  writes:

> 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
> consumer is waiting upon the results. With the introduction of
> NO_WAITBOOST

Is consumer a synonym for an userspace client in this context?

> in the previous patch, we can finally disable these needless boosts.
>
> Signed-off-by: Chris Wilson 

Seems to do what it advertizes. Might need to change the NO_WAITBOOST
define tho as Joonas pointed out.

-Mika

> ---
>  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 a4767c198413..08d9c081e9c8 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 40cc3da68611..2ec78aa7279e 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 9337d3a7b83d..813c9c3b32ca 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Disable waitboosting for fence_wait()

[Chris Wilson]

On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > +#define NO_WAITBOOST ERR_PTR(-1)
> 
> This does not seem to be a very common idiom in kernel, just add flags
> maybe.

I find the special values for the client (including the existing NULL
client) much more informative.
-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 i-g-t] tests: Fix compilation when some gcc configurations

[Damien Lespiau]

Depending how the gcc was compiled it may be necessary to enable SSE4
instructions explicitly. Otherwise:

  CC   gem_gtt_speed.o
In file included from gem_gtt_speed.c:54:0:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error 
"SSE4.1 instruction set not enabled"
 # error "SSE4.1 instruction set not enabled"
   ^

v2: Use a pragma directive (Chris)

Cc: Chris Wilson 
Signed-off-by: Damien Lespiau 
---
 tests/gem_exec_flush.c | 1 +
 tests/gem_gtt_speed.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tests/gem_exec_flush.c b/tests/gem_exec_flush.c
index c81a977..b43d511 100644
--- a/tests/gem_exec_flush.c
+++ b/tests/gem_exec_flush.c
@@ -41,6 +41,7 @@ IGT_TEST_DESCRIPTION("Basic check of flushing after batches");
 #define MOVNT 512
 
 #if defined(__x86_64__)
+#pragma GCC target ("sse4.1")
 #include 
 __attribute__((noinline))
 __attribute__((target("sse4.1")))
diff --git a/tests/gem_gtt_speed.c b/tests/gem_gtt_speed.c
index 94b3de3..ed8cfda 100644
--- a/tests/gem_gtt_speed.c
+++ b/tests/gem_gtt_speed.c
@@ -51,6 +51,7 @@ static double elapsed(const struct timeval *start,
 }
 
 #if defined(__x86_64__)
+#pragma GCC target ("sse4.1")
 #include 
 __attribute__((noinline))
 __attribute__((target("sse4.1")))
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Disable waitboosting for fence_wait()

[Chris Wilson]

On Fri, Jul 15, 2016 at 01:49:44PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > 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.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_request.c | 7 ---
> >  drivers/gpu/drm/i915/i915_gem_request.h | 1 +
> >  2 files changed, 5 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..bfec4a88707d 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_ERR(rps) && INTEL_GEN(req->i915) >= 6)
> > gen6_rps_boost(req->i915, rps, req->emitted_jiffies);
> >
> 
> The intention here is to boost even if rps client is NULL?
> Assuming so could you elaborate why.

Yes, NULL is the kernel request for rps boosting, not associated with
any client (and may be affecting multiple clients at any one time).
-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 Color management fixed for 4.7

[Patchwork]

== Series Details ==

Series: Color management fixed for 4.7
URL   : https://patchwork.freedesktop.org/series/9924/
State : failure

== Summary ==

  LD  drivers/scsi/built-in.o
  CC  drivers/usb/host/xhci-trace.o
  CC  drivers/video/fbdev/core/cfbfillrect.o
  LD  drivers/tty/vt/built-in.o
  CC  drivers/video/fbdev/core/cfbcopyarea.o
  CC  drivers/usb/host/xhci-pci.o
  CC  drivers/video/fbdev/core/cfbimgblt.o
  CC  drivers/usb/core/of.o
  CC  drivers/usb/core/hcd-pci.o
  CC [M]  drivers/video/fbdev/core/sysfillrect.o
  CC  drivers/usb/core/usb-acpi.o
  CC [M]  drivers/video/fbdev/core/sysimgblt.o
  CC [M]  drivers/video/fbdev/core/fb_sys_fops.o
  CC [M]  drivers/video/fbdev/core/syscopyarea.o
  LD  drivers/tty/built-in.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/acpi/acpica/built-in.o
  LD  drivers/video/fbdev/core/fb.o
  LD  drivers/acpi/built-in.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/video/built-in.o
  LD  drivers/usb/core/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
Makefile:987: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

[Lionel Landwerlin]

From: Bob Paauwe 

The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

v2: Update the comment with a FIXME.  (Daniel)

v3: Update arguments of the gamma_set vfunc (Lionel)

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Signed-off-by: Bob Paauwe 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9337d3a..f18a346 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13924,8 +13924,45 @@ out:
 
 #undef for_each_intel_crtc_masked
 
+/*
+ * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
+ *drm_atomic_helper_legacy_gamma_set() directly.
+ */
+static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_crtc_state *state;
+
+   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, size);
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(>base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+}
+
 static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,
-- 
2.8.1

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

[Intel-gfx] [PATCH] Nightly color management fixes

[Lionel Landwerlin]

Nightly has gone through some atomic reverts, we just need a single
patch to fix the remaining color management issues.

Cheers,

Lionel

Bob Paauwe (1):
  drm/i915: Set legacy properties when using legacy gamma set IOCTL.

 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 1 file changed, 38 insertions(+), 1 deletion(-)

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

[Intel-gfx] [PATCH 1/2] drm/i915: add missing condition for committing planes on crtc

[Lionel Landwerlin]

The i915 driver checks for color management properties changes as part
of a plane update. Therefore a color management update must imply a
plane update, otherwise we never update the transformation matrixes
and degamma/gamma LUTs.

v2: add comment about moving the commit of color management registers
to an async worker

v3: Commit color management register right after vblank

v4: Move back color management commit condition together with planes
commit

v5: Trigger color management commit through the planes commit (Daniel)

v6: Make plane change update more readable

igt-testcase: kms_pipe_color --run-subtests ctm-*
Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.)
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04452cf..3074c56 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11997,6 +11997,12 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = intel_color_check(crtc, crtc_state);
if (ret)
return ret;
+
+   /*
+* Changing color management on Intel hardware is
+* handled as part of planes update.
+*/
+   crtc_state->planes_changed = true;
}
 
ret = 0;
-- 
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/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

[Lionel Landwerlin]

From: Bob Paauwe 

The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

v2: Update the comment with a FIXME.  (Daniel)

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Signed-off-by: Bob Paauwe 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3074c56..3269af4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13806,8 +13806,45 @@ out:
 
 #undef for_each_intel_crtc_masked
 
+/*
+ * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
+ *drm_atomic_helper_legacy_gamma_set() directly.
+ */
+static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t start, uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_crtc_state *state;
+
+   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, start, size);
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(>base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(>base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+}
+
 static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,
-- 
2.8.1

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

[Intel-gfx] [PATCH 0/2] Color management fixed for 4.7

[Lionel Landwerlin]

A couple of fixes are needed to fix commit issues with color
management properties.

Cheers,

Lionel

Bob Paauwe (1):
  drm/i915: Set legacy properties when using legacy gamma set IOCTL.
(v2)

Lionel Landwerlin (1):
  drm/i915: add missing condition for committing planes on crtc

 drivers/gpu/drm/i915/intel_display.c | 45 +++-
 1 file changed, 44 insertions(+), 1 deletion(-)

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Disable waitboosting for fence_wait()

[Mika Kuoppala]

Chris Wilson  writes:

> 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.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 7 ---
>  drivers/gpu/drm/i915/i915_gem_request.h | 1 +
>  2 files changed, 5 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..bfec4a88707d 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_ERR(rps) && INTEL_GEN(req->i915) >= 6)
>   gen6_rps_boost(req->i915, rps, req->emitted_jiffies);
>

The intention here is to boost even if rps client is NULL?
Assuming so could you elaborate why.

Thanks,
-Mika


>   /* 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_ERR_OR_NULL(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..f7f497a07893 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -206,6 +206,7 @@ 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)
>  
>  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 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/9] drm/i915: Flush logical context image out to memory upon suspend

[Patchwork]

== Series Details ==

Series: series starting with [1/9] drm/i915: Flush logical context image out to 
memory upon suspend
URL   : https://patchwork.freedesktop.org/series/9922/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (ro-bdw-i7-5557U)
Test gem_sync:
Subgroup basic-store-each:
pass   -> DMESG-FAIL (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor:
dmesg-warn -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i7-5557U)
Test vgem_basic:
Subgroup debugfs:
incomplete -> PASS   (ro-snb-i7-2620M)

fi-kbl-qkkr  total:241  pass:174  dwarn:26  dfail:0   fail:10  skip:31 
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:214  dwarn:1   dfail:0   fail:7   skip:19 
ro-bdw-i7-5600u  total:241  pass:198  dwarn:0   dfail:1   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_1500/

c01b445 drm-intel-nightly: 2016y-07m-15d-07h-02m-07s UTC integration manifest
acd076e drm/i915: Mark imported dma-buf objects as being coherent
ab7e428f drm/i915: Wait on external rendering for GEM objects
bf0ac62 drm/i915: Disable waitboosting for mmioflips/semaphores
fdf757d drm/i915: Disable waitboosting for fence_wait()
4b17dce drm/i915: Derive GEM requests from dma-fence
880dc6c drm/i915: Mark all current requests as complete before resetting them
b7f8075 drm/i915: Retire oldest completed request before allocating next
13b5f9c drm/i915: Move GEM request routines to i915_gem_request.c
af13418 drm/i915: Flush logical context image out to memory upon suspend

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

Re: [Intel-gfx] [Beignet] [Patch V2] intel: Export pooled EU and min no. of eus in a pool.

[Chris Wilson]

On Fri, Jul 15, 2016 at 11:37:41AM +0100, Arun Siluvery wrote:
> On 15/07/2016 08:08, Yang Rong wrote:
> >Update kernel interface with new I915_GETPARAM ioctl entries for
> >pooled EU and min no. of eus in a pool. Add a wrapping function
> >for each parameter. Userspace drivers need these values when decide
> >the thread count. This kernel enabled pooled eu by default for BXT
> >and for fused down 2x6 parts it is advised to turn it off.
> >
> >But there is another HW issue in these parts (fused
> >down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
> >workaround. In this case the pool configuration changes depending upon
> >which subslice is disabled and the no. of eus in a pool is different,
> >So userspace need to know min no. of eus in a pool.
> >
> >V2: use return value as the query results.
> > ret < 0 when error, ret = 0 when not support, and ret > 0 indicate
> > query results.(Chris)
> >
> >Signed-off-by: Yang Rong 
> >---
> 
> [+ chris, intel-gfx]
> 
> 
> regards
> Arun
> 
> >  include/drm/i915_drm.h   |  2 ++
> >  intel/intel_bufmgr.h |  3 +++
> >  intel/intel_bufmgr_gem.c | 32 
> >  3 files changed, 37 insertions(+)
> >
> >diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> >index c4ce6b2..eb611a7 100644
> >--- a/include/drm/i915_drm.h
> >+++ b/include/drm/i915_drm.h
> >@@ -357,6 +357,8 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_HAS_GPU_RESET35
> >  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
> >  #define I915_PARAM_HAS_EXEC_SOFTPIN 37
> >+#define I915_PARAM_HAS_POOLED_EU 38
> >+#define I915_PARAM_MIN_EU_IN_POOL39
> >
> >  typedef struct drm_i915_getparam {
> > __s32 param;
> >diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> >index a1abbcd..96a4d9d 100644
> >--- a/intel/intel_bufmgr.h
> >+++ b/intel/intel_bufmgr.h
> >@@ -273,6 +273,9 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
> >  int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
> >  int drm_intel_get_eu_total(int fd, unsigned int *eu_total);
> >
> >+int drm_intel_get_pooled_eu(int fd);
> >+int drm_intel_get_min_eu_in_pool(int fd);
> >+
> >  /** @{ Compatibility defines to keep old code building despite the symbol 
> > rename
> >   * from dri_* to drm_intel_*
> >   */
> >diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> >index 0a4012b..4d9899d 100644
> >--- a/intel/intel_bufmgr_gem.c
> >+++ b/intel/intel_bufmgr_gem.c
> >@@ -3237,6 +3237,38 @@ drm_intel_get_eu_total(int fd, unsigned int *eu_total)
> > return 0;
> >  }
> >
> >+int
> >+drm_intel_get_pooled_eu(int fd)
> >+{
> >+drm_i915_getparam_t gp;
> >+int ret;
> >+
> >+memclear(gp);
> >+gp.param = I915_PARAM_HAS_POOLED_EU;
> >+gp.value = 
> >+ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> >+if (ret)
> >+return -errno;

Do I need to point out how the above is broken?

if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ))
return -errno;
-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 6/9] drm/i915: Disable waitboosting for fence_wait()

[Joonas Lahtinen]

On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> +#define NO_WAITBOOST ERR_PTR(-1)

This does not seem to be a very common idiom in kernel, just add flags
maybe.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Move GEM request routines to i915_gem_request.c

[Mika Kuoppala]

Chris Wilson  writes:

> 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 

> ---
>  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 e73c0fc84c73..a4767c198413 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 

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Flush logical context image out to memory upon suspend

[Mika Kuoppala]

Chris Wilson  writes:

> Before suspend, and especially before building the hibernation image, we
> need to context image to be coherent in memory. To do this we require
> that we perform a context switch to a disposable context (i.e. the
> dev_priv->kernel_context) - when that switch is complete, all other
> context images will be complete. This leaves the kernel_context image as
> incomplete, but fortunately that is disposable and we can do a quick
> fixup of the logical state after resuming.
>
> Testcase: igt/gem_exec_suspend # bsw
> References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  4 +---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 46 
> +
>  3 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 15440123e38d..c5b7b8e0678a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_csr_ucode_resume(dev_priv);
>  
> - mutex_lock(>struct_mutex);
> - i915_gem_restore_gtt_mappings(dev);
> - mutex_unlock(>struct_mutex);
> + i915_gem_resume(dev);
>  
>   i915_restore_state(dev);
>   intel_opregion_setup(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1ec523d29789..e73c0fc84c73 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
>  void i915_gem_cleanup_engines(struct drm_device *dev);
>  int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
>  int __must_check i915_gem_suspend(struct drm_device *dev);
> +void i915_gem_resume(struct drm_device *dev);
>  void __i915_add_request(struct drm_i915_gem_request *req,
>   struct drm_i915_gem_object *batch_obj,
>   bool flush_caches);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index cf0e8aa8035c..8b42a5101f11 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4974,6 +4974,35 @@ i915_gem_stop_engines(struct drm_device *dev)
>   dev_priv->gt.stop_engine(engine);
>  }
>  
> +static int switch_to_kernel_context(struct drm_i915_private *dev_priv)
> +{
> + struct intel_engine_cs *engine;
> +
> + for_each_engine(engine, dev_priv) {
> + struct drm_i915_gem_request *req;
> + int ret;
> +
> + if (engine->last_context == NULL)
> + continue;
> +
> + if (engine->last_context == dev_priv->kernel_context)
> + continue;
> +
> + req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
> + if (IS_ERR(req))
> + return PTR_ERR(req);
> +
> + ret = 0;
> + if (!i915.enable_execlists)
> + ret = i915_switch_context(req);
> + i915_add_request_no_flush(req);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +

Why do you want keep this separate? Altho the evict one is a little
bit different and as I didn't see any perf implications: Why not
consolidate the evict one and this one and have i915_gem_idle which
would park to default and wait for idle.

Other than that, this all looks fine.

-Mika



>  int
>  i915_gem_suspend(struct drm_device *dev)
>  {
> @@ -4983,6 +5012,10 @@ i915_gem_suspend(struct drm_device *dev)
>   intel_suspend_gt_powersave(dev_priv);
>  
>   mutex_lock(>struct_mutex);
> + ret = switch_to_kernel_context(dev_priv);
> + if (ret)
> + goto err;
> +
>   ret = i915_gem_wait_for_idle(dev_priv);
>   if (ret)
>   goto err;
> @@ -5009,6 +5042,19 @@ err:
>   return ret;
>  }
>  
> +void i915_gem_resume(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + mutex_lock(>struct_mutex);
> +
> + if (i915.enable_execlists)
> + intel_lr_context_reset(dev_priv, dev_priv->kernel_context);
> +
> + i915_gem_restore_gtt_mappings(dev);
> + mutex_unlock(>struct_mutex);
> +}
> +
>  void i915_gem_init_swizzling(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -- 
> 2.8.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Move GEM request routines to i915_gem_request.c

[Joonas Lahtinen]

On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> 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 
> ---
>  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
> 

Assuming pure code motion, 

Reviewed-by: Joonas Lahtinen 

Might wanna CC people who are working with the moved functions.

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

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

[Sedat Dilek]

On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson  wrote:
> On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
>> have reported. )
>> The call-trace is reproducible with my setup and seen on every boot.
>>
>> Not sure if this is a problem in intel-gfx or fbdev.
>
> Personally, I blamed backlight,
> https://patchwork.freedesktop.org/patch/95769/
>

Thanks, I try the patch when I am at home in front of my machine.

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

Re: [Intel-gfx] [Beignet] [Patch V2] intel: Export pooled EU and min no. of eus in a pool.

[Arun Siluvery]

On 15/07/2016 08:08, Yang Rong wrote:

Update kernel interface with new I915_GETPARAM ioctl entries for
pooled EU and min no. of eus in a pool. Add a wrapping function
for each parameter. Userspace drivers need these values when decide
the thread count. This kernel enabled pooled eu by default for BXT
and for fused down 2x6 parts it is advised to turn it off.

But there is another HW issue in these parts (fused
down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
workaround. In this case the pool configuration changes depending upon
which subslice is disabled and the no. of eus in a pool is different,
So userspace need to know min no. of eus in a pool.

V2: use return value as the query results.
 ret < 0 when error, ret = 0 when not support, and ret > 0 indicate
 query results.(Chris)

Signed-off-by: Yang Rong 
---


[+ chris, intel-gfx]


regards
Arun


  include/drm/i915_drm.h   |  2 ++
  intel/intel_bufmgr.h |  3 +++
  intel/intel_bufmgr_gem.c | 32 
  3 files changed, 37 insertions(+)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c4ce6b2..eb611a7 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -357,6 +357,8 @@ typedef struct drm_i915_irq_wait {
  #define I915_PARAM_HAS_GPU_RESET   35
  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
  #define I915_PARAM_HAS_EXEC_SOFTPIN37
+#define I915_PARAM_HAS_POOLED_EU 38
+#define I915_PARAM_MIN_EU_IN_POOL39

  typedef struct drm_i915_getparam {
__s32 param;
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index a1abbcd..96a4d9d 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -273,6 +273,9 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
  int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
  int drm_intel_get_eu_total(int fd, unsigned int *eu_total);

+int drm_intel_get_pooled_eu(int fd);
+int drm_intel_get_min_eu_in_pool(int fd);
+
  /** @{ Compatibility defines to keep old code building despite the symbol 
rename
   * from dri_* to drm_intel_*
   */
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 0a4012b..4d9899d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3237,6 +3237,38 @@ drm_intel_get_eu_total(int fd, unsigned int *eu_total)
return 0;
  }

+int
+drm_intel_get_pooled_eu(int fd)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.param = I915_PARAM_HAS_POOLED_EU;
+   gp.value = 
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return ret;
+}
+
+int
+drm_intel_get_min_eu_in_pool(int fd)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.param = I915_PARAM_MIN_EU_IN_POOL;
+   gp.value = 
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return ret;
+}
+
  /**
   * Annotate the given bo for use in aub dumping.
   *



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

[Intel-gfx] [PATCH 5/9] 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 7/9] 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
consumer is waiting upon the results. With the introduction of NO_WAITBOOST
in the previous patch, we can finally disable these needless boosts.

Signed-off-by: Chris Wilson 
---
 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 a4767c198413..08d9c081e9c8 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 40cc3da68611..2ec78aa7279e 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 9337d3a7b83d..813c9c3b32ca 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 9/9] 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 6/9] 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.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 7 ---
 drivers/gpu/drm/i915/i915_gem_request.h | 1 +
 2 files changed, 5 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..bfec4a88707d 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_ERR(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_ERR_OR_NULL(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..f7f497a07893 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -206,6 +206,7 @@ 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)
 
 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 8/9] 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).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 42 ++---
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2ec78aa7279e..c9ff9e3f348a 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 = i915_gem_object_wait_rendering(obj, !write);
if (ret)
return ret;
 
+   if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
+   return 0;
+
/* Flush and acquire obj->pages so that we are coherent through
 * direct access in memory with previous cached writes through
 * shmemfs and that our cache domain tracking remains valid.
@@ -3752,13 +3764,13 @@ i915_gem_object_set_to_cpu_domain(struct 
drm_i915_gem_object *obj, bool write)
uint32_t old_write_domain, old_read_domains;
int ret;
 
-   if 

[Intel-gfx] [PATCH 2/9] 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 
---
 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 e73c0fc84c73..a4767c198413 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 which this request was emitted, in jiffies. */
-   unsigned long emitted_jiffies;
-
-   /** global list 

[Intel-gfx] [PATCH 4/9] 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 10e5db3f294e..40cc3da68611 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 1/9] drm/i915: Flush logical context image out to memory upon suspend

[Chris Wilson]

Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will be complete. This leaves the kernel_context image as
incomplete, but fortunately that is disposable and we can do a quick
fixup of the logical state after resuming.

Testcase: igt/gem_exec_suspend # bsw
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 +---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 46 +
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 15440123e38d..c5b7b8e0678a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1590,9 +1590,7 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_csr_ucode_resume(dev_priv);
 
-   mutex_lock(>struct_mutex);
-   i915_gem_restore_gtt_mappings(dev);
-   mutex_unlock(>struct_mutex);
+   i915_gem_resume(dev);
 
i915_restore_state(dev);
intel_opregion_setup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ec523d29789..e73c0fc84c73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3384,6 +3384,7 @@ void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
 int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_suspend(struct drm_device *dev);
+void i915_gem_resume(struct drm_device *dev);
 void __i915_add_request(struct drm_i915_gem_request *req,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf0e8aa8035c..8b42a5101f11 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4974,6 +4974,35 @@ i915_gem_stop_engines(struct drm_device *dev)
dev_priv->gt.stop_engine(engine);
 }
 
+static int switch_to_kernel_context(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   struct drm_i915_gem_request *req;
+   int ret;
+
+   if (engine->last_context == NULL)
+   continue;
+
+   if (engine->last_context == dev_priv->kernel_context)
+   continue;
+
+   req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
+   if (IS_ERR(req))
+   return PTR_ERR(req);
+
+   ret = 0;
+   if (!i915.enable_execlists)
+   ret = i915_switch_context(req);
+   i915_add_request_no_flush(req);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 int
 i915_gem_suspend(struct drm_device *dev)
 {
@@ -4983,6 +5012,10 @@ i915_gem_suspend(struct drm_device *dev)
intel_suspend_gt_powersave(dev_priv);
 
mutex_lock(>struct_mutex);
+   ret = switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err;
+
ret = i915_gem_wait_for_idle(dev_priv);
if (ret)
goto err;
@@ -5009,6 +5042,19 @@ err:
return ret;
 }
 
+void i915_gem_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   mutex_lock(>struct_mutex);
+
+   if (i915.enable_execlists)
+   intel_lr_context_reset(dev_priv, dev_priv->kernel_context);
+
+   i915_gem_restore_gtt_mappings(dev);
+   mutex_unlock(>struct_mutex);
+}
+
 void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.8.1

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

[Intel-gfx] [PATCH 3/9] 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] Derive requests from dma-buf fence

[Chris Wilson]

This is the minimal conversion to derive struct i915_gem_request from
dma-buf fences. They are still only used privately (i.e. the requests
are not attached to the dma-buf or any reservation object so not exposed
to any other driver or userspace) and so we defer the issue of RCU
access to the request until later - until we have annotations over own
access to the request so that we can catch RCU issues.

This series just looks at the issues surrounding using requests as
fences, plus a bonus patch aimed at BAT/bsw.
-Chris

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

[Intel-gfx] [Eaglelake][i915] pipe state doesn't match

[Felix Miata]

I looked for a match on https://bugs.freedesktop.org/query.cgi but found
nothing looking like a close match that hadn't been marked fixed or
duplicate.

This is happening on a Dell Optiplex 780 in every openSUSE boot at least
as far back as kernel 3.16 in v13.2, but is not evident in v13.1 running
3.12.59. It's also evident in Knoppix 7.6.1 & kernel 4.2.6. This is full
dmesg from Tumbleweed's kernel 4.6.3, vaapi-intel-driver-1.7.0 and
libdrm2-2.4.68/libdrm_intel1-2.4.68, with the following cmdline:
audit=0 ipv6.disable=1 net.ifnames=0 noresume splash=0 vga=791 
video=1024x768@60 video=1440x900@60 3 
http://fm.no-ip.com/Tmp/SUSE/Factory/dmsg-gx780-tw20160710-k4631.txt

Dmesg excerpt:
[   11.571101] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
has_audio (expected 1, found 0)
[   11.571102] [ cut here ]
[   11.571128] WARNING: CPU: 0 PID: 71 at 
../drivers/gpu/drm/i915/intel_display.c:12921 
intel_modeset_check_state+0x6b6/0x840 [i915]
[   11.571129] pipe state doesn't match!
[   11.571149] Modules linked in: snd_hda_core snd_hwdep mei_wdt snd_pcm i915 
snd_timer drm_kms_helper dm_mod snd mei_me drm e1000e fb_sys_fops mei coretemp 
kvm_intel kvm dell_wmi ptp sparse_keymap acpi_cpufreq dell_smbios video ppdev 
tpm_tis syscopyarea button iTCO_wdt tpm shpchp parport_pc gpio_ich sysfillrect 
dcdbas parport wmi iTCO_vendor_support sysimgblt pps_core i2c_i801 floppy(+) 
lpc_ich mfd_core irqbypass soundcore i2c_algo_bit 8250_fintek pcspkr 
hid_generic usbhid uhci_hcd ehci_pci ehci_hcd serio_raw sr_mod cdrom usbcore 
usb_common ata_generic sg
[   11.571151] CPU: 0 PID: 71 Comm: kworker/u16:6 Not tainted 4.6.3-1-default #1
[   11.571152] Hardware name: Dell Inc. OptiPlex 780 /03NVJ6, 
BIOS A14 08/21/2012
[   11.571155] Workqueue: events_unbound async_run_entry_fn
[   11.571157]   8138a6f4 8800d7b83988 

[   11.571158]  8107b10e 8800d4f7b800 8800d7b839d8 
880112574000
[   11.571159]  880112a00c00 8800d3734400 8800d7b24000 
8107b17f
[   11.571160] Call Trace:
[   11.571168]  [] dump_trace+0x5e/0x300
[   11.571171]  [] show_stack_log_lvl+0x10c/0x180
[   11.571173]  [] show_stack+0x21/0x40
[   11.571175]  [] dump_stack+0x5c/0x78
[   11.571178]  [] __warn+0xbe/0xe0
[   11.571180]  [] warn_slowpath_fmt+0x4f/0x60
[   11.571206]  [] intel_modeset_check_state+0x6b6/0x840 
[i915]
[   11.571240]  [] intel_atomic_commit+0x832/0xc50 [i915]
[   11.571252]  [] restore_fbdev_mode+0x22c/0x260 
[drm_kms_helper]
[   11.571261]  [] 
drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper]
[   11.571267]  [] drm_fb_helper_set_par+0x29/0x50 
[drm_kms_helper]
[   11.571293]  [] intel_fbdev_set_par+0x16/0x60 [i915]
[   11.571297]  [] fbcon_init+0x563/0x5f0
[   11.571301]  [] visual_init+0xc3/0x120
[   11.571303]  [] do_bind_con_driver+0x1cf/0x3b0
[   11.571305]  [] do_take_over_console+0x14e/0x1c0
[   11.571308]  [] do_fbcon_takeover+0x58/0xb0
[   11.571311]  [] notifier_call_chain+0x45/0x70
[   11.571313]  [] __blocking_notifier_call_chain+0x41/0x60
[   11.571315]  [] register_framebuffer+0x202/0x330
[   11.571322]  [] drm_fb_helper_initial_config+0x26c/0x420 
[drm_kms_helper]
[   11.571348]  [] intel_fbdev_initial_config+0x1b/0x30 [i915]
[   11.571350]  [] async_run_entry_fn+0x43/0x140
[   11.571352]  [] process_one_work+0x1ed/0x4b0
[   11.571354]  [] worker_thread+0x47/0x4c0
[   11.571357]  [] kthread+0xbd/0xe0
[   11.571360]  [] ret_from_fork+0x22/0x40
[   11.572001] DWARF2 unwinder stuck at ret_from_fork+0x22/0x40
[   11.572001] Leftover inexact backtrace:
[   11.572001]  [] ? kthread_worker_fn+0x170/0x170
[   11.572932] ---[ end trace a60da7830c1f6140 ]---
[   11.653070] Console: switching to colour frame buffer device 180x56
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Eaglelake][i915] pipe state doesn't match

[Felix Miata]

I suspect this might be at root in these threads:
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089805.html
https://lists.freedesktop.org/archives/intel-gfx/2016-June/097652.html

Felix Miata composed on 2016-07-15 05:43 (UTC-0400):


I looked for a match on https://bugs.freedesktop.org/query.cgi but found
nothing looking like a close match that hadn't been marked fixed or
duplicate.



This is happening on a Dell Optiplex 780 in every openSUSE boot at least
as far back as kernel 3.16 in v13.2, but is not evident in v13.1 running
3.12.59. It's also evident in Knoppix 7.6.1 & kernel 4.2.6. This is full
dmesg from Tumbleweed's kernel 4.6.3, vaapi-intel-driver-1.7.0 and
libdrm2-2.4.68/libdrm_intel1-2.4.68, with the following cmdline:
audit=0 ipv6.disable=1 net.ifnames=0 noresume splash=0 vga=791 
video=1024x768@60 video=1440x900@60 3
http://fm.no-ip.com/Tmp/SUSE/Factory/dmsg-gx780-tw20160710-k4631.txt



Dmesg excerpt:
[   11.571101] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
has_audio (expected 1, found 0)
[   11.571102] [ cut here ]
[   11.571128] WARNING: CPU: 0 PID: 71 at 
../drivers/gpu/drm/i915/intel_display.c:12921 
intel_modeset_check_state+0x6b6/0x840 [i915]
[   11.571129] pipe state doesn't match!
[   11.571149] Modules linked in: snd_hda_core snd_hwdep mei_wdt snd_pcm i915 
snd_timer drm_kms_helper dm_mod snd mei_me drm e1000e fb_sys_fops mei coretemp 
kvm_intel kvm dell_wmi ptp sparse_keymap acpi_cpufreq dell_smbios video ppdev 
tpm_tis syscopyarea button iTCO_wdt tpm shpchp parport_pc gpio_ich sysfillrect 
dcdbas parport wmi iTCO_vendor_support sysimgblt pps_core i2c_i801 floppy(+) 
lpc_ich mfd_core irqbypass soundcore i2c_algo_bit 8250_fintek pcspkr 
hid_generic usbhid uhci_hcd ehci_pci ehci_hcd serio_raw sr_mod cdrom usbcore 
usb_common ata_generic sg
[   11.571151] CPU: 0 PID: 71 Comm: kworker/u16:6 Not tainted 4.6.3-1-default #1
[   11.571152] Hardware name: Dell Inc. OptiPlex 780 /03NVJ6, 
BIOS A14 08/21/2012
[   11.571155] Workqueue: events_unbound async_run_entry_fn
[   11.571157]   8138a6f4 8800d7b83988 

[   11.571158]  8107b10e 8800d4f7b800 8800d7b839d8 
880112574000
[   11.571159]  880112a00c00 8800d3734400 8800d7b24000 
8107b17f
[   11.571160] Call Trace:
[   11.571168]  [] dump_trace+0x5e/0x300
[   11.571171]  [] show_stack_log_lvl+0x10c/0x180
[   11.571173]  [] show_stack+0x21/0x40
[   11.571175]  [] dump_stack+0x5c/0x78
[   11.571178]  [] __warn+0xbe/0xe0
[   11.571180]  [] warn_slowpath_fmt+0x4f/0x60
[   11.571206]  [] intel_modeset_check_state+0x6b6/0x840 
[i915]
[   11.571240]  [] intel_atomic_commit+0x832/0xc50 [i915]
[   11.571252]  [] restore_fbdev_mode+0x22c/0x260 
[drm_kms_helper]
[   11.571261]  [] 
drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper]
[   11.571267]  [] drm_fb_helper_set_par+0x29/0x50 
[drm_kms_helper]
[   11.571293]  [] intel_fbdev_set_par+0x16/0x60 [i915]
[   11.571297]  [] fbcon_init+0x563/0x5f0
[   11.571301]  [] visual_init+0xc3/0x120
[   11.571303]  [] do_bind_con_driver+0x1cf/0x3b0
[   11.571305]  [] do_take_over_console+0x14e/0x1c0
[   11.571308]  [] do_fbcon_takeover+0x58/0xb0
[   11.571311]  [] notifier_call_chain+0x45/0x70
[   11.571313]  [] __blocking_notifier_call_chain+0x41/0x60
[   11.571315]  [] register_framebuffer+0x202/0x330
[   11.571322]  [] drm_fb_helper_initial_config+0x26c/0x420 
[drm_kms_helper]
[   11.571348]  [] intel_fbdev_initial_config+0x1b/0x30 [i915]
[   11.571350]  [] async_run_entry_fn+0x43/0x140
[   11.571352]  [] process_one_work+0x1ed/0x4b0
[   11.571354]  [] worker_thread+0x47/0x4c0
[   11.571357]  [] kthread+0xbd/0xe0
[   11.571360]  [] ret_from_fork+0x22/0x40
[   11.572001] DWARF2 unwinder stuck at ret_from_fork+0x22/0x40
[   11.572001] Leftover inexact backtrace:
[   11.572001]  [] ? kthread_worker_fn+0x170/0x170
[   11.572932] ---[ end trace a60da7830c1f6140 ]---
[   11.653070] Console: switching to colour frame buffer device 180x56

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init

[Patchwork]

== Series Details ==

Series: drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init
URL   : https://patchwork.freedesktop.org/series/9918/
State : warning

== Summary ==

Series 9918v1 drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in 
dsi_init
http://patchwork.freedesktop.org/api/1.0/series/9918/revisions/1/mbox

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-ivb-i7-3770)
pass   -> SKIP   (fi-skl-i7-6700k)
pass   -> SKIP   (ro-skl3-i5-6260u)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-ivb-i7-3770)
pass   -> SKIP   (fi-skl-i7-6700k)
pass   -> SKIP   (ro-skl3-i5-6260u)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-ivb-i7-3770)
pass   -> SKIP   (fi-skl-i7-6700k)
pass   -> SKIP   (ro-skl3-i5-6260u)
Subgroup basic-subslice-total:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-ivb-i7-3770)
pass   -> SKIP   (fi-skl-i7-6700k)
pass   -> SKIP   (ro-skl3-i5-6260u)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (ro-ivb-i7-3770)
pass   -> SKIP   (fi-skl-i7-6700k)
pass   -> SKIP   (ro-skl3-i5-6260u)
Test drv_module_reload_basic:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   (ro-hsw-i3-4010u)
pass   -> SKIP   (fi-skl-i5-6260u)
pass   -> SKIP   (ro-bdw-i7-5600u)
pass   -> SKIP   (ro-bdw-i5-5250u)
pass   -> SKIP   (ro-snb-i7-2620M)
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> SKIP   (fi-snb-i7-2600)
pass   -> SKIP   (fi-skl-i7-6700k)
dmesg-warn -> SKIP   (ro-skl3-i5-6260u)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (ro-bdw-i7-5557U)
pass   -> SKIP   (ro-ilk1-i5-650)
pass   -> SKIP   

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl) (rev2)

[Patchwork]

== Series Details ==

Series: drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl) (rev2)
URL   : https://patchwork.freedesktop.org/series/9757/
State : failure

== Summary ==

Series 9757v2 drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)
http://patchwork.freedesktop.org/api/1.0/series/9757/revisions/2/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (ro-bdw-i7-5557U)
Test gem_sync:
Subgroup basic-store-each:
pass   -> DMESG-FAIL (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor:
dmesg-warn -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-skl-i7-6700k)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> FAIL   (ro-bdw-i7-5557U)
skip   -> FAIL   (ro-ilk1-i5-650)
skip   -> FAIL   (ro-hsw-i3-4010u)
skip   -> FAIL   (fi-skl-i5-6260u)
skip   -> FAIL   (ro-skl3-i5-6260u)
skip   -> FAIL   (ro-bdw-i5-5250u)
skip   -> FAIL   (ro-hsw-i7-4770r)
skip   -> FAIL   (fi-snb-i7-2600)
skip   -> FAIL   (ro-ivb-i7-3770)
skip   -> FAIL   (ro-byt-n2820)
Subgroup basic-fence-wait-default:
skip   -> FAIL   (ro-bdw-i7-5557U)
skip   -> FAIL   (ro-ilk1-i5-650)
skip   -> FAIL   (ro-hsw-i3-4010u)
skip   -> FAIL   (fi-skl-i5-6260u)
skip   -> FAIL   (ro-bdw-i7-5600u)
skip   -> FAIL   (ro-snb-i7-2620M)
skip   -> FAIL   (ro-bdw-i5-5250u)
skip   -> FAIL   (ro-hsw-i7-4770r)
skip   -> FAIL   (fi-snb-i7-2600)
skip   -> FAIL   (ro-ivb-i7-3770)
skip   -> FAIL   (ro-byt-n2820)
skip   -> FAIL   (ro-skl3-i5-6260u)
Test vgem_basic:
Subgroup debugfs:
incomplete -> PASS   (ro-snb-i7-2620M)
Subgroup dmabuf-fence:
skip   -> FAIL   (ro-bdw-i7-5557U)
skip   -> FAIL   (ro-ilk1-i5-650)
skip   -> FAIL   (ro-hsw-i3-4010u)
skip   -> FAIL   (fi-skl-i5-6260u)
skip   -> FAIL   (ro-bdw-i7-5600u)
skip   -> FAIL   (ro-snb-i7-2620M)
skip   -> FAIL   (ro-bdw-i5-5250u)
skip   -> FAIL   (ro-hsw-i7-4770r)
skip   -> FAIL   (fi-snb-i7-2600)
skip   -> FAIL   (ro-ivb-i7-3770)
skip   -> FAIL   (ro-byt-n2820)
skip   -> FAIL   (ro-skl3-i5-6260u)
Subgroup dmabuf-fence-before:
skip   -> FAIL   (ro-bdw-i7-5557U)
skip   -> FAIL   (ro-ilk1-i5-650)
skip   -> FAIL   (ro-hsw-i3-4010u)
skip   -> FAIL   (fi-skl-i5-6260u)
skip   -> FAIL   (ro-bdw-i7-5600u)
skip   -> FAIL   (ro-snb-i7-2620M)
skip   -> FAIL   (ro-bdw-i5-5250u)
skip   -> FAIL   (ro-hsw-i7-4770r)
skip   -> FAIL   (fi-snb-i7-2600)
skip   -> FAIL   (ro-ivb-i7-3770)
skip   -> FAIL   (ro-byt-n2820)
skip   -> FAIL   (ro-skl3-i5-6260u)

fi-kbl-qkkr  total:241  pass:174  dwarn:28  dfail:1   fail:10  skip:28 
fi-skl-i5-6260u  total:241  pass:217  dwarn:0   dfail:0   fail:11  skip:13 
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:11  skip:40 
ro-bdw-i5-5250u  total:241  pass:213  dwarn:4   dfail:0   fail:11  skip:13 
ro-bdw-i7-5557U  total:241  pass:214  dwarn:0   dfail:0   fail:11  skip:16 
ro-bdw-i7-5600u  total:241  pass:198  dwarn:0   dfail:1   fail:10  skip:32 
ro-byt-n2820 total:241  pass:191  dwarn:0   dfail:0   fail:12  skip:38 
ro-hsw-i3-4010u  total:241  pass:206  dwarn:0   dfail:0   fail:11  skip:24 
ro-hsw-i7-4770r  total:241  pass:206  dwarn:0   dfail:0   fail:11  skip:24 
ro-ilk-i7-620lm  total:241  pass:166  dwarn:0   dfail:0   fail:12  skip:63 
ro-ilk1-i5-650   total:236  pass:166  dwarn:0   dfail:0   fail:12  skip:58 
ro-ivb-i7-3770   total:241  pass:197  dwarn:0   dfail:0   fail:11  skip:33 
ro-skl3-i5-6260u total:241  pass:217  dwarn:1   dfail:0   fail:11  skip:12 
ro-snb-i7-2620M  total:241  pass:188  dwarn:0   dfail:0   fail:11  skip:42 

Results at 

Re: [Intel-gfx] [PATCH] drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init

[Shobhit Kumar]

On Fri, Jul 15, 2016 at 2:33 PM, Shobhit Kumar  wrote:
> On devices that have MIPI DSI panel control and PWM control comming from
> CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
> driver. Defer probing for later in case we fail to get these devices.
>
> v2: Rebased on latest drm-intel-nightly
> Added failure check for pwm_get which got missed out
>

Just an attempt and is untested yet because of lack of device which
use CRC PMIC or LPSS. Hopefully can get some testing help from Stephen
and  Viric who have such devices.

Regards
Shobhit

> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  |  4 
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c | 25 +++--
>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_dsi.c | 24 +---
>  5 files changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b9a8117..9bfe0c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -648,6 +648,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
> /* Important: The output setup functions called by modeset_init need
>  * working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
> +   ret = intel_modeset_init(dev);
> +   if (ret == -EPROBE_DEFER)
> +   goto cleanup_deffered_probe;
>
> intel_guc_init(dev);
>
> @@ -675,6 +678,7 @@ cleanup_gem:
> i915_gem_fini(dev);
>  cleanup_irq:
> intel_guc_fini(dev);
> +cleanup_deffered_probe:
> drm_irq_uninstall(dev);
> intel_teardown_gmbus(dev);
>  cleanup_csr:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 03e1bfa..a9eed22 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3778,7 +3778,7 @@ void intel_device_info_dump(struct drm_i915_private 
> *dev_priv);
>
>  /* modesetting */
>  extern void intel_modeset_init_hw(struct drm_device *dev);
> -extern void intel_modeset_init(struct drm_device *dev);
> +extern int intel_modeset_init(struct drm_device *dev);
>  extern void intel_modeset_gem_init(struct drm_device *dev);
>  extern void intel_modeset_cleanup(struct drm_device *dev);
>  extern int intel_connector_register(struct drm_connector *);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index be3b2ca..b1250f2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14612,11 +14612,12 @@ static bool intel_crt_present(struct drm_device 
> *dev)
> return true;
>  }
>
> -static void intel_setup_outputs(struct drm_device *dev)
> +static int intel_setup_outputs(struct drm_device *dev)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_encoder *encoder;
> bool dpd_is_edp = false;
> +   int ret = 0;
>
> /*
>  * intel_edp_init_connector() depends on this completing first, to
> @@ -14638,7 +14639,9 @@ static void intel_setup_outputs(struct drm_device 
> *dev)
> intel_ddi_init(dev, PORT_B);
> intel_ddi_init(dev, PORT_C);
>
> -   intel_dsi_init(dev);
> +   ret = intel_dsi_init(dev);
> +   if (ret == -EPROBE_DEFER)
> +   return ret;
> } else if (HAS_DDI(dev)) {
> int found;
>
> @@ -14742,7 +14745,9 @@ static void intel_setup_outputs(struct drm_device 
> *dev)
> intel_hdmi_init(dev, CHV_HDMID, PORT_D);
> }
>
> -   intel_dsi_init(dev);
> +   ret = intel_dsi_init(dev);
> +   if (ret == -EPROBE_DEFER)
> +   return ret;
> } else if (!IS_GEN2(dev) && !IS_PINEVIEW(dev)) {
> bool found = false;
>
> @@ -14795,6 +14800,8 @@ static void intel_setup_outputs(struct drm_device 
> *dev)
> intel_init_pch_refclk(dev);
>
> drm_helper_move_panel_connectors_to_head(dev);
> +
> +   return 0;
>  }
>
>  static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
> @@ -15539,7 +15546,7 @@ fail:
> drm_modeset_acquire_fini();
>  }
>
> -void intel_modeset_init(struct drm_device *dev)
> +int intel_modeset_init(struct drm_device *dev)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct i915_ggtt *ggtt = _priv->ggtt;
> @@ -15564,7 +15571,7 @@ void intel_modeset_init(struct drm_device *dev)
> intel_init_pm(dev);
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> -   return;
> +   return 0;
>
> /*
>  * There may be no VBT; and if the BIOS enabled SSC we can
> @@ -15632,7 +15639,11 @@ void 

[Intel-gfx] [PATCH] drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init

[Shobhit Kumar]

On devices that have MIPI DSI panel control and PWM control comming from
CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
driver. Defer probing for later in case we fail to get these devices.

v2: Rebased on latest drm-intel-nightly
Added failure check for pwm_get which got missed out

Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 25 +++--
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c | 24 +---
 5 files changed, 42 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b9a8117..9bfe0c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -648,6 +648,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* Important: The output setup functions called by modeset_init need
 * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
+   ret = intel_modeset_init(dev);
+   if (ret == -EPROBE_DEFER)
+   goto cleanup_deffered_probe;
 
intel_guc_init(dev);
 
@@ -675,6 +678,7 @@ cleanup_gem:
i915_gem_fini(dev);
 cleanup_irq:
intel_guc_fini(dev);
+cleanup_deffered_probe:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
 cleanup_csr:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 03e1bfa..a9eed22 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3778,7 +3778,7 @@ void intel_device_info_dump(struct drm_i915_private 
*dev_priv);
 
 /* modesetting */
 extern void intel_modeset_init_hw(struct drm_device *dev);
-extern void intel_modeset_init(struct drm_device *dev);
+extern int intel_modeset_init(struct drm_device *dev);
 extern void intel_modeset_gem_init(struct drm_device *dev);
 extern void intel_modeset_cleanup(struct drm_device *dev);
 extern int intel_connector_register(struct drm_connector *);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index be3b2ca..b1250f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14612,11 +14612,12 @@ static bool intel_crt_present(struct drm_device *dev)
return true;
 }
 
-static void intel_setup_outputs(struct drm_device *dev)
+static int intel_setup_outputs(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_encoder *encoder;
bool dpd_is_edp = false;
+   int ret = 0;
 
/*
 * intel_edp_init_connector() depends on this completing first, to
@@ -14638,7 +14639,9 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_ddi_init(dev, PORT_B);
intel_ddi_init(dev, PORT_C);
 
-   intel_dsi_init(dev);
+   ret = intel_dsi_init(dev);
+   if (ret == -EPROBE_DEFER)
+   return ret;
} else if (HAS_DDI(dev)) {
int found;
 
@@ -14742,7 +14745,9 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_hdmi_init(dev, CHV_HDMID, PORT_D);
}
 
-   intel_dsi_init(dev);
+   ret = intel_dsi_init(dev);
+   if (ret == -EPROBE_DEFER)
+   return ret;
} else if (!IS_GEN2(dev) && !IS_PINEVIEW(dev)) {
bool found = false;
 
@@ -14795,6 +14800,8 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_init_pch_refclk(dev);
 
drm_helper_move_panel_connectors_to_head(dev);
+
+   return 0;
 }
 
 static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
@@ -15539,7 +15546,7 @@ fail:
drm_modeset_acquire_fini();
 }
 
-void intel_modeset_init(struct drm_device *dev)
+int intel_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
@@ -15564,7 +15571,7 @@ void intel_modeset_init(struct drm_device *dev)
intel_init_pm(dev);
 
if (INTEL_INFO(dev)->num_pipes == 0)
-   return;
+   return 0;
 
/*
 * There may be no VBT; and if the BIOS enabled SSC we can
@@ -15632,7 +15639,11 @@ void intel_modeset_init(struct drm_device *dev)
 
/* Just disable it once at startup */
i915_disable_vga(dev);
-   intel_setup_outputs(dev);
+
+   /* Check if we encountered -EPROBE_DEFER while initializing DSI */
+   ret = intel_setup_outputs(dev);
+   if (ret)
+   return ret;
 
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev);
@@ -15667,6 +15678,8 @@ void intel_modeset_init(struct drm_device *dev)
 * since the watermark calculation