[Intel-gfx] ✗ Ro.CI.BAT: failure for CHV vblank failures when PSR is active

[Patchwork]

== Series Details ==

Series: CHV vblank failures when PSR is active
URL   : https://patchwork.freedesktop.org/series/8477/
State : failure

== Summary ==

Applying: drm: Add vblank prepare and unprepare hooks.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/drm_irq.c
M   include/drm/drmP.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drmP.h
Auto-merging drivers/gpu/drm/drm_irq.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_irq.c
error: Failed to merge in the changes.
Patch failed at 0001 drm: Add vblank prepare and unprepare hooks.
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

[kbuild test robot]

Hi,

[auto build test WARNING on v4.7-rc2]
[cannot apply to drm-intel/for-linux-next drm/drm-next next-20160608]
[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/Dhinakaran-Pandiyan/CHV-vblank-failures-when-PSR-is-active/20160609-094028
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/drm_fb_cma_helper.c:233: warning: No description found for 
parameter 'dev'
   drivers/gpu/drm/drm_fb_cma_helper.c:233: warning: No description found for 
parameter 'file_priv'
   drivers/gpu/drm/drm_fb_cma_helper.c:233: warning: No description found for 
parameter 'mode_cmd'
   drivers/gpu/drm/drm_fb_cma_helper.c:285: warning: No description found for 
parameter 'm'
   drivers/gpu/drm/drm_fb_cma_helper.c:285: warning: No description found for 
parameter 'arg'
   include/drm/drm_dp_helper.h:750: warning: No description found for parameter 
'i2c_nack_count'
   include/drm/drm_dp_helper.h:750: warning: No description found for parameter 
'i2c_defer_count'
   drivers/gpu/drm/drm_dp_mst_topology.c:2383: warning: No description found 
for parameter 'connector'
   include/drm/drm_dp_mst_helper.h:92: warning: No description found for 
parameter 'cached_edid'
   include/drm/drm_dp_mst_helper.h:92: warning: No description found for 
parameter 'has_audio'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'max_dpcd_transaction_bytes'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'sink_count'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'total_slots'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'avail_slots'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'total_pbn'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'qlock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_msg_downq'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_down_in_progress'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payload_lock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'proposed_vcpis'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payloads'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payload_mask'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'vcpi_mask'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_waitq'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'work'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_work'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_list'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_lock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_work'
   drivers/gpu/drm/drm_dp_mst_topology.c:2383: warning: No description found 
for parameter 'connector'
   drivers/gpu/drm/drm_irq.c:176: warning: No description found for parameter 
'flags'
   include/drm/drmP.h:168: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:184: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:202: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:247: warning: No description found for parameter 'dev'
   include/drm/drmP.h:247: warning: No description found for parameter 'data'
   include/drm/drmP.h:247: warning: No description found for parameter 
'file_priv'
   include/drm/drmP.h:280: warning: No description found for parameter 'ioctl'
   include/drm/drmP.h:280: warning: No description found for parameter '_func'
   include/drm/drmP.h:280: warning: No description found for parameter '_flags'
   include/drm/drmP.h:362: warning: cannot understand function prototype: 
'struct drm_lock_data '
   include/drm/drmP.h:415: warning: cannot understand function prototype: 
'struct drm_driver '
   include/drm/drmP.h:705: warning: cannot understand function prototype: 
'struct drm_info_list '
   include/drm/drmP.h:715: warning: cannot understand function prototype: 
'struct drm_info_node '
   include/drm/drmP.h:725: warning: cannot understand function prototype: 
'struct drm_minor '
   include/drm/drmP.h:779: warning: cannot understand function prototype: 
'struct drm_device '
   drivers/gpu/drm/i915/intel_runtime_pm.c:2411: warning: No description found 
for parameter 'resume'
   drivers/gpu/drm/i915/intel_runtime_pm.c:2411: warning: No description found 
for parameter '

[Intel-gfx] [PATCH 2/3] drm/i915: Move drm_crtc_vblank_get out of disabled pre-emption area.

[Dhinakaran Pandiyan]

From: Rodrigo Vivi 

drm_crtc_vblank_get call the drm_vblank_prepare that will be used soon
to control power saving states or anything else that needs a mutex
before the vblank happens.

local_irq_disable disables kernel preemption so we won't be able
to use mutex inside drm_crtc_vblank_get. For this reason we need
to move the drm_crtc_vblank_get a little up before disabling the
interruptions.

Another option would be to use local_irq_enable + local_irq_disable
around the drm_crtc_vblank_get, but let's avoid touching the kernel
states if we can call the vblank_get a bit earlier.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_sprite.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 97b1a54..3351c7e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -94,13 +94,15 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
min = vblank_start - usecs_to_scanlines(adjusted_mode, 100);
max = vblank_start - 1;
 
-   local_irq_disable();
-
-   if (min <= 0 || max <= 0)
+   if (WARN_ON(drm_crtc_vblank_get(>base)))
return;
 
-   if (WARN_ON(drm_crtc_vblank_get(>base)))
+   local_irq_disable();
+
+   if (min <= 0 || max <= 0) {
+   drm_crtc_vblank_put(>base);
return;
+   }
 
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

[Dhinakaran Pandiyan]

PSR in CHV, unlike HSW, can get activated even if vblanks interrupts are
enabled. But, the pipe is not expected to generate timings signals
when PSR is active. Specifically, we do not get vblank interrupts in CHV
if PSR becomes active. This has led to drm_wait_vblank timing out.

Let's disable PSR using the vblank prepare hook that gets called before
enabling vblank interrupts and keep it disabled until the interrupts are
not needed.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_irq.c  | 12 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_psr.c | 61 +++-
 4 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4c8e34..03f311e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -994,6 +994,7 @@ struct i915_psr {
bool psr2_support;
bool aux_frame_sync;
bool link_standby;
+   bool vlv_src_timing;
 };
 
 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index caaf1e2..77f3d76 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2790,6 +2790,16 @@ static int gen8_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
return 0;
 }
 
+static void valleyview_prepare_vblank(struct drm_device *dev, unsigned int 
pipe)
+{
+   vlv_psr_src_timing_get(dev);
+}
+
+static void valleyview_unprepare_vblank(struct drm_device *dev, unsigned int 
pipe){
+
+   vlv_psr_src_timing_put(dev);
+}
+
 /* Called from drm generic code, passed 'crtc' which
  * we use as a pipe index
  */
@@ -4610,6 +4620,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->irq_uninstall = cherryview_irq_uninstall;
dev->driver->enable_vblank = valleyview_enable_vblank;
dev->driver->disable_vblank = valleyview_disable_vblank;
+   dev->driver->prepare_vblank = valleyview_prepare_vblank;
+   dev->driver->unprepare_vblank = valleyview_unprepare_vblank;
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else if (IS_VALLEYVIEW(dev_priv)) {
dev->driver->irq_handler = valleyview_irq_handler;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9b5f663..e2078fd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1511,6 +1511,8 @@ void intel_psr_flush(struct drm_device *dev,
 void intel_psr_init(struct drm_device *dev);
 void intel_psr_single_frame_update(struct drm_device *dev,
   unsigned frontbuffer_bits);
+void vlv_psr_src_timing_get(struct drm_device *dev);
+void vlv_psr_src_timing_put(struct drm_device *dev);
 
 /* intel_runtime_pm.c */
 int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 29a09bf..c95e680 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -462,6 +462,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
 
/* Enable PSR on the panel */
vlv_psr_enable_sink(intel_dp);
+   dev_priv->psr.vlv_src_timing = false;
 
/* On HSW+ enable_source also means go to PSR entry/active
 * state as soon as idle_frame achieved and here would be
@@ -608,8 +609,10 @@ static void intel_psr_work(struct work_struct *work)
 * The delayed work can race with an invalidate hence we need to
 * recheck. Since psr_flush first clears this and then reschedules we
 * won't ever miss a flush when bailing out here.
+* Also, do not enable PSR if source is required to generate timing
+* signals like vblanks.
 */
-   if (dev_priv->psr.busy_frontbuffer_bits)
+   if (dev_priv->psr.busy_frontbuffer_bits || dev_priv->psr.vlv_src_timing)
goto unlock;
 
intel_psr_activate(intel_dp);
@@ -708,6 +711,62 @@ void intel_psr_single_frame_update(struct drm_device *dev,
 }
 
 /**
+ * vlv_psr_src_timing_get - src timing generation requested
+ *
+ * CHV does not have HW tracking to trigger PSR exit when VBI are enabled nor
+ * does enabling vblank interrupts prevent PSR entry. This function is called
+ * before enabling VBI to exit PSR and prevent PSR re-entry until vblanks are
+ * disabled again.
+ */
+void vlv_psr_src_timing_get(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   mutex_lock(_priv->psr.lock);
+if (!dev_priv->psr.enabled) {
+mutex_unlock(_priv->psr.lock);
+return;
+   }
+
+   //Handle racing with intel_psr_work with this flag
+   dev_priv->psr.vlv_src_timing = true;
+
+   

[Intel-gfx] [PATCH 1/3] drm: Add vblank prepare and unprepare hooks.

[Dhinakaran Pandiyan]

From: Rodrigo Vivi 

This will allow drivers to control specific power saving
feature and power domains when dealing with vblanks.

Vblanks code are protected by spin_locks where we can't
have anything that can sleep. While power saving features
and power domain code have mutexes to control the states.

Mutex can sleep so they cannot be used inside spin lock areas.
So the easiest way to deal with them currently is to add these
prepare hook for pre enabling vblanks
and unprepare one for post disabling them.

Let's introduce this optional prepare and unprepare
hooks so drivers can deal with cases like this and any other
case that should require sleeping codes interacting with vblanks.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_irq.c | 28 +++-
 include/drm/drmP.h| 30 ++
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index d3124b6..c833a5d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -411,6 +411,8 @@ void drm_vblank_cleanup(struct drm_device *dev)
drm_core_check_feature(dev, DRIVER_MODESET));
 
del_timer_sync(>disable_timer);
+
+   flush_work(>unprepare.work);
}
 
kfree(dev->vblank);
@@ -419,6 +421,20 @@ void drm_vblank_cleanup(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_vblank_cleanup);
 
+static void drm_vblank_unprepare_work_fn(struct work_struct *work)
+{
+   struct drm_vblank_crtc *vblank;
+   struct drm_device *dev;
+
+   vblank = container_of(work, typeof(*vblank), unprepare.work);
+   dev = vblank->dev;
+
+   do {
+   if (dev->driver->unprepare_vblank)
+   dev->driver->unprepare_vblank(dev, vblank->pipe);
+   } while (!atomic_dec_and_test(>unprepare.counter));
+}
+
 /**
  * drm_vblank_init - initialize vblank support
  * @dev: DRM device
@@ -451,6 +467,8 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
init_waitqueue_head(>queue);
setup_timer(>disable_timer, vblank_disable_fn,
(unsigned long)vblank);
+   INIT_WORK(>unprepare.work,
+ drm_vblank_unprepare_work_fn);
}
 
DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
@@ -1241,6 +1259,9 @@ int drm_vblank_get(struct drm_device *dev, unsigned int 
pipe)
if (WARN_ON(pipe >= dev->num_crtcs))
return -EINVAL;
 
+   if (dev->driver->prepare_vblank)
+   dev->driver->prepare_vblank(dev, pipe);
+
spin_lock_irqsave(>vbl_lock, irqflags);
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, >refcount) == 1) {
@@ -1253,6 +1274,9 @@ int drm_vblank_get(struct drm_device *dev, unsigned int 
pipe)
}
spin_unlock_irqrestore(>vbl_lock, irqflags);
 
+   if (ret != 0 && dev->driver->unprepare_vblank)
+   dev->driver->unprepare_vblank(dev, pipe);
+
return ret;
 }
 EXPORT_SYMBOL(drm_vblank_get);
@@ -1305,6 +1329,9 @@ void drm_vblank_put(struct drm_device *dev, unsigned int 
pipe)
mod_timer(>disable_timer,
  jiffies + ((drm_vblank_offdelay * HZ)/1000));
}
+
+   atomic_inc(>unprepare.counter);
+   schedule_work(>unprepare.work);
 }
 EXPORT_SYMBOL(drm_vblank_put);
 
@@ -1740,7 +1767,6 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
}
 
spin_unlock_irqrestore(>event_lock, flags);
-
return 0;
 
 err_unlock:
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ed89038..544c65f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -447,6 +447,30 @@ struct drm_driver {
u32 (*get_vblank_counter) (struct drm_device *dev, unsigned int pipe);
 
/**
+* prepare_vblank - Optional prepare vblank hook.
+* @dev: DRM device
+* @pipe: counter to fetch
+*
+* Drivers that need to handle any kind of mutex or any other sleeping
+* code in combination with vblanks need to implement this hook
+* that will be called before drm_vblank_get spin_lock gets.
+*/
+   void (*prepare_vblank) (struct drm_device *dev, unsigned int pipe);
+
+   /**
+* unprepare_vblank - Optional unprepare vblank hook.
+* @dev: DRM device
+* @pipe: counter to fetch
+*
+* Drivers that need to handle any kind of mutex or any other sleeping
+* code in combination with vblanks need to implement this hook
+* that will be called in a work queue to be executed after spin lock
+* areas of drm_vblank_put.
+*/
+   void (*unprepare_vblank) (struct drm_device *dev, unsigned int pipe);
+
+
+   /**
 * 

[Intel-gfx] [PATCH 0/3] CHV vblank failures when PSR is active

[Dhinakaran Pandiyan]

IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We
do not get VBIs as the source timing generation is disabled when PSR is
active. The first two patches written by Rodrigo add drm hooks. Patch 3
deactivates PSR when VBI are needed.

[PATCH 1/3] drm: Add vblank prepare and unprepare hooks.
[PATCH 2/3] drm/i915: Move drm_crtc_vblank_get out of disabled
[PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't unregister fbdev twice

[Lukas Wunner]

On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > superfluous because the framebuffer will subsequently be unregistered by
> > drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> > The call is a leftover, when it was introduced by commit 362063619cf6
> > ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> > was still embedded in struct intel_fbdev rather than being a pointer as
> > it is today, and drm_framebuffer_remove() wasn't used yet.
> > 
> > As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> > 
> > Before:
> > [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> > [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> > [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> > 
> > After:
> > [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
> > [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
> > [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> > 
> > Signed-off-by: Lukas Wunner 
> 
> Hm yeah. But there's a pile of that particaluar cargo-culting copied all
> over the place, would be really good to audit all callers of
> unregister_private and fix them all up. A few older drivers still embed
> the fbdev fb, but most don't but still use the unregister_private +
> cleanup combo.

Yes, I noticed that but i915 was the only one that I could actually test,
the others I can only compile test. So fixing those up requires very
careful examination and takes more time, but I'll keep it on my todo list.


> Nitpick in your subject: s/fbdev/fbdev's fb/

Right, should I post a v2 or are you going to fix it up if/when merging?

Thanks,

Lukas

> 
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index ef8e676..4c7ea46 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
> > drm_fb_helper_fini(>helper);
> >  
> > if (ifbdev->fb) {
> > -   drm_framebuffer_unregister_private(>fb->base);
> > -
> > mutex_lock(>struct_mutex);
> > intel_unpin_fb_obj(>fb->base, BIT(DRM_ROTATE_0));
> > mutex_unlock(>struct_mutex);
> > -- 
> > 2.8.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

[Wang, Zhi A]

Sure. Will improve that in v9.

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, June 08, 2016 7:09 PM
> To: Wang, Zhi A 
> Cc: Lv, Zhiyuan ; Tian, Kevin ;
> tvrtko.ursu...@linux.intel.com; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v8 07/10] drm/i915: Make addressing mode bits in context
> descriptor configurable
> 
> On Wed, Jun 08, 2016 at 11:30:25AM -0400, Zhi Wang wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 66fdb8d..6a79c8c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -879,6 +879,7 @@ struct i915_gem_context {
> > bool initialised;
> > } engine[I915_NUM_ENGINES];
> > u32 ring_size;
> > +   u32 addressing_mode;
> >
> > struct list_head link;
> >
> > @@ -326,6 +314,7 @@ intel_lr_context_descriptor_update(struct
> i915_gem_context *ctx,
> > BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1< >
> > desc = engine->ctx_desc_template;   /* bits  0-11 */
> > +   desc |= ctx->addressing_mode;   /* bits  3-4  */
> 
> Did we not think that
> 
>   desc = ctx->desc_template;
>   desc |= engine->ctx_desc_template;
> 
> worked slightly better?
> 
> > desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
> > /* bits 12-31 */
> > desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52
> */
> 
> --
> 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] [Nouveau] [PATCH 9/9] drm: Turn off crtc before tearing down its data structure

[Lukas Wunner]

On Fri, Jun 03, 2016 at 08:21:50PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > > > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > > > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner  
> > > > > wrote:
> > > > > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> > > > > > > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > > > > > > > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), 
> > > > > > > > the DRM
> > > > > > > > core does not turn off the crtc first and neither do the 
> > > > > > > > drivers. With
> > > > > > > > nouveau, radeon and amdgpu, this causes a runtime pm ref to be 
> > > > > > > > leaked on
> > > > > > > > driver unload if at least one crtc was enabled.
> > > > > > > >
> > > > > > > > (See usage of have_disp_power_ref in nouveau_crtc_set_config(),
> > > > > > > > radeon_crtc_set_config() and amdgpu_crtc_set_config()).
> > > > > > > >
> > > > > > > > Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
> > > > > > > > Cc: Dave Airlie 
> > > > > > > > Tested-by: Karol Herbst 
> > > > > > > > Signed-off-by: Lukas Wunner 
> > > > > 
> > > > > With legacy kms the only way to keep a crtc enabled is to display a
> > > > > drm_framebuffer on it. And drm_mode_config_cleanup has a WARN_ON if
> > > > > framebuffers are left behind. There's a bunch of options:
> > > > > - nouveau somehow manages to keep the crtc on without a framebuffer
> > > > > - nouveau somehow leaks a drm_framebuffer, but removes it from the 
> > > > > fb_list
> > > > > - something else
> > > > 
> > > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove().
> > > > If I add that, the crtc gets properly disabled on unload.
> > > > 
> > > > It does call drm_framebuffer_cleanup(). That's why there was no WARN,
> > > > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the
> > > > mode_config.fb_list.
> > > > 
> > > > radeon and amdgpu have the same problem. In fact there are very few
> > > > drivers that call drm_framebuffer_remove(): tegra, msm, exynos, omapdrm
> > > > and i915 (since Imre Deak's 9d6612516da0).
> > > > 
> > > > Should we add a WARN to prevent this? How about WARN_ON(crtc->enabled)
> > > > in drm_crtc_cleanup()?
> > > > 
> > > > Also, i915 calls drm_framebuffer_unregister_private() before it calls
> > > > drm_framebuffer_remove(). This ordering has the unfortunate side effect
> > > > that the drm_framebuffer has ID 0 in log messages emitted by
> > > > drm_framebuffer_remove():
> > > > 
> > > > [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> > > > [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> > > > [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> > > 
> > > Well we must first unregister it before we can remove it, so this is
> > > unavoidable.
> > 
> > Yes but drm_framebuffer_free() calls drm_mode_object_unregister()
> > and is invoked by drm_framebuffer_remove(), so the additional call to
> > drm_framebuffer_unregister_private() in intel_fbdev_destroy() seems
> > superfluous. Or is there some reason I'm missing that this needs to
> > be called before intel_unpin_fb_obj()?
> > 
> > 
> > > Wrt switching from _cleanup to _remove, iirc there was troubles with the
> > > later calling into the fb->funcs->destroy hook. But many drivers have
> > > their fbdev fb embedded into some struct (instead of a pointer like i915),
> > > and then things go sideways badly. That's why you can't just blindly
> > > replace them.
> > 
> > So the options seem to be:
> > 
> > (1) Refactor nouveau, radeon and amdgpu to not embed their framebuffer
> > struct in their fbdev struct, so that drm_framebuffer_remove() can
> > be used.
> > 
> > (2) Amend each of them to turn off crtcs which are using the fbdev
> > framebuffer, duplicating the code in drm_framebuffer_remove().
> > 
> > (3) Split drm_framebuffer_remove(), move the portion to turn off crtcs
> > into a separate helper, say, drm_framebuffer_deactivate(), call that
> > from nouveau, radeon and amdgpu.
> > 
> > (4) Go back to square one and use patch [9/9] of this series.
> > 
> > Which one would be most preferred? Is there another solution I've missed?
> 
> I think a dedicated turn_off_everything helper would be best. We'd need an
> atomic and a legacy version (because hooray), but that would work in all
> cases. Relying on the implicit behaviour to turn off everything (strictly
> speaking you only need to turn off all the planes, you can leave crtcs on,
> and that's what most atomic drivers want really under normal
> circumstances) is a bit fragile, and it's also possible to disable fbdev
> emulation. If you driver needs everything to be off 

Re: [Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:30:25AM -0400, Zhi Wang wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 66fdb8d..6a79c8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -879,6 +879,7 @@ struct i915_gem_context {
>   bool initialised;
>   } engine[I915_NUM_ENGINES];
>   u32 ring_size;
> + u32 addressing_mode;
>  
>   struct list_head link;
>  
> @@ -326,6 +314,7 @@ intel_lr_context_descriptor_update(struct 
> i915_gem_context *ctx,
>   BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<  
>   desc = engine->ctx_desc_template;   /* bits  0-11 */
> + desc |= ctx->addressing_mode;   /* bits  3-4  */

Did we not think that 

desc = ctx->desc_template;
desc |= engine->ctx_desc_template;

worked slightly better?

>   desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
>   /* bits 12-31 */
>   desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */

-- 
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 v8 00/10] Introduce the implementation of GVT context

[Wang, Zhi A]

Sure. That's a good idea. :)

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, June 08, 2016 7:01 PM
> To: Wang, Zhi A 
> Cc: Lv, Zhiyuan ; Tian, Kevin ;
> tvrtko.ursu...@linux.intel.com; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v8 00/10] Introduce the implementation of GVT context
> 
> On Wed, Jun 08, 2016 at 11:30:18AM -0400, Zhi Wang wrote:
> > Bing Niu (1):
> >   drm/i915: Introduce host graphics memory partition for GVT-g
> >
> > Zhi Wang (9):
> >   drm/i915: Factor out i915_pvinfo.h
> >   drm/i915: Use offsetof() to calculate the offset of members in PVINFO
> > page
> >   drm/i915: Fold vGPU active check into inner functions
> >   drm/i915: gvt: Introduce the basic architecture of GVT-g
> >   drm/i915: Make ring buffer size of a LRC context configurable
> >   drm/i915: Make addressing mode bits in context descriptor configurable
> >   drm/i915: Introduce execlist context status change notification
> >   drm/i915: Support LRC context single submission
> >   drm/i915: Introduce GVT context creation API
> 
> You want to also send a
> 
> for-CI: Enable GVT-g by default
> 
> patch when sending these series so that we can run BAT and make sure we
> don't regress with the added code. Actually, better would be send to list with
> disable by default, but send the series to trybot with the enabling and add 
> the
> link here. Then the merged patches will include a reference to the normal CI
> config, with a reference to the enabled CI config available as well.
> 
> 2 very minor comments, but I just wanted to be sure that there were no
> accidental changes outside of GVT-g (hence BAT).
> -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 v8 06/10] drm/i915: Make ring buffer size of a LRC context configurable

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:30:24AM -0400, Zhi Wang wrote:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index cbc84e6..344b5d3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2478,7 +2478,8 @@ static int execlists_context_deferred_alloc(struct 
> i915_gem_context *ctx,
>   return PTR_ERR(ctx_obj);
>   }
>  
> - ringbuf = intel_engine_create_ringbuffer(engine, 4 * PAGE_SIZE);
> + ringbuf = intel_engine_create_ringbuffer(engine,
> + ctx->ring_size);

It fits onto one line now! Plus, please try to align the start of the
next line with the opening bracket (or whatever vertical alignment makes
sense). For vim, set cino=:0,(0
-Chris

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4)
URL   : https://patchwork.freedesktop.org/series/8414/
State : failure

== Summary ==

Applying: drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
Applying: drm/i915/bxt: Sanitiy check the PHY lane power down status
fatal: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_ddi.c).
error: could not build fake ancestor
Patch failed at 0002 drm/i915/bxt: Sanitiy check the PHY lane power down status
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH v8 00/10] Introduce the implementation of GVT context

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:30:18AM -0400, Zhi Wang wrote:
> Bing Niu (1):
>   drm/i915: Introduce host graphics memory partition for GVT-g
> 
> Zhi Wang (9):
>   drm/i915: Factor out i915_pvinfo.h
>   drm/i915: Use offsetof() to calculate the offset of members in PVINFO
> page
>   drm/i915: Fold vGPU active check into inner functions
>   drm/i915: gvt: Introduce the basic architecture of GVT-g
>   drm/i915: Make ring buffer size of a LRC context configurable
>   drm/i915: Make addressing mode bits in context descriptor configurable
>   drm/i915: Introduce execlist context status change notification
>   drm/i915: Support LRC context single submission
>   drm/i915: Introduce GVT context creation API

You want to also send a 

for-CI: Enable GVT-g by default

patch when sending these series so that we can run BAT and make sure we
don't regress with the added code. Actually, better would be send to
list with disable by default, but send the series to trybot with the
enabling and add the link here. Then the merged patches will include a
reference to the normal CI config, with a reference to the enabled CI
config available as well.

2 very minor comments, but I just wanted to be sure that there were no
accidental changes outside of GVT-g (hence BAT).
-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: warning for Introduce the implementation of GVT context (rev6)

[Patchwork]

== Series Details ==

Series: Introduce the implementation of GVT context (rev6)
URL   : https://patchwork.freedesktop.org/series/7208/
State : warning

== Summary ==

Series 7208v6 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/6/mbox

Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:208  pass:193  dwarn:0   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:208  pass:180  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:168  dwarn:1   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:208  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:208  pass:180  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:208  pass:169  dwarn:0   dfail:0   fail:1   skip:38 
fi-bdw-i7-5557u failed to connect after reboot
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1141/

ccadf0e drm-intel-nightly: 2016y-06m-08d-14h-55m-13s UTC integration manifest
7f44d6c drm/i915: Introduce GVT context creation API
5662403 drm/i915: Support LRC context single submission
729e7bf drm/i915: Introduce execlist context status change notification
24620f9 drm/i915: Make addressing mode bits in context descriptor configurable
b519bba drm/i915: Make ring buffer size of a LRC context configurable
80936b6 drm/i915: Introduce host graphics memory partition for GVT-g
740295d drm/i915: gvt: Introduce the basic architecture of GVT-g
3cb0c66 drm/i915: Fold vGPU active check into inner functions
f1d4892 drm/i915: Use offsetof() to calculate the offset of members in PVINFO 
page
e8f57b0 drm/i915: Factor out i915_pvinfo.h

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

[Intel-gfx] [PATCH v2 2/6] drm/i915: Factor out intel_power_well_get/put

[Imre Deak]

These helpers will be needed by the next patch, so factor them out.

No functional change.

v2:
- Move the refcount==0 WARN to the new put helper. (Ville)

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2b75b30..10978cb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -151,6 +151,23 @@ static void intel_power_well_disable(struct 
drm_i915_private *dev_priv,
power_well->ops->disable(dev_priv, power_well);
 }
 
+static void intel_power_well_get(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   if (!power_well->count++)
+   intel_power_well_enable(dev_priv, power_well);
+}
+
+static void intel_power_well_put(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   WARN(!power_well->count, "Use count on power well %s is already zero",
+power_well->name);
+
+   if (!--power_well->count)
+   intel_power_well_disable(dev_priv, power_well);
+}
+
 /*
  * We should only use the power well if we explicitly asked the hardware to
  * enable it, so check if it's enabled and also check if we've requested it to
@@ -1518,10 +1535,8 @@ __intel_display_power_get_domain(struct drm_i915_private 
*dev_priv,
struct i915_power_well *power_well;
int i;
 
-   for_each_power_well(i, power_well, BIT(domain), power_domains) {
-   if (!power_well->count++)
-   intel_power_well_enable(dev_priv, power_well);
-   }
+   for_each_power_well(i, power_well, BIT(domain), power_domains)
+   intel_power_well_get(dev_priv, power_well);
 
power_domains->domain_use_count[domain]++;
 }
@@ -1615,14 +1630,8 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
 intel_display_power_domain_str(domain));
power_domains->domain_use_count[domain]--;
 
-   for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
-   WARN(!power_well->count,
-"Use count on power well %s is already zero",
-power_well->name);
-
-   if (!--power_well->count)
-   intel_power_well_disable(dev_priv, power_well);
-   }
+   for_each_power_well_rev(i, power_well, BIT(domain), power_domains)
+   intel_power_well_put(dev_priv, power_well);
 
mutex_unlock(_domains->lock);
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

[Imre Deak]

So far we configured a static lane latency optimization during driver
loading/resuming. The specification changed at one point and now this
configuration depends on the lane count, so move the configuration
to modeset time accordingly.

It's not clear when this lane configuration takes effect. The
specification only requires that the programming is done before enabling
the port. On CHV OTOH the lanes start to power up already right after
enabling the PLL. To be safe preserve the current order and set things
up already before enabling the PLL.

v2: (Ander)
- Simplify the optimization mask calculation.
- Use the correct pipe_config always during the calculation instead
  of the bogus intel_crtc->config.

CC: Ander Conselvan de Oliveira 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95476
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 123 +++
 drivers/gpu/drm/i915/intel_display.c |   5 ++
 drivers/gpu/drm/i915/intel_drv.h |   6 ++
 3 files changed, 91 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index dee6dd0..e7edeec 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1789,8 +1789,7 @@ static void broxton_phy_wait_grc_done(struct 
drm_i915_private *dev_priv,
 
 void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
-   enum port port;
-   u32 ports, val;
+   u32 val;
 
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
@@ -1825,28 +1824,6 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
DRM_ERROR("timeout during PHY%d power on\n", phy);
}
 
-   if (phy == DPIO_PHY0)
-   ports = BIT(PORT_B) | BIT(PORT_C);
-   else
-   ports = BIT(PORT_A);
-
-   for_each_port_masked(port, ports) {
-   int lane;
-
-   for (lane = 0; lane < 4; lane++) {
-   val = I915_READ(BXT_PORT_TX_DW14_LN(port, lane));
-   /*
-* Note that on CHV this flag is called UPAR, but has
-* the same function.
-*/
-   val &= ~LATENCY_OPTIM;
-   if (lane != 1)
-   val |= LATENCY_OPTIM;
-
-   I915_WRITE(BXT_PORT_TX_DW14_LN(port, lane), val);
-   }
-   }
-
/* Program PLL Rcomp code offset */
val = I915_READ(BXT_PORT_CL1CM_DW9(phy));
val &= ~IREF0RC_OFFSET_MASK;
@@ -1956,8 +1933,6 @@ __phy_reg_verify_state(struct drm_i915_private *dev_priv, 
enum dpio_phy phy,
 bool bxt_ddi_phy_verify_state(struct drm_i915_private *dev_priv,
  enum dpio_phy phy)
 {
-   enum port port;
-   u32 ports;
uint32_t mask;
bool ok;
 
@@ -1970,21 +1945,6 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
 
ok = true;
 
-   if (phy == DPIO_PHY0)
-   ports = BIT(PORT_B) | BIT(PORT_C);
-   else
-   ports = BIT(PORT_A);
-
-   for_each_port_masked(port, ports) {
-   int lane;
-
-   for (lane = 0; lane < 4; lane++)
-   ok &= _CHK(BXT_PORT_TX_DW14_LN(port, lane),
-   LATENCY_OPTIM,
-   lane != 1 ? LATENCY_OPTIM : 0,
-   "BXT_PORT_TX_DW14_LN(%d, %d)", port, lane);
-   }
-
/* PLL Rcomp code offset */
ok &= _CHK(BXT_PORT_CL1CM_DW9(phy),
IREF0RC_OFFSET_MASK, 0xe4 << IREF0RC_OFFSET_SHIFT,
@@ -2028,6 +1988,67 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
 #undef _CHK
 }
 
+static uint8_t
+bxt_ddi_phy_calc_lane_lat_optim_mask(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
+{
+   switch (pipe_config->lane_count) {
+   case 1:
+   return 0;
+   case 2:
+   return BIT(2) | BIT(0);
+   case 4:
+   return BIT(3) | BIT(2) | BIT(0);
+   default:
+   MISSING_CASE(pipe_config->lane_count);
+
+   return 0;
+   }
+}
+
+static void bxt_ddi_pre_pll_enable(struct intel_encoder *encoder)
+{
+   struct intel_digital_port *dport = enc_to_dig_port(>base);
+   struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
+   enum port port = dport->port;
+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   int lane;
+
+   for (lane = 0; lane < 4; lane++) {
+   u32 val = I915_READ(BXT_PORT_TX_DW14_LN(port, lane));
+
+   /*
+* Note that on CHV this flag is called UPAR, but has
+   

[Intel-gfx] [PATCH v2 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Imre Deak]

We can check the power state of the PHY data and common lanes as
reported by the PHY. Do this in case we need to debug problems where the
PHY gets stuck in an unexpected state.

Note that I only check these when the lanes are expected to be powered
on purpose, since it's not clear at what point the PHY power/clock gates
things.

v2:
- Don't report the encoder as disabled when the sanity check fails.
  (Ville)

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h  |  9 +
 drivers/gpu/drm/i915/intel_ddi.c | 25 +
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81fc498..e904818 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
 #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
 #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
 
+#define _BXT_PHY_CTL_DDI_A 0x64C00
+#define _BXT_PHY_CTL_DDI_B 0x64C10
+#define _BXT_PHY_CTL_DDI_C 0x64C20
+#define   BXT_PHY_CMNLANE_POWERDOWN_ACK(1 << 10)
+#define   BXT_PHY_LANE_POWERDOWN_ACK   (1 << 9)
+#define   BXT_PHY_LANE_ENABLED (1 << 8)
+#define BXT_PHY_CTL(port)  _MMIO_PORT(port, _BXT_PHY_CTL_DDI_A, \
+_BXT_PHY_CTL_DDI_B)
+
 #define _PHY_CTL_FAMILY_EDP0x64C80
 #define _PHY_CTL_FAMILY_DDI0x64C90
 #define   COMMON_RESET_DIS (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cb48b0d..bd0c46a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1342,6 +1342,14 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
*encoder,
DRM_DEBUG_KMS("No pipe for ddi port %c found\n", port_name(port));
 
 out:
+   if (ret && IS_BROXTON(dev_priv)) {
+   tmp = I915_READ(BXT_PHY_CTL(port));
+   if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
+   BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED)
+   DRM_ERROR("Port %c enabled but PHY powered down? "
+ "(PHY_CTL %08x)\n", port_name(port), tmp);
+   }
+
intel_display_power_put(dev_priv, power_domain);
 
return ret;
@@ -1745,6 +1753,8 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
 bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
enum dpio_phy phy)
 {
+   enum port port;
+
if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
return false;
 
@@ -1770,6 +1780,21 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
+   for_each_port_masked(port,
+phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
+   BIT(PORT_A)) {
+   u32 tmp = I915_READ(BXT_PHY_CTL(port));
+
+   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
+   DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
+"for port %c powered down "
+"(PHY_CTL %08x)\n",
+phy, port_name(port), tmp);
+
+   return false;
+   }
+   }
+
return true;
 }
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v8 08/10] drm/i915: Introduce execlist context status change notification

[Zhi Wang]

This patch introduces an approach to track the execlist context status
change.

GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.

This function is configurable when creating a new GEM context. Currently,
Only GVT-g will create the "status-change-notification" enabled GEM
context.

v8:

- Remove the boolean flag in struct i915_gem_context. (Joonas)

v7:

- Remove per-engine ctx status notifiers. Use one status notifier for all
engines. (Joonas)
- Add prefix "INTEL_" for related definitions. (Joonas)
- Refine the comments in execlists_context_status_change(). (Joonas)

v6:

- When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
could automatically eliminate them for us. (Chris)
- Always initialize the notifier header, so it could be switched on/off
at runtime. (Chris)

v5:

- Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c |  1 +
 drivers/gpu/drm/i915/intel_lrc.c| 22 ++
 drivers/gpu/drm/i915/intel_lrc.h|  5 +
 4 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a79c8c..08ba4e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -880,6 +880,7 @@ struct i915_gem_context {
} engine[I915_NUM_ENGINES];
u32 ring_size;
u32 addressing_mode;
+   struct atomic_notifier_head status_notifier;
 
struct list_head link;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 821f550..cc461ed 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev,
ctx->ring_size = 4 * PAGE_SIZE;
ctx->addressing_mode = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
+   ATOMIC_INIT_NOTIFIER_HEAD(>status_notifier);
 
return ctx;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0652132..3513e2c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -404,6 +404,20 @@ static void execlists_submit_requests(struct 
drm_i915_gem_request *rq0,
spin_unlock_irq(_priv->uncore.lock);
 }
 
+static inline void execlists_context_status_change(
+   struct drm_i915_gem_request *rq,
+   unsigned long status)
+{
+   /*
+* Only used when GVT-g is enabled now. When GVT-g is disabled,
+* The compiler should eliminate this function as dead-code.
+*/
+   if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
+   return;
+
+   atomic_notifier_call_chain(>ctx->status_notifier, status, rq);
+}
+
 static void execlists_context_unqueue(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
@@ -439,6 +453,12 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
if (unlikely(!req0))
return;
 
+   execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN);
+
+   if (req1)
+   execlists_context_status_change(req1,
+   INTEL_CONTEXT_SCHEDULE_IN);
+
if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
/*
 * WaIdleLiteRestore: make sure we never cause a lite restore
@@ -477,6 +497,8 @@ execlists_check_remove_request(struct intel_engine_cs 
*engine, u32 ctx_id)
if (--head_req->elsp_submitted > 0)
return 0;
 
+   execlists_context_status_change(head_req, INTEL_CONTEXT_SCHEDULE_OUT);
+
list_del(_req->execlist_link);
i915_gem_request_unreference(head_req);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index a8db42a..2b8255c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -57,6 +57,11 @@
 #define GEN8_CSB_READ_PTR(csb_status) \
(((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
 
+enum {
+   INTEL_CONTEXT_SCHEDULE_IN = 0,
+   INTEL_CONTEXT_SCHEDULE_OUT,
+};
+
 /* Logical Rings */
 int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request);
 int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request);
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 09/10] drm/i915: Support LRC context single submission

[Zhi Wang]

This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.

Only GVT-g will create this kinds of GEM context currently.

v8:

- Rename the data member in struct i915_gem_context. (Chris)

v7:

- Fix typos in commit message. (Joonas)

v6:
- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)

v5:

- Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko)

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08ba4e0..01f2f77 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -881,6 +881,7 @@ struct i915_gem_context {
u32 ring_size;
u32 addressing_mode;
struct atomic_notifier_head status_notifier;
+   bool execlists_force_single_submission;
 
struct list_head link;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3513e2c..3ad52b1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -444,6 +444,21 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
i915_gem_request_unreference(req0);
req0 = cursor;
} else {
+   /* Compiler will do the dead-code elimination */
+   if (IS_ENABLED(CONFIG_DRM_I915_GVT)) {
+   /*
+* req0 (after merged) ctx requires single
+* submission, stop picking
+*/
+   if 
(req0->ctx->execlists_force_single_submission)
+   break;
+   /*
+* req0 ctx doesn't require single submission,
+* but next req ctx requires, stop picking
+*/
+   if 
(cursor->ctx->execlists_force_single_submission)
+   break;
+   }
req1 = cursor;
WARN_ON(req1->elsp_submitted);
break;
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 03/10] drm/i915: Fold vGPU active check into inner functions

[Zhi Wang]

v5:
- Let functions take struct drm_i915_private *. (Tvrtko)

- Fold vGPU related active check into the inner functions. (Kevin)

Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
Suggested-by: Kevin Tian 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
 drivers/gpu/drm/i915/i915_vgpu.c| 13 +
 drivers/gpu/drm/i915/i915_vgpu.h|  4 ++--
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..6f203fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2732,11 +2732,9 @@ static int i915_gem_setup_global_gtt(struct drm_device 
*dev,
i915_address_space_init(>base, dev_priv);
ggtt->base.total += PAGE_SIZE;
 
-   if (intel_vgpu_active(dev_priv)) {
-   ret = intel_vgt_balloon(dev);
-   if (ret)
-   return ret;
-   }
+   ret = intel_vgt_balloon(dev_priv);
+   if (ret)
+   return ret;
 
if (!HAS_LLC(dev))
ggtt->base.mm.color_adjust = i915_gtt_color_adjust;
@@ -2836,8 +2834,7 @@ void i915_ggtt_cleanup_hw(struct drm_device *dev)
i915_gem_cleanup_stolen(dev);
 
if (drm_mm_initialized(>base.mm)) {
-   if (intel_vgpu_active(dev_priv))
-   intel_vgt_deballoon();
+   intel_vgt_deballoon(dev_priv);
 
drm_mm_takedown(>base.mm);
list_del(>base.global_link);
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index c3c6c64..f6acb5a 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -101,10 +101,13 @@ static struct _balloon_info_ bl_info;
  * This function is called to deallocate the ballooned-out graphic memory, when
  * driver is unloaded or when ballooning fails.
  */
-void intel_vgt_deballoon(void)
+void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
 {
int i;
 
+   if (!intel_vgpu_active(dev_priv))
+   return;
+
DRM_DEBUG("VGT deballoon.\n");
 
for (i = 0; i < 4; i++) {
@@ -177,9 +180,8 @@ static int vgt_balloon_space(struct drm_mm *mm,
  * Returns:
  * zero on success, non-zero if configuration invalid or ballooning failed
  */
-int intel_vgt_balloon(struct drm_device *dev)
+int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
unsigned long ggtt_end = ggtt->base.start + ggtt->base.total;
 
@@ -187,6 +189,9 @@ int intel_vgt_balloon(struct drm_device *dev)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
 
+   if (!intel_vgpu_active(dev_priv))
+   return 0;
+
mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
@@ -258,6 +263,6 @@ int intel_vgt_balloon(struct drm_device *dev)
 
 err:
DRM_ERROR("VGT balloon fail\n");
-   intel_vgt_deballoon();
+   intel_vgt_deballoon(dev_priv);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index 07e67d5..f8917c6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -27,7 +27,7 @@
 #include "i915_pvinfo.h"
 
 extern void i915_check_vgpu(struct drm_i915_private *dev_priv);
-extern int intel_vgt_balloon(struct drm_device *dev);
-extern void intel_vgt_deballoon(void);
+extern int intel_vgt_balloon(struct drm_i915_private *dev_priv);
+extern void intel_vgt_deballoon(struct drm_i915_private *dev_priv);
 
 #endif /* _I915_VGPU_H_ */
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 06/10] drm/i915: Make ring buffer size of a LRC context configurable

[Zhi Wang]

This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.

v8:
- Rename the data member in i915_gem_context. (Chris)

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 1 +
 drivers/gpu/drm/i915/intel_lrc.c| 3 ++-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e25d761..66fdb8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -878,6 +878,7 @@ struct i915_gem_context {
int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
+   u32 ring_size;
 
struct list_head link;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a3b11aa..b722fa1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -295,6 +295,7 @@ __create_hw_context(struct drm_device *dev,
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
 
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
+   ctx->ring_size = 4 * PAGE_SIZE;
 
return ctx;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cbc84e6..344b5d3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2478,7 +2478,8 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
return PTR_ERR(ctx_obj);
}
 
-   ringbuf = intel_engine_create_ringbuffer(engine, 4 * PAGE_SIZE);
+   ringbuf = intel_engine_create_ringbuffer(engine,
+   ctx->ring_size);
if (IS_ERR(ringbuf)) {
ret = PTR_ERR(ringbuf);
goto error_deref_obj;
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 04/10] drm/i915: gvt: Introduce the basic architecture of GVT-g

[Zhi Wang]

This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.

v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)

v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (Joonas)
- Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas)
- Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas)
- Remove {alloc, free}_gvt_device()
- Rename intel_gvt_{create, destroy}_gvt_device()
- Expost intel_gvt_init_host()
- Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas)

v6:
- Refine introduction in Kconfig. (Chris)
- The exposed API functions will take struct intel_gvt * instead of
void *. (Chris/Tvrtko)
- Remove most memebers of strct intel_gvt_device_info. Will add them
in the device model patches.(Chris)
- Remove gvt_info() and gvt_err() in debug.h. (Chris)
- Move GVT kernel parameter into i915_params. (Chris)
- Remove include/drm/i915_gvt.h, as GVT-g will be built within i915.
- Remove the redundant struct i915_gvt *, as the functions in i915
will directly take struct intel_gvt *.
- Add more comments for reviewer.

v5:
Take Tvrtko's comments:
- Fix the misspelled words in Kconfig
- Let functions take drm_i915_private * instead of struct drm_device *
- Remove redundant prints/local varible initialization

v3:
Take Joonas' comments:
- Change file name i915_gvt.* to intel_gvt.*
- Move GVT kernel parameter into intel_gvt.c
- Remove redundant debug macros
- Change error handling style
- Add introductions for some stub functions
- Introduce drm/i915_gvt.h.

Take Kevin's comments:
- Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c

v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.

Take Joonas' comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Kevin Tian 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/Kconfig |  22 ++
 drivers/gpu/drm/i915/Makefile|   5 ++
 drivers/gpu/drm/i915/gvt/Makefile|   5 ++
 drivers/gpu/drm/i915/gvt/debug.h |  34 
 drivers/gpu/drm/i915/gvt/gvt.c   | 145 +++
 drivers/gpu/drm/i915/gvt/gvt.h   |  69 +
 drivers/gpu/drm/i915/gvt/hypercall.h |  38 +
 drivers/gpu/drm/i915/gvt/mpt.h   |  49 
 drivers/gpu/drm/i915/i915_dma.c  |  16 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  10 +++
 drivers/gpu/drm/i915/i915_params.c   |   5 ++
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/intel_gvt.c | 100 
 drivers/gpu/drm/i915/intel_gvt.h |  45 +++
 14 files changed, 540 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
 create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
 create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
 create mode 100644 drivers/gpu/drm/i915/intel_gvt.c
 create mode 100644 drivers/gpu/drm/i915/intel_gvt.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 29a32b1..7769e46 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -57,6 +57,28 @@ config DRM_I915_USERPTR
 
  If in doubt, say "Y".
 
+config DRM_I915_GVT
+bool "Enable Intel GVT-g graphics virtualization host support"
+depends on DRM_I915
+default n
+help
+ Choose this option if you want to enable Intel GVT-g graphics
+ virtualization technology host support with integrated graphics.
+ With GVT-g, it's possible to have one integrated graphics
+ device shared by multiple VMs under different hypervisors.
+
+ Note that at least one hypervisor like Xen or KVM is required for
+ this driver to work, and it only supports newer device from
+ Broadwell+. For further information and setup guide, you can
+ visit: http://01.org/igvt-g.
+
+ Now it's just a stub to support the modifications of i915 for
+ GVT device model. It requires at least one MPT modules for Xen/KVM
+ and other components of GVT device model to work. Use it under
+ you own risk.
+
+ If in doubt, say "N".
+
 menu "drm/i915 

[Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

[Zhi Wang]

Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.

GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a LRC context should be configurable under this case.

v8:

- Rename the data memeber in struct i915_gem_context. (Chris)

v7:

- Move context addressing mode bit into i915_reg.h. (Joonas/Chris)
- Add prefix "INTEL_" for related definitions. (Joonas)

v6:

- Directly save the addressing mode bits inside i915_gem_context. (Chris)
- Move the LRC context addressing mode bits into intel_lrc.h. (Chris)

v5:

- Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko)

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c |  2 ++
 drivers/gpu/drm/i915/i915_reg.h | 12 
 drivers/gpu/drm/i915/intel_lrc.c| 13 +
 4 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 66fdb8d..6a79c8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,7 @@ struct i915_gem_context {
bool initialised;
} engine[I915_NUM_ENGINES];
u32 ring_size;
+   u32 addressing_mode;
 
struct list_head link;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b722fa1..821f550 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -296,6 +296,8 @@ __create_hw_context(struct drm_device *dev,
 
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
ctx->ring_size = 4 * PAGE_SIZE;
+   ctx->addressing_mode = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
+   GEN8_CTX_ADDRESSING_MODE_SHIFT;
 
return ctx;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f0129d..4a6fe6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3022,6 +3022,18 @@ enum skl_disp_power_wells {
 /* Same as Haswell, but 72064 bytes now. */
 #define GEN8_CXT_TOTAL_SIZE(18 * PAGE_SIZE)
 
+enum {
+   INTEL_ADVANCED_CONTEXT = 0,
+   INTEL_LEGACY_32B_CONTEXT,
+   INTEL_ADVANCED_AD_CONTEXT,
+   INTEL_LEGACY_64B_CONTEXT
+};
+
+#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv) ?\
+   INTEL_LEGACY_64B_CONTEXT : \
+   INTEL_LEGACY_32B_CONTEXT)
+
 #define CHV_CLK_CTL1   _MMIO(0x101100)
 #define VLV_CLK_CTL2   _MMIO(0x101104)
 #define   CLK_CTL2_CZCOUNT_30NS_SHIFT  28
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 344b5d3..0652132 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -208,16 +208,6 @@
 } while (0)
 
 enum {
-   ADVANCED_CONTEXT = 0,
-   LEGACY_32B_CONTEXT,
-   ADVANCED_AD_CONTEXT,
-   LEGACY_64B_CONTEXT
-};
-#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ADDRESSING_MODE(dev)  (USES_FULL_48BIT_PPGTT(dev) ?\
-   LEGACY_64B_CONTEXT :\
-   LEGACY_32B_CONTEXT)
-enum {
FAULT_AND_HANG = 0,
FAULT_AND_HALT, /* Debug only */
FAULT_AND_STREAM,
@@ -281,8 +271,6 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
(engine->id == VCS || engine->id == 
VCS2);
 
engine->ctx_desc_template = GEN8_CTX_VALID;
-   engine->ctx_desc_template |= GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
-  GEN8_CTX_ADDRESSING_MODE_SHIFT;
if (IS_GEN8(dev_priv))
engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
@@ -326,6 +314,7 @@ intel_lr_context_descriptor_update(struct i915_gem_context 
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<ctx_desc_template;   /* bits  0-11 */
+   desc |= ctx->addressing_mode;   /* bits  3-4  */
desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 05/10] drm/i915: Introduce host graphics memory partition for GVT-g

[Zhi Wang]

From: Bing Niu 

This patch introduces host graphics memory partition when GVT-g
is enabled.

Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.

v7:

- Add comments about low/high GM size for host. (Joonas)

v6:

- Remove kernel parameters used to configure GGTT owned by host. (Chris)
- Other coding style comments from Chris.
- Add more comments for reviewer.

v3:

- Remove fence partition, will use i915 fence stealing in future.(Kevin)
- Santinize GVT host gm kernel parameters. (Joonas)

v2:
- Address all coding-style comments from Joonas previously.
- Fix errors and warnning reported by checkpatch.pl. (Joonas)
- Move the graphs into the header files. (Daniel)

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Kevin Tian 
Cc: Daniel Vetter 
Signed-off-by: Bing Niu 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_vgpu.c | 23 +--
 drivers/gpu/drm/i915/intel_gvt.h | 36 
 2 files changed, 53 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index f6acb5a..019db98 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -189,14 +189,25 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
 
-   if (!intel_vgpu_active(dev_priv))
+   if (intel_gvt_active(dev_priv)) {
+   /* Retrieve GGTT partition information from macros */
+   mappable_base = 0;
+   mappable_size = INTEL_GVT_HOST_LOW_GM_SIZE;
+   unmappable_base = dev_priv->ggtt.mappable_end;
+   unmappable_size = INTEL_GVT_HOST_HIGH_GM_SIZE;
+   } else if (intel_vgpu_active(dev_priv)) {
+   /* Retrieve GGTT partition information from PVINFO */
+   mappable_base = I915_READ(
+   vgtif_reg(avail_rs.mappable_gmadr.base));
+   mappable_size = I915_READ(
+   vgtif_reg(avail_rs.mappable_gmadr.size));
+   unmappable_base = I915_READ(
+   vgtif_reg(avail_rs.nonmappable_gmadr.base));
+   unmappable_size = I915_READ(
+   vgtif_reg(avail_rs.nonmappable_gmadr.size));
+   } else
return 0;
 
-   mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
-   mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
-   unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
-   unmappable_size = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.size));
-
mappable_end = mappable_base + mappable_size;
unmappable_end = unmappable_base + unmappable_size;
 
diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index 91e129f..d0d71d1 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -26,6 +26,42 @@
 
 #include "gvt/gvt.h"
 
+/*
+ * Under GVT-g, i915 host driver only owned limited graphics resources,
+ * others are managed by GVT-g resource allocator and kept for other vGPUs.
+ *
+ * For graphics memory space partition, a typical layout looks like:
+ *
+ * +---+---+--+---+
+ * |* Host |   *GVT-g Resource |* Host|   *GVT-g Resource |
+ * | Owned |   Allocator Managed   | Owned|   Allocator Managed   |
+ * |   |   |  |   |
+ * +---+---+--+---+---+
+ * |   |   |   |   |  |   |   |   |
+ * | i915  | vm 1  | vm 2  | vm 3  | i915 | vm 1  | vm 2  | vm 3  |
+ * |   |   |   |   |  |   |   |   |
+ * +---+---+---+--+---+---+---+
+ * |   Aperture|Hidden|
+ * +---+--+
+ * |   GGTT memory space  |
+ * +--+
+ */
+
+/* GGTT memory space owned by host */
+/*
+ * This amount is heavily related to the max screen resolution / multiple
+ * display in *host*. If you are using a 4K monitor or multiple display
+ * monitor, probably you should enlarge the low gm size.
+ */
+#define INTEL_GVT_HOST_LOW_GM_SIZE (96 * 1024 * 1024)
+
+/*
+ * This amount is related to the GPU workload in host. If you wish to run
+ * heavy workload like 3D gaming, media transcoding *in host* and encounter
+ * performance drops, probably you should enlarge the high gm size.
+ */
+#define 

[Intel-gfx] [PATCH v8 10/10] drm/i915: Introduce GVT context creation API

[Zhi Wang]

GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes, ring context is mostly owned by host i915.

v8:

- Remove the graph temporarily. (Chris)
- Use interruptible mutex_lock. (Chris)
- Rename the function name of creating a GVT context. (Chris)
- Add the missing declaration in i915_drv.h (Chris)

v7:

- Move chart to a better place. (Joonas)

v6:

- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)

v5:
- Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko)
- Rebase the code into new repo.
- Add a comment about the ring buffer size. (Joonas)

v2:

Mostly based on Daniel's idea. Call the refactored core logic of GEM
context creation service and LRC context creation service to create the GVT
context.

Reviewed-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_gem_context.c | 34 +
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01f2f77..e7f1bc3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3445,6 +3445,8 @@ int i915_switch_context(struct drm_i915_gem_request *req);
 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);
+struct i915_gem_context *
+i915_gem_context_create_gvt(struct drm_device *dev);
 
 static inline struct i915_gem_context *
 i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index cc461ed..0eeb06a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,40 @@ i915_gem_create_context(struct drm_device *dev,
return ctx;
 }
 
+/**
+ * i915_gem_context_create_gvt - create a GVT GEM context
+ * @dev: drm device *
+ *
+ * This function is used to create a GVT specific GEM context.
+ *
+ * Returns:
+ * pointer to i915_gem_context on success, error pointer if failed
+ *
+ */
+struct i915_gem_context *
+i915_gem_context_create_gvt(struct drm_device *dev)
+{
+   struct i915_gem_context *ctx;
+   int ret;
+
+   if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
+   return ERR_PTR(-ENODEV);
+
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   return ERR_PTR(ret);
+
+   ctx = i915_gem_create_context(dev, NULL);
+   if (IS_ERR(ctx))
+   goto out;
+
+   ctx->execlists_force_single_submission = true;
+   ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
+out:
+   mutex_unlock(>struct_mutex);
+   return ctx;
+}
+
 static void i915_gem_context_unpin(struct i915_gem_context *ctx,
   struct intel_engine_cs *engine)
 {
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 02/10] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page

[Zhi Wang]

To get the offset of the members in PVINFO page, offsetof() looks much
better than the tricky approach in current code.

v7:

- Move "offsetof()" modification into a dedicated patch. (Joonas)

Suggested-by: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_pvinfo.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 68bdf60..7b3cec4 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -104,7 +104,7 @@ struct vgt_if {
 } __packed;
 
 #define vgtif_reg(x) \
-   _MMIO((VGT_PVINFO_PAGE + (long)&((struct vgt_if *)NULL)->x))
+   _MMIO((VGT_PVINFO_PAGE + offsetof(struct vgt_if, x)))
 
 /* vGPU display status to be used by the host side */
 #define VGT_DRV_DISPLAY_NOT_READY 0
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 01/10] drm/i915: Factor out i915_pvinfo.h

[Zhi Wang]

As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.

v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)

v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joonas)

Reviewed-by: Joonas Lahtinen 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_pvinfo.h | 113 +
 drivers/gpu/drm/i915/i915_vgpu.h   |  86 +---
 2 files changed, 114 insertions(+), 85 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h

diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
new file mode 100644
index 000..68bdf60
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 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.
+ */
+
+#ifndef _I915_PVINFO_H_
+#define _I915_PVINFO_H_
+
+/* The MMIO offset of the shared info between guest and host emulator */
+#define VGT_PVINFO_PAGE0x78000
+#define VGT_PVINFO_SIZE0x1000
+
+/*
+ * The following structure pages are defined in GEN MMIO space
+ * for virtualization. (One page for now)
+ */
+#define VGT_MAGIC 0x4776544776544776ULL/* 'vGTvGTvG' */
+#define VGT_VERSION_MAJOR 1
+#define VGT_VERSION_MINOR 0
+
+#define INTEL_VGT_IF_VERSION_ENCODE(major, minor) ((major) << 16 | (minor))
+#define INTEL_VGT_IF_VERSION \
+   INTEL_VGT_IF_VERSION_ENCODE(VGT_VERSION_MAJOR, VGT_VERSION_MINOR)
+
+/*
+ * notifications from guest to vgpu device model
+ */
+enum vgt_g2v_type {
+   VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE = 2,
+   VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY,
+   VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE,
+   VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
+   VGT_G2V_EXECLIST_CONTEXT_CREATE,
+   VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+   VGT_G2V_MAX,
+};
+
+struct vgt_if {
+   uint64_t magic; /* VGT_MAGIC */
+   uint16_t version_major;
+   uint16_t version_minor;
+   uint32_t vgt_id;/* ID of vGT instance */
+   uint32_t rsv1[12];  /* pad to offset 0x40 */
+   /*
+*  Data structure to describe the balooning info of resources.
+*  Each VM can only have one portion of continuous area for now.
+*  (May support scattered resource in future)
+*  (starting from offset 0x40)
+*/
+   struct {
+   /* Aperture register balooning */
+   struct {
+   uint32_t base;
+   uint32_t size;
+   } mappable_gmadr;   /* aperture */
+   /* GMADR register balooning */
+   struct {
+   uint32_t base;
+   uint32_t size;
+   } nonmappable_gmadr;/* non aperture */
+   /* allowed fence registers */
+   uint32_t fence_num;
+   uint32_t rsv2[3];
+   } avail_rs; /* available/assigned resource */
+   uint32_t rsv3[0x200 - 24];  /* pad to half page */
+   /*
+* The bottom half page is for response from Gfx driver to hypervisor.
+*/
+   uint32_t rsv4;
+   uint32_t display_ready; /* ready for display owner switch */
+
+   uint32_t rsv5[4];
+
+   uint32_t g2v_notify;
+   uint32_t rsv6[7];
+
+   struct {
+   uint32_t lo;
+   uint32_t hi;
+   } pdp[4];
+
+   uint32_t execlist_context_descriptor_lo;
+   uint32_t execlist_context_descriptor_hi;
+
+   uint32_t  rsv7[0x200 - 24];/* pad to one page */
+} __packed;
+
+#define vgtif_reg(x) \
+   _MMIO((VGT_PVINFO_PAGE + (long)&((struct vgt_if *)NULL)->x))
+
+/* vGPU display status to be used by the host side */

[Intel-gfx] [PATCH v8 00/10] Introduce the implementation of GVT context

[Zhi Wang]

This patchset introduces the implementation of GVT context. GVT
context is a special GEM context used by GVT-g. GVT-g uses it as the shadow
context.It doesn't have a drm client nor a PPGTT. And it requires a larger
ring buffer with several special features need by GVT-g workload scheduler
like context status change notification, context single submission...

v8:

- Take Joonas/Chris' comments.

v7:

- Take Joonas' comments.

v6:

- Take Chris' comments.

v5:

- Drop PPGTT related patches.
- Let most functions take struct drm_i915_private *
- Fixed some misspelled words in Kconfig
- Only complied some feature when CONFIG_DRM_I915_GVT=y
- Drop the fecne related changes, will send it after this series.

v4:

- Based on the latest drm-intel-nightly branch.
- Drop PPGTT refactor patches. (GVT-g will use LRI to load PDPs)
- Drop i915_gem_context() refactor patches, reuse kernel context functions.
  (Dave Gordon)
- Drop context allocation params and refactor as the lrc deferred
  allocation function has been refactored in another styles.
- Re-wrtie GVT context creation function

Difference from community release
-

This patchset is different from regular iGVT-g code release[4], which
is still based on old host-mediated architecture. Furthermore, this
patchset only supports BDW whereas code release supports HSW/BDW/SKL.
We will add SKL support later based on this RFC code and HSW support
will be dropped.

Internally we tested this RFC patchset with both linux and windows VM
and the architecture changes work fine.

Acknowledgment
---

iGVT-g implementation is several years effort and many people
contributed to the code. There names are not here yet. In later formal
patchset we will reflect individual's contribution.

Meanwhile, in the previous iGVT-g related discussion, Daniel, Chris
and Joonas ever gave very good inputs. We appreciate them and look
forward to more comments/suggestions from community.

We are trying to get more familiar with i915 but may still have gaps.
We are willing to adopt suggestions to keep improving. We hope to work
with community together to make iGVT-g a great component in i915 to
support graphics virtualization. Thanks!

Reference
-

[1] https://01.org/igvt-g
[2] http://lists.freedesktop.org/archives/intel-gfx/2014-September/053098.html
[3] http://lists.freedesktop.org/archives/intel-gfx/2015-September/075397.html


Bing Niu (1):
  drm/i915: Introduce host graphics memory partition for GVT-g

Zhi Wang (9):
  drm/i915: Factor out i915_pvinfo.h
  drm/i915: Use offsetof() to calculate the offset of members in PVINFO
page
  drm/i915: Fold vGPU active check into inner functions
  drm/i915: gvt: Introduce the basic architecture of GVT-g
  drm/i915: Make ring buffer size of a LRC context configurable
  drm/i915: Make addressing mode bits in context descriptor configurable
  drm/i915: Introduce execlist context status change notification
  drm/i915: Support LRC context single submission
  drm/i915: Introduce GVT context creation API

 drivers/gpu/drm/i915/Kconfig|  22 +
 drivers/gpu/drm/i915/Makefile   |   5 ++
 drivers/gpu/drm/i915/gvt/Makefile   |   5 ++
 drivers/gpu/drm/i915/gvt/debug.h|  34 
 drivers/gpu/drm/i915/gvt/gvt.c  | 145 
 drivers/gpu/drm/i915/gvt/gvt.h  |  69 +++
 drivers/gpu/drm/i915/gvt/hypercall.h|  38 +
 drivers/gpu/drm/i915/gvt/mpt.h  |  49 +++
 drivers/gpu/drm/i915/i915_dma.c |  16 +++-
 drivers/gpu/drm/i915/i915_drv.h |  16 
 drivers/gpu/drm/i915/i915_gem_context.c |  38 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |  11 +--
 drivers/gpu/drm/i915/i915_params.c  |   5 ++
 drivers/gpu/drm/i915/i915_params.h  |   1 +
 drivers/gpu/drm/i915/i915_pvinfo.h  | 113 +
 drivers/gpu/drm/i915/i915_reg.h |  12 +++
 drivers/gpu/drm/i915/i915_vgpu.c|  32 +--
 drivers/gpu/drm/i915/i915_vgpu.h|  90 +---
 drivers/gpu/drm/i915/intel_gvt.c| 100 ++
 drivers/gpu/drm/i915/intel_gvt.h|  81 ++
 drivers/gpu/drm/i915/intel_lrc.c|  53 +---
 drivers/gpu/drm/i915/intel_lrc.h|   5 ++
 22 files changed, 821 insertions(+), 119 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
 create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
 create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
 create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h
 create mode 100644 drivers/gpu/drm/i915/intel_gvt.c
 create mode 100644 drivers/gpu/drm/i915/intel_gvt.h

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 05:55:23PM +0300, Imre Deak wrote:
> On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> > > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > > > > We can check the power state of the PHY data and common lanes as
> > > > > reported by the PHY. Do this in case we need to debug problems where 
> > > > > the
> > > > > PHY gets stuck in an unexpected state.
> > > > > 
> > > > > Note that I only check these when the lanes are expected to be powered
> > > > > on purpose, since it's not clear at what point the PHY power/clock 
> > > > > gates
> > > > > things.
> > > > > 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_reg.h  |  9 +
> > > > >  drivers/gpu/drm/i915/intel_ddi.c | 27 +++
> > > > >  2 files changed, 36 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > index 81fc498..e904818 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
> > > > >  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
> > > > >  #define   GT_DISPLAY_POWER_ON(phy)   (1 << (phy))
> > > > >  
> > > > > +#define _BXT_PHY_CTL_DDI_A   0x64C00
> > > > > +#define _BXT_PHY_CTL_DDI_B   0x64C10
> > > > > +#define _BXT_PHY_CTL_DDI_C   0x64C20
> > > > > +#define   BXT_PHY_CMNLANE_POWERDOWN_ACK  (1 << 10)
> > > > > +#define   BXT_PHY_LANE_POWERDOWN_ACK (1 << 9)
> > > > > +#define   BXT_PHY_LANE_ENABLED   (1 << 8)
> > > > > +#define BXT_PHY_CTL(port)_MMIO_PORT(port, 
> > > > > _BXT_PHY_CTL_DDI_A, \
> > > > > +  
> > > > > _BXT_PHY_CTL_DDI_B)
> > > > > +
> > > > >  #define _PHY_CTL_FAMILY_EDP  0x64C80
> > > > >  #define _PHY_CTL_FAMILY_DDI  0x64C90
> > > > >  #define   COMMON_RESET_DIS   (1 << 31)
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index acf0a7a..afa28a1 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -1342,6 +1342,16 @@ bool intel_ddi_get_hw_state(struct 
> > > > > intel_encoder *encoder,
> > > > >   DRM_DEBUG_KMS("No pipe for ddi port %c found\n", 
> > > > > port_name(port));
> > > > >  
> > > > >  out:
> > > > > + if (ret && IS_BROXTON(dev_priv)) {
> > > > > + tmp = I915_READ(BXT_PHY_CTL(port));
> > > > > + if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> > > > > + BXT_PHY_LANE_ENABLED)) != 
> > > > > BXT_PHY_LANE_ENABLED) {
> > > > > + DRM_DEBUG_KMS("Port %c enabled but PHY powered 
> > > > > down? "
> > > > > +   "(PHY_CTL %08x)\n", 
> > > > > port_name(port), tmp);
> > > > > + ret = false;
> > > > 
> > > > Hmm. I'm not sure I'd change the return value here because then we'd
> > > > fail to follow the proper shutdown sequence, perhaps even messing
> > > > up the next modeset?
> > > 
> > > What I wanted is to force a reprogramming in this case, but yea we
> > > would miss then the proper disable sequence. AFAICS we can't mark the
> > > state here as enabled but not valid, so for now I will just change the
> > > above to DRM_ERROR then and report an enabled state as you suggested.
> > 
> > Yeah. So far we've done any reprogramming in the sanitize phase, but
> > that may require splitting/duplicating some parts of state readout. Maybe
> > we should allow .get_config() & co. to flag the state as "this needs a
> > forced modeset to sanitize things"?
> 
> Yea, sounds good to me. Since this a new check in any case could we add
> this as a follow-up?

Yes. This was more of a food for thought type of suggestion, so wasn't
expecting that it would happen right away.

> 
> > > > So maybe just ERROR/WARN in these cases?
> > > > 
> > > > > + }
> > > > > + }
> > > > > +
> > > > >   intel_display_power_put(dev_priv, power_domain);
> > > > >  
> > > > >   return ret;
> > > > > @@ -1745,6 +1755,8 @@ static void intel_disable_ddi(struct 
> > > > > intel_encoder *intel_encoder)
> > > > >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> > > > >   enum dpio_phy phy)
> > > > >  {
> > > > > + enum port port;
> > > > > +
> > > > >   if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & 
> > > > > GT_DISPLAY_POWER_ON(phy)))
> > > > >   return false;
> > > > >  
> > > > > @@ -1770,6 +1782,21 @@ bool bxt_ddi_phy_is_enabled(struct 
> > > > > drm_i915_private *dev_priv,
> > > > >   return false;
> > > > >   }
> > > > >  
> > > > > + 

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for gen9 workarounds v3

[Chris Wilson]

On Wed, Jun 08, 2016 at 05:28:31PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > [ text/plain ]
> > On Tue, Jun 07, 2016 at 02:52:18PM -, Patchwork wrote:
> >> == Series Details ==
> >> 
> >> Series: gen9 workarounds v3
> >> URL   : https://patchwork.freedesktop.org/series/8405/
> >> State : success
> >> 
> >> == Summary ==
> >> 
> >> Series 8405v1 gen9 workarounds v3
> >> http://patchwork.freedesktop.org/api/1.0/series/8405/revisions/1/mbox
> >> 
> >> 
> >> fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
> >> fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
> >
> > Out of curiosity, how many of these w/a are exercised by mesa/piglit or
> > beignet test suites? If so, how many of those could we extract to igt?
> > i.e. are any of these w/a suitable for test cases??
> 
> WaEnableGapsTsvCreditFix we managed to trigger with gem_ringfill.
> 
> WaForceContextSaveRestoreNonCoherent was triggered by piglit,
> but it needed also mesa counterpart. So this is one candidate.
> 
> I agree that we should have igt triggering as a goal
> when reading, sometimes sketchy, hsds.

It's also indicative of what behaviour we should be stressing. If it is
not possible to exercise such through our uABI that is one thing. But if
we could have detected the error, then we are missing coverage in our igt.
It is definitely a useful exercise if the test remains valid for gen+1.
-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/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Imre Deak]

On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote:
> On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > > > We can check the power state of the PHY data and common lanes as
> > > > reported by the PHY. Do this in case we need to debug problems where the
> > > > PHY gets stuck in an unexpected state.
> > > > 
> > > > Note that I only check these when the lanes are expected to be powered
> > > > on purpose, since it's not clear at what point the PHY power/clock gates
> > > > things.
> > > > 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  9 +
> > > >  drivers/gpu/drm/i915/intel_ddi.c | 27 +++
> > > >  2 files changed, 36 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 81fc498..e904818 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
> > > >  #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
> > > >  #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
> > > >  
> > > > +#define _BXT_PHY_CTL_DDI_A 0x64C00
> > > > +#define _BXT_PHY_CTL_DDI_B 0x64C10
> > > > +#define _BXT_PHY_CTL_DDI_C 0x64C20
> > > > +#define   BXT_PHY_CMNLANE_POWERDOWN_ACK(1 << 10)
> > > > +#define   BXT_PHY_LANE_POWERDOWN_ACK   (1 << 9)
> > > > +#define   BXT_PHY_LANE_ENABLED (1 << 8)
> > > > +#define BXT_PHY_CTL(port)  _MMIO_PORT(port, 
> > > > _BXT_PHY_CTL_DDI_A, \
> > > > +    
> > > > _BXT_PHY_CTL_DDI_B)
> > > > +
> > > >  #define _PHY_CTL_FAMILY_EDP0x64C80
> > > >  #define _PHY_CTL_FAMILY_DDI0x64C90
> > > >  #define   COMMON_RESET_DIS (1 << 31)
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index acf0a7a..afa28a1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -1342,6 +1342,16 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > > > *encoder,
> > > >     DRM_DEBUG_KMS("No pipe for ddi port %c found\n", 
> > > > port_name(port));
> > > >  
> > > >  out:
> > > > +   if (ret && IS_BROXTON(dev_priv)) {
> > > > +   tmp = I915_READ(BXT_PHY_CTL(port));
> > > > +   if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> > > > +   BXT_PHY_LANE_ENABLED)) != 
> > > > BXT_PHY_LANE_ENABLED) {
> > > > +   DRM_DEBUG_KMS("Port %c enabled but PHY powered 
> > > > down? "
> > > > +     "(PHY_CTL %08x)\n", 
> > > > port_name(port), tmp);
> > > > +   ret = false;
> > > 
> > > Hmm. I'm not sure I'd change the return value here because then we'd
> > > fail to follow the proper shutdown sequence, perhaps even messing
> > > up the next modeset?
> > 
> > What I wanted is to force a reprogramming in this case, but yea we
> > would miss then the proper disable sequence. AFAICS we can't mark the
> > state here as enabled but not valid, so for now I will just change the
> > above to DRM_ERROR then and report an enabled state as you suggested.
> 
> Yeah. So far we've done any reprogramming in the sanitize phase, but
> that may require splitting/duplicating some parts of state readout. Maybe
> we should allow .get_config() & co. to flag the state as "this needs a
> forced modeset to sanitize things"?

Yea, sounds good to me. Since this a new check in any case could we add
this as a follow-up?

> > > So maybe just ERROR/WARN in these cases?
> > > 
> > > > +   }
> > > > +   }
> > > > +
> > > >     intel_display_power_put(dev_priv, power_domain);
> > > >  
> > > >     return ret;
> > > > @@ -1745,6 +1755,8 @@ static void intel_disable_ddi(struct 
> > > > intel_encoder *intel_encoder)
> > > >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> > > >     enum dpio_phy phy)
> > > >  {
> > > > +   enum port port;
> > > > +
> > > >     if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & 
> > > > GT_DISPLAY_POWER_ON(phy)))
> > > >     return false;
> > > >  
> > > > @@ -1770,6 +1782,21 @@ bool bxt_ddi_phy_is_enabled(struct 
> > > > drm_i915_private *dev_priv,
> > > >     return false;
> > > >     }
> > > >  
> > > > +   for_each_port_masked(port,
> > > > +    phy == DPIO_PHY0 ? BIT(PORT_B) | 
> > > > BIT(PORT_C) :
> > > > +   BIT(PORT_A)) {
> > > > +   u32 tmp = I915_READ(BXT_PHY_CTL(port));
> > > > +
> > > > +   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> > > > +   

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 04:47:48PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 15:35 schreef Ville Syrjälä:
> > On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
> >> Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> >>> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
>  This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
>  to 10s.
> >>> Does it still find the problem reliably on CHV pipe C (if you remove the
> >>> kernel w/a)?
> >> Yeah, a single coordinate is enough to trigger the fifo underrun. Rest is 
> >> probably still slightly overkill. :)
> > Hmm. IIRC it wasn't quite that easy to trigger on my CHV. Sometime
> > it survived for a few iterations. But I'm too lazy to retest it now,
> > so I'll take your word for it.
> >
> Weird, even kms_cursor_crc random test triggered it for me on the first try 
> with negative coordinates.

Might be that I'm only recalling the visual feedback. That is, maybe I
sometimes failed to see the underrun even though it did happen.

-- 
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 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > > We can check the power state of the PHY data and common lanes as
> > > reported by the PHY. Do this in case we need to debug problems where the
> > > PHY gets stuck in an unexpected state.
> > > 
> > > Note that I only check these when the lanes are expected to be powered
> > > on purpose, since it's not clear at what point the PHY power/clock gates
> > > things.
> > > 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  9 +
> > >  drivers/gpu/drm/i915/intel_ddi.c | 27 +++
> > >  2 files changed, 36 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 81fc498..e904818 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
> > >  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
> > >  #define   GT_DISPLAY_POWER_ON(phy)   (1 << (phy))
> > >  
> > > +#define _BXT_PHY_CTL_DDI_A   0x64C00
> > > +#define _BXT_PHY_CTL_DDI_B   0x64C10
> > > +#define _BXT_PHY_CTL_DDI_C   0x64C20
> > > +#define   BXT_PHY_CMNLANE_POWERDOWN_ACK  (1 << 10)
> > > +#define   BXT_PHY_LANE_POWERDOWN_ACK (1 << 9)
> > > +#define   BXT_PHY_LANE_ENABLED   (1 << 8)
> > > +#define BXT_PHY_CTL(port)_MMIO_PORT(port, 
> > > _BXT_PHY_CTL_DDI_A, \
> > > +  _BXT_PHY_CTL_DDI_B)
> > > +
> > >  #define _PHY_CTL_FAMILY_EDP  0x64C80
> > >  #define _PHY_CTL_FAMILY_DDI  0x64C90
> > >  #define   COMMON_RESET_DIS   (1 << 31)
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index acf0a7a..afa28a1 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1342,6 +1342,16 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > > *encoder,
> > >   DRM_DEBUG_KMS("No pipe for ddi port %c found\n", port_name(port));
> > >  
> > >  out:
> > > + if (ret && IS_BROXTON(dev_priv)) {
> > > + tmp = I915_READ(BXT_PHY_CTL(port));
> > > + if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> > > + BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED) {
> > > + DRM_DEBUG_KMS("Port %c enabled but PHY powered down? "
> > > +   "(PHY_CTL %08x)\n", port_name(port), tmp);
> > > + ret = false;
> > 
> > Hmm. I'm not sure I'd change the return value here because then we'd
> > fail to follow the proper shutdown sequence, perhaps even messing
> > up the next modeset?
> 
> What I wanted is to force a reprogramming in this case, but yea we
> would miss then the proper disable sequence. AFAICS we can't mark the
> state here as enabled but not valid, so for now I will just change the
> above to DRM_ERROR then and report an enabled state as you suggested.

Yeah. So far we've done any reprogramming in the sanitize phase, but
that may require splitting/duplicating some parts of state readout. Maybe
we should allow .get_config() & co. to flag the state as "this needs a
forced modeset to sanitize things"?

> 
> > So maybe just ERROR/WARN in these cases?
> > 
> > > + }
> > > + }
> > > +
> > >   intel_display_power_put(dev_priv, power_domain);
> > >  
> > >   return ret;
> > > @@ -1745,6 +1755,8 @@ static void intel_disable_ddi(struct intel_encoder 
> > > *intel_encoder)
> > >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> > >   enum dpio_phy phy)
> > >  {
> > > + enum port port;
> > > +
> > >   if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
> > >   return false;
> > >  
> > > @@ -1770,6 +1782,21 @@ bool bxt_ddi_phy_is_enabled(struct 
> > > drm_i915_private *dev_priv,
> > >   return false;
> > >   }
> > >  
> > > + for_each_port_masked(port,
> > > +  phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
> > > + BIT(PORT_A)) {
> > > + u32 tmp = I915_READ(BXT_PHY_CTL(port));
> > > +
> > > + if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> > > + DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
> > > +  "for port %c powered down "
> > > +  "(PHY_CTL %08x)\n",
> > > +  phy, port_name(port), tmp);
> > > +
> > > + return false;
> > > + }
> > > + }
> > > +
> > >   return true;
> > >  }
> > >  
> > > -- 
> > > 2.5.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > 

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Maarten Lankhorst]

Op 08-06-16 om 15:35 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
>> Op 08-06-16 om 15:12 schreef Ville Syrjälä:
>>> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
 This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
 to 10s.
>>> Does it still find the problem reliably on CHV pipe C (if you remove the
>>> kernel w/a)?
>> Yeah, a single coordinate is enough to trigger the fifo underrun. Rest is 
>> probably still slightly overkill. :)
> Hmm. IIRC it wasn't quite that easy to trigger on my CHV. Sometime
> it survived for a few iterations. But I'm too lazy to retest it now,
> so I'll take your word for it.
>
Weird, even kms_cursor_crc random test triggered it for me on the first try 
with negative coordinates.

~Maarten

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Imre Deak]

On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > We can check the power state of the PHY data and common lanes as
> > reported by the PHY. Do this in case we need to debug problems where the
> > PHY gets stuck in an unexpected state.
> > 
> > Note that I only check these when the lanes are expected to be powered
> > on purpose, since it's not clear at what point the PHY power/clock gates
> > things.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  9 +
> >  drivers/gpu/drm/i915/intel_ddi.c | 27 +++
> >  2 files changed, 36 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 81fc498..e904818 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
> >  #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
> >  #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
> >  
> > +#define _BXT_PHY_CTL_DDI_A 0x64C00
> > +#define _BXT_PHY_CTL_DDI_B 0x64C10
> > +#define _BXT_PHY_CTL_DDI_C 0x64C20
> > +#define   BXT_PHY_CMNLANE_POWERDOWN_ACK(1 << 10)
> > +#define   BXT_PHY_LANE_POWERDOWN_ACK   (1 << 9)
> > +#define   BXT_PHY_LANE_ENABLED (1 << 8)
> > +#define BXT_PHY_CTL(port)  _MMIO_PORT(port, _BXT_PHY_CTL_DDI_A, \
> > +    _BXT_PHY_CTL_DDI_B)
> > +
> >  #define _PHY_CTL_FAMILY_EDP0x64C80
> >  #define _PHY_CTL_FAMILY_DDI0x64C90
> >  #define   COMMON_RESET_DIS (1 << 31)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index acf0a7a..afa28a1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1342,6 +1342,16 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > *encoder,
> >     DRM_DEBUG_KMS("No pipe for ddi port %c found\n", port_name(port));
> >  
> >  out:
> > +   if (ret && IS_BROXTON(dev_priv)) {
> > +   tmp = I915_READ(BXT_PHY_CTL(port));
> > +   if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> > +   BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED) {
> > +   DRM_DEBUG_KMS("Port %c enabled but PHY powered down? "
> > +     "(PHY_CTL %08x)\n", port_name(port), tmp);
> > +   ret = false;
> 
> Hmm. I'm not sure I'd change the return value here because then we'd
> fail to follow the proper shutdown sequence, perhaps even messing
> up the next modeset?

What I wanted is to force a reprogramming in this case, but yea we
would miss then the proper disable sequence. AFAICS we can't mark the
state here as enabled but not valid, so for now I will just change the
above to DRM_ERROR then and report an enabled state as you suggested.

> So maybe just ERROR/WARN in these cases?
> 
> > +   }
> > +   }
> > +
> >     intel_display_power_put(dev_priv, power_domain);
> >  
> >     return ret;
> > @@ -1745,6 +1755,8 @@ static void intel_disable_ddi(struct intel_encoder 
> > *intel_encoder)
> >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> >     enum dpio_phy phy)
> >  {
> > +   enum port port;
> > +
> >     if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
> >     return false;
> >  
> > @@ -1770,6 +1782,21 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
> > *dev_priv,
> >     return false;
> >     }
> >  
> > +   for_each_port_masked(port,
> > +    phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
> > +   BIT(PORT_A)) {
> > +   u32 tmp = I915_READ(BXT_PHY_CTL(port));
> > +
> > +   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> > +   DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
> > +    "for port %c powered down "
> > +    "(PHY_CTL %08x)\n",
> > +    phy, port_name(port), tmp);
> > +
> > +   return false;
> > +   }
> > +   }
> > +
> >     return true;
> >  }
> >  
> > -- 
> > 2.5.0
> > 
> > ___
> > 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: warning for drm/i915: Remaining PSR fixes

[Patchwork]

== Series Details ==

Series: drm/i915: Remaining PSR fixes
URL   : https://patchwork.freedesktop.org/series/8046/
State : warning

== Summary ==

Series 8046v1 drm/i915: Remaining PSR fixes
http://patchwork.freedesktop.org/api/1.0/series/8046/revisions/1/mbox

Test kms_sink_crc_basic:
pass   -> SKIP   (ro-bdw-i7-5600u)

fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bdw-i7-5600u  total:183  pass:153  dwarn:0   dfail:0   fail:0   skip:29 
ro-bsw-n3050 total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:168  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:183  pass:161  dwarn:0   dfail:0   fail:0   skip:21 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-ivb2-i7-3770  total:183  pass:158  dwarn:0   dfail:0   fail:0   skip:24 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1140/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
7308d82 drm/i915: Move psr.link_standby setup to intel_psr_match_conditions()
1ab6761 drm/i915: Ask the sink whether training is required when exiting PSR 
main-link off mode
21ec657 drm/i915/psr: Skip aux handeshake if the vbt tells us to
0c49a1e drm/i915: Check PSR setup time vs. vblank length
fedc8d8 drm/dp: Add drm_dp_psr_need_train_on_exit()
a3c27c1 drm/dp: Add drm_dp_psr_setup_time()

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

Re: [Intel-gfx] [PATCH 27/27] drm/i915/gen9: Add WaFbcHighMemBwCorruptionAvoidance

[Mika Kuoppala]

Ville Syrjälä  writes:

> [ text/plain ]
> On Tue, Jun 07, 2016 at 05:19:19PM +0300, Mika Kuoppala wrote:
>> Add this fbc related workaround for all gen9
>> 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Mika Kuoppala 
>
> Reviewed-by: Ville Syrjälä 
>

All patches pushed to dinq. Ty all for review.

-Mika


>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>>  drivers/gpu/drm/i915/intel_pm.c | 4 
>>  2 files changed, 5 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index f6a140b2c77c..81d1896f158c 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2209,6 +2209,7 @@ enum skl_disp_power_wells {
>>  #define ILK_DPFC_STATUS _MMIO(0x43210)
>>  #define ILK_DPFC_FENCE_YOFF _MMIO(0x43218)
>>  #define ILK_DPFC_CHICKEN_MMIO(0x43224)
>> +#define   ILK_DPFC_DISABLE_DUMMY0 (1<<8)
>>  #define   ILK_DPFC_NUKE_ON_ANY_MODIFICATION (1<<23)
>>  #define ILK_FBC_RT_BASE _MMIO(0x2128)
>>  #define   ILK_FBC_RT_VALID  (1<<0)
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 1464d7ba69d4..658a75659657 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -75,6 +75,10 @@ static void gen9_init_clock_gating(struct drm_device *dev)
>>  I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
>> DISP_FBC_WM_DIS |
>> DISP_FBC_MEMORY_WAKE);
>> +
>> +/* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl */
>> +I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) |
>> +   ILK_DPFC_DISABLE_DUMMY0);
>>  }
>>  
>>  static void bxt_init_clock_gating(struct drm_device *dev)
>> -- 
>> 2.7.4
>
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for gen9 workarounds v3

[Mika Kuoppala]

Chris Wilson  writes:

> [ text/plain ]
> On Tue, Jun 07, 2016 at 02:52:18PM -, Patchwork wrote:
>> == Series Details ==
>> 
>> Series: gen9 workarounds v3
>> URL   : https://patchwork.freedesktop.org/series/8405/
>> State : success
>> 
>> == Summary ==
>> 
>> Series 8405v1 gen9 workarounds v3
>> http://patchwork.freedesktop.org/api/1.0/series/8405/revisions/1/mbox
>> 
>> 
>> fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
>> fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
>
> Out of curiosity, how many of these w/a are exercised by mesa/piglit or
> beignet test suites? If so, how many of those could we extract to igt?
> i.e. are any of these w/a suitable for test cases??

WaEnableGapsTsvCreditFix we managed to trigger with gem_ringfill.

WaForceContextSaveRestoreNonCoherent was triggered by piglit,
but it needed also mesa counterpart. So this is one candidate.

I agree that we should have igt triggering as a goal
when reading, sometimes sketchy, hsds.

Now for most part we trust only to the wording and
gem_workarounds.

-Mika

> -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/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Ville Syrjälä]

On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> We can check the power state of the PHY data and common lanes as
> reported by the PHY. Do this in case we need to debug problems where the
> PHY gets stuck in an unexpected state.
> 
> Note that I only check these when the lanes are expected to be powered
> on purpose, since it's not clear at what point the PHY power/clock gates
> things.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  9 +
>  drivers/gpu/drm/i915/intel_ddi.c | 27 +++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 81fc498..e904818 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1276,6 +1276,15 @@ enum skl_disp_power_wells {
>  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
>  #define   GT_DISPLAY_POWER_ON(phy)   (1 << (phy))
>  
> +#define _BXT_PHY_CTL_DDI_A   0x64C00
> +#define _BXT_PHY_CTL_DDI_B   0x64C10
> +#define _BXT_PHY_CTL_DDI_C   0x64C20
> +#define   BXT_PHY_CMNLANE_POWERDOWN_ACK  (1 << 10)
> +#define   BXT_PHY_LANE_POWERDOWN_ACK (1 << 9)
> +#define   BXT_PHY_LANE_ENABLED   (1 << 8)
> +#define BXT_PHY_CTL(port)_MMIO_PORT(port, _BXT_PHY_CTL_DDI_A, \
> +  _BXT_PHY_CTL_DDI_B)
> +
>  #define _PHY_CTL_FAMILY_EDP  0x64C80
>  #define _PHY_CTL_FAMILY_DDI  0x64C90
>  #define   COMMON_RESET_DIS   (1 << 31)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index acf0a7a..afa28a1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1342,6 +1342,16 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> *encoder,
>   DRM_DEBUG_KMS("No pipe for ddi port %c found\n", port_name(port));
>  
>  out:
> + if (ret && IS_BROXTON(dev_priv)) {
> + tmp = I915_READ(BXT_PHY_CTL(port));
> + if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> + BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED) {
> + DRM_DEBUG_KMS("Port %c enabled but PHY powered down? "
> +   "(PHY_CTL %08x)\n", port_name(port), tmp);
> + ret = false;

Hmm. I'm not sure I'd change the return value here because then we'd
fail to follow the proper shutdown sequence, perhaps even messing
up the next modeset?

So maybe just ERROR/WARN in these cases?

> + }
> + }
> +
>   intel_display_power_put(dev_priv, power_domain);
>  
>   return ret;
> @@ -1745,6 +1755,8 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder)
>  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
>   enum dpio_phy phy)
>  {
> + enum port port;
> +
>   if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
>   return false;
>  
> @@ -1770,6 +1782,21 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
> *dev_priv,
>   return false;
>   }
>  
> + for_each_port_masked(port,
> +  phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
> + BIT(PORT_A)) {
> + u32 tmp = I915_READ(BXT_PHY_CTL(port));
> +
> + if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> + DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
> +  "for port %c powered down "
> +  "(PHY_CTL %08x)\n",
> +  phy, port_name(port), tmp);
> +
> + return false;
> + }
> + }
> +
>   return true;
>  }
>  
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 2/2] igt/gem_reset_stats: Add time constraints on hang detection

[Chris Wilson]

On Wed, Jun 08, 2016 at 04:07:18PM +0300, Mika Kuoppala wrote:
> Make sure that injected hang is detected below time threshold.
> This ensures that we fail if hang was of no-progress type instead
> of a stuck engine.
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  tests/gem_reset_stats.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
> index 27bc6c9cfb59..74c102d3fd7d 100644
> --- a/tests/gem_reset_stats.c
> +++ b/tests/gem_reset_stats.c
> @@ -148,6 +148,23 @@ static int gem_reset_status(int fd, int ctx_id)
>   return RS_NO_ERROR;
>  }
>  
> +static struct timespec ts_injected;
> +
>  #define BAN HANG_ALLOW_BAN
>  #define ASYNC 2
>  static void inject_hang(int fd, uint32_t ctx,
> @@ -156,6 +173,8 @@ static void inject_hang(int fd, uint32_t ctx,
>  {
>   igt_hang_ring_t hang;
>  
> + clock_gettime(CLOCK_MONOTONIC, _injected);
> +
>   hang = igt_hang_ctx(fd, ctx, e->exec_id | e->flags, flags & BAN, NULL);
>   if ((flags & ASYNC) == 0)
>   igt_post_hang_ring(fd, hang);
> @@ -238,6 +257,8 @@ static void test_rs(const struct intel_execution_engine 
> *e,
>   assert_reset_status(i, fd[i], 0, RS_BATCH_PENDING);
>   }
>  
> + igt_assert(elapsed_from_hang_injection() < 31.0);
igt_assert(igt_seconds_elapsed(_injected) <= 30);
> +
>   for (i = 0; i < num_fds; i++)
>   close(fd[i]);
>  }
> @@ -290,6 +311,8 @@ static void test_rs_ctx(const struct 
> intel_execution_engine *e,
>   }
>   sync_gpu();
>  

> + igt_assert(elapsed_from_hang_injection() < 31.0);
igt_assert(igt_seconds_elapsed(_injected) <= 30);
-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 03/11] drm/i915: Use insert_page for pwrite_fast

[kbuild test robot]

Hi,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160608]
[cannot apply to v4.7-rc2]
[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/ankitprasad-r-sharma-intel-com/Support-for-creating-using-Stolen-memory-backed-objects/20160608-205058
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_overscan_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_saturation_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'tv_hue_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'scaling_mode_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'aspect_ratio_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'dirty_info_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'suggested_x_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'suggested_y_property'
   include/drm/drm_crtc.h:2185: warning: No description found for parameter 
'allow_fb_modifiers'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: No description found for 
parameter 'nonblock'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: Excess function parameter 
'nonblocking' description in 'drm_atomic_helper_commit'
   drivers/gpu/drm/drm_atomic_helper.c:2946: warning: No description found for 
parameter 'start'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: No description found for 
parameter 'nonblock'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: Excess function parameter 
'nonblocking' description in 'drm_atomic_helper_commit'
   drivers/gpu/drm/drm_atomic_helper.c:2946: warning: No description found for 
parameter 'start'
   drivers/gpu/drm/drm_atomic_helper.c:1: warning: no structured comments found
   Was looking for 'implementing async commit'.
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: No description found for 
parameter 'nonblock'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: Excess function parameter 
'nonblocking' description in 'drm_atomic_helper_commit'
   drivers/gpu/drm/drm_atomic_helper.c:2946: warning: No description found for 
parameter 'start'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: No description found for 
parameter 'nonblock'
   drivers/gpu/drm/drm_atomic_helper.c:1150: warning: Excess function parameter 
'nonblocking' description in 'drm_atomic_helper_commit'
   drivers/gpu/drm/drm_atomic_helper.c:2946: warning: No description found for 
parameter 'start'
   drivers/gpu/drm/drm_fb_cma_helper.c:173: warning: No description found for 
parameter 'dev'
   drivers/gpu/drm/drm_fb_cma_helper.c:173: warning: No description found for 
parameter 'file_priv'
   drivers/gpu/drm/drm_fb_cma_helper.c:173: warning: No description found for 
parameter 'mode_cmd'
   drivers/gpu/drm/drm_fb_cma_helper.c:173: warning: No description found for 
parameter 

Re: [Intel-gfx] [PATCH 1/2] lib/gt: Omit illegal instruction on hang injection with gen 8+

[Chris Wilson]

On Wed, Jun 08, 2016 at 04:07:17PM +0300, Mika Kuoppala wrote:
> 0x as an illegal command confuses the command execution
> on gen9 so that the next BB start will get ignored, causing a runaway
> head past the bb end. This delays the hang detection substantially
> as hangcheck then observes only a non progressing seqno.
> 
> Omit the bad instruction on gen8+ and rely on the chained batch
> loop to cause a deterministic hang. Make the chained bb start
> to jump straight into bb start, omitting the MI_NOOP or the bad
> instruction on subsequent passes. This makes the acthd sampling
> to hit more reliably to the same value, as the loop is smaller,
> making the head appear to be 'more stuck'.

You could note that BB(addr | 4) is also illegal. gen2+ requires 8 byte
alignment, ilk requires 64 byte.
 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=92715
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Factor out intel_power_well_get/put

[Ville Syrjälä]

On Tue, Jun 07, 2016 at 09:24:29PM +0300, Imre Deak wrote:
> These helpers will be needed by the next patch, so factor them out.
> 
> No functional change.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 2b75b30..d0d056a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -151,6 +151,20 @@ static void intel_power_well_disable(struct 
> drm_i915_private *dev_priv,
>   power_well->ops->disable(dev_priv, power_well);
>  }
>  
> +static void intel_power_well_get(struct drm_i915_private *dev_priv,
> +  struct i915_power_well *power_well)
> +{
> + if (!power_well->count++)
> + intel_power_well_enable(dev_priv, power_well);
> +}
> +
> +static void intel_power_well_put(struct drm_i915_private *dev_priv,
> +  struct i915_power_well *power_well)
> +{
> + if (!--power_well->count)
> + intel_power_well_disable(dev_priv, power_well);
> +}
> +
>  /*
>   * We should only use the power well if we explicitly asked the hardware to
>   * enable it, so check if it's enabled and also check if we've requested it 
> to
> @@ -1518,10 +1532,8 @@ __intel_display_power_get_domain(struct 
> drm_i915_private *dev_priv,
>   struct i915_power_well *power_well;
>   int i;
>  
> - for_each_power_well(i, power_well, BIT(domain), power_domains) {
> - if (!power_well->count++)
> - intel_power_well_enable(dev_priv, power_well);
> - }
> + for_each_power_well(i, power_well, BIT(domain), power_domains)
> + intel_power_well_get(dev_priv, power_well);
>  
>   power_domains->domain_use_count[domain]++;
>  }
> @@ -1620,8 +1632,7 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>"Use count on power well %s is already zero",
>power_well->name);

Move the WARN too?

>  
> - if (!--power_well->count)
> - intel_power_well_disable(dev_priv, power_well);
> + intel_power_well_put(dev_priv, power_well);
>   }
>  
>   mutex_unlock(_domains->lock);
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

[Chris Wilson]

On Wed, Jun 08, 2016 at 01:44:27PM +0100, Tvrtko Ursulin wrote:
> 
> On 08/06/16 13:34, Chris Wilson wrote:
> >On Wed, Jun 08, 2016 at 12:47:28PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/06/16 12:24, Chris Wilson wrote:
> >>>On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:
> 
> And why so long delays? It looks pretty lightweight to me.
> 
> >>One alternative could perhaps be to add a waiter->wake_up vfunc and
> >>signalers could then potentially use a tasklet?
> >
> >Hmm, I did find that in order to reduce execlists latency, I had to
> >drive the tasklet processing from the signaler.
> 
> What do you mean? The existing execlists tasklet? Now would that work?
> >>>
> >>>Due to how dma-fence signals, the softirq is never kicked
> >>>(spin_lock_irq doesn't handle local_bh_enable()) and so we would only
> >>>submit a new task via execlists on a reschedule. That latency added
> >>>about 30% (30s on bsw) to gem_exec_parallel.
> >>
> >>I don't follow. User interrupts are separate from context complete
> >>which drives the submission. How do fences interfere with the
> >>latter?
> >
> >The biggest user benchmark (ala sysmark) regression we have for
> >execlists is the latency in submitting the first request to hardware via
> >elsp (or at least the hw responding to and executing that batch,
> >the per-bb and per-ctx w/a are not free either). If we incur extra
> >latency in the driver in even adding the request to the queue for an
> >idle GPU, that is easily felt by userspace.
> 
> I still don't see how fences tie into that. But it is not so
> important since it was all along the lines of "do we really need a
> thread".

I was just mentioning in passing an issue I noticed when mixing fences
and tasklets! Which boils down to spin_unlock_irq() doesn't do
local_bh_enable() and so trying to schedule a tasklet from inside a
fence callback incurs more latency than you would expect. Entirely
unrelated expect for the signaling, fencing and their uses ;)

> >>>+int intel_engine_enable_signaling(struct drm_i915_gem_request 
> >>>*request)
> >>>+{
> >>>+  struct intel_engine_cs *engine = request->engine;
> >>>+  struct intel_breadcrumbs *b = >breadcrumbs;
> >>>+  struct rb_node *parent, **p;
> >>>+  struct signal *signal;
> >>>+  bool first, wakeup;
> >>>+
> >>>+  if (unlikely(IS_ERR(b->signaler)))
> >>>+  return PTR_ERR(b->signaler);
> >>
> >>I don't see that there is a fallback is kthread creation failed. It
> >>should just fail in intel_engine_init_breadcrumbs if that happens.
> >
> >Because it is not fatal to using the GPU, just one optional function.
> 
> But we never expect it to fail and it is not even dependent on
> anything user controllable. Just a random error which would cause
> user experience to degrade. If thread creation failed it means
> system is in such a poor shape I would just fail the driver init.
> >>>
> >>>A minimally functional system is better than nothing at all.
> >>>GEM is not required for driver loading, interrupt driven dma-fences less
> >>>so.
> >>
> >>If you are so hot for that, how about vfuncing enable signaling in
> >>that case? Because I find the "have we created our kthread at driver
> >>init time successfuly" question for every fence a bit too much.
> >
> >read + conditional that pulls in the cacheline we want? You can place
> >the test after the spinlock if you want to avoid the cost I supose.
> >Or we just mark the GPU as wedged.
> 
> What I meant was to pass in different fence_ops at fence_init time
> depending on whether or not signaler thread was created or not. If
> driver is wanted to be functional in that case, and
> fence->enable_signaling needs to keep returning errors, it sound
> like a much more elegant solution than to repeating the check at
> every fence->enable_signaling call.

Actually, looking at it, the code was broken for !thread as there was
not an automatic fallback to polling by dma-fence. Choice between doing
that ourselves for an impossible failure case or just marking the GPU as
wedged on init.
-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 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> > On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
> >> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
> >> to 10s.
> > Does it still find the problem reliably on CHV pipe C (if you remove the
> > kernel w/a)?
> Yeah, a single coordinate is enough to trigger the fifo underrun. Rest is 
> probably still slightly overkill. :)

Hmm. IIRC it wasn't quite that easy to trigger on my CHV. Sometime
it survived for a few iterations. But I'm too lazy to retest it now,
so I'll take your word for it.

-- 
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 03/12] drm/i915: Add output_types bitmask into the crtc state

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 02:25:25PM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Rather than looping through encoders to see which encoder types
> > are being driven by the pipe, add an output_types bitmask into
> > the crtc state and populate it prior to compute_config and during
> > state readout.
> > 
> > v2: Determine output_types before .compute_config() hooks are called
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 51 
> > +++-
> >  drivers/gpu/drm/i915/intel_drv.h |  5 
> >  2 files changed, 26 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 12ff79594bc1..eabace447b1c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -535,14 +535,7 @@ needs_modeset(struct drm_crtc_state *state)
> >   */
> >  bool intel_pipe_has_type(struct intel_crtc *crtc, enum intel_output_type 
> > type)
> >  {
> > -   struct drm_device *dev = crtc->base.dev;
> > -   struct intel_encoder *encoder;
> > -
> > -   for_each_encoder_on_crtc(dev, >base, encoder)
> > -   if (encoder->type == type)
> > -   return true;
> > -
> > -   return false;
> > +   return crtc->config->output_types & (1 << type);
> 
> This could become inline and then all those
> 
>   if (intel_pipe_has_type(crtc, VGA) ||
>   intel_pipe_has_type(crtc, LVDS) ||
>   intel_pipe_has_type(crtc, HDMI))
> 
> whatnots will just disapear into a single test.

Sounds sane. Or we could just kill the entire function and just open
code it. Not sure hiding it in a function buys us anything at this
point.

> 
> I won't say how long those loops have been upsetting me without doing
> anything about them.
> 
> > @@ -12529,6 +12503,19 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
> >_config->pipe_src_w,
> >_config->pipe_src_h);
> >  
> > +   for_each_connector_in_state(state, connector, connector_state, i) {
> > +   if (connector_state->crtc != crtc)
> > +   continue;
> > +
> > +   encoder = to_intel_encoder(connector_state->best_encoder);
> > +
> > +   /*
> > +* Determine output_types before calling the .compute_config()
> > +* hooks so that the hooks can use this information safely.
> > +*/
> > +   pipe_config->output_types |= 1 << encoder->type;
> 
> pipe_config->output_types |= BIT(encoder->type);
> 
> Not my personal favourite in obfuscation, but one available to us if we
> desire.

I've been a bit wary about BIT() on account of the UL in there. But I
suppose it might not make much of a difference in the end.

-- 
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 11/12] drm/i915: Check for invalid cloning earlier during modeset

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 02:15:25PM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Move the encoder cloning check to happen earlier in the modeset. The
> > main benefit will be that the debug output from a failed modeset will
> > be less confusing as output_types can not indicate an invalid
> > configuration during the later computation stages.
> > 
> > For instance, what happened to me was kms_setmode was attempting one
> > of its invalid cloning checks during which it asked for DP+VGA cloning
> > on HSW. In this case the DP .compute_config() was executed after
> > the FDI .compute_config() leaving the DP link clock (1.62 in this case)
> > in port_clock, and then later the FDI BW computation tried to use that
> > as the FDI link clock (which should always be 2.7). 1.62 x 2 wasn't
> > enough for the mode it was trying to use, and so it ended up rejecting
> > the modeset, not because of an invalid cloning configuration, but
> > because of supposedly running out of FDI bandwidth. Took me a while
> > to figure out what had actually happened.
> 
> Did it reject the 1.62 link clock when you simply removed the
> check_encoder_cloning()? Just checking... :)

Nope. The rejection only happened due to exceeding the max fdi lane
count. I think I had a warn in there somewhere when I originally
submitted the fdi==port_clock patch, but that apparently didn't
survive into the version that eventually got merged.

-- 
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 03/12] drm/i915: Add output_types bitmask into the crtc state

[Chris Wilson]

On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Rather than looping through encoders to see which encoder types
> are being driven by the pipe, add an output_types bitmask into
> the crtc state and populate it prior to compute_config and during
> state readout.
> 
> v2: Determine output_types before .compute_config() hooks are called
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 51 
> +++-
>  drivers/gpu/drm/i915/intel_drv.h |  5 
>  2 files changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 12ff79594bc1..eabace447b1c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -535,14 +535,7 @@ needs_modeset(struct drm_crtc_state *state)
>   */
>  bool intel_pipe_has_type(struct intel_crtc *crtc, enum intel_output_type 
> type)
>  {
> - struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *encoder;
> -
> - for_each_encoder_on_crtc(dev, >base, encoder)
> - if (encoder->type == type)
> - return true;
> -
> - return false;
> + return crtc->config->output_types & (1 << type);

This could become inline and then all those

if (intel_pipe_has_type(crtc, VGA) ||
intel_pipe_has_type(crtc, LVDS) ||
intel_pipe_has_type(crtc, HDMI))

whatnots will just disapear into a single test.

I won't say how long those loops have been upsetting me without doing
anything about them.

> @@ -12529,6 +12503,19 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>  _config->pipe_src_w,
>  _config->pipe_src_h);
>  
> + for_each_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != crtc)
> + continue;
> +
> + encoder = to_intel_encoder(connector_state->best_encoder);
> +
> + /*
> +  * Determine output_types before calling the .compute_config()
> +  * hooks so that the hooks can use this information safely.
> +  */
> + pipe_config->output_types |= 1 << encoder->type;

pipe_config->output_types |= BIT(encoder->type);

Not my personal favourite in obfuscation, but one available to us if we
desire.

The code looks correct, I can't comment on ordering between computation
of mask and use though.
-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 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Maarten Lankhorst]

Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
>> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
>> to 10s.
> Does it still find the problem reliably on CHV pipe C (if you remove the
> kernel w/a)?
Yeah, a single coordinate is enough to trigger the fifo underrun. Rest is 
probably still slightly overkill. :)

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/kms_chv_cursor_fail: Remove extra igt_pipe_crc_start.

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 01:25:31PM +0200, Maarten Lankhorst wrote:
> There is a extra call to igt_pipe_crc_start that is not matched to any
> stop. Because of this the exit handler tries to reset the crc source on
> exit while the pipe disabled. This causes fails with -EIO:
> 
> (kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Test assertion failure
> function igt_pipe_crc_pipe_off, file igt_debugfs.c:364:
> (kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Failed assertion:
> write(fd, buf, strlen(buf)) == strlen(buf)
> (kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Last errno: 5, EIO
> (kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: error: -1 != 11
> Stack trace:
>   #0 [__igt_fail_assert+0xf1]
>   #1 [igt_pipe_crc_pipe_off+0xe4]
>   #2 [pipe_crc_exit_handler+0x35]
>   #3 [igt_atexit_handler+0x4c]
>   #4 [__libc_secure_getenv+0x112]
>   #5 [exit+0x15]
>   #6 [igt_exit+0xd6]
>   #7 [main+0x1ee]
>   #8 [__libc_start_main+0xf0]
>   #9 [_start+0x29]
>   #10 [+0x29]
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
>  tests/kms_chv_cursor_fail.c |   3 -
>  tests/kms_rmfb.c| 180 
> 
>  2 files changed, 180 insertions(+), 3 deletions(-)
>  create mode 100644 tests/kms_rmfb.c
> 
> diff --git a/tests/kms_chv_cursor_fail.c b/tests/kms_chv_cursor_fail.c
> index 83af07f9b968..11d01f54e511 100644
> --- a/tests/kms_chv_cursor_fail.c
> +++ b/tests/kms_chv_cursor_fail.c
> @@ -163,9 +163,6 @@ static void test_edge_pos(data_t *data, int sx, int ex, 
> int y, bool swap_axis)
>   }
>   igt_debug("\n");
>   }
> -
> -
> - igt_pipe_crc_start(data->pipe_crc);

ack

>  }
>  
>  static void test_edge(data_t *data, int sy, int ey, int sx, int ex, bool 
> swap_axis)
> diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
> new file mode 100644
> index ..a3fde9f43788
> --- /dev/null
> +++ b/tests/kms_rmfb.c

git add fail?

-- 
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 3/4] drm/i915/guc: refactor doorbell management code

[Tvrtko Ursulin]

On 08/06/16 11:55, Dave Gordon wrote:

During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.


Perhaps a few word on the goal, method and result of refactoring. Would 
be good for documentation and easier review.



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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7510841..eef67c8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,36 +174,63 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
- struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct i915_guc_client *client,
+ struct guc_doorbell_info *doorbell,
+ u16 new_id)
  {
-   struct guc_doorbell_info *doorbell;
+   struct sg_table *sg = client->guc->ctx_pool_obj->pages;
+   void *doorbell_bitmap = client->guc->doorbell_bitmap;
+   struct guc_context_desc desc;
+   size_t len;
+
+   if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+   test_bit(client->doorbell_id, doorbell_bitmap)) {
+   /* Deactivate the old doorbell */
+   doorbell->db_status = GUC_DOORBELL_DISABLED;
+   (void)host2guc_release_doorbell(client->guc, client);
+   clear_bit(client->doorbell_id, doorbell_bitmap);
+   }

-   doorbell = client->client_base + client->doorbell_offset;
+   /* Update the GuC's idea of the doorbell ID */
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+   desc.db_id = new_id;
+   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+
+   client->doorbell_id = new_id;
+   if (new_id == GUC_INVALID_DOORBELL_ID)
+   return 0;

+   /* Activate the new doorbell */
+   set_bit(client->doorbell_id, doorbell_bitmap);
doorbell->db_status = GUC_DOORBELL_ENABLED;
doorbell->cookie = 0;
+   return host2guc_allocate_doorbell(client->guc, client);


A bunch of new code here which wasn't done on doorbell init before. 
Populating the ctx_pool_obj and hust2guc call. I think the commit needs 
to explain what is happening here.


Maybe it is mostly a matter of copying over some text from the cover 
letter, but ideally it should explain what it is doing more precisely.



  }

-static void guc_disable_doorbell(struct intel_guc *guc,
-struct i915_guc_client *client)
+static void guc_init_doorbell(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ uint16_t db_id)
  {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct guc_doorbell_info *doorbell;
-   i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
-   int value;

doorbell = client->client_base + client->doorbell_offset;

-   doorbell->db_status = GUC_DOORBELL_DISABLED;
-
-   I915_WRITE(drbreg, I915_READ(drbreg) & ~GEN8_DRB_VALID);
+   guc_update_doorbell_id(client, doorbell, db_id);
+}


This function does not end up doing anything now, just a pass-through to 
guc_update_doorbell_id.


What happens to the write to drbreg ? It is completely gone and also 
from the init doorbell path together with the write to another register.




-   value = I915_READ(drbreg);
-   WARN_ON((value & GEN8_DRB_VALID) != 0);
+static void guc_disable_doorbell(struct intel_guc *guc,
+struct i915_guc_client *client)
+{
+   struct guc_doorbell_info *doorbell;

-   I915_WRITE(GEN8_DRBREGU(client->doorbell_id), 0);
-   I915_WRITE(drbreg, 0);
+   doorbell = client->client_base + client->doorbell_offset;
+   guc_update_doorbell_id(client, doorbell, GUC_INVALID_DOORBELL_ID);

/* XXX: wait for any interrupts */
/* XXX: wait for workqueue to drain */
@@ -251,7 +278,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
-   bitmap_set(guc->doorbell_bitmap, id, 1);
+   set_bit(id, guc->doorbell_bitmap);


set_bit is atomic - is 

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Check for invalid cloning earlier during modeset

[Chris Wilson]

On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Move the encoder cloning check to happen earlier in the modeset. The
> main benefit will be that the debug output from a failed modeset will
> be less confusing as output_types can not indicate an invalid
> configuration during the later computation stages.
> 
> For instance, what happened to me was kms_setmode was attempting one
> of its invalid cloning checks during which it asked for DP+VGA cloning
> on HSW. In this case the DP .compute_config() was executed after
> the FDI .compute_config() leaving the DP link clock (1.62 in this case)
> in port_clock, and then later the FDI BW computation tried to use that
> as the FDI link clock (which should always be 2.7). 1.62 x 2 wasn't
> enough for the mode it was trying to use, and so it ended up rejecting
> the modeset, not because of an invalid cloning configuration, but
> because of supposedly running out of FDI bandwidth. Took me a while
> to figure out what had actually happened.

Did it reject the 1.62 link clock when you simply removed the
check_encoder_cloning()? Just checking... :)
-Chris

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

[Intel-gfx] [PATCH 1/2] lib/gt: Omit illegal instruction on hang injection with gen 8+

[Mika Kuoppala]

0x as an illegal command confuses the command execution
on gen9 so that the next BB start will get ignored, causing a runaway
head past the bb end. This delays the hang detection substantially
as hangcheck then observes only a non progressing seqno.

Omit the bad instruction on gen8+ and rely on the chained batch
loop to cause a deterministic hang. Make the chained bb start
to jump straight into bb start, omitting the MI_NOOP or the bad
instruction on subsequent passes. This makes the acthd sampling
to hit more reliably to the same value, as the loop is smaller,
making the head appear to be 'more stuck'.

References: https://bugs.freedesktop.org/show_bug.cgi?id=92715
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 lib/igt_gt.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 95d74a0cfeae..adb4b95bb913 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -181,16 +181,22 @@ igt_hang_ring_t igt_hang_ctx(int fd,
exec.relocs_ptr = (uintptr_t)
 
memset(b, 0xc5, sizeof(b));
-   b[0] = 0x;
+
len = 2;
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+   if (intel_gen(intel_get_drm_devid(fd)) >= 8) {
+   b[0] = MI_NOOP;
len++;
+   } else {
+   b[0] = 0x;
+   }
+
b[1] = MI_BATCH_BUFFER_START | (len - 2);
b[1+len] = MI_BATCH_BUFFER_END;
b[2+len] = MI_NOOP;
gem_write(fd, exec.handle, 0, b, sizeof(b));
 
reloc.offset = 8;
+   reloc.delta = 4;
reloc.target_handle = exec.handle;
reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
 
-- 
2.7.4

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

[Intel-gfx] ✓ Ro.CI.BAT: success for Support for creating/using Stolen memory backed objects (rev17)

[Patchwork]

== Series Details ==

Series: Support for creating/using Stolen memory backed objects (rev17)
URL   : https://patchwork.freedesktop.org/series/659/
State : success

== Summary ==

Series 659v17 Support for creating/using Stolen memory backed objects
http://patchwork.freedesktop.org/api/1.0/series/659/revisions/17/mbox


fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bdw-i7-5600u  total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:168  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:183  pass:161  dwarn:0   dfail:0   fail:0   skip:21 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-ivb2-i7-3770  total:183  pass:158  dwarn:0   dfail:0   fail:0   skip:24 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1139/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
5999129 drm/i915: Extend GET_APERTURE ioctl to report available map space
bbb5d49 drm/i915: Disable use of stolen area by User when Intel RST is present
2710e78 drm/i915: Migrate stolen objects before hibernation
834ac5c drm/i915: Support for pread/pwrite from/to non shmem backed objects
64de0a8 drm/i915: Add support for stealing purgable stolen pages
37f82e6 drm/i915: Propagating correct error codes to the userspace
0679368 drm/i915: Support for creating Stolen memory backed objects
6f1b112 drm/i915: Clearing buffer objects via CPU/GTT
ee9efab drm/i915: Use insert_page for pwrite_fast
b8a794a drm/i915: Introduce i915_gem_object_get_dma_address()
a424081 drm/i915: Add support for mapping an object page by page

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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Ville Syrjälä]

On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
> to 10s.

Does it still find the problem reliably on CHV pipe C (if you remove the
kernel w/a)?

> 
> Cc: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
>  tests/kms_chv_cursor_fail.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/kms_chv_cursor_fail.c b/tests/kms_chv_cursor_fail.c
> index 11d01f54e511..8f878cbffe96 100644
> --- a/tests/kms_chv_cursor_fail.c
> +++ b/tests/kms_chv_cursor_fail.c
> @@ -109,24 +109,26 @@ static void cursor_move(data_t *data, int x, int y, int 
> i)
>  }
>  
>  #define XSTEP 8
> -#define YSTEP 32
> -#define XOFF 0
> +#define YSTEP 8
>  #define NCRC 128
>  
>  static void test_edge_pos(data_t *data, int sx, int ex, int y, bool 
> swap_axis)
>  {
>   igt_crc_t *crc = NULL;
> - int i, n, x, xdir;
> + int i, n, x, xdir, dx;
>  
>   if (sx > ex)
>   xdir = -1;
>   else
>   xdir = 1;
>  
> + dx = (ex - sx)/XSTEP;
> +
>   igt_pipe_crc_start(data->pipe_crc);
>  
>   i = 0;
> - for (x = sx + XOFF; xdir * (x - ex - XOFF) <= 0; x += xdir * XSTEP) {
> +
> + for (x = sx; xdir * (x - ex) <= 0; x += dx) {
>   int xx, yy;
>  
>   if (swap_axis) {
> @@ -168,21 +170,23 @@ static void test_edge_pos(data_t *data, int sx, int ex, 
> int y, bool swap_axis)
>  static void test_edge(data_t *data, int sy, int ey, int sx, int ex, bool 
> swap_axis)
>  {
>   int crtc_id = data->output->config.crtc->crtc_id;
> - int y, ydir;
> + int y, ydir, dy;
>  
>   if (sy > ey)
>   ydir = -1;
>   else
>   ydir = 1;
>  
> + dy = (ey - sy) / YSTEP;
> +
>   igt_assert_eq(drmModeMoveCursor(data->drm_fd, crtc_id, -data->curw, 
> -data->curh), 0);
>   igt_assert_eq(drmModeSetCursor(data->drm_fd, crtc_id, 
> data->fb.gem_handle, data->curw, data->curh), 0);
>  
>   for (y = sy; ydir * (y - ey) <= 0; ) {
>   test_edge_pos(data, sx, ex, y, swap_axis);
> - y += ydir * YSTEP;
> + y += dy;
>   test_edge_pos(data, ex, sx, y, swap_axis);
> - y += ydir * YSTEP;
> + y += dy;
>   }
>  
>   igt_assert_eq(drmModeMoveCursor(data->drm_fd, crtc_id, -data->curw, 
> -data->curh), 0);
> -- 
> 2.5.5

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

[Intel-gfx] [PATCH 2/2] igt/gem_reset_stats: Add time constraints on hang detection

[Mika Kuoppala]

Make sure that injected hang is detected below time threshold.
This ensures that we fail if hang was of no-progress type instead
of a stuck engine.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 tests/gem_reset_stats.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 27bc6c9cfb59..74c102d3fd7d 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -148,6 +148,23 @@ static int gem_reset_status(int fd, int ctx_id)
return RS_NO_ERROR;
 }
 
+static struct timespec ts_injected;
+
+static double elapsed(const struct timespec *start, const struct timespec *end)
+{
+   return ((end->tv_sec - start->tv_sec) +
+   (end->tv_nsec - start->tv_nsec)*1e-9);
+}
+
+static double elapsed_from_hang_injection(void)
+{
+   struct timespec now;
+
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   return elapsed(_injected, );
+}
+
 #define BAN HANG_ALLOW_BAN
 #define ASYNC 2
 static void inject_hang(int fd, uint32_t ctx,
@@ -156,6 +173,8 @@ static void inject_hang(int fd, uint32_t ctx,
 {
igt_hang_ring_t hang;
 
+   clock_gettime(CLOCK_MONOTONIC, _injected);
+
hang = igt_hang_ctx(fd, ctx, e->exec_id | e->flags, flags & BAN, NULL);
if ((flags & ASYNC) == 0)
igt_post_hang_ring(fd, hang);
@@ -238,6 +257,8 @@ static void test_rs(const struct intel_execution_engine *e,
assert_reset_status(i, fd[i], 0, RS_BATCH_PENDING);
}
 
+   igt_assert(elapsed_from_hang_injection() < 31.0);
+
for (i = 0; i < num_fds; i++)
close(fd[i]);
 }
@@ -290,6 +311,8 @@ static void test_rs_ctx(const struct intel_execution_engine 
*e,
}
sync_gpu();
 
+   igt_assert(elapsed_from_hang_injection() < 31.0);
+
for (i = 0; i < num_fds; i++)
assert_reset_status(i, fd[i], 0, RS_NO_ERROR);
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 08/12] drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/

[Kahola, Mika]

I'll second this idea.

With small typo fixed on commit message this is
Reviewed-by: Mika Kahola 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, June 8, 2016 1:42 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/12] drm/i915:
> s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/
> 
> From: Ville Syrjälä 
> 
> INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always
> looks out of place besides INTEL_OUTPUT_EDP and
> INTEL_OUTPUT_DP_MST.
> Let's just rename it to INTEL_OUTPUT_DP.
> 
> v2: Rebase
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |  8 
>  drivers/gpu/drm/i915/intel_ddi.c  | 16 
>  drivers/gpu/drm/i915/intel_display.c  | 10 +-
>  drivers/gpu/drm/i915/intel_dp.c   | 10 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  6 +++---
>  drivers/gpu/drm/i915/intel_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_opregion.c |  2 +-
>  7 files changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e4f2c55d9697..cb69e4b361b5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2986,7 +2986,7 @@ static void intel_connector_info(struct seq_file *m,
>  connector->display_info.cea_rev);
>   }
>   if (intel_encoder) {
> - if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
> + if (intel_encoder->type == INTEL_OUTPUT_DP ||
>   intel_encoder->type == INTEL_OUTPUT_EDP)
>   intel_dp_info(m, intel_connector);
>   else if (intel_encoder->type == INTEL_OUTPUT_HDMI) @@ -
> 3387,7 +3387,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
>   case INTEL_OUTPUT_HDMI:
>   seq_puts(m, "HDMI:\n");
>   break;
> - case INTEL_OUTPUT_DISPLAYPORT:
> + case INTEL_OUTPUT_DP:
>   seq_puts(m, "DP:\n");
>   break;
>   default:
> @@ -3492,7 +3492,7 @@ static int i915_dp_mst_info(struct seq_file *m, void
> *unused)
>   drm_modeset_lock_all(dev);
>   list_for_each_entry(encoder, >mode_config.encoder_list,
> head) {
>   intel_encoder = to_intel_encoder(encoder);
> - if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
> + if (intel_encoder->type != INTEL_OUTPUT_DP)
>   continue;
>   intel_dig_port = enc_to_dig_port(encoder);
>   if (!intel_dig_port->dp.can_mst)
> @@ -3754,7 +3754,7 @@ static int i9xx_pipe_crc_auto_source(struct
> drm_device *dev, enum pipe pipe,
>   case INTEL_OUTPUT_TVOUT:
>   *source = INTEL_PIPE_CRC_SOURCE_TV;
>   break;
> - case INTEL_OUTPUT_DISPLAYPORT:
> + case INTEL_OUTPUT_DP:
>   case INTEL_OUTPUT_EDP:
>   dig_port = enc_to_dig_port(>base);
>   switch (dig_port->port) {
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b7285336fb53..4f7fc0ed8796 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -318,7 +318,7 @@ static void ddi_get_encoder_port(struct
> intel_encoder *intel_encoder,
>   default:
>   WARN(1, "Invalid DDI encoder type %d\n", intel_encoder-
> >type);
>   /* fallthrough and treat as unknown */
> - case INTEL_OUTPUT_DISPLAYPORT:
> + case INTEL_OUTPUT_DP:
>   case INTEL_OUTPUT_EDP:
>   case INTEL_OUTPUT_HDMI:
>   case INTEL_OUTPUT_UNKNOWN:
> @@ -482,7 +482,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder
> *encoder)
>   ddi_translations = ddi_translations_edp;
>   size = n_edp_entries;
>   break;
> - case INTEL_OUTPUT_DISPLAYPORT:
> + case INTEL_OUTPUT_DP:
>   case INTEL_OUTPUT_HDMI:
>   ddi_translations = ddi_translations_dp;
>   size = n_dp_entries;
> @@ -1068,7 +1068,7 @@ void intel_ddi_set_pipe_settings(struct drm_crtc
> *crtc)
>   int type = intel_encoder->type;
>   uint32_t temp;
> 
> - if (type == INTEL_OUTPUT_DISPLAYPORT || type ==
> INTEL_OUTPUT_EDP || type == INTEL_OUTPUT_DP_MST) {
> + if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP ||
> type ==
> +INTEL_OUTPUT_DP_MST) {
>   WARN_ON(transcoder_is_dsi(cpu_transcoder));
> 
>   temp = TRANS_MSA_SYNC_CLK;
> @@ -1182,7 +1182,7 @@ void intel_ddi_enable_transcoder_func(struct
> drm_crtc *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 

Re: [Intel-gfx] 4.7-rc0: redshift stopped working on intel display

[Pavel Machek]

Hi!

> Could you try to apply the following patch [1], hopefully this fixes
> the issue for you.
> 
> [1] https://patchwork.freedesktop.org/patch/89111/

I updated the kernel, applied the patch  and yes, that helped.

Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/38] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:43:57AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote:
> > Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for
> > i915_gem_object_ggtt_pin(), spare us the confustion and remove it.
> > Removing it now simplifies later patches to change the i915_vma_pin()
> > (and friends) interface.
> > 
> > Signed-off-by: Chris Wilson 
> 
> Diff looks like accidentally squashed in speed-up to help gcc along with
> bitfields in vma. Needs to be unsquashed.

That change was made a few months ago, at least outside of reflog's
history. I guess I got fed up of having a few patches doing very small
overlapping tasks of changing the function prototypes.
-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 19/21] drm/i915: Move the get/put irq locking into the caller

[Chris Wilson]

On Wed, Jun 08, 2016 at 12:49:14PM +0100, Tvrtko Ursulin wrote:
> 
> On 08/06/16 12:10, Chris Wilson wrote:
> >On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/06/16 11:01, Chris Wilson wrote:
> >>>On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/06/16 17:08, Chris Wilson wrote:
> >With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
> >we can reduce the code size by moving the common preamble into the
> >caller, and we can also eliminate the reference counting.
> >
> >For completeness, as we are no longer doing reference counting on irq,
> >rename the get/put vfunctions to enable/disable respectively.
> >
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_irq.c  |   8 +-
> >  drivers/gpu/drm/i915/intel_breadcrumbs.c |  10 +-
> >  drivers/gpu/drm/i915/intel_lrc.c |  34 +---
> >  drivers/gpu/drm/i915/intel_ringbuffer.c  | 269 
> > ++-
> >  drivers/gpu/drm/i915/intel_ringbuffer.h  |   5 +-
> >  5 files changed, 108 insertions(+), 218 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 14b3d65bb604..5bdb433dde8c 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -259,12 +259,12 @@ static void ilk_update_gt_irq(struct 
> >drm_i915_private *dev_priv,
> > dev_priv->gt_irq_mask &= ~interrupt_mask;
> > dev_priv->gt_irq_mask |= (~enabled_irq_mask & interrupt_mask);
> > I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
> >-POSTING_READ(GTIMR);
> >  }
> >
> >  void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t 
> > mask)
> >  {
> > ilk_update_gt_irq(dev_priv, mask, mask);
> >+POSTING_READ_FW(GTIMR);
> >  }
> 
> Unrelated hunks?
> 
> How is POSTING_READ_FW correct?
> >>>
> >>>The requirement here is an uncached read of the mmio register in order
> >>>to flush the previous write to hw. A grander scheme would be to convert
> >>>all posting reads, but that requires double checking to see if anyone
> >>>has been cheating!
> >>
> >>So what prevents to force-wake for getting released between the
> >>I915_WRITE and POSTING_READ_FW ?
> >
> >Nothing. The point is that the FW is not required for the correctness or
> >operation of the POSTING_READ as a barrier to hardware enabling the
> >interrupt.
> 
> So sleeping hardware is OK with being read from? It won't hang or
> anything, just provide bad data?

Just garbage.
 
> Why not change POSTING_READ to be I915_READ_FW always then?

First plan was to purge all the posting-reads. That proves some are
required. So now, if it appears in a profile, it is asked to justify its
existence.
-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 11/11] drm/i915: Extend GET_APERTURE ioctl to report available map space

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.

This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.

This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the cumulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.

This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region as
well as single largest block available in the stolen region too.

The patch also adds a debugfs file for convenient testing and
reporting.

v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.

v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.

v4: (Rodrigo) Fixed rebase conflicts.

v5: Rebased to the latest drm-intel-nightly (Ankit)

v6: Keeping limits to get_aperture ioctl, and moved changing numbers to
debugfs, Addressed comments (Chris/Tvrtko)

v7: Squashed stolen memory size patch to this one, Added a new version
field to validate the map_size and stolen size values, Changed Author
to me (Ankit) due to significant changes in the logic used to get size
values

Signed-off-by: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 143 +
 drivers/gpu/drm/i915/i915_drv.h|   3 +
 drivers/gpu/drm/i915/i915_gem.c|   4 +
 drivers/gpu/drm/i915/i915_gem_stolen.c |  27 +++
 include/uapi/drm/i915_drm.h|  17 
 5 files changed, 194 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e5b4274..c052174 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -586,6 +586,148 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)
return 0;
 }
 
+static int vma_rank_by_ggtt(void *priv,
+   struct list_head *A,
+   struct list_head *B)
+{
+   struct i915_vma *a = list_entry(A, typeof(*a), exec_list);
+   struct i915_vma *b = list_entry(B, typeof(*b), exec_list);
+
+   return a->node.start - b->node.start;
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start, u32 end)
+{
+   u32 size = end - start;
+   u32 fence_size;
+
+   if (INTEL_INFO(dev_priv)->gen < 4) {
+   u32 fence_max;
+   u32 fence_next;
+
+   if (IS_GEN3(dev_priv)) {
+   fence_max = I830_FENCE_MAX_SIZE_VAL << 20;
+   fence_next = 1024*1024;
+   } else {
+   fence_max = I830_FENCE_MAX_SIZE_VAL << 19;
+   fence_next = 512*1024;
+   }
+
+   fence_max = min(fence_max, size);
+   fence_size = 0;
+   /* Find fence_size less than fence_max and power of 2 */
+   while (fence_next <= fence_max) {
+   u32 base = ALIGN(start, fence_next);
+   if (base + fence_next > end)
+   break;
+
+   fence_size = fence_next;
+   fence_next <<= 1;
+   }
+   } else {
+   fence_size = size;
+   }
+
+   return fence_size;
+}
+
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_i915_gem_get_aperture arg;
+   struct i915_vma *vma;
+   struct list_head map_list;
+   const uint64_t map_limit = ggtt->mappable_end;
+   uint64_t map_space, map_largest, fence_space, fence_largest;
+   uint64_t last, hole_size, stolen_free, stolen_largest;
+   int ret;
+
+   

[Intel-gfx] [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation

[ankitprasad . r . sharma]

From: Chris Wilson 

Ville reminded us that stolen memory is not preserved across
hibernation, and a result of this was that context objects now being
allocated from stolen were being corrupted on S4 and promptly hanging
the GPU on resume.

We want to utilise stolen for as much as possible (nothing else will use
that wasted memory otherwise), so we need a strategy for handling
general objects allocated from stolen and hibernation. A simple solution
is to do a CPU copy through the GTT of the stolen object into a fresh
shmemfs backing store and thenceforth treat it as a normal objects. This
can be refined in future to either use a GPU copy to avoid the slow
uncached reads (though it's hibernation!) and recreate stolen objects
upon resume/first-use. For now, a simple approach should suffice for
testing the object migration.

v2:
Swap PTE for pinned bindings over to the shmemfs. This adds a
complicated dance, but is required as many stolen objects are likely to
be pinned for use by the hardware. Swapping the PTEs should not result
in externally visible behaviour, as each PTE update should be atomic and
the two pages identical. (danvet)

safe-by-default, or the principle of least surprise. We need a new flag
to mark objects that we can wilfully discard and recreate across
hibernation. (danvet)

Just use the global_list rather than invent a new stolen_list. This is
the slowpath hibernate and so adding a new list and the associated
complexity isn't worth it.

v3: Rebased on drm-intel-nightly (Ankit)

v4: Use insert_page to map stolen memory backed pages for migration to
shmem (Chris)

v5: Acquire mutex lock while copying stolen buffer objects to shmem (Chris)

v6: Handled file leak, Splitted object migration function, added kerneldoc
for migrate_stolen_to_shmemfs() function (Tvrtko)
Use i915 wrapper function for drm_mm_insert_node_in_range()

v7: Keep the object in cpu domain after get_pages, remove the object from
the unbound list only when marked PURGED, Corrected split of object migration
function (Chris)

v8: Split i915_gem_freeze(), removed redundant use of barrier, corrected
use of set_to_cpu_domain() (Chris)

v9: Replaced WARN_ON by BUG_ON and added a comment explaining it
(Daniel/Tvrtko)

v10: Document use of barriers (Chris)

v11: Resolved list corruption due to not removing obj from global_list
if no reference to pages is held, Rebased (Ankit)

v12: Rebase (Ankit)

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.c |  22 +++-
 drivers/gpu/drm/i915/i915_drv.h |  10 ++
 drivers/gpu/drm/i915/i915_gem.c | 204 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  49 
 drivers/gpu/drm/i915/intel_display.c|   3 +
 drivers/gpu/drm/i915/intel_fbdev.c  |   6 +
 drivers/gpu/drm/i915/intel_pm.c |   2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   6 +
 8 files changed, 284 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 872c6060..dc9e06d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1058,6 +1058,22 @@ static int i915_pm_suspend(struct device *dev)
return i915_drm_suspend(drm_dev);
 }
 
+/* freeze: before creating the hibernation_image */
+static int i915_pm_freeze(struct device *dev)
+{
+   int ret;
+
+   ret = i915_gem_freeze(pci_get_drvdata(to_pci_dev(dev)));
+   if (ret)
+   return ret;
+
+   ret = i915_pm_suspend(dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
 static int i915_pm_suspend_late(struct device *dev)
 {
struct drm_device *drm_dev = dev_to_i915(dev)->dev;
@@ -1107,12 +1123,6 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
 }
 
-/* freeze: before creating the hibernation_image */
-static int i915_pm_freeze(struct device *dev)
-{
-   return i915_pm_suspend(dev);
-}
-
 static int i915_pm_freeze_late(struct device *dev)
 {
int ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4caff4..81e0551 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2182,6 +2182,12 @@ struct drm_i915_gem_object {
 * Advice: are the backing pages purgeable?
 */
unsigned int madv:2;
+   /**
+* Whereas madv is for userspace, there are certain situations
+* where we want I915_MADV_DONTNEED behaviour on internal objects
+* without conflating the userspace setting.
+*/
+   unsigned int internal_volatile:1;
 
/**
 * Current tiling mode for the object.
@@ -3319,6 +3325,9 @@ int __must_check i915_gem_init_hw(struct drm_device *dev);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void 

[Intel-gfx] [PATCH 10/11] drm/i915: Disable use of stolen area by User when Intel RST is present

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patch
tries to identify presence of the RST device on the ACPI bus, and
disables use of stolen memory (for persistent data) if found.

v2: Updated comment, updated/corrected new functions private to driver
(Chris/Tvrtko)

v3: Disabling stolen by default, wait till required acpi changes to
detect device presence are pulled in (Ankit)

v4: Enabled stolen by default as required acpi changes are merged
(Ankit)

v5: renamed variable, is IS_ENABLED() in place of #ifdef, use char*
instead of structures (Lukas)

Signed-off-by: Ankitprasad Sharma 
Cc: Lukas Wunner 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 11 +++
 drivers/gpu/drm/i915/i915_gem.c|  8 
 drivers/gpu/drm/i915/i915_gem_stolen.c | 12 
 drivers/gpu/drm/i915/intel_acpi.c  |  7 +++
 4 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81e0551..5ac1996 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1340,6 +1340,16 @@ struct i915_gem_mm {
 */
bool busy;
 
+   /**
+* Stolen will be lost upon hibernate (as the memory is unpowered).
+* Across resume, we expect stolen to be intact - however, it may
+* also be utililised by third parties (e.g. Intel RapidStart
+* Technology) and if so we have to assume that any data stored in
+* stolen across resume is lost and we set this flag to indicate that
+* the stolen memory is volatile.
+*/
+   bool volatile_stolen;
+
/* the indicator for dispatch video commands on two BSD rings */
unsigned int bsd_ring_dispatch_index;
 
@@ -3704,6 +3714,7 @@ static inline int intel_opregion_get_panel_type(struct 
drm_i915_private *dev)
 #endif
 
 /* intel_acpi.c */
+bool intel_detect_acpi_rst(void);
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
 extern void intel_unregister_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b5a2604..3b66b68 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -391,8 +391,16 @@ static struct drm_i915_gem_object *
 i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
 {
struct drm_i915_gem_object *obj;
+   struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
+   if (dev_priv->mm.volatile_stolen) {
+   /* Stolen may be overwritten by external parties
+* so unsuitable for persistent user data.
+*/
+   return ERR_PTR(-ENODEV);
+   }
+
mutex_lock(>struct_mutex);
obj = i915_gem_object_create_stolen(dev, size);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 2518ebb..0e6203c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -492,6 +492,18 @@ int i915_gem_init_stolen(struct drm_device *dev)
 */
drm_mm_init(_priv->mm.stolen, 0, ggtt->stolen_usable_size);
 
+   /* If the stolen region can be modified behind our backs upon suspend,
+* then we cannot use it to store nonvolatile contents (i.e user data)
+* as it will be corrupted upon resume.
+*/
+   dev_priv->mm.volatile_stolen = false;
+   if (IS_ENABLED(CONFIG_SUSPEND)) {
+   /* BIOSes using RapidStart Technology have been reported
+* to overwrite stolen across S3, not just S4.
+*/
+   dev_priv->mm.volatile_stolen = intel_detect_acpi_rst();
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..60ccb39 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -23,6 +23,8 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static const char *irst_id = "INT3392";
+
 static char *intel_dsm_port_name(u8 id)
 {
switch (id) {
@@ -162,3 +164,8 @@ void intel_register_dsm_handler(void)
 void intel_unregister_dsm_handler(void)
 {
 }
+
+bool intel_detect_acpi_rst(void)
+{
+   return acpi_dev_found(irst_id);
+}
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

[Tvrtko Ursulin]

On 08/06/16 11:55, Dave Gordon wrote:

Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell management code, this function is somewhat
time-critical, so putting it near its caller may even yield a tiny
performance improvement.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2db1182..7510841 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,61 +185,6 @@ static void guc_init_doorbell(struct intel_guc *guc,
doorbell->cookie = 0;
  }

-static int guc_ring_doorbell(struct i915_guc_client *gc)
-{
-   struct guc_process_desc *desc;
-   union guc_doorbell_qw db_cmp, db_exc, db_ret;
-   union guc_doorbell_qw *db;
-   int attempt = 2, ret = -EAGAIN;
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
-   /* Update the tail so it is visible to GuC */
-   desc->tail = gc->wq_tail;
-
-   /* current cookie */
-   db_cmp.db_status = GUC_DOORBELL_ENABLED;
-   db_cmp.cookie = gc->cookie;
-
-   /* cookie to be updated */
-   db_exc.db_status = GUC_DOORBELL_ENABLED;
-   db_exc.cookie = gc->cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-
-   /* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
-
-   while (attempt--) {
-   /* lets ring the doorbell */
-   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
-   db_cmp.value_qw, db_exc.value_qw);
-
-   /* if the exchange was successfully executed */
-   if (db_ret.value_qw == db_cmp.value_qw) {
-   /* db was successfully rung */
-   gc->cookie = db_exc.cookie;
-   ret = 0;
-   break;
-   }
-
-   /* XXX: doorbell was lost and need to acquire it again */
-   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
-   break;
-
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
-
-   /* update the cookie to newly read cookie from GuC */
-   db_cmp.cookie = db_ret.cookie;
-   db_exc.cookie = db_ret.cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-   }
-
-   return ret;
-}
-
  static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
  {
@@ -543,6 +488,61 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
kunmap_atomic(base);
  }

+static int guc_ring_doorbell(struct i915_guc_client *gc)
+{
+   struct guc_process_desc *desc;
+   union guc_doorbell_qw db_cmp, db_exc, db_ret;
+   union guc_doorbell_qw *db;
+   int attempt = 2, ret = -EAGAIN;
+
+   desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Update the tail so it is visible to GuC */
+   desc->tail = gc->wq_tail;
+
+   /* current cookie */
+   db_cmp.db_status = GUC_DOORBELL_ENABLED;
+   db_cmp.cookie = gc->cookie;
+
+   /* cookie to be updated */
+   db_exc.db_status = GUC_DOORBELL_ENABLED;
+   db_exc.cookie = gc->cookie + 1;
+   if (db_exc.cookie == 0)
+   db_exc.cookie = 1;
+
+   /* pointer of current doorbell cacheline */
+   db = gc->client_base + gc->doorbell_offset;
+
+   while (attempt--) {
+   /* lets ring the doorbell */
+   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
+   db_cmp.value_qw, db_exc.value_qw);
+
+   /* if the exchange was successfully executed */
+   if (db_ret.value_qw == db_cmp.value_qw) {
+   /* db was successfully rung */
+   gc->cookie = db_exc.cookie;
+   ret = 0;
+   break;
+   }
+
+   /* XXX: doorbell was lost and need to acquire it again */
+   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
+   break;
+
+   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
+ db_cmp.cookie, db_ret.cookie);
+
+   /* update the cookie to newly read cookie from GuC */
+   db_cmp.cookie = db_ret.cookie;
+   db_exc.cookie = db_ret.cookie + 1;
+   if (db_exc.cookie == 0)
+   

[Intel-gfx] [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.

v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)

v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)

v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.

v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
updated barrier positioning (Chris)

v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
(Tvrtko)

v7: Fixed the onion (undo operation in reverse order) (Chris)

v8: Rebase (Ankit)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 45 +
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8228e8a..96eea3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3100,6 +3100,7 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
int *needs_clflush);
 
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 452178c..d658d46 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5418,3 +5418,48 @@ fail:
drm_gem_object_unreference(>base);
return ERR_PTR(ret);
 }
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct i915_ggtt *ggtt = >ggtt;
+   struct drm_mm_node node;
+   char __iomem *base;
+   uint64_t size = obj->base.size;
+   int ret, i;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+   ret = insert_mappable_node(i915, , PAGE_SIZE);
+   if (ret)
+   return ret;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   goto err_remove_node;
+
+   i915_gem_object_pin_pages(obj);
+   base = io_mapping_map_wc(ggtt->mappable, node.start, PAGE_SIZE);
+
+   for (i = 0; i < size/PAGE_SIZE; i++) {
+   ggtt->base.insert_page(>base,
+  i915_gem_object_get_dma_address(obj, i),
+  node.start, I915_CACHE_NONE, 0);
+   wmb(); /* flush modifications to the GGTT (insert_page) */
+   memset_io(base, 0, PAGE_SIZE);
+   wmb(); /* flush the write before we modify the GGTT */
+   }
+
+   io_mapping_unmap(base);
+   ggtt->base.clear_range(>base, node.start, node.size, true);
+   i915_gem_object_unpin_pages(obj);
+
+err_remove_node:
+   remove_mappable_node();
+   return ret;
+}
-- 
1.9.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: Support for pread/pwrite from/to non shmem backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.

v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)

v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)

v6: Using pwrite_fast for non-shmem backed objects as well (Chris)

v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)

v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)

v9: Corrected check during pread_ioctl, to avoid shmem_pread being
called for non-shmem backed objects (Tvrtko)

v10: Moved the write_domain check to needs_clflush and tiling mode check
to pwrite_fast (Chris)

v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
call fast_user_write regardless of pagefault in previous iteration

v12: Use page-by-page copy for slow user access too (Chris)

v13: Handled EFAULT, Avoid use of WARN_ON, put_fence only if whole obj
pinned (Chris)

v14: Corrected datatypes/initializations (Tvrtko)

Testcase: igt/gem_stolen, igt/gem_pread, igt/gem_pwrite

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 218 ++--
 1 file changed, 188 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 58c83d8..30069c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -54,6 +54,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
 
 static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 {
+   if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+   return false;
+
if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
return true;
 
@@ -644,6 +647,142 @@ shmem_pread_slow(struct page *page, int 
shmem_page_offset, int page_length,
return ret ? - EFAULT : 0;
 }
 
+static inline unsigned long
+slow_user_access(struct io_mapping *mapping,
+uint64_t page_base, int page_offset,
+char __user *user_data,
+unsigned long length, bool pwrite)
+{
+   void __iomem *ioaddr;
+   void *vaddr;
+   uint64_t unwritten;
+
+   ioaddr = io_mapping_map_wc(mapping, page_base, PAGE_SIZE);
+   /* We can use the cpu mem copy function because this is X86. */
+   vaddr = (void __force *)ioaddr + page_offset;
+   if (pwrite)
+   unwritten = __copy_from_user(vaddr, user_data, length);
+   else
+   unwritten = __copy_to_user(user_data, vaddr, length);
+
+   io_mapping_unmap(ioaddr);
+   return unwritten;
+}
+
+static int
+i915_gem_gtt_pread(struct drm_device *dev,
+  struct drm_i915_gem_object *obj, uint64_t size,
+  uint64_t data_offset, uint64_t data_ptr)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct drm_mm_node node;
+   char __user *user_data;
+   uint64_t remain;
+   uint64_t offset;
+   int ret;
+
+   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   if (ret) {
+   ret = insert_mappable_node(dev_priv, , PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node();
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   ret = i915_gem_object_put_fence(obj);
+   if (ret)
+   goto out_unpin;
+   }
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, false);
+   if (ret)
+   goto out_unpin;
+
+   user_data = u64_to_user_ptr(data_ptr);
+   remain = size;
+   offset = data_offset;
+
+   mutex_unlock(>struct_mutex);
+   if (likely(!i915.prefault_disable)) {
+   ret = fault_in_multipages_writeable(user_data, remain);
+   if (ret) {
+   mutex_lock(>struct_mutex);
+   goto out_unpin;
+   }
+   }
+
+   while (remain > 0) {
+   /* Operation in 

[Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, which if set, an attempt will be made to allocate
the object from stolen memory subject to the availability of
free space in the stolen region.

v2: Rebased to the latest drm-intel-nightly (Ankit)

v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)

v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
Corrected function arguments ordering (Chris)

v5: Corrected function name (Chris)

v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
aligned (Chris)

v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
function for object allocation from stolen region (Ankit)

v8: Added comment explaining STOLEN placement flag (Chris)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_dma.c|  3 +++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 49 ++
 drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +--
 include/uapi/drm/i915_drm.h| 41 
 5 files changed, 91 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 07edaed..83ae436 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -231,6 +231,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_SOFTPIN:
value = 1;
break;
+   case I915_PARAM_CREATE_VERSION:
+   value = 2;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 96eea3d..c92cb60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3523,7 +3523,7 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*dev_priv,
 int i915_gem_init_stolen(struct drm_device *dev);
 void i915_gem_cleanup_stolen(struct drm_device *dev);
 struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size);
 struct drm_i915_gem_object *
 i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
   u32 stolen_offset,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d658d46..28c7e28 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -384,10 +384,36 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
kmem_cache_free(dev_priv->objects, obj);
 }
 
+static struct drm_i915_gem_object *
+i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
+{
+   struct drm_i915_gem_object *obj;
+   int ret;
+
+   mutex_lock(>struct_mutex);
+   obj = i915_gem_object_create_stolen(dev, size);
+   if (!obj) {
+   mutex_unlock(>struct_mutex);
+   return NULL;
+   }
+
+   /* Always clear fresh buffers before handing to userspace */
+   ret = i915_gem_object_clear(obj);
+   if (ret) {
+   drm_gem_object_unreference(>base);
+   mutex_unlock(>struct_mutex);
+   return NULL;
+   }
+
+   mutex_unlock(>struct_mutex);
+   return obj;
+}
+
 static int
 i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
+   uint64_t flags,
uint32_t *handle_p)
 {
struct drm_i915_gem_object *obj;
@@ -398,10 +424,23 @@ i915_gem_create(struct drm_file *file,
if (size == 0)
return -EINVAL;
 
+   if (flags & __I915_CREATE_UNKNOWN_FLAGS)
+   return -EINVAL;
+
/* Allocate the new object */
-   obj = i915_gem_object_create(dev, size);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   switch (flags & I915_CREATE_PLACEMENT_MASK) {
+   case I915_CREATE_PLACEMENT_NORMAL:
+   obj = i915_gem_object_create(dev, size);
+   break;
+   case I915_CREATE_PLACEMENT_STOLEN:
+   obj = i915_gem_alloc_object_stolen(dev, size);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   if (IS_ERR_OR_NULL(obj))
+   return -ENOMEM;
 
ret = drm_gem_handle_create(file, >base, );
/* drop reference from allocate - handle holds it now */
@@ -422,7 +461,7 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = 

[Intel-gfx] [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
allocation. This patch helps user to identify the correct reason for the
failure and not just -ENOMEM each time.

v2: Moved the patch up in the series, added error propagation for
i915_gem_alloc_object too (Chris)

v3: Removed storing of error pointer inside structs, Corrected error
propagation in caller functions (Chris)

v4: Remove assignments inside the predicate (Chris)

v5: Removed unnecessary initializations, updated kerneldoc for
i915_guc_client, corrected missed error pointer handling (Tvrtko)

v6: Use ERR_CAST/temporary variable to avoid storing invalid pointer
in a common field (Chris)

v7: Resolved rebasing conflicts (Ankit)

v8: Removed redundant code (Chris)

v9: Rebase

v10: Rebase, resolve merge conflicts

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c  | 15 
 drivers/gpu/drm/i915/i915_gem_render_state.c |  7 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c   | 53 +++-
 drivers/gpu/drm/i915/i915_guc_submission.c   | 50 --
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c |  3 +-
 drivers/gpu/drm/i915/intel_pm.c  |  7 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  4 +--
 9 files changed, 83 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28c7e28..22e39b1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -392,19 +392,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev, 
size_t size)
 
mutex_lock(>struct_mutex);
obj = i915_gem_object_create_stolen(dev, size);
-   if (!obj) {
-   mutex_unlock(>struct_mutex);
-   return NULL;
-   }
+   if (IS_ERR(obj))
+   goto out;
 
/* Always clear fresh buffers before handing to userspace */
ret = i915_gem_object_clear(obj);
if (ret) {
drm_gem_object_unreference(>base);
-   mutex_unlock(>struct_mutex);
-   return NULL;
+   obj = ERR_PTR(ret);
+   goto out;
}
 
+out:
mutex_unlock(>struct_mutex);
return obj;
 }
@@ -439,8 +438,8 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
}
 
-   if (IS_ERR_OR_NULL(obj))
-   return -ENOMEM;
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
 
ret = drm_gem_handle_create(file, >base, );
/* drop reference from allocate - handle holds it now */
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 7c93327..84d91c9 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -59,8 +59,11 @@ static int render_state_init(struct render_state *so,
return -EINVAL;
 
so->obj = i915_gem_object_create(dev_priv->dev, 4096);
-   if (IS_ERR(so->obj))
-   return PTR_ERR(so->obj);
+   if (IS_ERR(so->obj)) {
+   ret = PTR_ERR(so->obj);
+   so->obj = NULL;
+   return ret;
+   }
 
ret = i915_gem_obj_ggtt_pin(so->obj, 4096, 0);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 81d5b6b..dcb70c1 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -503,6 +503,7 @@ i915_pages_create_for_stolen(struct drm_device *dev,
struct i915_ggtt *ggtt = _priv->ggtt;
struct sg_table *st;
struct scatterlist *sg;
+   int ret;
 
DRM_DEBUG_DRIVER("offset=0x%x, size=%d\n", offset, size);
BUG_ON(offset > ggtt->stolen_size - size);
@@ -514,11 +515,12 @@ i915_pages_create_for_stolen(struct drm_device *dev,
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
-   if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+   ret = sg_alloc_table(st, 1, GFP_KERNEL);
+   if (ret) {
kfree(st);
-   return NULL;
+   return ERR_PTR(ret);
}
 
sg = st->sgl;
@@ -567,18 +569,23 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
   struct drm_mm_node *stolen)
 {
struct drm_i915_gem_object *obj;
+   struct sg_table *pages;
 
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
-   return NULL;
+   

[Intel-gfx] [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address()

[ankitprasad . r . sharma]

From: Chris Wilson 

This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index adc5e7d..8228e8a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3109,6 +3109,23 @@ static inline int __sg_page_count(struct scatterlist *sg)
 struct page *
 i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
 
+static inline dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
+{
+   if (n < obj->get_page.last) {
+   obj->get_page.sg = obj->pages->sgl;
+   obj->get_page.last = 0;
+   }
+
+   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
+   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
+   if (unlikely(sg_is_chain(obj->get_page.sg)))
+   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
+   }
+
+   return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << 
PAGE_SHIFT);
+}
+
 static inline struct page *
 i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
 {
-- 
1.9.1

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

[Intel-gfx] [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages

[ankitprasad . r . sharma]

From: Chris Wilson 

If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.

At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.

v2: Remember to remove the drm_mm_node.

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: corrected if-else braces format (Tvrtko/kerneldoc)

v5: Rebased to the latest drm-intel-nightly (Ankit)
Added a seperate list to maintain purgable objects from stolen memory
region (Chris/Daniel)

v6: Compiler optimization (merging 2 single loops into one for() loop),
corrected code for object eviction, retire_requests before starting
object eviction (Chris)

v7: Added kernel doc for i915_gem_object_create_stolen()

v8: Check for struct_mutex lock before creating object from stolen
region (Tvrtko)

v9: Renamed variables to make usage clear, added comment, removed onetime
used macro (Tvrtko)

v10: Avoid masking of error when stolen_alloc fails (Tvrtko)

v11: Renamed stolen_link to tmp_link, as it may be used for other
purposes too (Chris)
Used ERR_CAST to cast error pointers while returning

v12: Added lockdep_assert before starting stolen-backed object
eviction (Chris)

v13: Rebased

Testcase: igt/gem_stolen

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   6 +-
 drivers/gpu/drm/i915/i915_drv.h|  17 +++-
 drivers/gpu/drm/i915/i915_gem.c|  15 +++
 drivers/gpu/drm/i915/i915_gem_stolen.c | 171 +
 drivers/gpu/drm/i915/intel_pm.c|   4 +-
 5 files changed, 188 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..e5b4274 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -182,7 +182,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_puts(m, ")");
}
if (obj->stolen)
-   seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
+   seq_printf(m, " (stolen: %08llx)", obj->stolen->base.start);
if (obj->pin_display || obj->fault_mappable) {
char s[3], *t = s;
if (obj->pin_display)
@@ -254,9 +254,9 @@ static int obj_rank_by_stolen(void *priv,
struct drm_i915_gem_object *b =
container_of(B, struct drm_i915_gem_object, obj_exec_link);
 
-   if (a->stolen->start < b->stolen->start)
+   if (a->stolen->base.start < b->stolen->base.start)
return -1;
-   if (a->stolen->start > b->stolen->start)
+   if (a->stolen->base.start > b->stolen->base.start)
return 1;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c92cb60..a4caff4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,6 +831,12 @@ struct i915_ctx_hang_stats {
bool banned;
 };
 
+struct i915_stolen_node {
+   struct drm_mm_node base;
+   struct list_head mm_link;
+   struct drm_i915_gem_object *obj;
+};
+
 /* This must match up with the value previously used for execbuf2.rsvd1. */
 #define DEFAULT_CONTEXT_HANDLE 0
 
@@ -1281,6 +1287,13 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;
 
+   /**
+* List of stolen objects that have been marked as purgeable and
+* thus available for reaping if we need more space for a new
+* allocation. Ordered by time of marking purgeable.
+*/
+   struct list_head stolen_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */
 
@@ -2134,7 +2147,7 @@ struct drm_i915_gem_object {
struct list_head vma_list;
 
/** Stolen memory for this object, instead of being backed by shmem. */
-   struct drm_mm_node *stolen;
+   struct i915_stolen_node *stolen;
struct list_head global_list;
 
struct list_head engine_list[I915_NUM_ENGINES];
@@ -2142,6 +2155,8 @@ struct drm_i915_gem_object {
struct list_head obj_exec_link;
 
struct list_head batch_pool_link;
+   /** Used to link an object to a list temporarily */
+   struct list_head tmp_link;
 
/**
 * This is set if the object is on the active lists (has pending
diff 

[Intel-gfx] [PATCH v22 00/11] Support for creating/using Stolen memory backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch series adds support for creating/using Stolen memory backed
objects.

Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GPU
and display engine, but in general it goes wasted. Whilst we cannot
return it back to the system, we need to find some other method for
utilising it. As we do not support direct access to the physical address
in the stolen region, it behaves like a different class of memory,
closer in kin to local GPU memory. This strongly suggests that we need a
placement model like TTM if we are to fully utilize these discrete
chunks of differing memory.

To add support for creating Stolen memory backed objects, we extend the
drm_i915_gem_create structure, by adding a new flag through which user
can specify the preference to allocate the object from stolen memory,
which if set, an attempt will be made to allocate the object from stolen
memory subject to the availability of free space in the stolen region.

This patch series adds support for clearing buffer objects via CPU/GTT.
This is particularly useful for clearing out the memory from stolen
region, but can also be used for other shmem allocated objects. Currently
being used for buffers allocated in the stolen region. Also adding support
for stealing purgable stolen pages, if we run out of stolen memory when
trying to allocate an object.

v2: Added support for read/write from/to objects not backed by
shmem using the pread/pwrite interface.
Also extended the current get_aperture ioctl to retrieve the
total and available size of the stolen region.

v3: Removed the extended get_aperture ioctl patch 5 (to be submitted as
part of other patch series), addressed comments by Chris about pread/pwrite
for non shmem backed objects.

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

v5: Addressed comments, replaced patch 1/4 "Clearing buffers via blitter
engine" by "Clearing buffers via CPU/GTT".

v6: Rebased to the latest drm-intel-nightly, Addressed comments, updated
stolen memory purging logic by maintaining a list for purgable stolen
memory objects, enabled pread/pwrite for all non-shmem backed objects
without tiling restrictions.

v7: Addressed comments, compiler optimization, new patch added for correct
error code propagation to the userspace.

v8: Added a new patch to the series to Migrate stolen objects before
hibernation, as stolen memory is not preserved across hibernation. Added
correct error propagation for shmem as well non-shmem backed object allocation.

v9: Addressed comments, use of insert_page helper function to map object page
by page which can be helpful in low aperture space availability.

v10: Addressed comments, use insert_page for clearing out the stolen memory

v11: Addressed comments, 3 new patches added to support allocation from Stolen
memory
1. Allow use of i915_gem_object_get_dma_address for stolen backed objects
2. Use insert_page for pwrite_fast
3. Fail the execbuff using stolen objects as batchbuffers

v12: Addressed comments, Removed patch "Fail the execbuff using stolen objects
as batchbuffers"

v13: Addressed comments, Added 2 patches to detect Intel RST and disable stolen
for persistent data if RST device found
1. acpi: Export acpi_bus_type
2. drm/i915: Disable use of stolen area by User when Intel RST is present

v14: Addressed comments, Added 2 base patches to the series
1. drm/i915: Add support for mapping an object page by page
2. drm/i915: Introduce i915_gem_object_get_dma_address()

v15: Addressed comments, Disabled stolen memory by default

v16: Addressed comments, Added low level rpm assertions, Enabled stolen
memory

v17: Addressed comments

v18: Rebased and fixed issue

v19: Rebased and added 2 more patches to report mappable and stolen size
numbers
1. drm/i915: Extend GET_APERTURE ioctl to report available map space
2. drm/i915: Extend GET_APERTURE ioctl to report size of the stolen region

v20: Rebased and squashed last 2 patches into one.

v21: Rebased and resolved conflicts.

v22: Rebased again.

This can be verified using IGT tests:
igt/gem_stolen, igt/gem_create, igt/gem_pread, igt/gem_pwrite

Ankitprasad Sharma (7):
  drm/i915: Use insert_page for pwrite_fast
  drm/i915: Clearing buffer objects via CPU/GTT
  drm/i915: Support for creating Stolen memory backed objects
  drm/i915: Propagating correct error codes to the userspace
  drm/i915: Support for pread/pwrite from/to non shmem backed objects
  drm/i915: Disable use of stolen area by User when Intel RST is present
  drm/i915: Extend GET_APERTURE ioctl to report available map space

Chris Wilson (4):
  drm/i915: Add support for mapping an object page by page
  drm/i915: Introduce i915_gem_object_get_dma_address()
  drm/i915: Add support for stealing purgable stolen 

[Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).

v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)

v3: Combined loops based on local patch by Chris (Chris)

v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Renamed wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Added wrapper for drm_mm_remove_node() (Chris)

v6: Added get_pages call before pinning the pages (Tvrtko)
Added remove_mappable_node() wrapper for drm_mm_remove_node() (Chris)

v7: Added size argument for insert_mappable_node (Tvrtko)

v8: Do not put_pages after pwrite, do memset of node in the wrapper
function (insert_mappable_node) (Chris)

v9: Rebase (Ankit)

Signed-off-by: Ankitprasad Sharma 
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 90 +++--
 1 file changed, 68 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eae8d7a..452178c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -60,6 +60,24 @@ static bool cpu_write_needs_clflush(struct 
drm_i915_gem_object *obj)
return obj->pin_display;
 }
 
+static int
+insert_mappable_node(struct drm_i915_private *i915,
+ struct drm_mm_node *node, u32 size)
+{
+   memset(node, 0, sizeof(*node));
+   return drm_mm_insert_node_in_range_generic(>ggtt.base.mm, node,
+  size, 0, 0, 0,
+  i915->ggtt.mappable_end,
+  DRM_MM_SEARCH_DEFAULT,
+  DRM_MM_CREATE_DEFAULT);
+}
+
+static void
+remove_mappable_node(struct drm_mm_node *node)
+{
+   drm_mm_remove_node(node);
+}
+
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
  size_t size)
@@ -765,21 +783,34 @@ fast_user_write(struct io_mapping *mapping,
  * @file: drm file pointer
  */
 static int
-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 struct drm_i915_gem_object *obj,
 struct drm_i915_gem_pwrite *args,
 struct drm_file *file)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
-   ssize_t remain;
-   loff_t offset, page_base;
+   struct i915_ggtt *ggtt = >ggtt;
+   struct drm_mm_node node;
+   uint64_t remain, offset;
char __user *user_data;
-   int page_offset, page_length, ret;
+   int ret;
 
ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
-   if (ret)
-   goto out;
+   if (ret) {
+   ret = insert_mappable_node(i915, , PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node();
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   }
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
if (ret)
@@ -789,26 +820,32 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
 
-   user_data = u64_to_user_ptr(args->data_ptr);
-   remain = args->size;
-
-   offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
-
intel_fb_obj_invalidate(obj, ORIGIN_GTT);
+   obj->dirty = true;
 
-   while (remain > 0) {
+   user_data = u64_to_user_ptr(args->data_ptr);
+   offset = args->offset;
+   remain = args->size;
+   while (remain) {
/* Operation in this page
 *
 * page_base = page offset within aperture
 * page_offset = offset within page
 * page_length = bytes to copy for this page
 */
-   page_base = offset & PAGE_MASK;
-   page_offset = offset_in_page(offset);
-   page_length = remain;
-   if ((page_offset + remain) > PAGE_SIZE)
-   page_length = PAGE_SIZE - page_offset;
-
+   u32 

[Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

[ankitprasad . r . sharma]

From: Chris Wilson 

Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.

v2: Added low level rpm assertions to insert_page routines (Chris)

v3: Added POSTING_READ post register write (Tvrtko)

v4: Rebase (Ankit)

v5: Removed wmb() and FLUSH_CTL from insert_page, caller to take care
of it (Chris)

v6: insert_page not working correctly without FLSH_CNTL write, added the
write again.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/char/agp/intel-gtt.c|  8 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 66 -
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
 include/drm/intel-gtt.h |  3 ++
 4 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index aef87fd..4431129 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -840,6 +840,14 @@ static bool i830_check_flags(unsigned int flags)
return false;
 }
 
+void intel_gtt_insert_page(dma_addr_t addr,
+  unsigned int pg,
+  unsigned int flags)
+{
+   intel_private.driver->write_entry(addr, pg, flags);
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
 void intel_gtt_insert_sg_entries(struct sg_table *st,
 unsigned int pg_start,
 unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..7a139a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2355,6 +2355,28 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t 
pte)
 #endif
 }
 
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen8_pte_t __iomem *pte =
+   (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 uint64_t start,
@@ -2424,6 +2446,28 @@ static void gen8_ggtt_insert_entries__BKL(struct 
i915_address_space *vm,
stop_machine(gen8_ggtt_insert_entries__cb, , NULL);
 }
 
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen6_pte_t __iomem *pte =
+   (gen6_pte_t __iomem *)dev_priv->ggtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   iowrite32(vm->pte_encode(addr, level, true, flags), pte);
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 /*
  * Binds an object into the global gtt with the specified cache level. The 
object
  * will be accessible to the GPU via commands whose operands reference offsets
@@ -2543,6 +2587,24 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
+static void i915_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

[Tvrtko Ursulin]

On 08/06/16 13:34, Chris Wilson wrote:

On Wed, Jun 08, 2016 at 12:47:28PM +0100, Tvrtko Ursulin wrote:


On 08/06/16 12:24, Chris Wilson wrote:

On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:


On 08/06/16 10:48, Chris Wilson wrote:

On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote:

+static int intel_breadcrumbs_signaler(void *arg)
+{
+   struct intel_engine_cs *engine = arg;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   struct signal *signal;
+
+   /* Install ourselves with high priority to reduce signalling latency */
+   signaler_set_rtpriority();
+
+   do {
+   set_current_state(TASK_INTERRUPTIBLE);
+
+   /* We are either woken up by the interrupt bottom-half,
+* or by a client adding a new signaller. In both cases,
+* the GPU seqno may have advanced beyond our oldest signal.
+* If it has, propagate the signal, remove the waiter and
+* check again with the next oldest signal. Otherwise we
+* need to wait for a new interrupt from the GPU or for
+* a new client.
+*/
+   signal = READ_ONCE(b->first_signal);
+   if (signal_complete(signal)) {
+   /* Wake up all other completed waiters and select the
+* next bottom-half for the next user interrupt.
+*/
+   intel_engine_remove_wait(engine, >wait);
+
+   i915_gem_request_unreference(signal->request);
+
+   /* Find the next oldest signal. Note that as we have
+* not been holding the lock, another client may
+* have installed an even older signal than the one
+* we just completed - so double check we are still
+* the oldest before picking the next one.
+*/
+   spin_lock(>lock);
+   if (signal == b->first_signal)
+   b->first_signal = rb_next(>node);
+   rb_erase(>node, >signals);
+   spin_unlock(>lock);
+
+   kfree(signal);
+   } else {
+   if (kthread_should_stop())
+   break;
+
+   schedule();
+   }
+   } while (1);
+
+   return 0;
+}


So the thread is only because it is convenient to plug it in the
breadcrumbs infrastructure. Otherwise the processing above could be
done from a lighter weight context as well since nothing seems to
need the process context.


No, seqno processing requires process/sleepable context. The delays we
incur can be >100us and not suitable for irq/softirq context.


Nothing in this patch needs it - please say in the commit why it is
choosing the process context then.


Bottom half processing requires it. irq_seqno_barrier is not suitable
for irq/softirq context.


Why? Because of a single clflush? How long does that take?


Because both Ironlake and Baytrail require definite delays on the order of
100us. Haswell, Broadwell, Skylake all need an extra delay that we don't
yet have.


Okay, please mention in the commit so the choice is documented.


And why so long delays? It looks pretty lightweight to me.


One alternative could perhaps be to add a waiter->wake_up vfunc and
signalers could then potentially use a tasklet?


Hmm, I did find that in order to reduce execlists latency, I had to
drive the tasklet processing from the signaler.


What do you mean? The existing execlists tasklet? Now would that work?


Due to how dma-fence signals, the softirq is never kicked
(spin_lock_irq doesn't handle local_bh_enable()) and so we would only
submit a new task via execlists on a reschedule. That latency added
about 30% (30s on bsw) to gem_exec_parallel.


I don't follow. User interrupts are separate from context complete
which drives the submission. How do fences interfere with the
latter?


The biggest user benchmark (ala sysmark) regression we have for
execlists is the latency in submitting the first request to hardware via
elsp (or at least the hw responding to and executing that batch,
the per-bb and per-ctx w/a are not free either). If we incur extra
latency in the driver in even adding the request to the queue for an
idle GPU, that is easily felt by userspace.


I still don't see how fences tie into that. But it is not so important 
since it was all along the lines of "do we really need a thread".



+int intel_engine_enable_signaling(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   struct rb_node *parent, **p;
+   struct signal *signal;
+   bool first, wakeup;
+
+   if (unlikely(IS_ERR(b->signaler)))
+   return 

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

[Chris Wilson]

On Wed, Jun 08, 2016 at 12:47:28PM +0100, Tvrtko Ursulin wrote:
> 
> On 08/06/16 12:24, Chris Wilson wrote:
> >On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/06/16 10:48, Chris Wilson wrote:
> >>>On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote:
> >+static int intel_breadcrumbs_signaler(void *arg)
> >+{
> >+struct intel_engine_cs *engine = arg;
> >+struct intel_breadcrumbs *b = >breadcrumbs;
> >+struct signal *signal;
> >+
> >+/* Install ourselves with high priority to reduce signalling 
> >latency */
> >+signaler_set_rtpriority();
> >+
> >+do {
> >+set_current_state(TASK_INTERRUPTIBLE);
> >+
> >+/* We are either woken up by the interrupt bottom-half,
> >+ * or by a client adding a new signaller. In both cases,
> >+ * the GPU seqno may have advanced beyond our oldest 
> >signal.
> >+ * If it has, propagate the signal, remove the waiter 
> >and
> >+ * check again with the next oldest signal. Otherwise we
> >+ * need to wait for a new interrupt from the GPU or for
> >+ * a new client.
> >+ */
> >+signal = READ_ONCE(b->first_signal);
> >+if (signal_complete(signal)) {
> >+/* Wake up all other completed waiters and 
> >select the
> >+ * next bottom-half for the next user interrupt.
> >+ */
> >+intel_engine_remove_wait(engine, >wait);
> >+
> >+i915_gem_request_unreference(signal->request);
> >+
> >+/* Find the next oldest signal. Note that as we 
> >have
> >+ * not been holding the lock, another client may
> >+ * have installed an even older signal than the 
> >one
> >+ * we just completed - so double check we are 
> >still
> >+ * the oldest before picking the next one.
> >+ */
> >+spin_lock(>lock);
> >+if (signal == b->first_signal)
> >+b->first_signal = 
> >rb_next(>node);
> >+rb_erase(>node, >signals);
> >+spin_unlock(>lock);
> >+
> >+kfree(signal);
> >+} else {
> >+if (kthread_should_stop())
> >+break;
> >+
> >+schedule();
> >+}
> >+} while (1);
> >+
> >+return 0;
> >+}
> 
> So the thread is only because it is convenient to plug it in the
> breadcrumbs infrastructure. Otherwise the processing above could be
> done from a lighter weight context as well since nothing seems to
> need the process context.
> >>>
> >>>No, seqno processing requires process/sleepable context. The delays we
> >>>incur can be >100us and not suitable for irq/softirq context.
> >>
> >>Nothing in this patch needs it - please say in the commit why it is
> >>choosing the process context then.
> >
> >Bottom half processing requires it. irq_seqno_barrier is not suitable
> >for irq/softirq context.
> 
> Why? Because of a single clflush? How long does that take?

Because both Ironlake and Baytrail require definite delays on the order of
100us. Haswell, Broadwell, Skylake all need an extra delay that we don't
yet have.
 
> >>And why so long delays? It looks pretty lightweight to me.
> >>
> One alternative could perhaps be to add a waiter->wake_up vfunc and
> signalers could then potentially use a tasklet?
> >>>
> >>>Hmm, I did find that in order to reduce execlists latency, I had to
> >>>drive the tasklet processing from the signaler.
> >>
> >>What do you mean? The existing execlists tasklet? Now would that work?
> >
> >Due to how dma-fence signals, the softirq is never kicked
> >(spin_lock_irq doesn't handle local_bh_enable()) and so we would only
> >submit a new task via execlists on a reschedule. That latency added
> >about 30% (30s on bsw) to gem_exec_parallel.
> 
> I don't follow. User interrupts are separate from context complete
> which drives the submission. How do fences interfere with the
> latter?

The biggest user benchmark (ala sysmark) regression we have for
execlists is the latency in submitting the first request to hardware via
elsp (or at least the hw responding to and executing that batch, 
the per-bb and per-ctx w/a are not free either). If we incur extra
latency in the driver in even adding the request to the queue for an
idle GPU, that is easily felt by 

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

[Tvrtko Ursulin]

On 08/06/16 11:55, Dave Gordon wrote:

To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..fbb4b16 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2560,6 +2560,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct i915_guc_client client = {};
struct intel_engine_cs *engine;
u64 total = 0;
+   int i;

if (!HAS_GUC_SCHED(dev_priv))
return 0;
@@ -2574,6 +2575,14 @@ static int i915_guc_info(struct seq_file *m, void *data)

mutex_unlock(>struct_mutex);

+   seq_printf(m, "Doorbell map:\n");
+   BUILD_BUG_ON(ARRAY_SIZE(guc.doorbell_bitmap) % 4);
+   for (i = 0; i < ARRAY_SIZE(guc.doorbell_bitmap) - 3; i += 4)
+   seq_printf(m, "\t%016lx %016lx %016lx %016lx\n",


Bitmap is unsigned long so 32-bit or 64-bit depending on the kernel 
build. Which makes the format wrong for 32-bit. And the ARRAY_SIZE will 
be different as well. So I think output should be made consistent 
between the two. Probably either pick u32 or u64 and dump it like that.


#define DECLARE_BITMAP(name,bits) \
unsigned long name[BITS_TO_LONGS(bits)]

 DECLARE_BITMAP(doorbell_bitmap, GUC_MAX_DOORBELLS);


+   guc.doorbell_bitmap[i], guc.doorbell_bitmap[i+1],
+   guc.doorbell_bitmap[i+2], guc.doorbell_bitmap[i+3]);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc.db_cacheline);
+
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);



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: Don't unregister fbdev twice

[Daniel Vetter]

On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> superfluous because the framebuffer will subsequently be unregistered by
> drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> The call is a leftover, when it was introduced by commit 362063619cf6
> ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> was still embedded in struct intel_fbdev rather than being a pointer as
> it is today, and drm_framebuffer_remove() wasn't used yet.
> 
> As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> 
> Before:
> [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> 
> After:
> [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
> [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
> [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> 
> Signed-off-by: Lukas Wunner 

Hm yeah. But there's a pile of that particaluar cargo-culting copied all
over the place, would be really good to audit all callers of
unregister_private and fix them all up. A few older drivers still embed
the fbdev fb, but most don't but still use the unregister_private +
cleanup combo.

Nitpick in your subject: s/fbdev/fbdev's fb/

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index ef8e676..4c7ea46 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
>   drm_fb_helper_fini(>helper);
>  
>   if (ifbdev->fb) {
> - drm_framebuffer_unregister_private(>fb->base);
> -
>   mutex_lock(>struct_mutex);
>   intel_unpin_fb_obj(>fb->base, BIT(DRM_ROTATE_0));
>   mutex_unlock(>struct_mutex);
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 01/62] drm/i915: Only start retire worker when idle

[Joonas Lahtinen]

On ke, 2016-06-08 at 12:06 +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 11:53:15AM +0100, Chris Wilson wrote:
> > 
> > On Tue, Jun 07, 2016 at 02:31:07PM +0300, Joonas Lahtinen wrote:
> > > 
> > > On pe, 2016-06-03 at 17:36 +0100, Chris Wilson wrote:
> > > > 
> > > >  i915_gem_idle_work_handler(struct work_struct *work)
> > > >  {
> > > >     struct drm_i915_private *dev_priv =
> > > > -   container_of(work, typeof(*dev_priv), 
> > > > mm.idle_work.work);
> > > > +   container_of(work, typeof(*dev_priv), 
> > > > gt.idle_work.work);
> > > >     struct drm_device *dev = dev_priv->dev;
> > > >     struct intel_engine_cs *engine;
> > > >  
> > > > -   for_each_engine(engine, dev_priv)
> > > > -   if (!list_empty(>request_list))
> > > > -   return;
> > > > +   if (!READ_ONCE(dev_priv->gt.awake))
> > > > +   return;
> > > >  
> > > > -   /* we probably should sync with hangcheck here, using 
> > > > cancel_work_sync.
> > > > -    * Also locking seems to be fubar here, engine->request_list is 
> > > > protected
> > > > -    * by dev->struct_mutex. */
> > > > +   mutex_lock(>struct_mutex);
> > > > +   if (dev_priv->gt.active_engines)
> > > > +   goto out;
> > > >  
> > > > -   intel_mark_idle(dev_priv);
> > > > +   for_each_engine(engine, dev_priv)
> > > > +   i915_gem_batch_pool_fini(>batch_pool);
> > > >  
> > > > -   if (mutex_trylock(>struct_mutex)) {
> > > > -   for_each_engine(engine, dev_priv)
> > > > -   i915_gem_batch_pool_fini(>batch_pool);
> > > > +   GEM_BUG_ON(!dev_priv->gt.awake);
> > > > +   dev_priv->gt.awake = false;
> > > >  
> > > > -   mutex_unlock(>struct_mutex);
> > > > +   if (INTEL_INFO(dev_priv)->gen >= 6)
> > > > +   gen6_rps_idle(dev_priv);
> > > > +   intel_runtime_pm_put(dev_priv);
> > > > +out:
> > > > +   mutex_unlock(>struct_mutex);
> > > > +
> > > > +   if (!dev_priv->gt.awake &&
> > > No READ_ONCE here, even we just unlocked the mutex. So lacks some
> > > consistency.
> > > 
> > > Also, this assumes we might be pre-empted between unlocking mutex and
> > > making this test, so I'm little bit confused. Do you want to optimize
> > > by avoiding calling cancel_delayed_work_sync?
> > General principle to never call work_sync functions with locks held. I
> > had actually thought I had fixed this up (but realized that I just
> > rewrote hangcheck later on instead ;)
> > 
> > Ok, what I think is safer here is
> > 
> > bool hangcheck = cancel_delay_work_sync(hangcheck_work)
> > 
> > mutex_lock()
> > if (actually_idle()) {
> > awake = false;
> > missed_irq_rings |= intel_kick_waiters();
> > }
> > mutex_unlock();
> > 
> > if (awake && hangcheck)
> > queue_hangcheck()
> > 
> > So always kick the hangcheck and reeanble if we tried to idle too early.
> > This will potentially delay hangcheck by one full hangcheck period if we
> > do encounter that race. But we shouldn't be hitting this race that
> > often, or hanging the GPU for that mterr.
> Actual delta:
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 406046f66e36..856da4036fb3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3066,10 +3066,15 @@ i915_gem_idle_work_handler(struct work_struct *work)
> container_of(work, typeof(*dev_priv), gt.idle_work.work);
> struct drm_device *dev = dev_priv->dev;
> struct intel_engine_cs *engine;
> +   unsigned stuck_engines;
> +   bool rearm_hangcheck;
>  
> if (!READ_ONCE(dev_priv->gt.awake))
> return;
>  
> +   rearm_hangcheck =
> +   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> +
> mutex_lock(>struct_mutex);
> if (dev_priv->gt.active_engines)
> goto out;
> @@ -3079,6 +3084,13 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  
> GEM_BUG_ON(!dev_priv->gt.awake);
> dev_priv->gt.awake = false;
> +   rearm_hangcheck = false;
> +
> +   stuck_engines = intel_kick_waiters(dev_priv);
> +   if (unlikely(stuck_engines)) {
> +   DRM_DEBUG_DRIVER("kicked stuck waiters...missed irq\n");
> +   dev_priv->gpu_error.missed_irq_rings |= stuck_engines;
> +   }
>  
> if (INTEL_INFO(dev_priv)->gen >= 6)
> gen6_rps_idle(dev_priv);
> @@ -3086,14 +3098,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  out:
> mutex_unlock(>struct_mutex);
>  
> -   if (!dev_priv->gt.awake &&
> -   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work)) {
> -   unsigned stuck = intel_kick_waiters(dev_priv);
> -   if (unlikely(stuck)) {
> -   DRM_DEBUG_DRIVER("kicked stuck 

Re: [Intel-gfx] [PATCH 12/62] drm/i915: Skip capturing an error state if we already have one

[Chris Wilson]

On Wed, Jun 08, 2016 at 04:44:45PM +0530, Arun Siluvery wrote:
> On 03/06/2016 22:06, Chris Wilson wrote:
> >As we only ever keep the first error state around, we can avoid some
> >work that can be quite intrusive if we don't record the error the second
> >time around. This does move the race whereby the user could discard one
> >error state as the second is being captured, but that race exists in the
> >current code and we hope that recapturing error state is only done for
> >debugging.
> >
> >Note that as we discard the error state for simulated errors, igt that
> >exercise error capture continue to function.
> >
> >Signed-off-by: Chris Wilson 
> >---
> 
> Patch does more than what is described here, all of i915_gem_request
> changes are part of this patch, accidentally squashed may be.

Thanks, I spotted that as I posted it, and was able to recover the 2
patches from reflog.
-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: success for drm/i915: Don't unregister fbdev twice

[Patchwork]

== Series Details ==

Series: drm/i915: Don't unregister fbdev twice
URL   : https://patchwork.freedesktop.org/series/8443/
State : success

== Summary ==

Series 8443v1 drm/i915: Don't unregister fbdev twice
http://patchwork.freedesktop.org/api/1.0/series/8443/revisions/1/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)

fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bdw-i7-5600u  total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:169  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:183  pass:161  dwarn:0   dfail:0   fail:0   skip:21 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1138/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
1be3f6d drm/i915: Don't unregister fbdev twice

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

Re: [Intel-gfx] [PATCH 08/62] drm/i915: Remove stop-rings debugfs interface

[Arun Siluvery]

On 03/06/2016 22:06, Chris Wilson wrote:

Now that we have (near) universal GPU recovery code, we can inject a
real hang from userspace and not need any fakery. Not only does this
mean that the testing is far more realistic, but we can simplify the
kernel in the process.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 35 --
  drivers/gpu/drm/i915/i915_drv.c | 17 ++---
  drivers/gpu/drm/i915/i915_drv.h | 19 --
  drivers/gpu/drm/i915/i915_gem.c | 44 ++---
  drivers/gpu/drm/i915/intel_lrc.c|  3 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c |  8 --
  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
  7 files changed, 15 insertions(+), 112 deletions(-)



looks good to me,
Reviewed-by: Arun Siluvery 

regards
Arun


diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index dd6cf222e8f5..8f576b443ff6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4821,40 +4821,6 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
"%llu\n");

  static int
-i915_ring_stop_get(void *data, u64 *val)
-{
-   struct drm_device *dev = data;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   *val = dev_priv->gpu_error.stop_rings;
-
-   return 0;
-}
-
-static int
-i915_ring_stop_set(void *data, u64 val)
-{
-   struct drm_device *dev = data;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
-
-   DRM_DEBUG_DRIVER("Stopping rings 0x%08llx\n", val);
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   dev_priv->gpu_error.stop_rings = val;
-   mutex_unlock(>struct_mutex);
-
-   return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_ring_stop_fops,
-   i915_ring_stop_get, i915_ring_stop_set,
-   "0x%08llx\n");
-
-static int
  i915_ring_missed_irq_get(void *data, u64 *val)
  {
struct drm_device *dev = data;
@@ -5457,7 +5423,6 @@ static const struct i915_debugfs_files {
{"i915_max_freq", _max_freq_fops},
{"i915_min_freq", _min_freq_fops},
{"i915_cache_sharing", _cache_sharing_fops},
-   {"i915_ring_stop", _ring_stop_fops},
{"i915_ring_missed_irq", _ring_missed_irq_fops},
{"i915_ring_test_irq", _ring_test_irq_fops},
{"i915_gem_drop_caches", _drop_caches_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7ba040141722..f2ac0cae929b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2125,24 +2125,11 @@ int i915_reset(struct drm_i915_private *dev_priv)
goto error;
}

+   pr_notice("drm/i915: Resetting chip after gpu hang\n");
+
i915_gem_reset(dev);

ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
-
-   /* Also reset the gpu hangman. */
-   if (error->stop_rings != 0) {
-   DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   error->stop_rings = 0;
-   if (ret == -ENODEV) {
-   DRM_INFO("Reset not implemented, but ignoring "
-"error for simulated gpu hangs\n");
-   ret = 0;
-   }
-   }
-
-   if (i915_stop_ring_allow_warn(dev_priv))
-   pr_notice("drm/i915: Resetting chip after gpu hang\n");
-
if (ret) {
if (ret != -ENODEV)
DRM_ERROR("Failed to reset chip: %i\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3f075adf9e84..a48c0f4e1d42 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1393,13 +1393,6 @@ struct i915_gpu_error {
 */
wait_queue_head_t reset_queue;

-   /* Userspace knobs for gpu hang simulation;
-* combines both a ring mask, and extra flags
-*/
-   u32 stop_rings;
-#define I915_STOP_RING_ALLOW_BAN   (1 << 31)
-#define I915_STOP_RING_ALLOW_WARN  (1 << 30)
-
/* For missed irq/seqno simulation. */
unsigned long test_irq_rings;
  };
@@ -3292,18 +3285,6 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return ((i915_reset_counter(error) & ~I915_WEDGED) + 1) / 2;
  }

-static inline bool i915_stop_ring_allow_ban(struct drm_i915_private *dev_priv)
-{
-   return dev_priv->gpu_error.stop_rings == 0 ||
-   dev_priv->gpu_error.stop_rings & I915_STOP_RING_ALLOW_BAN;
-}
-
-static inline bool i915_stop_ring_allow_warn(struct drm_i915_private *dev_priv)
-{
-   return dev_priv->gpu_error.stop_rings == 0 ||
-   dev_priv->gpu_error.stop_rings & I915_STOP_RING_ALLOW_WARN;
-}
-
  void i915_gem_reset(struct drm_device *dev);
  bool 

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

[Tvrtko Ursulin]

On 08/06/16 12:10, Chris Wilson wrote:

On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote:


On 08/06/16 11:01, Chris Wilson wrote:

On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote:


On 03/06/16 17:08, Chris Wilson wrote:

With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
we can reduce the code size by moving the common preamble into the
caller, and we can also eliminate the reference counting.

For completeness, as we are no longer doing reference counting on irq,
rename the get/put vfunctions to enable/disable respectively.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_irq.c  |   8 +-
  drivers/gpu/drm/i915/intel_breadcrumbs.c |  10 +-
  drivers/gpu/drm/i915/intel_lrc.c |  34 +---
  drivers/gpu/drm/i915/intel_ringbuffer.c  | 269 ++-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |   5 +-
  5 files changed, 108 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 14b3d65bb604..5bdb433dde8c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -259,12 +259,12 @@ static void ilk_update_gt_irq(struct drm_i915_private 
*dev_priv,
dev_priv->gt_irq_mask &= ~interrupt_mask;
dev_priv->gt_irq_mask |= (~enabled_irq_mask & interrupt_mask);
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
-   POSTING_READ(GTIMR);
  }

  void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
  {
ilk_update_gt_irq(dev_priv, mask, mask);
+   POSTING_READ_FW(GTIMR);
  }


Unrelated hunks?

How is POSTING_READ_FW correct?


The requirement here is an uncached read of the mmio register in order
to flush the previous write to hw. A grander scheme would be to convert
all posting reads, but that requires double checking to see if anyone
has been cheating!


So what prevents to force-wake for getting released between the
I915_WRITE and POSTING_READ_FW ?


Nothing. The point is that the FW is not required for the correctness or
operation of the POSTING_READ as a barrier to hardware enabling the
interrupt.


So sleeping hardware is OK with being read from? It won't hang or 
anything, just provide bad data?


Why not change POSTING_READ to be I915_READ_FW always then?

Regards,

Tvrtko



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

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

[Tvrtko Ursulin]

On 08/06/16 12:24, Chris Wilson wrote:

On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:


On 08/06/16 10:48, Chris Wilson wrote:

On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote:

+static int intel_breadcrumbs_signaler(void *arg)
+{
+   struct intel_engine_cs *engine = arg;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   struct signal *signal;
+
+   /* Install ourselves with high priority to reduce signalling latency */
+   signaler_set_rtpriority();
+
+   do {
+   set_current_state(TASK_INTERRUPTIBLE);
+
+   /* We are either woken up by the interrupt bottom-half,
+* or by a client adding a new signaller. In both cases,
+* the GPU seqno may have advanced beyond our oldest signal.
+* If it has, propagate the signal, remove the waiter and
+* check again with the next oldest signal. Otherwise we
+* need to wait for a new interrupt from the GPU or for
+* a new client.
+*/
+   signal = READ_ONCE(b->first_signal);
+   if (signal_complete(signal)) {
+   /* Wake up all other completed waiters and select the
+* next bottom-half for the next user interrupt.
+*/
+   intel_engine_remove_wait(engine, >wait);
+
+   i915_gem_request_unreference(signal->request);
+
+   /* Find the next oldest signal. Note that as we have
+* not been holding the lock, another client may
+* have installed an even older signal than the one
+* we just completed - so double check we are still
+* the oldest before picking the next one.
+*/
+   spin_lock(>lock);
+   if (signal == b->first_signal)
+   b->first_signal = rb_next(>node);
+   rb_erase(>node, >signals);
+   spin_unlock(>lock);
+
+   kfree(signal);
+   } else {
+   if (kthread_should_stop())
+   break;
+
+   schedule();
+   }
+   } while (1);
+
+   return 0;
+}


So the thread is only because it is convenient to plug it in the
breadcrumbs infrastructure. Otherwise the processing above could be
done from a lighter weight context as well since nothing seems to
need the process context.


No, seqno processing requires process/sleepable context. The delays we
incur can be >100us and not suitable for irq/softirq context.


Nothing in this patch needs it - please say in the commit why it is
choosing the process context then.


Bottom half processing requires it. irq_seqno_barrier is not suitable
for irq/softirq context.


Why? Because of a single clflush? How long does that take?


And why so long delays? It looks pretty lightweight to me.


One alternative could perhaps be to add a waiter->wake_up vfunc and
signalers could then potentially use a tasklet?


Hmm, I did find that in order to reduce execlists latency, I had to
drive the tasklet processing from the signaler.


What do you mean? The existing execlists tasklet? Now would that work?


Due to how dma-fence signals, the softirq is never kicked
(spin_lock_irq doesn't handle local_bh_enable()) and so we would only
submit a new task via execlists on a reschedule. That latency added
about 30% (30s on bsw) to gem_exec_parallel.


I don't follow. User interrupts are separate from context complete which 
drives the submission. How do fences interfere with the latter?



+int intel_engine_enable_signaling(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   struct rb_node *parent, **p;
+   struct signal *signal;
+   bool first, wakeup;
+
+   if (unlikely(IS_ERR(b->signaler)))
+   return PTR_ERR(b->signaler);


I don't see that there is a fallback is kthread creation failed. It
should just fail in intel_engine_init_breadcrumbs if that happens.


Because it is not fatal to using the GPU, just one optional function.


But we never expect it to fail and it is not even dependent on
anything user controllable. Just a random error which would cause
user experience to degrade. If thread creation failed it means
system is in such a poor shape I would just fail the driver init.


A minimally functional system is better than nothing at all.
GEM is not required for driver loading, interrupt driven dma-fences less
so.


If you are so hot for that, how about vfuncing enable signaling in that 
case? Because I find the "have we created our kthread at driver init 
time successfuly" question for every fence a bit too much.


Regards,

Tvrtko

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: updates to GuC doorbell handling

[Patchwork]

== Series Details ==

Series: drm/i915: updates to GuC doorbell handling
URL   : https://patchwork.freedesktop.org/series/8441/
State : success

== Summary ==

Series 8441v1 drm/i915: updates to GuC doorbell handling
http://patchwork.freedesktop.org/api/1.0/series/8441/revisions/1/mbox


fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bsw-n3050 total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:168  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-ivb2-i7-3770  total:183  pass:158  dwarn:0   dfail:0   fail:0   skip:24 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot
ro-bdw-i7-5600u failed to connect after reboot
ro-hsw-i7-4770r failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1137/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
d22be7d4 drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
b7d2be1 drm/i915/guc: refactor doorbell management code
e566931 drm/i915/guc: move guc_ring_doorbell() nearer to callsite
cd5f059 drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Wed, Jun 08, 2016 at 12:06:05PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:47PM +0100, Chris Wilson wrote:
> > The error state is purposefully racy as we expect it to be called at any
> > time and so have avoided any locking whilst capturing the crash dump.
> > However, with multi-engine GPUs and multiple CPUs, those races can
> > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > other CPUs. Under discussion are lots of ways to slow down normal
> > operation in order to protect the post-mortem error capture, but what it
> > we take the opposite approach and freeze the machine whilst the error
> > capture runs (note the GPU may still running, but as long as we don't
> > process any of the results the driver's bookkeeping will be static).
> > 
> > Note that by of itself, this is not a complete fix. It also depends on
> > the compiler barriers in list_add/list_del to prevent traversing the
> > lists into the void.
> > 
> > v2: Avoid drm_clflush_pages() inside stop_machine() as it may use
> > stop_machine() itself for its wbinvd fallback.
> > 
> > Signed-off-by: Chris Wilson 
> 
> rt folks will hate us for this I think. But yeah the only other options is
> mass-rcu-ifying everything, which is much more fragile. Ack on the general
> idea at least, need to look at what's all needed for list manipulation
> still.

General answer, if you have a problem with a GPU hang talk to whoever
caused it and tell them to stop ;)

Last inspection of list.h, suggests they are safe for our usage:

static inline void __list_del(struct list_head * prev, struct list_head * next)
{
next->prev = prev;
WRITE_ONCE(prev->next, next);
}


static inline void __list_add(struct list_head *new,
  struct list_head *prev,
  struct list_head *next)
{
next->prev = new;
new->next = next;
new->prev = prev;
WRITE_ONCE(prev->next, new);
}

i.e. they have gained the compiler barriers to prevent us from seeing a
partial list manipulation (they are basically RCU-safe by default now).

I also do passes over the error capture trying to minimise our list
usage so that we only have to verify the request list (and all GPU state
associated with the request should then be derivable from the request).
E.g that saves having to iterate over the context lists looking for the
request->ctx!
-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 1/2] tests/kms_chv_cursor_fail: Remove extra igt_pipe_crc_start.

[Maarten Lankhorst]

There is a extra call to igt_pipe_crc_start that is not matched to any
stop. Because of this the exit handler tries to reset the crc source on
exit while the pipe disabled. This causes fails with -EIO:

(kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Test assertion failure
function igt_pipe_crc_pipe_off, file igt_debugfs.c:364:
(kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Failed assertion:
write(fd, buf, strlen(buf)) == strlen(buf)
(kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Last errno: 5, EIO
(kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: error: -1 != 11
Stack trace:
  #0 [__igt_fail_assert+0xf1]
  #1 [igt_pipe_crc_pipe_off+0xe4]
  #2 [pipe_crc_exit_handler+0x35]
  #3 [igt_atexit_handler+0x4c]
  #4 [__libc_secure_getenv+0x112]
  #5 [exit+0x15]
  #6 [igt_exit+0xd6]
  #7 [main+0x1ee]
  #8 [__libc_start_main+0xf0]
  #9 [_start+0x29]
  #10 [+0x29]

Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
 tests/kms_chv_cursor_fail.c |   3 -
 tests/kms_rmfb.c| 180 
 2 files changed, 180 insertions(+), 3 deletions(-)
 create mode 100644 tests/kms_rmfb.c

diff --git a/tests/kms_chv_cursor_fail.c b/tests/kms_chv_cursor_fail.c
index 83af07f9b968..11d01f54e511 100644
--- a/tests/kms_chv_cursor_fail.c
+++ b/tests/kms_chv_cursor_fail.c
@@ -163,9 +163,6 @@ static void test_edge_pos(data_t *data, int sx, int ex, int 
y, bool swap_axis)
}
igt_debug("\n");
}
-
-
-   igt_pipe_crc_start(data->pipe_crc);
 }
 
 static void test_edge(data_t *data, int sy, int ey, int sx, int ex, bool 
swap_axis)
diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
new file mode 100644
index ..a3fde9f43788
--- /dev/null
+++ b/tests/kms_rmfb.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright © 2016 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 "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
+struct rmfb_data {
+   int drm_fd;
+   igt_display_t display;
+};
+
+/*
+ * 1. Set primary plane to a known fb.
+ * 2. Make sure getcrtc returns the correct fb id.
+ * 3. Call rmfb on the fb.
+ * 4. Make sure getcrtc returns 0 fb id.
+ *
+ * RMFB is supposed to free the framebuffers from any and all planes,
+ * so test this and make sure it works.
+ */
+static bool
+test_rmfb(struct rmfb_data *data, igt_output_t *output, enum pipe pipe, bool 
reopen)
+{
+   struct igt_fb fb, argb_fb;
+   drmModeModeInfo *mode;
+   igt_plane_t *plane;
+   drmModeCrtc *crtc;
+   uint64_t cursor_width, cursor_height;
+
+   igt_output_set_pipe(output, pipe);
+   igt_display_commit(>display);
+
+   if (!output->valid) {
+   igt_output_set_pipe(output, PIPE_ANY);
+   return false;
+   }
+
+   mode = igt_output_get_mode(output);
+
+   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, );
+
+   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_ARGB, LOCAL_DRM_FORMAT_MOD_NONE, _fb);
+
+   do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, _width));
+   if (cursor_width > mode->hdisplay)
+   cursor_width = mode->hdisplay;
+
+   do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, 
_height));
+   if (cursor_height > mode->vdisplay)
+   cursor_height = mode->vdisplay;
+
+   /*
+* Make sure these buffers are suited for display use
+* because most of the modeset operations must be fast
+* later on.
+*/
+   for_each_plane_on_pipe(>display, pipe, 

[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Maarten Lankhorst]

This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
to 10s.

Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
 tests/kms_chv_cursor_fail.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/tests/kms_chv_cursor_fail.c b/tests/kms_chv_cursor_fail.c
index 11d01f54e511..8f878cbffe96 100644
--- a/tests/kms_chv_cursor_fail.c
+++ b/tests/kms_chv_cursor_fail.c
@@ -109,24 +109,26 @@ static void cursor_move(data_t *data, int x, int y, int i)
 }
 
 #define XSTEP 8
-#define YSTEP 32
-#define XOFF 0
+#define YSTEP 8
 #define NCRC 128
 
 static void test_edge_pos(data_t *data, int sx, int ex, int y, bool swap_axis)
 {
igt_crc_t *crc = NULL;
-   int i, n, x, xdir;
+   int i, n, x, xdir, dx;
 
if (sx > ex)
xdir = -1;
else
xdir = 1;
 
+   dx = (ex - sx)/XSTEP;
+
igt_pipe_crc_start(data->pipe_crc);
 
i = 0;
-   for (x = sx + XOFF; xdir * (x - ex - XOFF) <= 0; x += xdir * XSTEP) {
+
+   for (x = sx; xdir * (x - ex) <= 0; x += dx) {
int xx, yy;
 
if (swap_axis) {
@@ -168,21 +170,23 @@ static void test_edge_pos(data_t *data, int sx, int ex, 
int y, bool swap_axis)
 static void test_edge(data_t *data, int sy, int ey, int sx, int ex, bool 
swap_axis)
 {
int crtc_id = data->output->config.crtc->crtc_id;
-   int y, ydir;
+   int y, ydir, dy;
 
if (sy > ey)
ydir = -1;
else
ydir = 1;
 
+   dy = (ey - sy) / YSTEP;
+
igt_assert_eq(drmModeMoveCursor(data->drm_fd, crtc_id, -data->curw, 
-data->curh), 0);
igt_assert_eq(drmModeSetCursor(data->drm_fd, crtc_id, 
data->fb.gem_handle, data->curw, data->curh), 0);
 
for (y = sy; ydir * (y - ey) <= 0; ) {
test_edge_pos(data, sx, ex, y, swap_axis);
-   y += ydir * YSTEP;
+   y += dy;
test_edge_pos(data, ex, sx, y, swap_axis);
-   y += ydir * YSTEP;
+   y += dy;
}
 
igt_assert_eq(drmModeMoveCursor(data->drm_fd, crtc_id, -data->curw, 
-data->curh), 0);
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

[kbuild test robot]

Hi,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.7-rc2 next-20160608]
[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/Akshu-Agrawal/Revert-drm-i915-Workaround-CHV-pipe-C-cursor-fail/20160608-163007
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
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: In function 
'vlv_pin_and_map_buffer_obj':
>> drivers/gpu/drm/i915/intel_display.c:14306:36: error: 'struct 
>> drm_i915_private' has no member named 'gtt'
 buffer_start = ioremap_wc(dev_priv->gtt.mappable_base +
   ^

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

 14300  ret = i915_gem_object_set_to_gtt_domain(obj, true);
 14301  if (ret) {
 14302  i915_gem_object_ggtt_unpin(obj);
 14303  return NULL;
 14304  }
 14305  
 14306  buffer_start = ioremap_wc(dev_priv->gtt.mappable_base +
 14307  i915_gem_obj_ggtt_offset(obj), obj->base.size);
 14308  if (buffer_start == NULL) {
 14309  i915_gem_object_ggtt_unpin(obj);

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

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:
> 
> On 08/06/16 10:48, Chris Wilson wrote:
> >On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote:
> >>>+static int intel_breadcrumbs_signaler(void *arg)
> >>>+{
> >>>+  struct intel_engine_cs *engine = arg;
> >>>+  struct intel_breadcrumbs *b = >breadcrumbs;
> >>>+  struct signal *signal;
> >>>+
> >>>+  /* Install ourselves with high priority to reduce signalling latency */
> >>>+  signaler_set_rtpriority();
> >>>+
> >>>+  do {
> >>>+  set_current_state(TASK_INTERRUPTIBLE);
> >>>+
> >>>+  /* We are either woken up by the interrupt bottom-half,
> >>>+   * or by a client adding a new signaller. In both cases,
> >>>+   * the GPU seqno may have advanced beyond our oldest signal.
> >>>+   * If it has, propagate the signal, remove the waiter and
> >>>+   * check again with the next oldest signal. Otherwise we
> >>>+   * need to wait for a new interrupt from the GPU or for
> >>>+   * a new client.
> >>>+   */
> >>>+  signal = READ_ONCE(b->first_signal);
> >>>+  if (signal_complete(signal)) {
> >>>+  /* Wake up all other completed waiters and select the
> >>>+   * next bottom-half for the next user interrupt.
> >>>+   */
> >>>+  intel_engine_remove_wait(engine, >wait);
> >>>+
> >>>+  i915_gem_request_unreference(signal->request);
> >>>+
> >>>+  /* Find the next oldest signal. Note that as we have
> >>>+   * not been holding the lock, another client may
> >>>+   * have installed an even older signal than the one
> >>>+   * we just completed - so double check we are still
> >>>+   * the oldest before picking the next one.
> >>>+   */
> >>>+  spin_lock(>lock);
> >>>+  if (signal == b->first_signal)
> >>>+  b->first_signal = rb_next(>node);
> >>>+  rb_erase(>node, >signals);
> >>>+  spin_unlock(>lock);
> >>>+
> >>>+  kfree(signal);
> >>>+  } else {
> >>>+  if (kthread_should_stop())
> >>>+  break;
> >>>+
> >>>+  schedule();
> >>>+  }
> >>>+  } while (1);
> >>>+
> >>>+  return 0;
> >>>+}
> >>
> >>So the thread is only because it is convenient to plug it in the
> >>breadcrumbs infrastructure. Otherwise the processing above could be
> >>done from a lighter weight context as well since nothing seems to
> >>need the process context.
> >
> >No, seqno processing requires process/sleepable context. The delays we
> >incur can be >100us and not suitable for irq/softirq context.
> 
> Nothing in this patch needs it - please say in the commit why it is
> choosing the process context then.

Bottom half processing requires it. irq_seqno_barrier is not suitable
for irq/softirq context.

> And why so long delays? It looks pretty lightweight to me.
> 
> >>One alternative could perhaps be to add a waiter->wake_up vfunc and
> >>signalers could then potentially use a tasklet?
> >
> >Hmm, I did find that in order to reduce execlists latency, I had to
> >drive the tasklet processing from the signaler.
> 
> What do you mean? The existing execlists tasklet? Now would that work?

Due to how dma-fence signals, the softirq is never kicked
(spin_lock_irq doesn't handle local_bh_enable()) and so we would only
submit a new task via execlists on a reschedule. That latency added
about 30% (30s on bsw) to gem_exec_parallel.

> >>>+int intel_engine_enable_signaling(struct drm_i915_gem_request *request)
> >>>+{
> >>>+  struct intel_engine_cs *engine = request->engine;
> >>>+  struct intel_breadcrumbs *b = >breadcrumbs;
> >>>+  struct rb_node *parent, **p;
> >>>+  struct signal *signal;
> >>>+  bool first, wakeup;
> >>>+
> >>>+  if (unlikely(IS_ERR(b->signaler)))
> >>>+  return PTR_ERR(b->signaler);
> >>
> >>I don't see that there is a fallback is kthread creation failed. It
> >>should just fail in intel_engine_init_breadcrumbs if that happens.
> >
> >Because it is not fatal to using the GPU, just one optional function.
> 
> But we never expect it to fail and it is not even dependent on
> anything user controllable. Just a random error which would cause
> user experience to degrade. If thread creation failed it means
> system is in such a poor shape I would just fail the driver init.

A minimally functional system is better than nothing at all.
GEM is not required for driver loading, interrupt driven dma-fences less
so.
-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] drm/i915: Don't unregister fbdev twice

[Lukas Wunner]

Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
superfluous because the framebuffer will subsequently be unregistered by
drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
The call is a leftover, when it was introduced by commit 362063619cf6
("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
was still embedded in struct intel_fbdev rather than being a pointer as
it is today, and drm_framebuffer_remove() wasn't used yet.

As a bonus, the ID of the framebuffer is no longer 0 in the debug log:

Before:
[   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
[   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
[   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)

After:
[  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
[  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
[  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index ef8e676..4c7ea46 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
drm_fb_helper_fini(>helper);
 
if (ifbdev->fb) {
-   drm_framebuffer_unregister_private(>fb->base);
-
mutex_lock(>struct_mutex);
intel_unpin_fb_obj(>fb->base, BIT(DRM_ROTATE_0));
mutex_unlock(>struct_mutex);
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 12/62] drm/i915: Skip capturing an error state if we already have one

[Arun Siluvery]

On 03/06/2016 22:06, Chris Wilson wrote:

As we only ever keep the first error state around, we can avoid some
work that can be quite intrusive if we don't record the error the second
time around. This does move the race whereby the user could discard one
error state as the second is being captured, but that race exists in the
current code and we hope that recapturing error state is only done for
debugging.

Note that as we discard the error state for simulated errors, igt that
exercise error capture continue to function.

Signed-off-by: Chris Wilson 
---


Patch does more than what is described here, all of i915_gem_request 
changes are part of this patch, accidentally squashed may be.


regards
Arun


  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/i915_drv.h | 210 +-
  drivers/gpu/drm/i915/i915_gem.c | 653 +--
  drivers/gpu/drm/i915/i915_gem_request.c | 659 
  drivers/gpu/drm/i915/i915_gem_request.h | 245 
  drivers/gpu/drm/i915/i915_gpu_error.c   |   3 +
  6 files changed, 916 insertions(+), 855 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 f20007440821..14cef1d2343c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -32,6 +32,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 15a0c6bdf500..939cd45043c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -60,6 +60,7 @@
  #include "i915_gem.h"
  #include "i915_gem_gtt.h"
  #include "i915_gem_render_state.h"
+#include "i915_gem_request.h"

  /* General customization:
   */
@@ -2339,172 +2340,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;
-   unsigned reset_counter;
-   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 

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Eliminate DDI encoder->type frobbery

[Patchwork]

== Series Details ==

Series: drm/i915: Eliminate DDI encoder->type frobbery
URL   : https://patchwork.freedesktop.org/series/8439/
State : success

== Summary ==

Series 8439v1 drm/i915: Eliminate DDI encoder->type frobbery
http://patchwork.freedesktop.org/api/1.0/series/8439/revisions/1/mbox


fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bdw-i7-5600u  total:161  pass:137  dwarn:0   dfail:0   fail:0   skip:23 
ro-bsw-n3050 total:208  pass:166  dwarn:1   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:208  pass:168  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:183  pass:161  dwarn:0   dfail:0   fail:0   skip:21 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:54   pass:51   dwarn:0   dfail:0   fail:0   skip:3  
ro-ivb2-i7-3770  total:183  pass:158  dwarn:0   dfail:0   fail:0   skip:24 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot
ro-bdw-i7-5600u failed to connect after reboot
ro-ivb-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1136/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
22c492e drm/i915: Stop frobbing with DDI encoder->type
839a38c drm/i915: Check for invalid cloning earlier during modeset
f1341cd drm/i915: Simplify hdmi_12bpc_possible()
a1d7cbf drm/i915: Kill has_dsi_encoder
97669c4 drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/
0babbea drm/i915: Replace some open coded intel_crtc_has_dp_encoder()s
4349ca8e drm/i915: Kill has_dp_encoder from pipe_config
60b1828 drm/i915: Replace manual lvds and sdvo/hdmi counting with 
intel_crtc_has_type()
6b50b1c drm/i915: Unify intel_pipe_has_type() and intel_pipe_will_have_type()
0ade9c1 drm/i915: Add output_types bitmask into the crtc state
1435be2 drm/i915: Remove encoder type checks from MST suspend/resume
5f65c4a drm/i915: Don't mark eDP encoders as MST capable

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

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote:
> 
> On 08/06/16 11:01, Chris Wilson wrote:
> >On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 03/06/16 17:08, Chris Wilson wrote:
> >>>With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
> >>>we can reduce the code size by moving the common preamble into the
> >>>caller, and we can also eliminate the reference counting.
> >>>
> >>>For completeness, as we are no longer doing reference counting on irq,
> >>>rename the get/put vfunctions to enable/disable respectively.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_irq.c  |   8 +-
> >>>  drivers/gpu/drm/i915/intel_breadcrumbs.c |  10 +-
> >>>  drivers/gpu/drm/i915/intel_lrc.c |  34 +---
> >>>  drivers/gpu/drm/i915/intel_ringbuffer.c  | 269 
> >>> ++-
> >>>  drivers/gpu/drm/i915/intel_ringbuffer.h  |   5 +-
> >>>  5 files changed, 108 insertions(+), 218 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >>>b/drivers/gpu/drm/i915/i915_irq.c
> >>>index 14b3d65bb604..5bdb433dde8c 100644
> >>>--- a/drivers/gpu/drm/i915/i915_irq.c
> >>>+++ b/drivers/gpu/drm/i915/i915_irq.c
> >>>@@ -259,12 +259,12 @@ static void ilk_update_gt_irq(struct 
> >>>drm_i915_private *dev_priv,
> >>>   dev_priv->gt_irq_mask &= ~interrupt_mask;
> >>>   dev_priv->gt_irq_mask |= (~enabled_irq_mask & interrupt_mask);
> >>>   I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
> >>>-  POSTING_READ(GTIMR);
> >>>  }
> >>>
> >>>  void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
> >>>  {
> >>>   ilk_update_gt_irq(dev_priv, mask, mask);
> >>>+  POSTING_READ_FW(GTIMR);
> >>>  }
> >>
> >>Unrelated hunks?
> >>
> >>How is POSTING_READ_FW correct?
> >
> >The requirement here is an uncached read of the mmio register in order
> >to flush the previous write to hw. A grander scheme would be to convert
> >all posting reads, but that requires double checking to see if anyone
> >has been cheating!
> 
> So what prevents to force-wake for getting released between the
> I915_WRITE and POSTING_READ_FW ?

Nothing. The point is that the FW is not required for the correctness or
operation of the POSTING_READ as a barrier to hardware enabling the
interrupt.
-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 01/62] drm/i915: Only start retire worker when idle

[Chris Wilson]

On Wed, Jun 08, 2016 at 11:53:15AM +0100, Chris Wilson wrote:
> On Tue, Jun 07, 2016 at 02:31:07PM +0300, Joonas Lahtinen wrote:
> > On pe, 2016-06-03 at 17:36 +0100, Chris Wilson wrote:
> > >  i915_gem_idle_work_handler(struct work_struct *work)
> > >  {
> > >   struct drm_i915_private *dev_priv =
> > > - container_of(work, typeof(*dev_priv), mm.idle_work.work);
> > > + container_of(work, typeof(*dev_priv), gt.idle_work.work);
> > >   struct drm_device *dev = dev_priv->dev;
> > >   struct intel_engine_cs *engine;
> > >  
> > > - for_each_engine(engine, dev_priv)
> > > - if (!list_empty(>request_list))
> > > - return;
> > > + if (!READ_ONCE(dev_priv->gt.awake))
> > > + return;
> > >  
> > > - /* we probably should sync with hangcheck here, using cancel_work_sync.
> > > -  * Also locking seems to be fubar here, engine->request_list is 
> > > protected
> > > -  * by dev->struct_mutex. */
> > > + mutex_lock(>struct_mutex);
> > > + if (dev_priv->gt.active_engines)
> > > + goto out;
> > >  
> > > - intel_mark_idle(dev_priv);
> > > + for_each_engine(engine, dev_priv)
> > > + i915_gem_batch_pool_fini(>batch_pool);
> > >  
> > > - if (mutex_trylock(>struct_mutex)) {
> > > - for_each_engine(engine, dev_priv)
> > > - i915_gem_batch_pool_fini(>batch_pool);
> > > + GEM_BUG_ON(!dev_priv->gt.awake);
> > > + dev_priv->gt.awake = false;
> > >  
> > > - mutex_unlock(>struct_mutex);
> > > + if (INTEL_INFO(dev_priv)->gen >= 6)
> > > + gen6_rps_idle(dev_priv);
> > > + intel_runtime_pm_put(dev_priv);
> > > +out:
> > > + mutex_unlock(>struct_mutex);
> > > +
> > > + if (!dev_priv->gt.awake &&
> > 
> > No READ_ONCE here, even we just unlocked the mutex. So lacks some
> > consistency.
> > 
> > Also, this assumes we might be pre-empted between unlocking mutex and
> > making this test, so I'm little bit confused. Do you want to optimize
> > by avoiding calling cancel_delayed_work_sync?
> 
> General principle to never call work_sync functions with locks held. I
> had actually thought I had fixed this up (but realized that I just
> rewrote hangcheck later on instead ;)
> 
> Ok, what I think is safer here is
> 
>   bool hangcheck = cancel_delay_work_sync(hangcheck_work)
> 
>   mutex_lock()
>   if (actually_idle()) {
>   awake = false;
>   missed_irq_rings |= intel_kick_waiters();
>   }
>   mutex_unlock();
> 
>   if (awake && hangcheck)
>   queue_hangcheck()
>   
> So always kick the hangcheck and reeanble if we tried to idle too early.
> This will potentially delay hangcheck by one full hangcheck period if we
> do encounter that race. But we shouldn't be hitting this race that
> often, or hanging the GPU for that mterr.

Actual delta:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 406046f66e36..856da4036fb3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3066,10 +3066,15 @@ i915_gem_idle_work_handler(struct work_struct *work)
container_of(work, typeof(*dev_priv), gt.idle_work.work);
struct drm_device *dev = dev_priv->dev;
struct intel_engine_cs *engine;
+   unsigned stuck_engines;
+   bool rearm_hangcheck;
 
if (!READ_ONCE(dev_priv->gt.awake))
return;
 
+   rearm_hangcheck =
+   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
+
mutex_lock(>struct_mutex);
if (dev_priv->gt.active_engines)
goto out;
@@ -3079,6 +3084,13 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
+   rearm_hangcheck = false;
+
+   stuck_engines = intel_kick_waiters(dev_priv);
+   if (unlikely(stuck_engines)) {
+   DRM_DEBUG_DRIVER("kicked stuck waiters...missed irq\n");
+   dev_priv->gpu_error.missed_irq_rings |= stuck_engines;
+   }
 
if (INTEL_INFO(dev_priv)->gen >= 6)
gen6_rps_idle(dev_priv);
@@ -3086,14 +3098,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
 out:
mutex_unlock(>struct_mutex);
 
-   if (!dev_priv->gt.awake &&
-   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work)) {
-   unsigned stuck = intel_kick_waiters(dev_priv);
-   if (unlikely(stuck)) {
-   DRM_DEBUG_DRIVER("kicked stuck waiters...missed irq\n");
-   dev_priv->gpu_error.missed_irq_rings |= stuck;
-   }
-   }
+   if (rearm_hangcheck)
+   i915_queue_hangcheck(dev_priv);
 }
-Chris

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

Re: [Intel-gfx] [PATCH v3 29/33] drm/i915: Split idling from forcing context switch

[Chris Wilson]

On Wed, Jun 08, 2016 at 12:02:28PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote:
> > @@ -261,11 +298,17 @@ int i915_gem_evict_vm(struct i915_address_space *vm, 
> > bool do_idle)
> >     trace_i915_gem_evict_vm(vm);
> >  
> >     if (do_idle) {
> > -   ret = i915_gpu_idle(vm->dev);
> > +   struct drm_i915_private *dev_priv = to_i915(vm->dev);
> > +
> > +   ret = switch_to_pinned_context(dev_priv);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = i915_gem_wait_for_idle(dev_priv);
> >     if (ret)
> >     return ret;
> >  
> > -   i915_gem_retire_requests(to_i915(vm->dev));
> > +   i915_gem_retire_requests(dev_priv);
> 
> This and previous hunk, my eyes see a need for a new function (with an
> appropriate name, hopefully).

We'll get to the point where the duplication no longer exists.
-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 2/4] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

[Dave Gordon]

Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell management code, this function is somewhat
time-critical, so putting it near its caller may even yield a tiny
performance improvement.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2db1182..7510841 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,61 +185,6 @@ static void guc_init_doorbell(struct intel_guc *guc,
doorbell->cookie = 0;
 }
 
-static int guc_ring_doorbell(struct i915_guc_client *gc)
-{
-   struct guc_process_desc *desc;
-   union guc_doorbell_qw db_cmp, db_exc, db_ret;
-   union guc_doorbell_qw *db;
-   int attempt = 2, ret = -EAGAIN;
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
-   /* Update the tail so it is visible to GuC */
-   desc->tail = gc->wq_tail;
-
-   /* current cookie */
-   db_cmp.db_status = GUC_DOORBELL_ENABLED;
-   db_cmp.cookie = gc->cookie;
-
-   /* cookie to be updated */
-   db_exc.db_status = GUC_DOORBELL_ENABLED;
-   db_exc.cookie = gc->cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-
-   /* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
-
-   while (attempt--) {
-   /* lets ring the doorbell */
-   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
-   db_cmp.value_qw, db_exc.value_qw);
-
-   /* if the exchange was successfully executed */
-   if (db_ret.value_qw == db_cmp.value_qw) {
-   /* db was successfully rung */
-   gc->cookie = db_exc.cookie;
-   ret = 0;
-   break;
-   }
-
-   /* XXX: doorbell was lost and need to acquire it again */
-   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
-   break;
-
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
-
-   /* update the cookie to newly read cookie from GuC */
-   db_cmp.cookie = db_ret.cookie;
-   db_exc.cookie = db_ret.cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-   }
-
-   return ret;
-}
-
 static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
 {
@@ -543,6 +488,61 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
kunmap_atomic(base);
 }
 
+static int guc_ring_doorbell(struct i915_guc_client *gc)
+{
+   struct guc_process_desc *desc;
+   union guc_doorbell_qw db_cmp, db_exc, db_ret;
+   union guc_doorbell_qw *db;
+   int attempt = 2, ret = -EAGAIN;
+
+   desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Update the tail so it is visible to GuC */
+   desc->tail = gc->wq_tail;
+
+   /* current cookie */
+   db_cmp.db_status = GUC_DOORBELL_ENABLED;
+   db_cmp.cookie = gc->cookie;
+
+   /* cookie to be updated */
+   db_exc.db_status = GUC_DOORBELL_ENABLED;
+   db_exc.cookie = gc->cookie + 1;
+   if (db_exc.cookie == 0)
+   db_exc.cookie = 1;
+
+   /* pointer of current doorbell cacheline */
+   db = gc->client_base + gc->doorbell_offset;
+
+   while (attempt--) {
+   /* lets ring the doorbell */
+   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
+   db_cmp.value_qw, db_exc.value_qw);
+
+   /* if the exchange was successfully executed */
+   if (db_ret.value_qw == db_cmp.value_qw) {
+   /* db was successfully rung */
+   gc->cookie = db_exc.cookie;
+   ret = 0;
+   break;
+   }
+
+   /* XXX: doorbell was lost and need to acquire it again */
+   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
+   break;
+
+   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
+ db_cmp.cookie, db_ret.cookie);
+
+   /* update the cookie to newly read cookie from GuC */
+   db_cmp.cookie = db_ret.cookie;
+   db_exc.cookie = db_ret.cookie + 1;
+   if (db_exc.cookie == 0)
+   db_exc.cookie = 1;
+   }
+
+   return ret;

[Intel-gfx] [PATCH 0/4] drm/i915: updates to GuC doorbell handling

[Dave Gordon]

The Linux hibernate/resume sequence involves booting one kernel, and
then replacing(!) its in-memory image with that of the previously
hibernated system.  This can lead to inconsistencies in the state of
the hardware, in particular where a driver does not or cannot reset
it to a well-defined initial state during resume.

For i915, the issue is that the doorbell hardware is not reset when
the GuC is reset; also, the driver *cannot* directly reprogram it:
only the GuC can do that. So this set of patches first reorganises
the doorbell handling, and then (in the last patch of the set)
ensures that the doorbell hardware is fully (re-)initialised when
the GuC is (re-)loaded.

Dave Gordon (4):
  drm/i915/guc: add doorbell map to debugfs/i915_guc_info
  drm/i915/guc: move guc_ring_doorbell() nearer to callsite
  drm/i915/guc: refactor doorbell management code
  drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

 drivers/gpu/drm/i915/i915_debugfs.c|   9 ++
 drivers/gpu/drm/i915/i915_guc_submission.c | 232 ++---
 2 files changed, 154 insertions(+), 87 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 1/4] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

[Dave Gordon]

To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..fbb4b16 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2560,6 +2560,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct i915_guc_client client = {};
struct intel_engine_cs *engine;
u64 total = 0;
+   int i;
 
if (!HAS_GUC_SCHED(dev_priv))
return 0;
@@ -2574,6 +2575,14 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
mutex_unlock(>struct_mutex);
 
+   seq_printf(m, "Doorbell map:\n");
+   BUILD_BUG_ON(ARRAY_SIZE(guc.doorbell_bitmap) % 4);
+   for (i = 0; i < ARRAY_SIZE(guc.doorbell_bitmap) - 3; i += 4)
+   seq_printf(m, "\t%016lx %016lx %016lx %016lx\n",
+   guc.doorbell_bitmap[i], guc.doorbell_bitmap[i+1],
+   guc.doorbell_bitmap[i+2], guc.doorbell_bitmap[i+3]);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc.db_cacheline);
+
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/4] drm/i915/guc: refactor doorbell management code

[Dave Gordon]

During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.

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

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7510841..eef67c8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,36 +174,63 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
  * client object which contains the page being used for the doorbell
  */
 
-static void guc_init_doorbell(struct intel_guc *guc,
- struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct i915_guc_client *client,
+ struct guc_doorbell_info *doorbell,
+ u16 new_id)
 {
-   struct guc_doorbell_info *doorbell;
+   struct sg_table *sg = client->guc->ctx_pool_obj->pages;
+   void *doorbell_bitmap = client->guc->doorbell_bitmap;
+   struct guc_context_desc desc;
+   size_t len;
+
+   if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+   test_bit(client->doorbell_id, doorbell_bitmap)) {
+   /* Deactivate the old doorbell */
+   doorbell->db_status = GUC_DOORBELL_DISABLED;
+   (void)host2guc_release_doorbell(client->guc, client);
+   clear_bit(client->doorbell_id, doorbell_bitmap);
+   }
 
-   doorbell = client->client_base + client->doorbell_offset;
+   /* Update the GuC's idea of the doorbell ID */
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+   desc.db_id = new_id;
+   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+
+   client->doorbell_id = new_id;
+   if (new_id == GUC_INVALID_DOORBELL_ID)
+   return 0;
 
+   /* Activate the new doorbell */
+   set_bit(client->doorbell_id, doorbell_bitmap);
doorbell->db_status = GUC_DOORBELL_ENABLED;
doorbell->cookie = 0;
+   return host2guc_allocate_doorbell(client->guc, client);
 }
 
-static void guc_disable_doorbell(struct intel_guc *guc,
-struct i915_guc_client *client)
+static void guc_init_doorbell(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ uint16_t db_id)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct guc_doorbell_info *doorbell;
-   i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
-   int value;
 
doorbell = client->client_base + client->doorbell_offset;
 
-   doorbell->db_status = GUC_DOORBELL_DISABLED;
-
-   I915_WRITE(drbreg, I915_READ(drbreg) & ~GEN8_DRB_VALID);
+   guc_update_doorbell_id(client, doorbell, db_id);
+}
 
-   value = I915_READ(drbreg);
-   WARN_ON((value & GEN8_DRB_VALID) != 0);
+static void guc_disable_doorbell(struct intel_guc *guc,
+struct i915_guc_client *client)
+{
+   struct guc_doorbell_info *doorbell;
 
-   I915_WRITE(GEN8_DRBREGU(client->doorbell_id), 0);
-   I915_WRITE(drbreg, 0);
+   doorbell = client->client_base + client->doorbell_offset;
+   guc_update_doorbell_id(client, doorbell, GUC_INVALID_DOORBELL_ID);
 
/* XXX: wait for any interrupts */
/* XXX: wait for workqueue to drain */
@@ -251,7 +278,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
-   bitmap_set(guc->doorbell_bitmap, id, 1);
+   set_bit(id, guc->doorbell_bitmap);
 
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -259,11 +286,6 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
return id;
 }
 
-static void release_doorbell(struct intel_guc *guc, uint16_t id)
-{
-   bitmap_clear(guc->doorbell_bitmap, id, 1);
-}
-
 /*
  * Initialise the process descriptor shared with the GuC firmware.
  */
@@ -657,8 +679,6 @@ static void guc_client_free(struct drm_device *dev,
 */
 
if (client->client_base) {
-   uint16_t db_id = client->doorbell_id;
-
/*
 * If we got as far as setting up a doorbell, make sure
 * we shut it down before