[Intel-gfx] [PATCH] drm/i915: Get audio power domain during initial hw readout

2016-04-12 Thread Bob Paauwe
if the crtc has audio is enabled. Otherwise, when the first atomic
modeset happens it will warn when trying to drop the audio power
domain.

Signed-off-by: Bob Paauwe 
---
 drivers/gpu/drm/i915/intel_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5155efb6..caeb3e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10561,6 +10561,7 @@ found:
}
 
ret = intel_modeset_setup_plane_state(state, crtc, mode, fb, 0, 0);
+
if (ret)
goto fail;
 
@@ -15998,6 +15999,10 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
 
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc->base.state->active) {
+   if (crtc->config->has_audio)
+   intel_display_power_get(dev_priv,
+   POWER_DOMAIN_AUDIO);
+
intel_mode_from_pipe_config(>base.mode, 
crtc->config);

intel_mode_from_pipe_config(>base.state->adjusted_mode, crtc->config);
WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
>base.mode));
-- 
2.5.5

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() (rev3)

2016-04-12 Thread Jim Bride
On Tue, Apr 12, 2016 at 07:39:35AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() (rev3)
> URL   : https://patchwork.freedesktop.org/series/5390/
> State : failure
> 
> == Summary ==
> 
> Series 5390v3 drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()
> http://patchwork.freedesktop.org/api/1.0/series/5390/revisions/3/mbox/
> 
> Test gem_basic:
> Subgroup create-fd-close:
> incomplete -> PASS   (bsw-nuc-2)
> Test gem_ctx_param_basic:
> Subgroup invalid-param-get:
> incomplete -> PASS   (bsw-nuc-2)
> Test gem_exec_basic:
> Subgroup basic-bsd1:
> incomplete -> SKIP   (bsw-nuc-2)
> Test gem_exec_store:
> Subgroup basic-bsd1:
> incomplete -> SKIP   (bsw-nuc-2)
> Subgroup basic-bsd2:
> incomplete -> SKIP   (bsw-nuc-2)
> Test gem_ringfill:
> Subgroup basic-default-hang:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test gem_storedw_loop:
> Subgroup basic-bsd2:
> incomplete -> SKIP   (bsw-nuc-2)
> Test kms_addfb_basic:
> Subgroup bad-pitch-1024:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Subgroup basic-y-tiled:
> incomplete -> PASS   (bsw-nuc-2)
> Subgroup small-bo:
> incomplete -> PASS   (bsw-nuc-2)
> Subgroup unused-handle:
> incomplete -> PASS   (bsw-nuc-2)
> Test kms_force_connector_basic:
> Subgroup prune-stale-modes:
> pass   -> SKIP   (snb-x220t)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a:
> incomplete -> SKIP   (bsw-nuc-2)
> Subgroup read-crc-pipe-b:
> incomplete -> SKIP   (bsw-nuc-2)
> Test prime_self_import:
> Subgroup basic-with_one_bo:
> incomplete -> PASS   (bsw-nuc-2)
> Subgroup basic-with_two_bos:
> incomplete -> PASS   (bsw-nuc-2)
> 
> bdw-nuci7total:202  pass:190  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:202  pass:179  dwarn:0   dfail:0   fail:0   skip:23 
> bsw-nuc-2total:201  pass:162  dwarn:0   dfail:0   fail:0   skip:39 
> byt-nuc  total:201  pass:163  dwarn:0   dfail:0   fail:0   skip:38 
> hsw-brixbox  total:202  pass:178  dwarn:0   dfail:0   fail:0   skip:24 
> ilk-hp8440p  total:202  pass:134  dwarn:0   dfail:0   fail:0   skip:68 
> ivb-t430stotal:202  pass:174  dwarn:0   dfail:0   fail:0   skip:28 
> skl-i7k-2total:202  pass:177  dwarn:0   dfail:0   fail:0   skip:25 
> snb-x220ttotal:202  pass:163  dwarn:0   dfail:0   fail:1   skip:38 
> BOOT FAILED for snb-dellxps

Although I'm not sure whether it's the one snb-x220t case listed above or
the boot failure for the system snb-dellxps that caused this to be flagged
as failing by CI, I don't see how either of these things could be caused
by this patch set.

Jim

> 
> Results at /archive/results/CI_IGT_test/Patchwork_1864/
> 
> dc5380b5263ebb0bf251bb09db542585702b528b drm-intel-nightly: 
> 2016y-04m-11d-19h-43m-10s UTC integration manifest
> e9b4dd341189637119d15df79a72a9a1f53c62fa drm/i915/dp/mst: Fix MST logic in 
> intel_dp_long_pulse()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI-ping 12/15] drm/i915: Force ringbuffers to not be at offset 0

2016-04-12 Thread Chris Wilson
For reasons unknown Sandybridge GT1 (at least) will eventually hang when
it encounters a ring wraparound at offset 0. The test case that
reproduces the bug reliably forces a large number of interrupted context
switches, thereby causing very frequent ring wraparounds, but there are
similar bug reports in the wild with the same symptoms, seqno writes
stop just before the wrap and the ringbuffer at address 0. It is also
timing crucial, but adding various delays hasn't helped pinpoint where
the window lies.

Whether the fault is restricted to the ringbuffer itself or the GTT
addressing is unclear, but moving the ringbuffer fixes all the hangs I
have been able to reproduce.

References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262
Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1
Signed-off-by: Chris Wilson 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8391382431b2..904a8a276f6a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2096,10 +2096,12 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj = ringbuf->obj;
+   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+   unsigned flags = PIN_OFFSET_BIAS | 4096;
int ret;
 
if (HAS_LLC(dev_priv) && !obj->stolen) {
-   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, 0);
+   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, flags);
if (ret)
return ret;
 
@@ -2113,7 +2115,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
goto err_unpin;
}
} else {
-   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
+   ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+   flags | PIN_MAPPABLE);
if (ret)
return ret;
 
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 09/15] drm/i915: Prevent leaking of -EIO from i915_wait_request()

2016-04-12 Thread Chris Wilson
Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.

If the we reset the GPU or have detected a hang and wish to reset the
GPU, the request is forcibly complete and the wait broken. Currently, we
report either -EAGAIN or -EIO in order for the caller to retreat and
restart the wait (if appropriate) after dropping and then reacquiring
the struct_mutex (essential to allow the GPU reset to proceed). However,
if we take the view that the request is complete (no further work will
be done on it by the GPU because it is dead and soon to be reset), then
we can proceed with the task at hand and then drop the struct_mutex
allowing the reset to occur. This transfers the burden of checking
whether it is safe to proceed to the caller, which in all but one
instance it is safe - completely eliminating the source of all spurious
-EIO.

Of note, we only have two API entry points where we expect that
userspace can observe an EIO. First is when submitting an execbuf, if
the GPU is terminally wedged, then the operation cannot succeed and an
-EIO is reported. Secondly, existing userspace uses the throttle ioctl
to detect an already wedged GPU before starting using HW acceleration
(or to confirm that the GPU is wedged after an error condition). So if
the GPU is wedged when the user calls throttle, also report -EIO.

v2: Split more carefully the change to i915_wait_request() and assorted
ABI from the reset handling.
v3: Add a couple of WARN_ON(EIO) to the interruptible modesetting code
so that we don't start to leak EIO there in future (and break our hang
resistant modesetting).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 --
 drivers/gpu/drm/i915/i915_gem.c | 44 -
 drivers/gpu/drm/i915/i915_gem_userptr.c |  6 ++---
 drivers/gpu/drm/i915/intel_display.c| 13 +-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  3 +--
 6 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8821d38c07ed..061ecc43d935 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3083,8 +3083,6 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine);
 
 bool i915_gem_retire_requests(struct drm_device *dev);
 void i915_gem_retire_requests_ring(struct intel_engine_cs *engine);
-int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
- bool interruptible);
 
 static inline u32 i915_reset_counter(struct i915_gpu_error *error)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01cdebfea27a..765efa88db32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -206,11 +206,10 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object 
*obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
+   if (WARN_ON(ret)) {
/* In the event of a disaster, abandon all caches and
 * hope for the best.
 */
-   WARN_ON(ret != -EIO);
obj->base.read_domains = obj->base.write_domain = 
I915_GEM_DOMAIN_CPU;
}
 
@@ -1105,15 +1104,13 @@ put_rpm:
return ret;
 }
 
-int
-i915_gem_check_wedge(struct i915_gpu_error *error,
-bool interruptible)
+static int
+i915_gem_check_wedge(unsigned reset_counter, bool interruptible)
 {
-   if (i915_reset_in_progress_or_wedged(error)) {
-   /* Recovery complete, but the reset failed ... */
-   if (i915_terminally_wedged(error))
-   return -EIO;
+   if (__i915_terminally_wedged(reset_counter))
+   return -EIO;
 
+   if (__i915_reset_in_progress(reset_counter)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1287,13 +1284,14 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
prepare_to_wait(>irq_queue, , state);
 
/* We need to check whether any gpu reset happened in between
-* the caller grabbing the seqno and now ... */
+* the request being submitted and now. If a reset has occurred,
+* the request is effectively complete (we either are in the
+* process of or have discarded the rendering and completely
+* reset the GPU. The results of the request are lost and we
+* are free to continue 

[Intel-gfx] [CI-ping 10/15] drm/i915: Suppress error message when GPU resets are disabled

2016-04-12 Thread Chris Wilson
If we do not have lowlevel support for reseting the GPU, or if the user
has explicitly disabled reseting the device, the failure is expected.
Since it is an expected failure, we should be using a lower priority
message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just
emit the expected failure as a DEBUG message.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 310dc61817fa..18eb3e698763 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -917,7 +917,10 @@ int i915_reset(struct drm_device *dev)
pr_notice("drm/i915: Resetting chip after gpu hang\n");
 
if (ret) {
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   if (ret != -ENODEV)
+   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   else
+   DRM_DEBUG_DRIVER("GPU reset disabled\n");
goto error;
}
 
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

2016-04-12 Thread Lyude
I'm going to take back the NAK on this, apparently this hotplugging
issue has been around longer then this patchset.

Reviewed-by: Lyude 


On Tue, 2016-04-12 at 10:11 +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-04-11 at 10:11 -0700, Jim Bride wrote:
> > 
> > In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> > some
> > much needed clean-up was done, but unfortunately part of the change
> > broke DP MST.  The real issue was setting the connector state to
> > disconnected in the MST case, which is good, but the code then
> > (after
> > a goto) checks if the connector state is not connected and shuts
> > down
> > MST if this is the case, which is bad.  With this change both SST
> > and
> > MST seem to be happy.
> > 
> > v2: Add removed check further up in the function to be sure that
> > MST
> > is shut down when we lose the link. (Ander)
> > 
> > Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> > cc: Sivakumar Thulasimani 
> > cc: Shubhangi Shrivastava 
> > cc: Ander Conselvan de Oliveira 
> > cc: Nathan D Ciobanu 
> > Signed-off-by: Jim Bride 
> Reviewed-by: Ander Conselvan de Oliveira 
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 24 +++-
> >  1 file changed, 11 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index da0c3d2..31b222a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4608,6 +4608,15 @@ intel_dp_long_pulse(struct intel_connector
> > *intel_connector)
> >     intel_dp->compliance_test_type = 0;
> >     intel_dp->compliance_test_data = 0;
> >  
> > +   if (intel_dp->is_mst) {
> > +   DRM_DEBUG_KMS("MST device may have
> > disappeared %d vs
> > %d\n",
> > +     intel_dp->is_mst,
> > +     intel_dp-
> > >mst_mgr.mst_state);
> > +   intel_dp->is_mst = false;
> > +   drm_dp_mst_topology_mgr_set_mst(_dp-
> > >mst_mgr,
> > +   intel_dp-
> > >is_mst);
> > +   }
> > +
> >     goto out;
> >     }
> >  
> > @@ -4665,20 +4674,9 @@ intel_dp_long_pulse(struct intel_connector
> > *intel_connector)
> >     }
> >  
> >  out:
> > -   if (status != connector_status_connected) {
> > +   if ((status != connector_status_connected) &&
> > +   (intel_dp->is_mst == false))
> >     intel_dp_unset_edid(intel_dp);
> > -   /*
> > -    * If we were in MST mode, and device is not
> > there,
> > -    * get out of MST mode
> > -    */
> > -   if (intel_dp->is_mst) {
> > -   DRM_DEBUG_KMS("MST device may have
> > disappeared %d vs
> > %d\n",
> > -     intel_dp->is_mst, intel_dp
> > ->mst_mgr.mst_state);
> > -   intel_dp->is_mst = false;
> > -   drm_dp_mst_topology_mgr_set_mst(_dp-
> > >mst_mgr,
> > -   intel_dp-
> > >is_mst);
> > -   }
> > -   }
> >  
> >     intel_display_power_put(to_i915(dev), power_domain);
> >     return;
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Cheers,
Lyude

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


[Intel-gfx] [CI-ping 08/15] drm/i915: Simplify reset_counter handling during atomic modesetting

2016-04-12 Thread Chris Wilson
Now that the reset_counter is stored on the request, we can rearrange
the code to handle reading the counter versus waiting during the atomic
modesetting for readibility (by deleting the hairiest of codes).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8763d953f1df..6500f77fc78e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13424,9 +13424,9 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
return ret;
 
ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (!ret && !async && 
!i915_reset_in_progress_or_wedged(_priv->gpu_error)) {
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>struct_mutex);
 
+   if (!ret && !async) {
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
@@ -13440,19 +13440,15 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
/* Swallow -EIO errors to allow updates during hw 
lockup. */
if (ret == -EIO)
ret = 0;
-
-   if (ret)
+   if (ret) {
+   mutex_lock(>struct_mutex);
+   drm_atomic_helper_cleanup_planes(dev, state);
+   mutex_unlock(>struct_mutex);
break;
+   }
}
-
-   if (!ret)
-   return 0;
-
-   mutex_lock(>struct_mutex);
-   drm_atomic_helper_cleanup_planes(dev, state);
}
 
-   mutex_unlock(>struct_mutex);
return ret;
 }
 
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 11/15] drm/i915: Prevent machine death on Ivybridge context switching

2016-04-12 Thread Chris Wilson
Two concurrent writes into the same register cacheline has the chance of
killing the machine on Ivybridge and other gen7. This includes LRI
emitted from the command parser.  The MI_SET_CONTEXT itself serves as
serialising barrier and prevents the pair of register writes in the first
packet from triggering the fault.  However, if a second switch-context
immediately occurs then we may have two adjacent blocks of LRI to the
same registers which may then trigger the hang. To counteract this we
need to insert a delay after the second register write using SRM.

This is easiest to reproduce with something like
igt/gem_ctx_switch/interruptible that triggers back-to-back context
switches (with no operations in between them in the command stream,
which requires the execbuf operation to be interrupted after the
MI_SET_CONTEXT) but can be observed sporadically elsewhere when running
interruptible igt. No reports from the wild though, so it must be of low
enough frequency that no one has correlated the random machine freezes
with i915.ko

The issue was introduced with
commit 2c550183476dfa25641309ae9a28d30feed14379 [v3.19]
Author: Chris Wilson 
Date:   Tue Dec 16 10:02:27 2014 +

drm/i915: Disable PSMI sleep messages on all rings around context switches

Testcase: igt/gem_ctx_switch/render-interruptible #ivb
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_context.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index fe580cb9501a..e5ad7b21e356 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -539,7 +539,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
len = 4;
if (INTEL_INFO(engine->dev)->gen >= 7)
-   len += 2 + (num_rings ? 4*num_rings + 2 : 0);
+   len += 2 + (num_rings ? 4*num_rings + 6 : 0);
 
ret = intel_ring_begin(req, len);
if (ret)
@@ -579,6 +579,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
if (INTEL_INFO(engine->dev)->gen >= 7) {
if (num_rings) {
struct intel_engine_cs *signaller;
+   i915_reg_t last_reg = {}; /* keep gcc quiet */
 
intel_ring_emit(engine,
MI_LOAD_REGISTER_IMM(num_rings));
@@ -586,11 +587,19 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
if (signaller == engine)
continue;
 
-   intel_ring_emit_reg(engine,
-   
RING_PSMI_CTL(signaller->mmio_base));
+   last_reg = RING_PSMI_CTL(signaller->mmio_base);
+   intel_ring_emit_reg(engine, last_reg);
intel_ring_emit(engine,

_MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
}
+
+   /* Insert a delay before the next switch! */
+   intel_ring_emit(engine,
+   MI_STORE_REGISTER_MEM |
+   MI_SRM_LRM_GLOBAL_GTT);
+   intel_ring_emit_reg(engine, last_reg);
+   intel_ring_emit(engine, engine->scratch.gtt_offset);
+   intel_ring_emit(engine, MI_NOOP);
}
intel_ring_emit(engine, MI_ARB_ON_OFF | MI_ARB_ENABLE);
}
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 01/15] drm/i915: Force clean compilation with -Werror

2016-04-12 Thread Chris Wilson
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the patch.)

v2: Kick off a new "Debugging" submenu for i915.ko

At this point, we applied it to the kernel and promptly kicked it out
again as it broke buildbots (due to a compiler warning on 32bits):

commit 908d759b210effb33d927a8cb6603a16448474e4
Author: Daniel Vetter 
Date:   Tue May 26 07:46:21 2015 +0200

Revert "drm/i915: Force clean compilation with -Werror"

v3: Avoid enabling -Werror for allyesconfig/allmodconfig builds, using
COMPILE_TEST as a suitable proxy suggested by Andrew Morton. (Damien)
Only make the option available for EXPERT to reinforce that the option
should not be casually enabled.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Damien Lespiau 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Kconfig.debug | 17 +
 drivers/gpu/drm/i915/Makefile  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 649a562ddf17..61485c8ba3a8 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -1,3 +1,20 @@
+config DRM_I915_WERROR
+bool "Force GCC to throw an error instead of a warning when compiling"
+# As this may inadvertently break the build, only allow the user
+# to shoot oneself in the foot iff they aim really hard
+depends on EXPERT
+# We use the dependency on !COMPILE_TEST to not be enabled in
+# allmodconfig or allyesconfig configurations
+depends on !COMPILE_TEST
+default n
+help
+  Add -Werror to the build flags for (and only for) i915.ko.
+  Do not enable this unless you are writing code for the i915.ko 
module.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
 config DRM_I915_DEBUG
 bool "Enable additional driver debugging"
 depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b0cbc2..0b88ba0f3c1f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
+subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
+
 # Please keep these build lists sorted!
 
 # core driver code
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 07/15] drm/i915: Store the reset counter when constructing a request

2016-04-12 Thread Chris Wilson
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to transfer those waits to a central dispatcher for all
waiters and all requests.

PS: With per-engine resets, we obviously cannot assume a global reset
epoch for the requests - a per-engine epoch makes the most sense. The
challenge then is how to handle checking in the waiter for when to break
the wait, as the fine-grained reset may also want to requeue the
request (i.e. the assumption that just because the epoch changes the
request is completed may be broken - or we just avoid breaking that
assumption with the fine-grained resets).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 40 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c |  5 +
 drivers/gpu/drm/i915/intel_display.c|  7 +-
 drivers/gpu/drm/i915/intel_lrc.c|  7 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 -
 6 files changed, 16 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1da57d309618..8821d38c07ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2250,6 +2250,7 @@ struct drm_i915_gem_request {
/** On Which ring this request was generated */
struct drm_i915_private *i915;
struct intel_engine_cs *engine;
+   unsigned reset_counter;
 
 /** GEM sequence number associated with the previous request,
  * when the HWS breadcrumb is equal to this the GPU is processing
@@ -3155,7 +3156,6 @@ void __i915_add_request(struct drm_i915_gem_request *req,
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, NULL, false)
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f1e91cf8cbf9..01cdebfea27a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1213,7 +1213,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
 /**
  * __i915_wait_request - wait until execution of request has finished
  * @req: duh!
- * @reset_counter: reset sequence associated with the given request
  * @interruptible: do an interruptible wait (normally yes)
  * @timeout: in - how long to wait (NULL forever); out - how much time 
remaining
  *
@@ -1228,7 +1227,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
  * errno with remaining time filled in timeout argument.
  */
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps)
@@ -1290,7 +1288,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != i915_reset_counter(_priv->gpu_error)) {
+   if (req->reset_counter != 
i915_reset_counter(_priv->gpu_error)) {
/* ... but upgrade the -EAGAIN to an -EIO if the gpu
 * is truely gone. */
ret = i915_gem_check_wedge(_priv->gpu_error, 
interruptible);
@@ -1460,13 +1458,7 @@ i915_wait_request(struct drm_i915_gem_request *req)
 
BUG_ON(!mutex_is_locked(>struct_mutex));
 
-   ret = i915_gem_check_wedge(_priv->gpu_error, interruptible);
-   if (ret)
-   return ret;
-
-   ret = __i915_wait_request(req,
- i915_reset_counter(_priv->gpu_error),
- interruptible, NULL, NULL);
+   ret = __i915_wait_request(req, interruptible, NULL, NULL);
if (ret)
return ret;
 
@@ -1541,7 +1533,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   unsigned reset_counter;
int ret, i, n = 0;
 
BUG_ON(!mutex_is_locked(>struct_mutex));
@@ -1550,12 +1541,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
if (!obj->active)

[Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

2016-04-12 Thread Chris Wilson
Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the request and make
references to the pending request. If we do so and then cancel that
request, external objects then point to the deleted request leading to
both graphical and memory corruption.

The easiest example is to consider object/VMA tracking. When we mark an
object as active in a request, we store a pointer to this, the most
recent request, in the object. Then we want to free that object, we wait
for the most recent request to be idle before proceeding (otherwise the
hardware will write to pages now owned by the system, or we will attempt
to read from those pages before the hardware is finished writing). If
the request was cancelled instead, that wait completes immediately. As a
result, all requests must be committed and not cancelled if the external
state is unknown.

All that remains of i915_gem_request_cancel() users are just a couple of
extremely unlikely allocation failures, so remove the API entirely.

A consequence of committing all incomplete requests is that we generate
excess breadcrumbs and fill the ring much more often with dummy work. We
have completely undone the outstanding_last_seqno optimisation.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_gem.c| 50 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++--
 drivers/gpu/drm/i915/intel_display.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
 drivers/gpu/drm/i915/intel_overlay.c   |  8 ++---
 6 files changed, 30 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 061ecc43d935..de84dd7be971 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2331,7 +2331,6 @@ struct drm_i915_gem_request {
 struct drm_i915_gem_request * __must_check
 i915_gem_request_alloc(struct intel_engine_cs *engine,
   struct intel_context *ctx);
-void i915_gem_request_cancel(struct drm_i915_gem_request *req);
 void i915_gem_request_free(struct kref *req_ref);
 int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
   struct drm_file *file);
@@ -2883,7 +2882,6 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
 struct drm_file *file_priv);
 void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct drm_i915_gem_request *req);
-void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params 
*params);
 int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b6879d43dd74..c6f09e7839ea 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2785,7 +2785,8 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
 * fully prepared. Thus it can be cleaned up using the proper
 * free code.
 */
-   i915_gem_request_cancel(req);
+   intel_ring_reserved_space_cancel(req->ringbuf);
+   i915_gem_request_unreference(req);
return ret;
}
 
@@ -2822,13 +2823,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
return err ? ERR_PTR(err) : req;
 }
 
-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-   intel_ring_reserved_space_cancel(req->ringbuf);
-
-   i915_gem_request_unreference(req);
-}
-
 struct drm_i915_gem_request *
 i915_gem_find_active_request(struct intel_engine_cs *engine)
 {
@@ -3438,12 +3432,9 @@ int i915_gpu_idle(struct drm_device *dev)
return PTR_ERR(req);
 
ret = i915_switch_context(req);
-   if (ret) {
-   i915_gem_request_cancel(req);
-   return ret;
-   }
-
i915_add_request_no_flush(req);
+   if (ret)
+   return ret;
}
 
ret = intel_engine_idle(engine);
@@ -4943,34 +4934,33 @@ i915_gem_init_hw(struct drm_device *dev)
req = i915_gem_request_alloc(engine, NULL);
if (IS_ERR(req)) {
ret = 

[Intel-gfx] [CI-ping 05/15] drm/i915: Simplify checking of GPU reset_counter in display pageflips

2016-04-12 Thread Chris Wilson
If we, when we store the reset_counter for the operation, we ensure that
it is not in a wedged or in the middle of a reset, we can then assert that
if any reset occurs the reset_counter must change. Later we can just
compare the operation's reset epoch against the current counter to see
if we need to abort the operation (to handle the hang).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0bb78009379b..ec11c7ef08a2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3198,14 +3198,12 @@ void intel_finish_reset(struct drm_device *dev)
 static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
unsigned reset_counter;
bool pending;
 
-   reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (intel_crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   reset_counter = i915_reset_counter(_i915(dev)->gpu_error);
+   if (intel_crtc->reset_counter != reset_counter)
return false;
 
spin_lock_irq(>event_lock);
@@ -10913,8 +10911,7 @@ static bool page_flip_finished(struct intel_crtc *crtc)
unsigned reset_counter;
 
reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   if (crtc->reset_counter != reset_counter)
return true;
 
/*
@@ -11576,8 +11573,13 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup;
 
-   atomic_inc(_crtc->unpin_work_count);
intel_crtc->reset_counter = i915_reset_counter(_priv->gpu_error);
+   if (__i915_reset_in_progress_or_wedged(intel_crtc->reset_counter)) {
+   ret = -EIO;
+   goto cleanup;
+   }
+
+   atomic_inc(_crtc->unpin_work_count);
 
if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
work->flip_count = I915_READ(PIPE_FLIPCOUNT_G4X(pipe)) + 1;
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 06/15] drm/i915: Tighten reset_counter for reset status

2016-04-12 Thread Chris Wilson
In the reset_counter, we use two bits to track a GPU hang and reset. The
low bit is a "reset-in-progress" flag that we set to signal when we need
to break waiters in order for the recovery task to grab the mutex. As
soon as the recovery task has the mutex, we can clear that flag (which
we do by incrementing the reset_counter thereby incrementing the gobal
reset epoch). By clearing that flag when the recovery task holds the
struct_mutex, we can forgo a second flag that simply tells GEM to ignore
the "reset-in-progress" flag.

The second flag we store in the reset_counter is whether the
reset failed and we consider the GPU terminally wedged. Whilst this flag
is set, all access to the GPU (at least through GEM rather than direct mmio
access) is verboten.

PS: Fun is in store, as in the future we want to move from a global
reset epoch to a per-engine reset engine with request recovery.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.c | 39 ++---
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/i915_gem.c | 27 +
 drivers/gpu/drm/i915/i915_irq.c | 21 ++--
 5 files changed, 36 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f1470834e874..1d5c2e23c47e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4721,7 +4721,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = i915_reset_counter(_priv->gpu_error);
+   *val = i915_terminally_wedged(_priv->gpu_error);
 
return 0;
 }
@@ -4740,7 +4740,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
+   if (i915_reset_in_progress(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79c85a6..310dc61817fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -880,23 +880,32 @@ int i915_resume_switcheroo(struct drm_device *dev)
 int i915_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   bool simulated;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   unsigned reset_counter;
int ret;
 
intel_reset_gt_powersave(dev);
 
mutex_lock(>struct_mutex);
 
-   i915_gem_reset(dev);
+   /* Clear any previous failed attempts at recovery. Time to try again. */
+   atomic_andnot(I915_WEDGED, >reset_counter);
 
-   simulated = dev_priv->gpu_error.stop_rings != 0;
+   /* Clear the reset-in-progress flag and increment the reset epoch. */
+   reset_counter = atomic_inc_return(>reset_counter);
+   if (WARN_ON(__i915_reset_in_progress(reset_counter))) {
+   ret = -EIO;
+   goto error;
+   }
+
+   i915_gem_reset(dev);
 
ret = intel_gpu_reset(dev, ALL_ENGINES);
 
/* Also reset the gpu hangman. */
-   if (simulated) {
+   if (error->stop_rings != 0) {
DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   dev_priv->gpu_error.stop_rings = 0;
+   error->stop_rings = 0;
if (ret == -ENODEV) {
DRM_INFO("Reset not implemented, but ignoring "
 "error for simulated gpu hangs\n");
@@ -909,8 +918,7 @@ int i915_reset(struct drm_device *dev)
 
if (ret) {
DRM_ERROR("Failed to reset chip: %i\n", ret);
-   mutex_unlock(>struct_mutex);
-   return ret;
+   goto error;
}
 
intel_overlay_reset(dev_priv);
@@ -929,20 +937,14 @@ int i915_reset(struct drm_device *dev)
 * was running at the time of the reset (i.e. we weren't VT
 * switched away).
 */
-
-   /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset 
*/
-   dev_priv->gpu_error.reload_in_reset = true;
-
ret = i915_gem_init_hw(dev);
-
-   dev_priv->gpu_error.reload_in_reset = false;
-
-   mutex_unlock(>struct_mutex);
if (ret) {
DRM_ERROR("Failed hw init on reset %d\n", ret);
-   return ret;
+   goto error;
}
 
+   mutex_unlock(>struct_mutex);
+
/*
 * rps/rc6 re-init is necessary to restore state lost after the
 * reset and the re-install of gt irqs. Skip for ironlake per
@@ -953,6 +955,11 @@ int i915_reset(struct drm_device *dev)

[Intel-gfx] [CI-ping 02/15] drm/i915: Disentangle i915_drv.h includes

2016-04-12 Thread Chris Wilson
Separate out the layers of includes (linux, drm, intel, i915) so that it
is a little easier to order our definitions between our multiple
reentrant headers. A couple of headers needed fixes to make them more
standalone (forgotten includes, forward declarations etc).

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 29 +
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 drivers/gpu/drm/i915/intel_lrc.h |  2 ++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5c91b01194f..f058f7d68929 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -33,27 +33,32 @@
 #include 
 #include 
 
-#include 
-#include "i915_params.h"
-#include "i915_reg.h"
-#include "intel_bios.h"
-#include "intel_ringbuffer.h"
-#include "intel_lrc.h"
-#include "i915_gem_gtt.h"
-#include "i915_gem_render_state.h"
 #include 
 #include 
 #include 
-#include 
-#include  /* for struct drm_dma_handle */
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "intel_guc.h"
+#include 
+
+#include 
+#include 
+#include  /* for struct drm_dma_handle */
+#include 
+
+#include "i915_params.h"
+#include "i915_reg.h"
+
+#include "intel_bios.h"
 #include "intel_dpll_mgr.h"
+#include "intel_guc.h"
+#include "intel_lrc.h"
+#include "intel_ringbuffer.h"
+
+#include "i915_gem_gtt.h"
+#include "i915_gem_render_state.h"
 
 /* General customization:
  */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 73002e901ff2..3bb85b127cb0 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -27,6 +27,8 @@
 #include "intel_guc_fwif.h"
 #include "i915_guc_reg.h"
 
+struct drm_i915_gem_request;
+
 struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
struct intel_context *owner;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 8de1ea536ad4..f82ea3f59211 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -24,6 +24,8 @@
 #ifndef _INTEL_LRC_H_
 #define _INTEL_LRC_H_
 
+#include "intel_ringbuffer.h"
+
 #define GEN8_LR_CONTEXT_ALIGN 4096
 
 /* Execlists regs */
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 13/15] drm/i915: Move the mb() following release-mmap into release-mmap

2016-04-12 Thread Chris Wilson
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release_mmap().

v2: Reduce the mb() into a wmb() following the revoke.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: "Goel, Akash" 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 765efa88db32..b6879d43dd74 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1936,11 +1936,21 @@ out:
 void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
+   /* Serialisation between user GTT access and our code depends upon
+* revoking the CPU's PTE whilst the mutex is held. The next user
+* pagefault then has to wait until we release the mutex.
+*/
+   lockdep_assert_held(>base.dev->struct_mutex);
+
if (!obj->fault_mappable)
return;
 
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
+
+   /* Ensure that the CPU's PTE are revoked before we return */
+   wmb();
+
obj->fault_mappable = false;
 }
 
@@ -3324,9 +3334,6 @@ static void i915_gem_object_finish_gtt(struct 
drm_i915_gem_object *obj)
if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
return;
 
-   /* Wait for any direct GTT access to complete */
-   mb();
-
old_read_domains = obj->base.read_domains;
old_write_domain = obj->base.write_domain;
 
-- 
2.8.0.rc3

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


[Intel-gfx] [CI-ping 03/15] drm/i915: Add GEM debugging Kconfig option

2016-04-12 Thread Chris Wilson
Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to enable - with the usual
caveats of not enabling unless explicitly requested.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Kconfig.debug | 12 
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c| 12 +---
 drivers/gpu/drm/i915/i915_gem.h| 34 ++
 4 files changed, 52 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem.h

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 61485c8ba3a8..8f404103341d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -27,3 +27,15 @@ config DRM_I915_DEBUG
 
   If in doubt, say "N".
 
+config DRM_I915_DEBUG_GEM
+bool "Insert extra checks into the GEM internals"
+default n
+depends on DRM_I915_WERROR
+help
+  Enable extra sanity checks (including BUGs) along the GEM driver
+  paths that may slow the system down and if hit hang the machine.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f058f7d68929..452f64acd7de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,6 +57,7 @@
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
+#include "i915_gem.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_render_state.h"
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b37ffea8b458..00bed3b79793 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 
-#define RQ_BUG_ON(expr)
-
 static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object 
*obj);
 static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object 
*obj);
 static void
@@ -1521,7 +1519,7 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
 
i915_gem_object_retire__read(obj, i);
}
-   RQ_BUG_ON(obj->active);
+   GEM_BUG_ON(obj->active);
}
 
return 0;
@@ -2473,8 +2471,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 static void
 i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
 {
-   RQ_BUG_ON(obj->last_write_req == NULL);
-   RQ_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
+   GEM_BUG_ON(obj->last_write_req == NULL);
+   GEM_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
 
i915_gem_request_assign(>last_write_req, NULL);
intel_fb_obj_flush(obj, true, ORIGIN_CS);
@@ -2485,8 +2483,8 @@ i915_gem_object_retire__read(struct drm_i915_gem_object 
*obj, int ring)
 {
struct i915_vma *vma;
 
-   RQ_BUG_ON(obj->last_read_req[ring] == NULL);
-   RQ_BUG_ON(!(obj->active & (1 << ring)));
+   GEM_BUG_ON(obj->last_read_req[ring] == NULL);
+   GEM_BUG_ON(!(obj->active & (1 << ring)));
 
list_del_init(>engine_list[ring]);
i915_gem_request_assign(>last_read_req[ring], NULL);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
new file mode 100644
index ..8292e797d9b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -0,0 +1,34 @@
+/*
+ * 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.
+ *
+ */
+
+#ifndef __I915_GEM_H__
+#define 

[Intel-gfx] [CI-ping 04/15] drm/i915: Hide the atomic_read(reset_counter) behind a helper

2016-04-12 Thread Chris Wilson
This is principally a little bit of syntatic sugar to hide the
atomic_read()s throughout the code to retrieve the current reset_counter.
It also provides the other utility functions to check the reset state on the
already read reset_counter, so that (in later patches) we can read it once
and do multiple tests rather than risk the value changing between tests.

v2: Be more strict on converting existing i915_reset_in_progress() over to
the more verbose i915_reset_in_progress_or_wedged().

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h | 32 
 drivers/gpu/drm/i915/i915_gem.c | 16 
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 18 +++---
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  7 ---
 7 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2d11b4948a74..f1470834e874 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4721,7 +4721,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = atomic_read(_priv->gpu_error.reset_counter);
+   *val = i915_reset_counter(_priv->gpu_error);
 
return 0;
 }
@@ -4740,7 +4740,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress(_priv->gpu_error))
+   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 452f64acd7de..1053cb3f9e7b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3088,20 +3088,44 @@ void i915_gem_retire_requests_ring(struct 
intel_engine_cs *engine);
 int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
  bool interruptible);
 
+static inline u32 i915_reset_counter(struct i915_gpu_error *error)
+{
+   return atomic_read(>reset_counter);
+}
+
+static inline bool __i915_reset_in_progress(u32 reset)
+{
+   return unlikely(reset & I915_RESET_IN_PROGRESS_FLAG);
+}
+
+static inline bool __i915_reset_in_progress_or_wedged(u32 reset)
+{
+   return unlikely(reset & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+}
+
+static inline bool __i915_terminally_wedged(u32 reset)
+{
+   return unlikely(reset & I915_WEDGED);
+}
+
 static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
 {
-   return unlikely(atomic_read(>reset_counter)
-   & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+   return __i915_reset_in_progress(i915_reset_counter(error));
+}
+
+static inline bool i915_reset_in_progress_or_wedged(struct i915_gpu_error 
*error)
+{
+   return __i915_reset_in_progress_or_wedged(i915_reset_counter(error));
 }
 
 static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
 {
-   return atomic_read(>reset_counter) & I915_WEDGED;
+   return __i915_terminally_wedged(i915_reset_counter(error));
 }
 
 static inline u32 i915_reset_count(struct i915_gpu_error *error)
 {
-   return ((atomic_read(>reset_counter) & ~I915_WEDGED) + 1) / 2;
+   return ((i915_reset_counter(error) & ~I915_WEDGED) + 1) / 2;
 }
 
 static inline bool i915_stop_ring_allow_ban(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 00bed3b79793..ecbe56810796 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -83,7 +83,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
 {
int ret;
 
-#define EXIT_COND (!i915_reset_in_progress(error) || \
+#define EXIT_COND (!i915_reset_in_progress_or_wedged(error) || \
   i915_terminally_wedged(error))
if (EXIT_COND)
return 0;
@@ -1112,7 +1112,7 @@ int
 i915_gem_check_wedge(struct i915_gpu_error *error,
 bool interruptible)
 {
-   if (i915_reset_in_progress(error)) {
+   if (i915_reset_in_progress_or_wedged(error)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1299,7 +1299,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != 

[Intel-gfx] [CI-ping 14/15] drm/i915: Reorganise legacy context switch to cope with late failure

2016-04-12 Thread Chris Wilson
After mi_set_context() succeeds, we need to update the state of the
engine's last_context. This ensures that we hold a pin on the context
whilst the hardware may write to it. However, since we didn't complete
the post-switch setup of the context, we need to force the subsequent
use of the same context to complete the setup (which means updating
should_skip_switch()).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 215 
 1 file changed, 109 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index e5ad7b21e356..361959b1d53a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -609,50 +609,40 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
return ret;
 }
 
-static inline bool should_skip_switch(struct intel_engine_cs *engine,
- struct intel_context *from,
+static inline bool should_skip_switch(struct intel_context *from,
  struct intel_context *to)
 {
if (to->remap_slice)
return false;
 
-   if (to->ppgtt && from == to &&
-   !(intel_engine_flag(engine) & to->ppgtt->pd_dirty_rings))
-   return true;
+   if (!to->legacy_hw_ctx.initialized)
+   return false;
 
-   return false;
+   if (to->ppgtt && to->ppgtt->pd_dirty_rings & (1 << RCS))
+   return false;
+
+   return to == from;
 }
 
 static bool
-needs_pd_load_pre(struct intel_engine_cs *engine, struct intel_context *to)
+needs_pd_load_pre(struct intel_context *to)
 {
-   struct drm_i915_private *dev_priv = engine->dev->dev_private;
-
if (!to->ppgtt)
return false;
 
-   if (INTEL_INFO(engine->dev)->gen < 8)
-   return true;
-
-   if (engine != _priv->engine[RCS])
+   if (INTEL_INFO(to->i915)->gen < 8)
return true;
 
return false;
 }
 
 static bool
-needs_pd_load_post(struct intel_engine_cs *engine, struct intel_context *to,
-  u32 hw_flags)
+needs_pd_load_post(struct intel_context *to, u32 hw_flags)
 {
-   struct drm_i915_private *dev_priv = engine->dev->dev_private;
-
if (!to->ppgtt)
return false;
 
-   if (!IS_GEN8(engine->dev))
-   return false;
-
-   if (engine != _priv->engine[RCS])
+   if (!IS_GEN8(to->i915))
return false;
 
if (hw_flags & MI_RESTORE_INHIBIT)
@@ -661,60 +651,33 @@ needs_pd_load_post(struct intel_engine_cs *engine, struct 
intel_context *to,
return false;
 }
 
-static int do_switch(struct drm_i915_gem_request *req)
+static int do_rcs_switch(struct drm_i915_gem_request *req)
 {
struct intel_context *to = req->ctx;
struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = req->i915;
-   struct intel_context *from = engine->last_context;
-   u32 hw_flags = 0;
-   bool uninitialized = false;
+   struct intel_context *from;
+   u32 hw_flags;
int ret, i;
 
-   if (from != NULL && engine == _priv->engine[RCS]) {
-   BUG_ON(from->legacy_hw_ctx.rcs_state == NULL);
-   BUG_ON(!i915_gem_obj_is_pinned(from->legacy_hw_ctx.rcs_state));
-   }
-
-   if (should_skip_switch(engine, from, to))
+   if (should_skip_switch(engine->last_context, to))
return 0;
 
/* Trying to pin first makes error handling easier. */
-   if (engine == _priv->engine[RCS]) {
-   ret = i915_gem_obj_ggtt_pin(to->legacy_hw_ctx.rcs_state,
-   get_context_alignment(engine->dev),
-   0);
-   if (ret)
-   return ret;
-   }
+   ret = i915_gem_obj_ggtt_pin(to->legacy_hw_ctx.rcs_state,
+   get_context_alignment(engine->dev),
+   0);
+   if (ret)
+   return ret;
 
/*
 * Pin can switch back to the default context if we end up calling into
 * evict_everything - as a last ditch gtt defrag effort that also
 * switches to the default context. Hence we need to reload from here.
+*
+* XXX: Doing so is painfully broken!
 */
from = engine->last_context;
 
-   if (needs_pd_load_pre(engine, to)) {
-   /* Older GENs and non render rings still want the load first,
-* "PP_DCLV followed by PP_DIR_BASE register through Load
-* Register Immediate commands in Ring Buffer before submitting
-* a context."*/
-   trace_switch_mm(engine, to);
-   ret = 

Re: [Intel-gfx] [PATCH 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 08:08:01PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 12, 2016 at 03:04:10PM +0300, Imre Deak wrote:
> > On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Enable the unclaimd register detection stuff on vlv/chv since we've
> > > now
> > > fixed the known problems during suspend.
> > > 
> > > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Reviewed-by: Imre Deak 
> 
> Entire series pushed to dinq. Thanks for the reviews.

Nice work on getting mmio_debug out of its little rats nest!
-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 5/5] drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI,
and just trying to frob the display timings to include borders results
in a corrupted picture. So reject the 'Center' scaling mode on GMCH
platforms for eDP and DSI.

TODO: Should really filter out the unsupported modes from the prop,
but that would be fairly invasive since the prop is now created and
stored by drm core. So leave it for a rainy day.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c  | 5 +
 drivers/gpu/drm/i915/intel_dsi.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7523558190d1..61ee22664ee7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4821,6 +4821,11 @@ intel_dp_set_property(struct drm_connector *connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+   if (HAS_GMCH_DISPLAY(dev_priv) &&
+   val == DRM_MODE_SCALE_CENTER) {
+   DRM_DEBUG_KMS("centering not supported\n");
+   return -EINVAL;
+   }
 
if (intel_connector->panel.fitting_mode == val) {
/* the eDP scaling property is not changed */
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index d94193aa6ffc..a3cb89ee7fd0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1205,6 +1205,11 @@ static int intel_dsi_set_property(struct drm_connector 
*connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+   if (HAS_GMCH_DISPLAY(dev) &&
+   val == DRM_MODE_SCALE_CENTER) {
+   DRM_DEBUG_KMS("centering not supported\n");
+   return -EINVAL;
+   }
 
if (intel_connector->panel.fitting_mode == val)
return 0;
-- 
2.7.4

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


[Intel-gfx] [PATCH 5/5] drm-i915: Add sys IPS toggle interface

2016-04-12 Thread Alexandra Yates
This interface allows enabling/disabling of IPS feature.  It allows
to see immediately the power management savings and will allow
to expose this through sysfs interface for powertop to leverage its
functionality.

Signed-off-by: Alexandra Yates 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++-
 drivers/gpu/drm/i915/i915_drv.h  |  8 
 drivers/gpu/drm/i915/i915_sysfs.c| 78 
 drivers/gpu/drm/i915/intel_color.c   | 12 --
 drivers/gpu/drm/i915/intel_display.c | 37 +
 drivers/gpu/drm/i915/intel_dp.c  | 11 +++--
 drivers/gpu/drm/i915/intel_drv.h |  4 +-
 7 files changed, 136 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2d11b49..e338c8a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4022,6 +4022,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
enum intel_display_power_domain power_domain;
u32 val = 0; /* shut up gcc */
int ret;
+   bool sysfs_set = false;
 
if (pipe_crc->source == source)
return 0;
@@ -4071,7 +4072,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
 * user space can't make reliable use of the CRCs, so let's just
 * completely disable it.
 */
-   hsw_disable_ips(crtc);
+   hsw_disable_ips(crtc, sysfs_set);
 
spin_lock_irq(_crc->lock);
kfree(pipe_crc->entries);
@@ -4116,7 +4117,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
else if (IS_HASWELL(dev) && pipe == PIPE_A)
hsw_trans_edp_pipe_A_crc_wa(dev, false);
 
-   hsw_enable_ips(crtc);
+   hsw_enable_ips(crtc, sysfs_set);
}
 
ret = 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c5eea6..0df0030 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -967,6 +967,12 @@ struct i915_drrs {
bool sysfs_set;
 };
 
+struct i915_ips {
+   struct mutex lock;
+   int enable;
+   bool sysfs_set;
+};
+
 struct i915_psr {
struct mutex lock;
bool sink_support;
@@ -1888,6 +1894,8 @@ struct drm_i915_private {
 
struct i915_power_domains power_domains;
 
+   struct i915_ips hsw_ips;
+
struct i915_psr psr;
 
struct i915_gpu_error gpu_error;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index f489ab6..3bc830b 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -265,6 +265,64 @@ toggle_psr(struct device *kdev, struct device_attribute 
*attr,
 }
 
 static ssize_t
+show_ips(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   ssize_t ret;
+
+   mutex_lock(_priv->hsw_ips.lock);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->hsw_ips.enable ?
+   "enabled":"disabled");
+   mutex_unlock(_priv->hsw_ips.lock);
+   return ret;
+}
+
+static ssize_t
+toggle_ips(struct device *kdev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct intel_connector *connector;
+   struct intel_encoder *encoder;
+   struct intel_crtc *crtc = NULL;
+   bool sysfs_set = true;
+   u32 val;
+   ssize_t ret;
+
+   ret = kstrtou32(buf, 0, );
+   if (ret)
+   return ret;
+
+   for_each_intel_connector(dev, connector) {
+   if (!connector->base.encoder)
+   continue;
+   encoder = to_intel_encoder(connector->base.encoder);
+   crtc = to_intel_crtc(encoder->base.crtc);
+   }
+   if (!crtc)
+   return -ENODEV;
+
+   switch (val) {
+   case 0:
+   ret = hsw_disable_ips(crtc, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   case 1:
+   ret = hsw_enable_ips(crtc, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return count;
+}
+
+static ssize_t
 show_drrs(struct device *kdev, struct device_attribute *attr, char *buf)
 {
struct drm_minor *dminor = dev_to_drm_minor(kdev);
@@ -329,6 +387,7 @@ toggle_drrs(struct device *kdev, struct device_attribute 
*attr,
return 

[Intel-gfx] [PATCH 4/5] drm/i915: Hook up pfit for DSI

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Add the scaling mode property to DSI connectors, handle changes in the
property value, and compute the panel fitter state during
.compute_config().

v2: Handle BXT as well

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 73 +---
 1 file changed, 68 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index c43c8caf8c95..d94193aa6ffc 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -290,7 +290,8 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
   base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
-   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
+   const struct drm_display_mode *fixed_mode = 
intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int ret;
 
@@ -298,9 +299,17 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->has_dsi_encoder = true;
 
-   if (fixed_mode)
+   if (fixed_mode) {
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
 
+   if (HAS_GMCH_DISPLAY(dev_priv))
+   intel_gmch_panel_fitting(crtc, pipe_config,
+
intel_connector->panel.fitting_mode);
+   else
+   intel_pch_panel_fitting(crtc, pipe_config,
+   
intel_connector->panel.fitting_mode);
+   }
+
/* DSI uses short packets for sync events, so clear mode flags for DSI 
*/
adjusted_mode->flags = 0;
 
@@ -840,7 +849,7 @@ intel_dsi_mode_valid(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
-   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   const struct drm_display_mode *fixed_mode = 
intel_connector->panel.fixed_mode;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
DRM_DEBUG_KMS("\n");
@@ -1178,6 +1187,43 @@ static int intel_dsi_get_modes(struct drm_connector 
*connector)
return 1;
 }
 
+static int intel_dsi_set_property(struct drm_connector *connector,
+ struct drm_property *property,
+ uint64_t val)
+{
+   struct drm_device *dev = connector->dev;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct drm_crtc *crtc;
+   int ret;
+
+   ret = drm_object_property_set_value(>base, property, val);
+   if (ret)
+   return ret;
+
+   if (property == dev->mode_config.scaling_mode_property) {
+   if (val == DRM_MODE_SCALE_NONE) {
+   DRM_DEBUG_KMS("no scaling not supported\n");
+   return -EINVAL;
+   }
+
+   if (intel_connector->panel.fitting_mode == val)
+   return 0;
+
+   intel_connector->panel.fitting_mode = val;
+   }
+
+   crtc = intel_attached_encoder(connector)->base.crtc;
+   if (crtc && crtc->state->enable) {
+   /*
+* If the CRTC is enabled, the display will be changed
+* according to the new panel fitting mode.
+*/
+   intel_crtc_restore_mode(crtc);
+   }
+
+   return 0;
+}
+
 static void intel_dsi_connector_destroy(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -1220,11 +1266,25 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.detect = intel_dsi_detect,
.destroy = intel_dsi_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
+   .set_property = intel_dsi_set_property,
.atomic_get_property = intel_connector_atomic_get_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 };
 
+static void intel_dsi_add_properties(struct intel_connector *connector)
+{
+   struct drm_device *dev = connector->base.dev;
+
+   if (connector->panel.fixed_mode) {
+   drm_mode_create_scaling_mode_property(dev);
+   drm_object_attach_property(>base.base,
+  
dev->mode_config.scaling_mode_property,
+  

[Intel-gfx] [PATCH 2/5] drm/i915: Compute DSI PLL parameters during .compute_config()

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Compute the DSI PLL parameters during .compute_config() rather than
.pre_pll_enable() so that we can fail gracefully if we can't find
suitable parameters.

In order to do that we need to store the DSI PLL parameters in
pipe_config.

v2: Handle BXT too

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |   3 +
 drivers/gpu/drm/i915/intel_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_dsi.c |  15 ++--
 drivers/gpu/drm/i915/intel_dsi.h |  14 ++--
 drivers/gpu/drm/i915/intel_dsi_pll.c | 156 +++
 5 files changed, 112 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c74a930f45d..017dad536492 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12752,6 +12752,9 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
 
+   PIPE_CONF_CHECK_X(dsi_pll.ctrl);
+   PIPE_CONF_CHECK_X(dsi_pll.div);
+
if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e0fcfa1683cc..a4d375dd068f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -497,6 +497,11 @@ struct intel_crtc_state {
/* Actual register state of the dpll, for shared dpll cross-checking. */
struct intel_dpll_hw_state dpll_hw_state;
 
+   /* DSI PLL registers */
+   struct {
+   u32 ctrl, div;
+   } dsi_pll;
+
int pipe_bpp;
struct intel_link_m_n dp_m_n;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 22bd42a8aab0..c43c8caf8c95 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -292,6 +292,7 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
struct intel_connector *intel_connector = intel_dsi->attached_connector;
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
+   int ret;
 
DRM_DEBUG_KMS("\n");
 
@@ -311,10 +312,10 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
pipe_config->cpu_transcoder = TRANSCODER_DSI_A;
}
 
-   /*
-* FIXME move the DSI PLL calc from vlv_enable_dsi_pll()
-* to .compute_config().
-*/
+   ret = intel_compute_dsi_pll(encoder, pipe_config);
+   if (ret)
+   return false;
+
pipe_config->clock_set = true;
 
return true;
@@ -504,6 +505,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
enum port port;
u32 tmp;
 
@@ -514,7 +516,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
 * lock. It needs to be fully powered down to fix it.
 */
intel_disable_dsi_pll(encoder);
-   intel_enable_dsi_pll(encoder);
+   intel_enable_dsi_pll(encoder, crtc->config);
 
intel_dsi_prepare(encoder);
 
@@ -824,7 +826,8 @@ static void intel_dsi_get_config(struct intel_encoder 
*encoder,
if (IS_BROXTON(dev))
bxt_dsi_get_pipe_config(encoder, pipe_config);
 
-   pclk = intel_dsi_get_pclk(encoder, pipe_config->pipe_bpp);
+   pclk = intel_dsi_get_pclk(encoder, pipe_config->pipe_bpp,
+ pipe_config);
if (!pclk)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index dabde19ee8aa..61a6957fc6c2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -127,11 +127,15 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
drm_encoder *encoder)
 }
 
 bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
-extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
-extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
-extern u32 intel_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp);
-extern void intel_dsi_reset_clocks(struct intel_encoder *encoder,
-   enum port port);
+int intel_compute_dsi_pll(struct intel_encoder *encoder,
+ struct intel_crtc_state *config);
+void intel_enable_dsi_pll(struct intel_encoder *encoder,
+ const struct intel_crtc_state *config);
+void 

[Intel-gfx] [PATCH 1/5] drm/i915: Add sys PSR toggle interface

2016-04-12 Thread Alexandra Yates
This interface allows an immediate enabling of PSR feature. What allow us
to see immediately the PSR savings and will allow us to expose this
through sysfs interface for powertop to leverage its functionality.

Signed-off-by: Alexandra Yates 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_sysfs.c | 79 +++
 drivers/gpu/drm/i915/intel_ddi.c  |  6 ++-
 drivers/gpu/drm/i915/intel_dp.c   | 11 --
 drivers/gpu/drm/i915/intel_drv.h  |  4 +-
 drivers/gpu/drm/i915/intel_psr.c  | 36 ++
 6 files changed, 122 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5c91b0..c96da4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,7 @@ struct i915_psr {
bool psr2_support;
bool aux_frame_sync;
bool link_standby;
+   bool sysfs_set;
 };
 
 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2d576b7..208c6ec 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -106,12 +106,84 @@ show_media_rc6_ms(struct device *kdev, struct 
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
 }
 
+static ssize_t
+show_psr(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   ssize_t ret;
+
+   mutex_lock(_priv->psr.lock);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->psr.enabled ?
+   "enabled":"disabled");
+   mutex_unlock(_priv->psr.lock);
+   return ret;
+}
+
+static ssize_t
+toggle_psr(struct device *kdev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct intel_connector *connector;
+   struct intel_encoder *encoder;
+   struct intel_crtc *crtc = NULL;
+   u32 val;
+   ssize_t ret;
+   struct intel_dp *intel_dp = NULL;
+   bool sysfs_set = true;
+
+   ret = kstrtou32(buf, 0, );
+   if (ret)
+   return ret;
+
+   for_each_intel_connector(dev, connector) {
+   if (!connector->base.encoder)
+   continue;
+   encoder = to_intel_encoder(connector->base.encoder);
+   crtc = to_intel_crtc(encoder->base.crtc);
+   intel_dp = enc_to_intel_dp(>base);
+   }
+
+   if (!crtc)
+   return -ENODEV;
+   switch (val) {
+   case 0:
+   ret = intel_psr_disable(intel_dp, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   case 1:
+   ret = intel_psr_enable(intel_dp, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   default:
+   return -EINVAL;
+
+   }
+   return count;
+}
+
+static DEVICE_ATTR(psr_enable, S_IRUGO | S_IWUSR, show_psr, toggle_psr);
 static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
 static DEVICE_ATTR(rc6_residency_ms, S_IRUGO, show_rc6_ms, NULL);
 static DEVICE_ATTR(rc6p_residency_ms, S_IRUGO, show_rc6p_ms, NULL);
 static DEVICE_ATTR(rc6pp_residency_ms, S_IRUGO, show_rc6pp_ms, NULL);
 static DEVICE_ATTR(media_rc6_residency_ms, S_IRUGO, show_media_rc6_ms, NULL);
 
+static struct attribute *psr_attrs[] = {
+   _attr_psr_enable.attr,
+   NULL
+};
+
+static struct attribute_group psr_attr_group = {
+   .name = power_group_name,
+   .attrs = psr_attrs
+};
+
 static struct attribute *rc6_attrs[] = {
_attr_rc6_enable.attr,
_attr_rc6_residency_ms.attr,
@@ -596,6 +668,12 @@ void i915_setup_sysfs(struct drm_device *dev)
int ret;
 
 #ifdef CONFIG_PM
+   if (HAS_PSR(dev)) {
+   ret = sysfs_merge_group(>primary->kdev->kobj,
+   _attr_group);
+   if (ret)
+   DRM_ERROR("PSR sysfs setup failed\n");
+   }
if (HAS_RC6(dev)) {
ret = sysfs_merge_group(>primary->kdev->kobj,
_attr_group);
@@ -652,6 +730,7 @@ void i915_teardown_sysfs(struct drm_device *dev)
device_remove_bin_file(dev->primary->kdev,  _attrs_1);
device_remove_bin_file(dev->primary->kdev,  _attrs);
 #ifdef CONFIG_PM
+   sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 921edf1..8e384e5 100644
--- 

[Intel-gfx] [PATCH 3/5] drm/i915: Eliminate {vlv, bxt}_configure_dsi_pll()

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Fold the DSI PLL configuration functions into the DSI PLL
enable functions since they are small and not called from anywhere else.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 115f59646514..1765e6e18f2c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -141,17 +141,6 @@ static int vlv_compute_dsi_pll(struct intel_encoder 
*encoder,
return 0;
 }
 
-static void vlv_configure_dsi_pll(struct intel_encoder *encoder,
- const struct intel_crtc_state *config)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
-   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
- config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
-}
-
 static void vlv_enable_dsi_pll(struct intel_encoder *encoder,
   const struct intel_crtc_state *config)
 {
@@ -161,7 +150,10 @@ static void vlv_enable_dsi_pll(struct intel_encoder 
*encoder,
 
mutex_lock(_priv->sb_lock);
 
-   vlv_configure_dsi_pll(encoder, config);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
+   vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
+ config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
 
/* wait at least 0.5 us after ungating before enabling VCO */
usleep_range(1, 10);
@@ -470,15 +462,6 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
*encoder,
return 0;
 }
 
-static void bxt_configure_dsi_pll(struct intel_encoder *encoder,
- const struct intel_crtc_state *config)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
-   I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
-   POSTING_READ(BXT_DSI_PLL_CTL);
-}
-
 static void bxt_enable_dsi_pll(struct intel_encoder *encoder,
   const struct intel_crtc_state *config)
 {
@@ -490,7 +473,8 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
*encoder,
DRM_DEBUG_KMS("\n");
 
/* Configure PLL vales */
-   bxt_configure_dsi_pll(encoder, config);
+   I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
+   POSTING_READ(BXT_DSI_PLL_CTL);
 
/* Program TX, RX, Dphy clocks */
for_each_dsi_port(port, intel_dsi->ports)
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/5] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
the DPLL isn't used to provide the clock we still need the refclock, and
it appears that the pixel repeat factor also has an effect on DSI
output. So set up eveyrhing in DPLL and DPLL_MD as we would do for
DP/HDMI/VGA, but don't actually enable the DPLL or configure the
dividers via DPIO.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 120 +--
 drivers/gpu/drm/i915/intel_dsi.c |  28 ++--
 2 files changed, 80 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 607dc41bcc68..7c74a930f45d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1530,45 +1530,47 @@ static void assert_pch_ports_disabled(struct 
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
 }
 
+static void _vlv_enable_pll(struct intel_crtc *crtc,
+   const struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   I915_WRITE(DPLL(pipe), pipe_config->dpll_hw_state.dpll);
+   POSTING_READ(DPLL(pipe));
+   udelay(150);
+
+   if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
+   DRM_ERROR("DPLL %d failed to lock\n", pipe);
+}
+
 static void vlv_enable_pll(struct intel_crtc *crtc,
   const struct intel_crtc_state *pipe_config)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   i915_reg_t reg = DPLL(pipe);
-   u32 dpll = pipe_config->dpll_hw_state.dpll;
 
assert_pipe_disabled(dev_priv, pipe);
 
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
 
-   I915_WRITE(reg, dpll);
-   POSTING_READ(reg);
-   udelay(150);
-
-   if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
-   DRM_ERROR("DPLL %d failed to lock\n", pipe);
+   if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+   _vlv_enable_pll(crtc, pipe_config);
 
I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
POSTING_READ(DPLL_MD(pipe));
 }
 
-static void chv_enable_pll(struct intel_crtc *crtc,
-  const struct intel_crtc_state *pipe_config)
+
+static void _chv_enable_pll(struct intel_crtc *crtc,
+   const struct intel_crtc_state *pipe_config)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 tmp;
 
-   assert_pipe_disabled(dev_priv, pipe);
-
-   /* PLL is protected by panel, make sure we can write it */
-   assert_panel_unlocked(dev_priv, pipe);
-
mutex_lock(_priv->sb_lock);
 
/* Enable back the 10bit clock to display controller */
@@ -1589,6 +1591,21 @@ static void chv_enable_pll(struct intel_crtc *crtc,
/* Check PLL is locked */
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
+}
+
+static void chv_enable_pll(struct intel_crtc *crtc,
+  const struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   assert_pipe_disabled(dev_priv, pipe);
+
+   /* PLL is protected by panel, make sure we can write it */
+   assert_panel_unlocked(dev_priv, pipe);
+
+   if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+   _chv_enable_pll(crtc, pipe_config);
 
if (pipe != PIPE_A) {
/*
@@ -6073,14 +6090,12 @@ static void valleyview_crtc_enable(struct drm_crtc 
*crtc)
if (encoder->pre_pll_enable)
encoder->pre_pll_enable(encoder);
 
-   if (!intel_crtc->config->has_dsi_encoder) {
-   if (IS_CHERRYVIEW(dev)) {
-   chv_prepare_pll(intel_crtc, intel_crtc->config);
-   chv_enable_pll(intel_crtc, intel_crtc->config);
-   } else {
-   vlv_prepare_pll(intel_crtc, intel_crtc->config);
-   vlv_enable_pll(intel_crtc, intel_crtc->config);
-   }
+   if (IS_CHERRYVIEW(dev)) {
+   chv_prepare_pll(intel_crtc, intel_crtc->config);
+   

[Intel-gfx] [PATCH 4/5] drm/i915: Add sys drrs toggle interface

2016-04-12 Thread Alexandra Yates
This interface allows enabling/disabling of DRRS feature.  It allows
to see immediately the power management savings and will allow
to expose this through sysfs interface for powertop to leverage its
functionality.

Signed-off-by: Alexandra Yates 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_sysfs.c | 86 +++
 drivers/gpu/drm/i915/intel_ddi.c  |  9 +++-
 drivers/gpu/drm/i915/intel_dp.c   | 26 +---
 drivers/gpu/drm/i915/intel_drv.h  |  4 +-
 5 files changed, 116 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bbe189f..4c5eea6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -964,6 +964,7 @@ struct i915_drrs {
unsigned busy_frontbuffer_bits;
enum drrs_refresh_rate_type refresh_rate_type;
enum drrs_support_type type;
+   bool sysfs_set;
 };
 
 struct i915_psr {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 81aa534..f489ab6 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -264,6 +264,72 @@ toggle_psr(struct device *kdev, struct device_attribute 
*attr,
return count;
 }
 
+static ssize_t
+show_drrs(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   ssize_t ret;
+
+   mutex_lock(_priv->drrs.mutex);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->drrs.dp ?
+   "enabled":"disabled");
+   mutex_unlock(_priv->drrs.mutex);
+   return ret;
+}
+
+static ssize_t
+toggle_drrs(struct device *kdev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct intel_connector *connector;
+   struct intel_encoder *encoder;
+   struct intel_crtc *crtc = NULL;
+   struct intel_dp *intel_dp = NULL;
+   u32 val;
+   ssize_t ret;
+   bool sysfs_set = true;
+
+   ret = kstrtou32(buf, 0, );
+   if (ret)
+   return ret;
+
+   for_each_intel_connector(dev, connector) {
+   if (!connector->base.encoder)
+   continue;
+
+   encoder = to_intel_encoder(connector->base.encoder);
+   crtc = to_intel_crtc(encoder->base.crtc);
+   intel_dp = enc_to_intel_dp(>base);
+   }
+   if (!crtc)
+   return -ENODEV;
+
+   switch (val) {
+   case 0:
+   ret = intel_edp_drrs_disable(intel_dp, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   case 1:
+   if (encoder->type == INTEL_OUTPUT_EDP) {
+   ret = intel_edp_drrs_enable(intel_dp, sysfs_set);
+   if (ret)
+   return ret;
+   }
+   break;
+   default:
+   return -EINVAL;
+
+   }
+
+   return count;
+}
+
+static DEVICE_ATTR(drrs_enable, S_IRUGO | S_IWUSR, show_drrs, toggle_drrs);
 static DEVICE_ATTR(fbc_enable, S_IRUGO | S_IWUSR, show_fbc, toggle_fbc);
 static DEVICE_ATTR(psr_enable, S_IRUGO | S_IWUSR, show_psr, toggle_psr);
 static DEVICE_ATTR(rc6_enable, S_IRUGO | S_IWUSR, show_rc6_mask, toggle_rc6);
@@ -323,6 +389,17 @@ static struct attribute_group media_rc6_attr_group = {
.name = power_group_name,
.attrs =  media_rc6_attrs
 };
+
+static struct attribute *drrs_attrs[] = {
+   _attr_drrs_enable.attr,
+   NULL
+};
+
+static struct attribute_group drrs_attr_group = {
+   .name = power_group_name,
+   .attrs = drrs_attrs
+};
+
 #endif
 
 static int l3_access_valid(struct drm_device *dev, loff_t offset)
@@ -788,6 +865,14 @@ void i915_setup_sysfs(struct drm_device *dev)
if (ret)
DRM_ERROR("PSR sysfs setup failed\n");
}
+
+   if (HAS_PSR(dev)) {
+   ret = sysfs_merge_group(>primary->kdev->kobj,
+   _attr_group);
+   if (ret)
+   DRM_ERROR("DRRS sysfs setup failed\n");
+   }
+
if (HAS_RC6(dev)) {
ret = sysfs_merge_group(>primary->kdev->kobj,
_attr_group);
@@ -844,6 +929,7 @@ void i915_teardown_sysfs(struct drm_device *dev)
device_remove_bin_file(dev->primary->kdev,  _attrs_1);
device_remove_bin_file(dev->primary->kdev,  _attrs);
 #ifdef CONFIG_PM
+   sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);

[Intel-gfx] [PATCH 2/5] drm/i915: Add sys FBC toggle interface

2016-04-12 Thread Alexandra Yates
This interface allows an immediate enabling of FBC feature. What allow us
to see immediately the FBC power management savings and will allow us to
expose this through sysfs interface for powertop to leverage its
functionality.

Signed-off-by: Alexandra Yates 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_sysfs.c| 77 
 drivers/gpu/drm/i915/intel_display.c | 15 +--
 drivers/gpu/drm/i915/intel_drv.h |  4 +-
 drivers/gpu/drm/i915/intel_fbc.c | 29 +++---
 5 files changed, 115 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c96da4d..0f3a37f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -936,6 +936,7 @@ struct intel_fbc {
} work;
 
const char *no_fbc_reason;
+   bool sysfs_set;
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 208c6ec..50d45ef 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -107,6 +107,65 @@ show_media_rc6_ms(struct device *kdev, struct 
device_attribute *attr, char *buf)
 }
 
 static ssize_t
+show_fbc(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   ssize_t ret;
+
+   mutex_lock(_priv->fbc.lock);
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->fbc.enabled ?
+   "enabled":"disabled");
+   mutex_unlock(_priv->fbc.lock);
+   return ret;
+}
+
+static ssize_t
+toggle_fbc(struct device *kdev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   struct intel_connector *connector;
+   struct intel_encoder *encoder;
+   struct intel_crtc *crtc = NULL;
+   u32 val;
+   ssize_t ret;
+   bool sysfs_set = true;
+
+   ret = kstrtou32(buf, 0, );
+   if (ret)
+   return ret;
+
+   for_each_intel_connector(dev, connector) {
+   if (!connector->base.encoder)
+   continue;
+   encoder = to_intel_encoder(connector->base.encoder);
+   crtc = to_intel_crtc(encoder->base.crtc);
+   }
+
+   if (!crtc)
+   return -ENODEV;
+   switch (val) {
+   case 0:
+   ret = intel_fbc_disable(crtc, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   case 1:
+   ret = intel_fbc_enable(crtc, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   default:
+   return -EINVAL;
+
+   }
+   return count;
+}
+
+static ssize_t
 show_psr(struct device *kdev, struct device_attribute *attr, char *buf)
 {
struct drm_minor *dminor = dev_to_drm_minor(kdev);
@@ -167,6 +226,7 @@ toggle_psr(struct device *kdev, struct device_attribute 
*attr,
return count;
 }
 
+static DEVICE_ATTR(fbc_enable, S_IRUGO | S_IWUSR, show_fbc, toggle_fbc);
 static DEVICE_ATTR(psr_enable, S_IRUGO | S_IWUSR, show_psr, toggle_psr);
 static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
 static DEVICE_ATTR(rc6_residency_ms, S_IRUGO, show_rc6_ms, NULL);
@@ -174,6 +234,16 @@ static DEVICE_ATTR(rc6p_residency_ms, S_IRUGO, 
show_rc6p_ms, NULL);
 static DEVICE_ATTR(rc6pp_residency_ms, S_IRUGO, show_rc6pp_ms, NULL);
 static DEVICE_ATTR(media_rc6_residency_ms, S_IRUGO, show_media_rc6_ms, NULL);
 
+static struct attribute *fbc_attrs[] = {
+   _attr_fbc_enable.attr,
+   NULL
+};
+
+static struct attribute_group fbc_attr_group = {
+   .name = power_group_name,
+   .attrs = fbc_attrs
+};
+
 static struct attribute *psr_attrs[] = {
_attr_psr_enable.attr,
NULL
@@ -668,6 +738,12 @@ void i915_setup_sysfs(struct drm_device *dev)
int ret;
 
 #ifdef CONFIG_PM
+   if (HAS_FBC(dev)) {
+   ret = sysfs_merge_group(>primary->kdev->kobj,
+   _attr_group);
+   if (ret)
+   DRM_ERROR("FBC sysfs setup failed\n");
+   }
if (HAS_PSR(dev)) {
ret = sysfs_merge_group(>primary->kdev->kobj,
_attr_group);
@@ -730,6 +806,7 @@ void i915_teardown_sysfs(struct drm_device *dev)
device_remove_bin_file(dev->primary->kdev,  _attrs_1);
device_remove_bin_file(dev->primary->kdev,  _attrs);
 #ifdef CONFIG_PM
+   sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);
sysfs_unmerge_group(>primary->kdev->kobj, _attr_group);

[Intel-gfx] [PATCH 3/5] drm/i915: Add sys RC6 toggle interface

2016-04-12 Thread Alexandra Yates
This interface allows enabling/disabling of RC6 feature.  It allows
to see immediately the RC6 power management savings and will allow
to expose this through sysfs interface for powertop to leverage its
functionality.

Signed-off-by: Alexandra Yates 
---
 drivers/gpu/drm/i915/i915_drv.c  |  5 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_sysfs.c| 42 ++--
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 drivers/gpu/drm/i915/intel_drv.h |  5 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 53 ++--
 6 files changed, 99 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79..6ffbdfb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -950,7 +950,7 @@ int i915_reset(struct drm_device *dev)
 * of re-init after reset.
 */
if (INTEL_INFO(dev)->gen > 5)
-   intel_enable_gt_powersave(dev);
+   intel_enable_gt_powersave(dev, false);
 
return 0;
 }
@@ -1600,7 +1600,8 @@ static int intel_runtime_resume(struct device *device)
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_init(dev_priv);
 
-   intel_enable_gt_powersave(dev);
+   if (dev_priv->rps.sysfs_set != true)
+   intel_enable_gt_powersave(dev, dev_priv->rps.sysfs_set);
 
enable_rpm_wakeref_asserts(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f3a37f..bbe189f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1158,6 +1158,7 @@ struct intel_gen6_power_mgmt {
 * talking to hw - so only take it when talking to hw!
 */
struct mutex hw_lock;
+   bool sysfs_set;
 };
 
 /* defined intel_pm.c */
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 50d45ef..81aa534 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -71,7 +71,45 @@ static ssize_t
 show_rc6_mask(struct device *kdev, struct device_attribute *attr, char *buf)
 {
struct drm_minor *dminor = dev_to_drm_minor(kdev);
-   return snprintf(buf, PAGE_SIZE, "%x\n", intel_enable_rc6(dminor->dev));
+   struct drm_device *dev = dminor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int enable_rc6;
+
+   enable_rc6 = sanitize_rc6_option(dev, intel_enable_rc6(dminor->dev));
+   return snprintf(buf, PAGE_SIZE, "%x\n",
+   (dev_priv->rps.enabled && enable_rc6));
+}
+
+static ssize_t
+toggle_rc6(struct device *kdev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_minor *dminor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
+   u32 val;
+   ssize_t ret;
+   bool sysfs_set = true;
+
+   ret = kstrtou32(buf, 0, );
+   if (ret)
+   return ret;
+
+   switch (val) {
+   case 0:
+   ret = intel_disable_rc_powersave(dev, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   case 1:
+   ret = intel_enable_gt_powersave(dev, sysfs_set);
+   if (ret)
+   return ret;
+   break;
+   default:
+   return -EINVAL;
+
+   }
+   return count;
 }
 
 static ssize_t
@@ -228,7 +266,7 @@ toggle_psr(struct device *kdev, struct device_attribute 
*attr,
 
 static DEVICE_ATTR(fbc_enable, S_IRUGO | S_IWUSR, show_fbc, toggle_fbc);
 static DEVICE_ATTR(psr_enable, S_IRUGO | S_IWUSR, show_psr, toggle_psr);
-static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
+static DEVICE_ATTR(rc6_enable, S_IRUGO | S_IWUSR, show_rc6_mask, toggle_rc6);
 static DEVICE_ATTR(rc6_residency_ms, S_IRUGO, show_rc6_ms, NULL);
 static DEVICE_ATTR(rc6p_residency_ms, S_IRUGO, show_rc6p_ms, NULL);
 static DEVICE_ATTR(rc6pp_residency_ms, S_IRUGO, show_rc6pp_ms, NULL);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3d252b9..4a671e3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15256,7 +15256,8 @@ void intel_modeset_init_hw(struct drm_device *dev)
dev_priv->atomic_cdclk_freq = dev_priv->cdclk_freq;
 
intel_init_clock_gating(dev);
-   intel_enable_gt_powersave(dev);
+   if (dev_priv->rps.sysfs_set != true)
+   intel_enable_gt_powersave(dev, dev_priv->rps.sysfs_set);
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 93d09cc..d280847 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1586,8 +1586,9 @@ void intel_gpu_ips_init(struct drm_i915_private 
*dev_priv);
 void intel_gpu_ips_teardown(void);
 void 

[Intel-gfx] [PATCH 0/5] drm/i915: Rest of my DSI and DPLL stuff

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Here is the remainder of my DSI/DPLL series [1]. Everything else got merged
already. The first patch in the series is the only one to lack an r-b.

Tested on BYT FFRD8 only, BXT stuff is not tested.

[1] https://lists.freedesktop.org/archives/intel-gfx/2016-March/089782.html

Ville Syrjälä (5):
  drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV
  drm/i915: Compute DSI PLL parameters during .compute_config()
  drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()
  drm/i915: Hook up pfit for DSI
  drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

 drivers/gpu/drm/i915/intel_display.c | 123 ++
 drivers/gpu/drm/i915/intel_dp.c  |   5 ++
 drivers/gpu/drm/i915/intel_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_dsi.c | 113 ---
 drivers/gpu/drm/i915/intel_dsi.h |  14 ++--
 drivers/gpu/drm/i915/intel_dsi_pll.c | 144 +--
 6 files changed, 252 insertions(+), 152 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

2016-04-12 Thread Alexandra Yates
This project is explained in detail on the HAS
https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f08UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing
  

Summary: 
Permits the user to identify and toggle values for PSR, FBC, RC6, DRRS, and IPS
under /sys/class/drm/card0/power/.  By enabling these features I'm looking to
empower our customers, such as, power team, chrome OS, and platform integration 
teams
to debug graphics power management features. 

From the current patchset PSR, FBC, RC6, and, DRRS are complete and past BAT, 
modset,
and suspend/resume tests.  For IPS I'm looking for feedback since IPS seems to 
change
during runtime dynamically.  Additionally, as a future project IPS would be 
better 
served if it is implemented by using the atomic check, pre-commit, commit, 
post-commit,
a good example of this is the PSR enable/disable implementation.

For this project to be completed needs to have in place the following 
components:
(Need to be developed)
* IPS toggle interface flesh-out
* Tests added to intel-gpu-tools repo
* Documentation for all sysfs added interfaces
* PowerTOP component named: GFX-TOP. With the following requirements:
* It would be available only to developers
* It would allow the developers to toggle the interfaces from
  the PowerTOP user interface.  
* It would show the Power Consumption impact of toggling on and off
  these settings.  
 
Your review of this patchset is intended to contribute to its full
maturity so that when we reach the PowerTOP development all pieces would
be ready for commit.  

Thank you in advance,

Alexandra Yates (5):
  drm/i915: Add sys PSR toggle interface
  drm/i915: Add sys FBC toggle interface
  drm/i915: Add sys RC6 toggle interface
  drm/i915: Add sys drrs toggle interface
  drm-i915: Add sys IPS toggle interface

 drivers/gpu/drm/i915/i915_debugfs.c  |   5 +-
 drivers/gpu/drm/i915/i915_drv.c  |   5 +-
 drivers/gpu/drm/i915/i915_drv.h  |  12 ++
 drivers/gpu/drm/i915/i915_sysfs.c| 362 ++-
 drivers/gpu/drm/i915/intel_color.c   |  12 +-
 drivers/gpu/drm/i915/intel_ddi.c |  15 +-
 drivers/gpu/drm/i915/intel_display.c |  55 --
 drivers/gpu/drm/i915/intel_dp.c  |  48 +++--
 drivers/gpu/drm/i915/intel_drv.h |  21 +-
 drivers/gpu/drm/i915/intel_fbc.c |  29 ++-
 drivers/gpu/drm/i915/intel_pm.c  |  53 -
 drivers/gpu/drm/i915/intel_psr.c |  36 +++-
 12 files changed, 588 insertions(+), 65 deletions(-)

-- 
2.5.0

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


Re: [Intel-gfx] [PATCH 00/16] drm/i915: DSI and DPLL stuff for VLV/CHV mostly

2016-04-12 Thread Ville Syrjälä
On Tue, Mar 15, 2016 at 04:39:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Here's a pile of pending VLV/CHV DSI and DPLL patches I had lying around.
> Most of these have been posted before. Would be nice to finally get them
> in.
> 
> I've tried to rebase things to account for BXT as well, but obviously
> that part is not tested. I have tested this on a BYT FFRD8 which has
> a DSI panel.
> 
> Apart from the VLV/CHV specific stuff, the main thing here is moving
> the DSI PLL calculations to the .compute_config() phase. Another neat
> thing is hooking up the panel fitter for DSI.
> 
> Ville Syrjälä (16):
>   drm/i915: Throw out BUGs from DPLL/PCH functions
>   drm/i915: Make {vlv,chv}_{disable,update}_pll() more similar
>   drm/i915: Implement WaPixelRepeatModeFixForC0:chv
>   drm/i915: Add a local pipe variable to vlv_enable_pll()
>   drm/i915: assert_panel_unlocked() in chv_enable_pll()
>   drm/i915: Remove the "three times for luck" trick from
> vlv_enable_pll()

These I have pushed earlier.

>   drm/i915: Don't read out port_clock on CHV when DPLL is disabled
>   drm/i915: Change lfsr_converts[] to u16
>   drm/i915: Power down the DSI PLL before reconfiguring it
>   drm/i915: Fix CHV DSI PLL refclk during state readout
>   drm/i915: Dump pfit PGM_RATIOS as hex

These I just pushed now. Thanks for the reviews.

>   drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV
>   drm/i915: Compute DSI PLL parameters during .compute_config()
>   drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()
>   drm/i915: Hook up pfit for DSI
>   drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

These are still out in the cold. I'll rebase and repost them
as a new series.

> 
>  drivers/gpu/drm/i915/i915_drv.h  |   7 +
>  drivers/gpu/drm/i915/i915_reg.h  |   4 +
>  drivers/gpu/drm/i915/intel_display.c | 244 
> +++
>  drivers/gpu/drm/i915/intel_dp.c  |   5 +
>  drivers/gpu/drm/i915/intel_drv.h |   5 +
>  drivers/gpu/drm/i915/intel_dsi.c | 120 +
>  drivers/gpu/drm/i915/intel_dsi.h |  14 +-
>  drivers/gpu/drm/i915/intel_dsi_pll.c | 155 +++---
>  8 files changed, 332 insertions(+), 222 deletions(-)
> 
> -- 
> 2.4.10

-- 
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 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

2016-04-12 Thread Ville Syrjälä
On Tue, Apr 12, 2016 at 03:04:10PM +0300, Imre Deak wrote:
> On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Enable the unclaimd register detection stuff on vlv/chv since we've
> > now
> > fixed the known problems during suspend.
> > 
> > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Imre Deak 

Entire series pushed to dinq. Thanks for the reviews.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_uncore.c | 9 -
> >  1 file changed, 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index ac2ac07b505b..2f7fb7d169b8 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -633,15 +633,6 @@ __unclaimed_reg_debug(struct drm_i915_private
> > *dev_priv,
> >       const bool read,
> >       const bool before)
> >  {
> > -   /* XXX. We limit the auto arming traces for mmio
> > -    * debugs on these platforms. There are just too many
> > -    * revealed by these and CI/Bat suffers from the noise.
> > -    * Please fix and then re-enable the automatic traces.
> > -    */
> > -   if (i915.mmio_debug < 2 &&
> > -   (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > -   return;
> > -
> >     if (WARN(check_for_unclaimed_mmio(dev_priv),
> >      "Unclaimed register detected %s %s register
> > 0x%x\n",
> >      before ? "before" : "after",

-- 
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 00/14] Gen8 Execlist based Engine reset and recovery support

2016-04-12 Thread Arun Siluvery
This series for Engine reset functionality from Gen8 onwards. Some of the
prep patches are already sent and merged, now follows more of them and
implementation patches.

Many many thanks to Mika and Chris for their time in review, these patches
have become much more simpler than they were originally and they are easy
to follow as well. I request you to please review further and provide
feedback so that they can be get closer to upstream. We can also get some
testing done now.

Tomas Elf originally started upstreaming effort for Gen8 and I am
continuing it, any mistakes they are mine.

These are based on nightly tree pulled on 11th April. 

Arun Siluvery (12):
  drm/i915: Update i915.reset to handle engine resets
  drm/i915/tdr: Extend the idea of reset_counter to engine reset
  drm/i915/tdr: Modify error handler for per engine hang recovery
  drm/i915/tdr: Prepare execlist submission to handle tdr resubmission
after reset
  drm/i915/tdr: Capture engine state before reset
  drm/i915/tdr: Restore engine state and start after reset
  drm/i915/tdr: Add support for per engine reset recovery
  drm/i915: Extending i915_gem_check_wedge to check engine reset in
progress
  drm/i915: Port of Added scheduler support to __wait_request() calls
  drm/i915/tdr: Add engine reset count to error state
  drm/i915/tdr: Export reset count info to debugfs
  drm/i915/tdr: Enable Engine reset and recovery support

Mika Kuoppala (1):
  drm/i915: Skip reset request if there is one already

Tomas Elf (1):
  drm/i915: Reinstate hang recovery work queue.

 drivers/gpu/drm/i915/i915_debugfs.c |  33 
 drivers/gpu/drm/i915/i915_dma.c |   1 +
 drivers/gpu/drm/i915/i915_drv.c |  73 +
 drivers/gpu/drm/i915/i915_drv.h |  39 -
 drivers/gpu/drm/i915/i915_gem.c |  96 +---
 drivers/gpu/drm/i915/i915_gpu_error.c   |   3 +
 drivers/gpu/drm/i915/i915_irq.c | 262 +++-
 drivers/gpu/drm/i915/i915_params.c  |   6 +-
 drivers/gpu/drm/i915/i915_params.h  |   2 +-
 drivers/gpu/drm/i915/intel_display.c|   4 +-
 drivers/gpu/drm/i915/intel_lrc.c| 216 --
 drivers/gpu/drm/i915/intel_lrc.h|   3 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   7 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  19 +++
 drivers/gpu/drm/i915/intel_uncore.c |  60 +++-
 15 files changed, 714 insertions(+), 110 deletions(-)

-- 
1.9.1

___
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: Replace ILK eDP underrun suppression with something better

2016-04-12 Thread Ville Syrjälä
On Tue, Apr 12, 2016 at 10:16:26AM +0200, Patrik Jakobsson wrote:
> On Fri, Apr 01, 2016 at 09:53:19PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The underruns we were seeing when enabling eDP port A on ILK seem to
> > have been caused by prematurely clearing the LP1+ watermark values when
> > disabling LP1+ watermarks. Now that the watermarks are handled
> > properly, we can rip out the underrun suppression around the port A
> > enable.
> > 
> > We still need to worry about the underruns on FDI when enabling
> > the eDP PLL. But as Bspec tells us, we can avoid that by a vblank
> > wait on the pipe driving FDI just prior to enabling the eDP PLL.
> > 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Patrik Jakobsson 

Series pushed to dinq. Thanks for the reviews.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 36 +---
> >  1 file changed, 9 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 95fe01d55bce..7523558190d1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2215,6 +2215,15 @@ static void ironlake_edp_pll_on(struct intel_dp 
> > *intel_dp)
> > POSTING_READ(DP_A);
> > udelay(500);
> >  
> > +   /*
> > +* [DevILK] Work around required when enabling DP PLL
> > +* while a pipe is enabled going to FDI:
> > +* 1. Wait for the start of vertical blank on the enabled pipe going to 
> > FDI
> > +* 2. Program DP PLL enable
> > +*/
> > +   if (IS_GEN5(dev_priv))
> > +   intel_wait_for_vblank_if_active(dev_priv->dev, !crtc->pipe);
> > +
> > intel_dp->DP |= DP_PLL_ENABLE;
> >  
> > I915_WRITE(DP_A, intel_dp->DP);
> > @@ -2630,7 +2639,6 @@ static void intel_enable_dp(struct intel_encoder 
> > *encoder)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> > uint32_t dp_reg = I915_READ(intel_dp->output_reg);
> > -   enum port port = dp_to_dig_port(intel_dp)->port;
> > enum pipe pipe = crtc->pipe;
> >  
> > if (WARN_ON(dp_reg & DP_PORT_EN))
> > @@ -2643,17 +2651,6 @@ static void intel_enable_dp(struct intel_encoder 
> > *encoder)
> >  
> > intel_dp_enable_port(intel_dp);
> >  
> > -   if (port == PORT_A && IS_GEN5(dev_priv)) {
> > -   /*
> > -* Underrun reporting for the other pipe was disabled in
> > -* g4x_pre_enable_dp(). The eDP PLL and port have now been
> > -* enabled, so it's now safe to re-enable underrun reporting.
> > -*/
> > -   intel_wait_for_vblank_if_active(dev_priv->dev, !pipe);
> > -   intel_set_cpu_fifo_underrun_reporting(dev_priv, !pipe, true);
> > -   intel_set_pch_fifo_underrun_reporting(dev_priv, !pipe, true);
> > -   }
> > -
> > edp_panel_vdd_on(intel_dp);
> > edp_panel_on(intel_dp);
> > edp_panel_vdd_off(intel_dp, true);
> > @@ -2699,26 +2696,11 @@ static void vlv_enable_dp(struct intel_encoder 
> > *encoder)
> >  
> >  static void g4x_pre_enable_dp(struct intel_encoder *encoder)
> >  {
> > -   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > enum port port = dp_to_dig_port(intel_dp)->port;
> > -   enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
> >  
> > intel_dp_prepare(encoder);
> >  
> > -   if (port == PORT_A && IS_GEN5(dev_priv)) {
> > -   /*
> > -* We get FIFO underruns on the other pipe when
> > -* enabling the CPU eDP PLL, and when enabling CPU
> > -* eDP port. We could potentially avoid the PLL
> > -* underrun with a vblank wait just prior to enabling
> > -* the PLL, but that doesn't appear to help the port
> > -* enable case. Just sweep it all under the rug.
> > -*/
> > -   intel_set_cpu_fifo_underrun_reporting(dev_priv, !pipe, false);
> > -   intel_set_pch_fifo_underrun_reporting(dev_priv, !pipe, false);
> > -   }
> > -
> > /* Only ilk+ has port A */
> > if (port == PORT_A)
> > ironlake_edp_pll_on(intel_dp);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, 
> Stockholm, Sweden Registration Number: 556189-6027 

-- 
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 12/14] drm/i915/tdr: Add engine reset count to error state

2016-04-12 Thread Arun Siluvery
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.

Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h   | 1 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2aafb2f..b4558483 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -490,6 +490,7 @@ struct drm_i915_error_state {
int hangcheck_score;
enum intel_ring_hangcheck_action hangcheck_action;
int num_requests;
+   u32 reset_count;
 
/* our own tracking of ring head and tail */
u32 cpu_ring_head;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 89725c9..76359c2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -303,6 +303,7 @@ static void i915_ring_error_state(struct 
drm_i915_error_state_buf *m,
err_printf(m, "  hangcheck: %s [%d]\n",
   hangcheck_action_to_str(ring->hangcheck_action),
   ring->hangcheck_score);
+   err_printf(m, "  engine reset count: %u\n", ring->reset_count);
 }
 
 void i915_error_printf(struct drm_i915_error_state_buf *e, const char *f, ...)
@@ -970,6 +971,8 @@ static void i915_record_ring_state(struct drm_device *dev,
 
ering->hangcheck_score = engine->hangcheck.score;
ering->hangcheck_action = engine->hangcheck.action;
+   ering->reset_count = i915_engine_reset_count(_priv->gpu_error,
+engine);
 
if (USES_PPGTT(dev)) {
int i;
-- 
1.9.1

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


[Intel-gfx] [PATCH 14/14] drm/i915/tdr: Enable Engine reset and recovery support

2016-04-12 Thread Arun Siluvery
Everything in place, flip the switch.

This feature is available only from Gen8, for previous gen devices driver
falls back to legacy full gpu reset.

Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h| 4 
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4558483..6865ffb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2617,6 +2617,10 @@ struct drm_i915_cmd_table {
 #define VEBOX_RING (1<ring_mask & BSD_RING)
 #define HAS_BSD2(dev)  (INTEL_INFO(dev)->ring_mask & BSD2_RING)
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index e4f9d6a..a322fd6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -45,7 +45,7 @@ struct i915_params i915 __read_mostly = {
.fastboot = 0,
.prefault_disable = 0,
.load_detect_test = 0,
-   .reset = 1,
+   .reset = I915_ENGINE_RESET_MASK,
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
@@ -109,7 +109,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
 module_param_named_unsafe(reset, i915.reset, int, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 
2=engine reset [default])");
 
 module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
 MODULE_PARM_DESC(enable_hangcheck,
-- 
1.9.1

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


[Intel-gfx] [PATCH 11/14] drm/i915: Port of Added scheduler support to __wait_request() calls

2016-04-12 Thread Arun Siluvery
This is a partial port of the following patch from John Harrison's GPU
scheduler patch series: (patch sent to Intel-GFX with the subject line
"[Intel-gfx] [RFC 19/39] drm/i915: Added scheduler support to __wait_request()
calls" on Fri 17 July 2015)

Author: John Harrison 
Date:   Thu Apr 10 10:48:55 2014 +0100
Subject: drm/i915: Added scheduler support to __wait_request() calls

Removed all scheduler references and backported it to this baseline. The reason
we need this is because Chris Wilson has pointed out that threads that don't
hold the struct_mutex should not be thrown out of __i915_wait_request during
TDR hang recovery. Therefore we need a way to determine which threads are
holding the mutex and which are not.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: John Harrison 
Signed-off-by: Arun Siluvery 
---

Note: These names for WAIT_INTERRUPTIBLE and WAIT_LOCKED are not consistent
with the ones used in Scheduler series, I agreed upon a consistent naming
with John Harrison but forgot to update them this time.

 drivers/gpu/drm/i915/i915_drv.h |  7 +++-
 drivers/gpu/drm/i915/i915_gem.c | 67 -
 drivers/gpu/drm/i915/intel_display.c|  4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 ++-
 4 files changed, 63 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 682bf207..2aafb2f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3115,9 +3115,14 @@ void __i915_add_request(struct drm_i915_gem_request *req,
__i915_add_request(req, NULL, true)
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, NULL, false)
+
+/* flags used by users of __i915_wait_request */
+#define WAIT_INTERRUPTIBLE  (1<<0)
+#define WAIT_LOCKED (1<<1)
+
 int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
-   bool interruptible,
+   u32 flags,
s64 *timeout,
struct intel_rps_client *rps);
 int __must_check i915_wait_request(struct drm_i915_gem_request *req);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ca8bd5..b8adf4a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1244,7 +1244,9 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
  * __i915_wait_request - wait until execution of request has finished
  * @req: duh!
  * @reset_counter: reset sequence associated with the given request
- * @interruptible: do an interruptible wait (normally yes)
+ * @flags: flags to define the nature of wait
+ *WAIT_INTERRUPTIBLE - do an interruptible wait (normally yes)
+ *WAIT_LOCKED - caller is holding struct_mutex
  * @timeout: in - how long to wait (NULL forever); out - how much time 
remaining
  *
  * Note: It is of utmost importance that the passed in seqno and reset_counter
@@ -1259,7 +1261,7 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
  */
 int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
-   bool interruptible,
+   u32 flags,
s64 *timeout,
struct intel_rps_client *rps)
 {
@@ -1268,6 +1270,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
struct drm_i915_private *dev_priv = dev->dev_private;
const bool irq_test_in_progress =
ACCESS_ONCE(dev_priv->gpu_error.test_irq_rings) & 
intel_engine_flag(engine);
+   bool interruptible = flags & WAIT_INTERRUPTIBLE;
int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
DEFINE_WAIT(wait);
unsigned long timeout_expire;
@@ -1316,22 +1319,43 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
for (;;) {
struct timer_list timer;
int reset_in_progress;
+   bool locked = flags & WAIT_LOCKED;
 
prepare_to_wait(>irq_queue, , state);
 
+   /*
+* If the driver is terminally wedged then we are stuck in
+* irrecoverable situation, just return -EIO as + there is no
+* point in having the caller retry
+*/
+   if (unlikely(i915_terminally_wedged(_priv->gpu_error))) {
+   ret = -EIO;
+   break;
+   }
+
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
+   if (reset_counter != 

[Intel-gfx] [PATCH 13/14] drm/i915/tdr: Export reset count info to debugfs

2016-04-12 Thread Arun Siluvery
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they areexpected to trigger reset; these counts are checked before
and after the test to ensure the same.

Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9640738..9fa39e4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4758,6 +4758,38 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
i915_wedged_get, i915_wedged_set,
"%llu\n");
 
+
+static ssize_t i915_reset_info_read(struct file *filp, char __user *ubuf,
+   size_t max, loff_t *ppos)
+{
+   int len;
+   char buf[300];
+   struct drm_device *dev = filp->private_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   struct intel_engine_cs *engine;
+
+   len = scnprintf(buf, sizeof(buf), "full gpu reset = %u\n",
+   i915_reset_count(error));
+
+   for_each_engine(engine, dev_priv) {
+   len += scnprintf(buf + len, sizeof(buf) - len,
+"%s = %u\n", engine->name,
+i915_engine_reset_count(error, engine));
+   }
+
+   len += scnprintf(buf + len - 1, sizeof(buf) - len, "\n");
+
+   return simple_read_from_buffer(ubuf, max, ppos, buf, len);
+}
+
+static const struct file_operations i915_reset_info_fops = {
+   .owner = THIS_MODULE,
+   .open = simple_open,
+   .read = i915_reset_info_read,
+   .llseek = default_llseek,
+};
+
 static int
 i915_ring_stop_get(void *data, u64 *val)
 {
@@ -5414,6 +5446,7 @@ static const struct i915_debugfs_files {
const struct file_operations *fops;
 } i915_debugfs_files[] = {
{"i915_wedged", _wedged_fops},
+   {"i915_reset_info", _reset_info_fops},
{"i915_max_freq", _max_freq_fops},
{"i915_min_freq", _min_freq_fops},
{"i915_cache_sharing", _cache_sharing_fops},
-- 
1.9.1

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


[Intel-gfx] [PATCH 06/14] drm/i915/tdr: Capture engine state before reset

2016-04-12 Thread Arun Siluvery
Minimal state of engine is saved before resetting it, this state includes
head, current active request.

A consistency check is performed on the active request to make sure that
the context HW is executing is same as the one for the active request. This
check is important because engine recovery in execlist mode relies on the
context resubmission after reset. If the state is inconsistent,
resubmission can cause unforseen side-effects such as unexpected
preemptions.

Engine is restarted after reset with this state.

Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_lrc.c| 85 +
 drivers/gpu/drm/i915/intel_lrc.h|  3 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 10 
 3 files changed, 98 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index edae3ed..5bfc93d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1188,6 +1188,87 @@ void intel_lr_context_unpin(struct intel_context *ctx,
}
 }
 
+/**
+ * intel_execlist_get_current_request() - returns request currently processed
+ * by the given engine
+ *
+ * @engine: Engine currently running context to be returned.
+ *
+ * Returns:
+ *  req - if a valid req is found in the execlist queue and HW also agrees.
+ *caller has to dereference at the end of its lifecycle.
+ *  NULL - otherwise
+ */
+static struct drm_i915_gem_request *
+intel_execlist_get_current_request(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv;
+   struct drm_i915_gem_request *req;
+   unsigned long flags;
+
+   dev_priv = engine->dev->dev_private;
+
+   spin_lock_irqsave(>execlist_lock, flags);
+
+   req = list_first_entry_or_null(>execlist_queue,
+  struct drm_i915_gem_request,
+  execlist_link);
+   /*
+* Only acknowledge the request in the execlist queue if it's actually
+* been submitted to hardware, otherwise there's the risk of
+* inconsistency between the (unsubmitted) request and the idle
+* hardware state.
+*/
+   if (req && req->ctx && req->elsp_submitted) {
+   u32 execlist_status;
+   u32 hw_context;
+   u32 hw_active;
+   u32 sw_context;
+
+   hw_context = I915_READ(RING_EXECLIST_STATUS_CTX_ID(engine));
+   execlist_status = I915_READ(RING_EXECLIST_STATUS_LO(engine));
+   hw_active = ((execlist_status & 
EXECLIST_STATUS_ELEMENT0_ACTIVE) ||
+(execlist_status & 
EXECLIST_STATUS_ELEMENT1_ACTIVE));
+
+   sw_context = intel_execlists_ctx_id(req->ctx, engine);
+
+   /* If both HW and driver agrees then we found it */
+   if (hw_active && hw_context == sw_context)
+   i915_gem_request_reference(req);
+   } else {
+   req = NULL;
+   WARN(1, "No active request for %s\n", engine->name);
+   }
+
+   spin_unlock_irqrestore(>execlist_lock, flags);
+
+   return req;
+}
+
+/**
+ * gen8_engine_state_save() - save minimum engine state
+ * @engine: engine whose state is to be saved
+ * @state: location where the state is saved
+ *
+ * captured engine state includes head, tail, active request. After reset,
+ * engine is restarted with this state.
+ *
+ * Returns:
+ * 0 if ok, otherwise propagates error codes.
+ */
+static int gen8_engine_state_save(struct intel_engine_cs *engine,
+ struct intel_engine_cs_state *state)
+{
+   struct drm_i915_private *dev_priv = engine->dev->dev_private;
+
+   state->head = I915_READ_HEAD(engine);
+   state->req = intel_execlist_get_current_request(engine);
+   if (!state->req)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int intel_logical_ring_workarounds_emit(struct drm_i915_gem_request 
*req)
 {
int ret, i;
@@ -2091,6 +2172,10 @@ logical_ring_default_vfuncs(struct drm_device *dev,
engine->emit_bb_start = gen8_emit_bb_start;
engine->get_seqno = gen8_get_seqno;
engine->set_seqno = gen8_set_seqno;
+
+   /* engine reset supporting functions */
+   engine->save = gen8_engine_state_save;
+
if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
engine->irq_seqno_barrier = bxt_a_seqno_barrier;
engine->set_seqno = bxt_a_set_seqno;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 0b0853e..d7e22fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -29,7 +29,10 @@
 /* Execlists regs */
 #define RING_ELSP(ring)_MMIO((ring)->mmio_base 
+ 0x230)
 #define RING_EXECLIST_STATUS_LO(ring)  _MMIO((ring)->mmio_base + 0x234)
+#define   

[Intel-gfx] [PATCH 10/14] drm/i915: Extending i915_gem_check_wedge to check engine reset in progress

2016-04-12 Thread Arun Siluvery
i915_gem_check_wedge now returns a non-zero result in three different cases:

1. Legacy: A hang has been detected and full GPU reset is in progress.

2. Per-engine recovery:
   a. A single engine reference can be passed to the function, in which
   case only that engine will be checked. If that particular engine is
   detected to be hung and is to be reset this will yield a non-zero result
   but not if reset is in progress for any other engine.

   b. No engine reference is passed to the function, in which case all
   engines are checked for ongoing per-engine hang recovery.

Also, i915_wait_request was updated to take advantage of this new
functionality. This is important since the TDR hang recovery mechanism needs a
way to force waiting threads that hold the struct_mutex to give up the
struct_mutex and try again after the hang recovery has completed. If
i915_wait_request does not take per-engine hang recovery into account there is
no way for a waiting thread to know that a per-engine recovery is about to
happen and that it needs to back off.

Signed-off-by: Tomas Elf 
Signed-off-by: Ian Lister 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 39 +++--
 drivers/gpu/drm/i915/intel_lrc.c|  1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  1 +
 4 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eda531f..682bf207 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3052,6 +3052,7 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine);
 bool i915_gem_retire_requests(struct drm_device *dev);
 void i915_gem_retire_requests_ring(struct intel_engine_cs *engine);
 int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
+ struct intel_engine_cs *engine,
  bool interruptible);
 
 static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c62583..5ca8bd5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -80,12 +80,29 @@ static void i915_gem_info_remove_obj(struct 
drm_i915_private *dev_priv,
spin_unlock(_priv->mm.object_stat_lock);
 }
 
+static bool i915_engine_reset_pending(struct i915_gpu_error *error,
+struct intel_engine_cs *engine)
+{
+   int i;
+
+   if (engine)
+   return i915_engine_reset_in_progress(error, engine->id);
+
+   for (i = 0; i < I915_NUM_ENGINES; ++i) {
+   if (i915_engine_reset_in_progress(error, i))
+   return true;
+   }
+
+   return false;
+}
+
 static int
 i915_gem_wait_for_error(struct i915_gpu_error *error)
 {
int ret;
 
 #define EXIT_COND (!i915_reset_in_progress(error) || \
+  !i915_engine_reset_pending(error, NULL) ||   \
   i915_terminally_wedged(error))
if (EXIT_COND)
return 0;
@@ -1112,9 +1129,11 @@ put_rpm:
 
 int
 i915_gem_check_wedge(struct i915_gpu_error *error,
+struct intel_engine_cs *engine,
 bool interruptible)
 {
-   if (i915_reset_in_progress(error)) {
+   if (i915_reset_in_progress(error) ||
+   i915_engine_reset_pending(error, engine)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1296,16 +1315,22 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
 
for (;;) {
struct timer_list timer;
+   int reset_in_progress;
 
prepare_to_wait(>irq_queue, , state);
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != 
atomic_read(_priv->gpu_error.reset_counter)) {
+   reset_in_progress = i915_gem_check_wedge(_priv->gpu_error,
+NULL,
+interruptible);
+   if (reset_counter != 
atomic_read(_priv->gpu_error.reset_counter) ||
+   reset_in_progress) {
/* ... but upgrade the -EAGAIN to an -EIO if the gpu
 * is truely gone. */
-   ret = i915_gem_check_wedge(_priv->gpu_error, 
interruptible);
-   if (ret == 0)
+   if (reset_in_progress)
+   ret = 

[Intel-gfx] [PATCH 08/14] drm/i915/tdr: Add support for per engine reset recovery

2016-04-12 Thread Arun Siluvery
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.

Hangchecker determines which engines are hung and invokes error handler to
recover from it. Error handler schedules recovery for each of those engines
that are hung. The recovery procedure is as follows,
 - force engine to idle: this is done by issuing a reset request
 - save current state which includes head and current request
 - reset engine
 - restore saved state and resubmit context

If engine reset fails then we fall back to heavy weight full gpu reset
which resets all engines and reinitiazes complete state of HW and SW.

Possible reasons for failure,
 - engine not ready for reset
 - if the HW and SW doesn't agree on the context that caused the hang
 - reset itself failed for some reason

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.c | 54 +++--
 drivers/gpu/drm/i915/i915_drv.h |  4 +++
 drivers/gpu/drm/i915/i915_gem.c |  4 +--
 drivers/gpu/drm/i915/intel_uncore.c | 37 +
 4 files changed, 95 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1933f87..227ad42 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -970,10 +970,60 @@ int i915_reset(struct drm_device *dev)
  */
 int i915_reset_engine(struct intel_engine_cs *engine)
 {
+   struct drm_device *dev = engine->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_engine_cs_state state;
int ret;
 
-   /* FIXME: replace me with engine reset sequence */
-   ret = -ENODEV;
+   WARN_ON(!mutex_is_locked(>struct_mutex));
+
+   i915_gem_reset_engine_status(dev_priv, engine);
+
+   /*Take wake lock to prevent power saving mode */
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+   ret = intel_request_for_reset(engine);
+   if (ret) {
+   DRM_ERROR("Failed to disable %s\n", engine->name);
+   goto out;
+   }
+
+   ret = engine->save(engine, );
+   if (ret)
+   goto enable_engine;
+
+   ret = intel_gpu_reset(dev, intel_engine_flag(engine));
+   if (ret) {
+   DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
+   goto enable_engine;
+   }
+
+   ret = engine->init_hw(engine);
+   if (ret)
+   goto out;
+
+   /*
+* Restart the engine after reset.
+* Engine state is first restored and the context is resubmitted.
+*/
+   engine->start(engine, );
+
+enable_engine:
+   /*
+* we only need to enable engine if we cannot either save engine state
+* or reset fails. If the reset is successful, engine gets enabled
+* automatically so we can skip this step.
+*/
+   if (ret)
+   intel_clear_reset_request(engine);
+
+out:
+   if (state.req)
+   i915_gem_request_unreference(state.req);
+
+   /* Wake up anything waiting on this engine's queue */
+   wake_up_all(>irq_queue);
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb34107..eda531f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2754,6 +2754,8 @@ extern long i915_compat_ioctl(struct file *filp, unsigned 
int cmd,
  unsigned long arg);
 #endif
 extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
+extern int intel_request_for_reset(struct intel_engine_cs *engine);
+extern int intel_clear_reset_request(struct intel_engine_cs *engine);
 extern bool intel_has_gpu_reset(struct drm_device *dev);
 extern bool intel_has_engine_reset_support(struct intel_engine_cs *engine);
 extern int i915_reset(struct drm_device *dev);
@@ -3094,6 +3096,8 @@ static inline bool i915_stop_ring_allow_warn(struct 
drm_i915_private *dev_priv)
 }
 
 void i915_gem_reset(struct drm_device *dev);
+void i915_gem_reset_engine_status(struct drm_i915_private *dev_priv,
+ struct intel_engine_cs *ring);
 bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
 int __must_check i915_gem_init(struct drm_device *dev);
 int i915_gem_init_engines(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a76..4c62583 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2802,8 +2802,8 @@ i915_gem_find_active_request(struct 

[Intel-gfx] [PATCH 07/14] drm/i915/tdr: Restore engine state and start after reset

2016-04-12 Thread Arun Siluvery
We capture the state of an engine before resetting it, once the reset is
successful engine is restored with the same state and restarted.

The state includes head register and active request. We also nudge the head
forward if it hasn't advanced, otherwise when the engine is restarted HW
executes the same instruction and may hang again. Generally head
automatically advances to the next instruction as soon as HW reads current
instruction, without waiting for it to complete, however a MBOX wait
inserted directly to VCS/BCS engines doesn't behave in the same way,
instead head will still be pointing at the same instruction until it
completes.

If the head is modified, this is also updated in the context image so that
HW sees up to date value.

A valid request is expected in the state at this point otherwise we
wouldn't have reached this point, the context that submitted this request
is resubmitted to HW. The request that caused the hang would be at the
start of execlist queue, unless we resubmit and complete this request, it
cannot be removed from the queue.

Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_lrc.c| 94 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 
 2 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5bfc93d..86d5e18 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -505,6 +505,30 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine,
execlists_submit_requests(req0, req1, tdr_resubmission);
 }
 
+/**
+ * intel_execlists_resubmit()
+ * @engine: engine to do resubmission for
+ *
+ * In execlists mode, engine reset postprocess mainly includes resubmission of
+ * context after reset, for this we bypass the execlist queue. This is
+ * necessary since at the point of TDR hang recovery the hardware will be hung
+ * and resubmitting a fixed context (the context that the TDR has identified
+ * as hung and fixed up in order to move past the blocking batch buffer) to a
+ * hung execlist queue will lock up the TDR.  Instead, opt for direct ELSP
+ * submission without depending on the rest of the driver.
+ */
+static void intel_execlists_resubmit(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+
+   if (WARN_ON(list_empty(>execlist_queue)))
+   return;
+
+   spin_lock_irqsave(>execlist_lock, flags);
+   execlists_context_unqueue(engine, true);
+   spin_unlock_irqrestore(>execlist_lock, flags);
+}
+
 static unsigned int
 execlists_check_remove_request(struct intel_engine_cs *engine, u32 request_id)
 {
@@ -1269,6 +1293,75 @@ static int gen8_engine_state_save(struct intel_engine_cs 
*engine,
return 0;
 }
 
+/**
+ * gen8_engine_start() - restore saved state and start engine
+ * @engine: engine to be started
+ * @state: state to be restored
+ *
+ * Returns:
+ * 0 if ok, otherwise propagates error codes.
+ */
+static int gen8_engine_start(struct intel_engine_cs *engine,
+struct intel_engine_cs_state *state)
+{
+   u32 head;
+   u32 head_addr, tail_addr;
+   u32 *reg_state;
+   struct intel_ringbuffer *ringbuf;
+   struct intel_context *ctx;
+   struct drm_i915_private *dev_priv = engine->dev->dev_private;
+
+   ctx = state->req->ctx;
+   ringbuf = ctx->engine[engine->id].ringbuf;
+   reg_state = ctx->engine[engine->id].lrc_reg_state;
+
+   head = state->head;
+   head_addr = head & HEAD_ADDR;
+
+   if (head == engine->hangcheck.last_head) {
+   /*
+* The engine has not advanced since the last time it hung,
+* force it to advance to the next QWORD. In most cases the
+* engine head pointer will automatically advance to the
+* next instruction as soon as it has read the current
+* instruction, without waiting for it to complete. This
+* seems to be the default behaviour, however an MBOX wait
+* inserted directly to the VCS/BCS engines does not behave
+* in the same way, instead the head pointer will still be
+* pointing at the MBOX instruction until it completes.
+*/
+   head_addr = roundup(head_addr, 8);
+   engine->hangcheck.last_head = head;
+   } else if (head_addr & 0x7) {
+   /* Ensure head pointer is pointing to a QWORD boundary */
+   head_addr = ALIGN(head_addr, 8);
+   }
+
+   tail_addr = reg_state[CTX_RING_TAIL+1] & TAIL_ADDR;
+
+   if (head_addr > tail_addr)
+   head_addr = tail_addr;
+   else if (head_addr >= ringbuf->size)
+   head_addr = 0;
+
+   head &= ~HEAD_ADDR;
+   head |= (head_addr 

[Intel-gfx] [PATCH 05/14] drm/i915/tdr: Prepare execlist submission to handle tdr resubmission after reset

2016-04-12 Thread Arun Siluvery
To resume execution after engine reset we resubmit the context and this
needs to be treated differently otherwise we would count it as a completely
new submission. This change modifies the submission path to account for
this.

During resubmission we only submit the head request that caused the hang,
once this is done then we continue with the normally submission of two
contexts at a time. The intention is to restore the submission state at the
time of hang.

Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_lrc.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0d6dc5e..edae3ed 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -358,7 +358,8 @@ u32 intel_execlists_ctx_id(struct intel_context *ctx,
 }
 
 static void execlists_elsp_write(struct drm_i915_gem_request *rq0,
-struct drm_i915_gem_request *rq1)
+struct drm_i915_gem_request *rq1,
+bool tdr_resubmission)
 {
 
struct intel_engine_cs *engine = rq0->engine;
@@ -368,13 +369,15 @@ static void execlists_elsp_write(struct 
drm_i915_gem_request *rq0,
 
if (rq1) {
desc[1] = intel_lr_context_descriptor(rq1->ctx, rq1->engine);
-   rq1->elsp_submitted++;
+   if (!tdr_resubmission)
+   rq1->elsp_submitted++;
} else {
desc[1] = 0;
}
 
desc[0] = intel_lr_context_descriptor(rq0->ctx, rq0->engine);
-   rq0->elsp_submitted++;
+   if (!tdr_resubmission)
+   rq0->elsp_submitted++;
 
/* You must always write both descriptors in the order below. */
I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
@@ -415,7 +418,8 @@ static void execlists_update_context(struct 
drm_i915_gem_request *rq)
 }
 
 static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
- struct drm_i915_gem_request *rq1)
+ struct drm_i915_gem_request *rq1,
+ bool tdr_resubmission)
 {
struct drm_i915_private *dev_priv = rq0->i915;
 
@@ -427,13 +431,14 @@ static void execlists_submit_requests(struct 
drm_i915_gem_request *rq0,
spin_lock_irq(_priv->uncore.lock);
intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
 
-   execlists_elsp_write(rq0, rq1);
+   execlists_elsp_write(rq0, rq1, tdr_resubmission);
 
intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
spin_unlock_irq(_priv->uncore.lock);
 }
 
-static void execlists_context_unqueue(struct intel_engine_cs *engine)
+static void execlists_context_unqueue(struct intel_engine_cs *engine,
+ bool tdr_resubmission)
 {
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
struct drm_i915_gem_request *cursor, *tmp;
@@ -451,6 +456,19 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
 execlist_link) {
if (!req0) {
req0 = cursor;
+
+   /*
+* Only submit head request if this is a resubmission
+* following engine reset. The intention is to restore
+* the original submission state from the situation
+* when the hang originally happened. Once the request
+* that caused the hang is resubmitted we can continue
+* normally by submitting two request at a time.
+*/
+   if (tdr_resubmission) {
+   req1 = NULL;
+   break;
+   }
} else if (req0->ctx == cursor->ctx) {
/* Same ctx: ignore first request, as second request
 * will update tail past first request's workload */
@@ -484,7 +502,7 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
req0->tail &= ringbuf->size - 1;
}
 
-   execlists_submit_requests(req0, req1);
+   execlists_submit_requests(req0, req1, tdr_resubmission);
 }
 
 static unsigned int
@@ -599,7 +617,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (submit_contexts) {
if (!engine->disable_lite_restore_wa ||
(csb[i][0] & GEN8_CTX_STATUS_ACTIVE_IDLE))
-   execlists_context_unqueue(engine);
+   execlists_context_unqueue(engine, false);
}
 
spin_unlock(>execlist_lock);
@@ -642,7 +660,7 @@ static void 

[Intel-gfx] [PATCH 09/14] drm/i915: Skip reset request if there is one already

2016-04-12 Thread Arun Siluvery
From: Mika Kuoppala 

To perform engine reset we first disable engine to capture its state. This
is done by issuing a reset request. Because we are reusing existing
infrastructure, again when we actually reset an engine, reset function
checks engine mask and issues reset request again which is unnecessary. To
avoid this we check if the engine is already prepared, if so we just exit
from that point.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_uncore.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 3bfda85..d4b8c82 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1585,12 +1585,17 @@ static int gen8_request_engine_reset(struct 
intel_engine_cs *engine)
 {
int ret;
struct drm_i915_private *dev_priv = engine->dev->dev_private;
+   const i915_reg_t reset_ctrl = RING_RESET_CTL(engine->mmio_base);
+   const u32 ready = RESET_CTL_REQUEST_RESET | RESET_CTL_READY_TO_RESET;
 
-   I915_WRITE_FW(RING_RESET_CTL(engine->mmio_base),
- _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
+   /* If engine has been already prepared, we can shortcut here */
+   if ((I915_READ_FW(reset_ctrl) & ready) == ready)
+   return 0;
+
+   I915_WRITE_FW(reset_ctrl, _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
 
ret = wait_for_register_fw(dev_priv,
-  RING_RESET_CTL(engine->mmio_base),
+  reset_ctrl,
   RESET_CTL_READY_TO_RESET,
   RESET_CTL_READY_TO_RESET,
   700);
-- 
1.9.1

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


[Intel-gfx] [PATCH 04/14] drm/i915/tdr: Modify error handler for per engine hang recovery

2016-04-12 Thread Arun Siluvery
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at this point
because core implementation is lacking) and continue recovery using legacy
full gpu reset.

A helper function is also added to query whether engine reset is available
on a particular engine because this can be controlled on an engine basis to
help with a hypothetical situtation of a bad engine e.g., engine reset
works fine for render but fails on blitter. Engine reset is chosen only
when all engines support this otherwise we fallback to full gpu reset.

i915.reset is already prepared for this purpose. It now accepts a mask
formed of exec_id indicating whether that engine supports engine reset or
not, default is full gpu reset for now.

i915.reset == 1, full gpu reset
i915.reset == mask of exec_id, eg: (1 << I915_EXEC_RENDER) | ...;

Engine reset and full gpu reset sections are also extracted to separate
functions, it helps readability and branching between reset type simpler.

The error events behaviour that are used to notify user of reset are
adapted to engine reset such that it doesn't break users listening to these
events. In legacy we report an error event, a reset event before resetting
the gpu and a reset done event marking the completion of reset. The same
behaviour is adapted but reset event is only dispatched once even when
multiple engines are hung. Finally once reset is complete we send reset
done event as usual.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Ian Lister 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.c |  23 
 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_irq.c | 233 ++--
 drivers/gpu/drm/i915/intel_uncore.c |  12 ++
 4 files changed, 206 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79..1933f87 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -955,6 +955,29 @@ int i915_reset(struct drm_device *dev)
return 0;
 }
 
+/**
+ * i915_reset_engine - reset GPU engine to recover from a hang
+ * @engine: engine to reset
+ *
+ * Reset a specific GPU engine. Useful if a hang is detected.
+ * Returns zero on successful reset or otherwise an error code.
+ *
+ * Procedure is fairly simple:
+ *  - force engine to idle
+ *  - save current state which includes head and current request
+ *  - reset engine
+ *  - restore saved state and resubmit context
+ */
+int i915_reset_engine(struct intel_engine_cs *engine)
+{
+   int ret;
+
+   /* FIXME: replace me with engine reset sequence */
+   ret = -ENODEV;
+
+   return ret;
+}
+
 static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
 {
struct intel_device_info *intel_info =
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 674d2ab..bb34107 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2755,7 +2755,9 @@ extern long i915_compat_ioctl(struct file *filp, unsigned 
int cmd,
 #endif
 extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_device *dev);
+extern bool intel_has_engine_reset_support(struct intel_engine_cs *engine);
 extern int i915_reset(struct drm_device *dev);
+extern int i915_reset_engine(struct intel_engine_cs *engine);
 extern int intel_guc_reset(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6f6a2a2..468058d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2473,6 +2473,89 @@ static void i915_error_wake_up(struct drm_i915_private 
*dev_priv,
wake_up_all(_priv->gpu_error.reset_queue);
 }
 
+static int i915_reset_engines(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   int ret;
+   struct i915_gpu_error *error = _priv->gpu_error;
+
+   if (!i915_engine_reset_in_progress(error, engine->id))
+   continue;
+
+   ret = i915_reset_engine(engine);
+   if (ret) {
+   struct intel_engine_cs *e;
+
+   DRM_ERROR("Reset of %s failed! ret=%d",
+ engine->name, ret);
+
+   /*
+* when 

[Intel-gfx] [PATCH 02/14] drm/i915/tdr: Extend the idea of reset_counter to engine reset

2016-04-12 Thread Arun Siluvery
This change extends the idea of reset_counter variable to engine reset by
creating additional variables for each engine. Least significant bit is set
to mark the engine reset is pending and once reset is successful it is
incremented again, this is further used to count the no of engine resets.

Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5424016..ca9b1ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1370,6 +1370,12 @@ struct i915_gpu_error {
 #define I915_RESET_IN_PROGRESS_FLAG1
 #define I915_WEDGED(1 << 31)
 
+   /* indicates request to reset engine */
+#define I915_ENGINE_RESET_IN_PROGRESS  (1<<0)
+
+   /* extending the idea of reset_counter to engine reset */
+   atomic_t engine_reset_counter[I915_NUM_ENGINES];
+
/**
 * Waitqueue to signal when the reset has completed. Used by clients
 * that wait for dev_priv->mm.wedged to settle.
@@ -3059,6 +3065,19 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return ((atomic_read(>reset_counter) & ~I915_WEDGED) + 1) / 2;
 }
 
+static inline bool i915_engine_reset_in_progress(struct i915_gpu_error *error,
+u32 engine_id)
+{
+   return unlikely(atomic_read(>engine_reset_counter[engine_id])
+   & I915_ENGINE_RESET_IN_PROGRESS);
+}
+
+static inline u32 i915_engine_reset_count(struct i915_gpu_error *error,
+ struct intel_engine_cs *engine)
+{
+   return (atomic_read(>engine_reset_counter[engine->id]) + 1) / 2;
+}
+
 static inline bool i915_stop_ring_allow_ban(struct drm_i915_private *dev_priv)
 {
return dev_priv->gpu_error.stop_rings == 0 ||
-- 
1.9.1

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


[Intel-gfx] [PATCH 03/14] drm/i915: Reinstate hang recovery work queue.

2016-04-12 Thread Arun Siluvery
From: Tomas Elf 

There used to be a work queue separating the error handler from the hang
recovery path, which was removed a while back in this commit:

commit b8d24a06568368076ebd5a858a011699a97bfa42
Author: Mika Kuoppala 
Date:   Wed Jan 28 17:03:14 2015 +0200

drm/i915: Remove nested work in gpu error handling

Now we need to revert most of that commit since the work queue separating
hang detection from hang recovery is needed in preparation for the upcoming
watchdog timeout feature. The watchdog interrupt service routine will be a
second callsite of the error handler alongside the periodic hang checker,
which runs in a work queue context. Seeing as the error handler will be
serving a caller in a hard interrupt execution context that means that the
error handler must never end up in a situation where it needs to grab the
struct_mutex.  Unfortunately, that is exactly what we need to do first at
the start of the hang recovery path, which might potentially sleep if the
struct_mutex is already held by another thread. Not good when you're in a
hard interrupt context.

Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_dma.c |  1 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c | 29 ++---
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b377753..6a642bd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1451,6 +1451,7 @@ int i915_driver_unload(struct drm_device *dev)
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_destroy_error_state(dev);
+   cancel_work_sync(_priv->gpu_error.work);
 
/* Flush any outstanding unpin_work. */
flush_workqueue(dev_priv->wq);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca9b1ec..674d2ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1341,6 +1341,7 @@ struct i915_gpu_error {
spinlock_t lock;
/* Protected by the above dev->gpu_error.lock. */
struct drm_i915_error_state *first_error;
+   struct work_struct work;
 
unsigned long missed_irq_rings;
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 679f08c..6f6a2a2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2474,16 +2474,19 @@ static void i915_error_wake_up(struct drm_i915_private 
*dev_priv,
 }
 
 /**
- * i915_reset_and_wakeup - do process context error handling work
- * @dev: drm device
+ * i915_error_work_func - do process context error handling work
+ * @work: work item containing error struct, passed by the error handler
  *
  * Fire an error uevent so userspace can see that a hang or error
  * was detected.
  */
-static void i915_reset_and_wakeup(struct drm_device *dev)
+static void i915_error_work_func(struct work_struct *work)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_gpu_error *error = _priv->gpu_error;
+   struct i915_gpu_error *error = container_of(work, struct i915_gpu_error,
+   work);
+   struct drm_i915_private *dev_priv =
+   container_of(error, struct drm_i915_private, gpu_error);
+   struct drm_device *dev = dev_priv->dev;
char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
@@ -2693,7 +2696,19 @@ void i915_handle_error(struct drm_device *dev, u32 
engine_mask,
i915_error_wake_up(dev_priv, false);
}
 
-   i915_reset_and_wakeup(dev);
+   /*
+* Our reset work can grab modeset locks (since it needs to reset the
+* state of outstanding pageflips). Hence it must not be run on our own
+* dev-priv->wq work queue for otherwise the flush_work in the pageflip
+* code will deadlock.
+* If error_work is already in the work queue then it will not be added
+* again. It hasn't yet executed so it will see the reset flags when
+* it is scheduled. If it isn't in the queue or it is currently
+* executing then this call will add it to the queue again so that
+* even if it misses the reset flags during the current call it is
+* guaranteed to see them on the next call.
+*/
+   schedule_work(_priv->gpu_error.work);
 }
 
 /* Called from drm generic code, passed 'crtc' which
@@ -4591,7 +4606,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
struct drm_device *dev = dev_priv->dev;
 
 

[Intel-gfx] [PATCH 01/14] drm/i915: Update i915.reset to handle engine resets

2016-04-12 Thread Arun Siluvery
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_params.c | 6 +++---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..e4f9d6a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -45,7 +45,7 @@ struct i915_params i915 __read_mostly = {
.fastboot = 0,
.prefault_disable = 0,
.load_detect_test = 0,
-   .reset = true,
+   .reset = 1,
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
@@ -108,8 +108,8 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-module_param_named_unsafe(reset, i915.reset, bool, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
+module_param_named_unsafe(reset, i915.reset, int, 0600);
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
 
 module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
 MODULE_PARM_DESC(enable_hangcheck,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..9b13c10 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -34,6 +34,7 @@ struct i915_params {
int lvds_channel_mode;
int panel_use_ssc;
int vbt_sdvo_panel_type;
+   int reset;
int enable_rc6;
int enable_dc;
int enable_fbc;
@@ -55,7 +56,6 @@ struct i915_params {
bool fastboot;
bool prefault_disable;
bool load_detect_test;
-   bool reset;
bool disable_display;
bool enable_guc_submission;
bool verbose_state_checks;
-- 
1.9.1

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Split execlists hardware status page initialisation from setup

2016-04-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Split execlists hardware status 
page initialisation from setup
URL   : https://patchwork.freedesktop.org/series/5596/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
pass   -> FAIL   (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ivb-t430s)

bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:202  pass:163  dwarn:0   dfail:0   fail:0   skip:39 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ivb-t430stotal:203  pass:174  dwarn:0   dfail:0   fail:1   skip:28 
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:203  pass:164  dwarn:0   dfail:0   fail:1   skip:38 
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1875/

42189a46296988a9e16b57dca9e25c22745b drm-intel-nightly: 
2016y-04m-12d-14h-35m-43s UTC integration manifest
6d8f2e9 drm/i915: Use new i915_gem_object_pin_map for LRC
f1b4a09 drm/i915: Split execlists hardware status page initialisation from setup

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev3)

2016-04-12 Thread Patchwork
== Series Details ==

Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev3)
URL   : https://patchwork.freedesktop.org/series/5367/
State : failure

== Summary ==

Series 5367v3 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport
http://patchwork.freedesktop.org/api/1.0/series/5367/revisions/3/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_basic:
Subgroup create-close:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_exec:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup invalid-param-get:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-blt:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_create:
Subgroup basic:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-copy:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-read:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-read-distinct:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pread:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pwrite:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-bsd:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-render:
pass   -> INCOMPLETE (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup bad-pitch-128:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-256:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup clobberred-modifier:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup size-max:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup unused-offsets:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-FAIL (bsw-nuc-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup hang-read-crc-pipe-a:
pass   -> INCOMPLETE (snb-dellxps)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
Test pm_rps:
Subgroup basic-api:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:185  pass:119  dwarn:19  dfail:3   fail:0   skip:43 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ivb-t430stotal:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:203  pass:177  dwarn:1   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:33   pass:26   dwarn:0   dfail:0   fail:0   skip:6  
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1874/

42189a46296988a9e16b57dca9e25c22745b drm-intel-nightly: 
2016y-04m-12d-14h-35m-43s UTC integration manifest
5be1245 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

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


Re: [Intel-gfx] [PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

2016-04-12 Thread kbuild test robot
Hi Maarten,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.6-rc3 next-20160412]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-core-Add-drm_accurate_vblank_count-v3/20160412-223507
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2663: warning: No description found for 
parameter 'fmt'
   include/drm/drm_crtc.h:364: warning: No description found for parameter 
'mode_blob'
   include/drm/drm_crtc.h:779: warning: No description found for parameter 
'name'
   include/drm/drm_crtc.h:1238: warning: No description found for parameter 
'connector_id'
   include/drm/drm_crtc.h:1238: warning: No description found for parameter 
'tile_blob_ptr'
   include/drm/drm_crtc.h:1277: warning: No description found for parameter 
'rotation'
   include/drm/drm_crtc.h:1539: warning: No description found for parameter 
'name'
   include/drm/drm_crtc.h:1539: warning: No description found for parameter 
'mutex'
   include/drm/drm_crtc.h:1539: warning: No description found for parameter 
'helper_private'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tile_idr'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'connector_ida'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'delayed_event'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'edid_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'dpms_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'path_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tile_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'plane_type_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'rotation_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_src_x'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_src_y'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_src_w'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_src_h'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_crtc_x'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_crtc_y'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_crtc_w'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_overscan_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_saturation_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'tv_hue_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'scaling_mode_property'
   include/drm/drm_crtc.h:2175: warning: No description found for parameter 
'aspect_ratio_property'
   include/drm/drm_crtc.h:2175: w

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2)

2016-04-12 Thread Dave Gordon

On 12/04/16 17:03, Patchwork wrote:

== Series Details ==

Series: series starting with drm/i915: check for ERR_PTR from 
i915_gem_object_pin_map() (rev2)
URL   : https://patchwork.freedesktop.org/series/5591/
State : failure

== Summary ==

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

Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 pass   -> FAIL   (snb-x220t)


https://bugs.freedesktop.org/show_bug.cgi?id=94294

"basic-flip-vs-wf_vblank timestamp vs. seq counter difference"


bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23
bsw-nuc-2total:202  pass:162  dwarn:1   dfail:0   fail:0   skip:39
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19
ivb-t430stotal:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11
snb-x220ttotal:203  pass:164  dwarn:0   dfail:0   fail:2   skip:37
BOOT FAILED for ilk-hp8440p
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1872/

d89f227a17b175fce74e11b2d5fa2a41f86fc489 drm-intel-nightly: 
2016y-04m-12d-13h-31m-26s UTC integration manifest
33d810a drm/i915: Mark obj->mapping as dirtying the backing storage
0d172b1 drm/i915: check for ERR_PTR from i915_gem_object_pin_map()



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


Re: [Intel-gfx] [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 04:56:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Similarly to i915_gem_object_pin_map on LLC platforms, we can
> use the new VMA based io mapping on !LLC to decrease the cost
> of ringbuf pinning and unpinning.

If you are going to mention pin_map, you open up the discussion that we
can avoid the mappable apertures requirement on !llc if we use pin_map
with a pgprot_writecombine. That's my preferred solution, caching the
ioremap is just a stopgap, or fallback for when we can't use direct CPU
access.
-Chris

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


Re: [Intel-gfx] [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote:
> From: Chris Wilson 
> 
> By tracking the iomapping on the VMA itself, we can share that area
> between multiple users. Also by only revoking the iomapping upon
> unbinding from the mappable portion of the GGTT, we can keep that iomap
> across multiple invocations (e.g. execlists context pinning).
> 
> v2:
>   * Rebase on nightly;
>   * added kerneldoc. (Tvrtko Ursulin)
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_gem.c |  2 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 38 
> +
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 38 
> +
>  drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-
>  4 files changed, 81 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b37ffea8b458..6a485630595e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
> wait)
>   ret = i915_gem_object_put_fence(obj);
>   if (ret)
>   return ret;
> +
> + i915_vma_iounmap(vma);
>   }
>  
>   trace_i915_vma_unbind(vma);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index c5cb04907525..b2a8a14e8dcb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
>   return obj->base.size;
>   }
>  }
> +
> +void *i915_vma_iomap(struct drm_i915_private *dev_priv,
> +  struct i915_vma *vma)
> +{
> + struct drm_i915_gem_object *obj = vma->obj;
> + struct i915_ggtt *ggtt = _priv->ggtt;
> +
> + if (WARN_ON(!obj->map_and_fenceable))
> + return ERR_PTR(-ENODEV);
> +
> + BUG_ON(!vma->is_ggtt);
> + BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
> + BUG_ON((vma->bound & GLOBAL_BIND) == 0);
> +
> + if (vma->iomap == NULL) {
> + void *ptr;

We could extract ggtt from the is_ggtt vma->vm that would remove the
dev_priv parameter and make the callers a bit tidier.

static inline struct i915_ggtt *to_ggtt(struct i915_address_space *vm)
{
BUG_ON(!i915_is_ggtt(vm));
return container_of(vm, struct i915_ggtt, base);
}

> +
> + ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> +  obj->base.size);
> + if (ptr == NULL) {
> + int ret;
> +
> + /* Too many areas already allocated? */
> + ret = i915_gem_evict_vm(vma->vm, true);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> +  obj->base.size);

No, we really don't want to create a new ioremap for every caller when
we already have one, ggtt->mappable. Hence,
io-mapping: Specify mapping size for io_mapping_map_wc
being its preceeding patch. The difference is huge on Braswell.
-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] ✗ Fi.CI.BAT: failure for drm/i915: Fix VLV/CHV unclaimed register errors

2016-04-12 Thread Ville Syrjälä
On Mon, Apr 11, 2016 at 02:30:51PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix VLV/CHV unclaimed register errors
> URL   : https://patchwork.freedesktop.org/series/5531/
> State : failure
> 
> == Summary ==
> 
> Series 5531v1 drm/i915: Fix VLV/CHV unclaimed register errors
> http://patchwork.freedesktop.org/api/1.0/series/5531/revisions/1/mbox/
> 
> Test gem_busy:
> Subgroup basic-blt:
> pass   -> INCOMPLETE (snb-dellxps)

Machine died?

Last lines in the log:
[  219.031203] kms_flip: exiting, ret=0
[  219.031690] [drm:connected_sink_compute_bpp] [CONNECTOR:35:HDMI-A-1] 
checking for sink bpp constrains
[  219.031692] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) 
to EDID reported max of 24
[  219.031695] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output
[  219.031696] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI
[  219.031698] [drm:ironlake_check_fdi_lanes] checking fdi config on pipe A, 
lanes 2
[  219.031700] [drm:intel_modeset_pipe_config] hw max bpp: 36, pipe bpp: 24, 
dithering: 0
[  219.031702] [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 
880128230008 for pipe A
[  219.031703] [drm:intel_dump_pipe_config] cpu_transcoder: A
[  219.031704] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
[  219.031706] [drm:intel_dump_pipe_config] fdi/pch: 1, lanes: 2, gmch_m: 
6920601, gmch_n: 8388608, link_m: 288358, link_n: 524288, tu: 64
[  219.031708] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m: 0, gmch_n: 
0, link_m: 0, link_n: 0, tu: 0
[  219.031709] [drm:intel_dump_pipe_config] dp: 0, lanes: 0, gmch_m2: 0, 
gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  219.031711] [drm:intel_dump_pipe_config] audio: 1, infoframes: 1
[  219.031712] [drm:intel_dump_pipe_config] requested mode:
[  219.031714] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[  219.031715] [drm:intel_dump_pipe_config] adjusted mode:
[  219.031718] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[  219.031720] [drm:intel_dump_crtc_timings] crtc timings: 148500 1920 2008 
2052 2200 1080 1084 1089 1125, type: 0x48 flags: 0x5
[  219.031721] [drm:intel_dump_pipe_config] port clock: 148500
[  219.031722] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  219.031724] [drm:intel_dump_pipe_config] num_scalers: 0, scaler_users: 0x0, 
scaler_id: 0
[  219.031725] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, 
ratios: 0x, lvds border: 0x
[  219.031726] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: 
0x, disabled
[  219.031727] [drm:intel_dump_pipe_config] ips: 0
[  

> Subgroup basic-render:
> skip   -> PASS   (hsw-gt2)
> Test gem_ctx_param_basic:
> Subgroup invalid-ctx-get:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Subgroup non-root-set:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Test gem_exec_basic:
> Subgroup gtt-bsd:
> pass   -> SKIP   (bsw-nuc-2)
> Test gem_mmap_gtt:
> Subgroup basic-small-copy-xy:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Subgroup basic-write-no-prefault:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Test gem_storedw_loop:
> Subgroup basic-render:
> pass   -> SKIP   (bsw-nuc-2)
> Test gem_tiled_fence_blits:
> Subgroup basic:
> pass   -> DMESG-FAIL (bsw-nuc-2)
> Test kms_addfb_basic:
> Subgroup no-handle:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
> Test kms_force_connector_basic:
> Subgroup force-edid:
> pass   -> SKIP   (ivb-t430s)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> SKIP   (hsw-brixbox)
> Subgroup suspend-read-crc-pipe-c:
> pass   -> DMESG-FAIL (bsw-nuc-2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> DMESG-WARN (bsw-nuc-2)
> Subgroup basic-rte:
> dmesg-warn -> PASS   (bsw-nuc-2)

[  452.682257] WARNING: CPU: 1 PID: 6456 at drivers/gpu/drm/drm_irq.c:1323 
drm_wait_one_vblank+0x150/0x1a0
[  452.682273] vblank wait timed out on crtc 2

[  477.071090] [drm:i915_set_reset_status [i915]] *ERROR* gpu hanging too fast, 
banning!
[  477.082011] drm/i915: Resetting chip after gpu hang
[  483.074746] [drm:i915_set_reset_status [i915]] *ERROR* gpu hanging too fast, 
banning!
[  483.080771] drm/i915: Resetting chip after gpu hang

BSW is generally unhappy about interrupts. I'll post some fixes soon, I hope.

> 
> bdw-ultratotal:202  pass:179  dwarn:0   

Re: [Intel-gfx] [PATCH v4] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-04-12 Thread Dave Gordon

On 12/04/16 14:51, Michał Winiarski wrote:

We started to use PIPE_CONTROL to write render ring seqno in order to
combat seqno write vs interrupt generation problems. This was introduced
by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
generation on gen8+ execlists").

On gen8+ size of PIPE_CONTROL with Post Sync Operation should be
6 dwords. When we're using older 5-dword variant it's possible to
observe inconsistent values written by PIPE_CONTROL with Post
Sync Operation from user batches, resulting in rendering corruptions.

v2: Fix BAT failures
v3: Comments on alignment and thrashing high dword of seqno (Chris)
v4: Updated commit msg (Mika)

Testcase: igt/gem_pipe_control_store_loop/*-qword-write
Issue: VIZ-7393
Cc: sta...@vger.kernel.org
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Abdiel Janulgue 
Signed-off-by: Michał Winiarski 
---
  drivers/gpu/drm/i915/intel_lrc.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0d6dc5e..30abe53 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1945,15 +1945,18 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
struct intel_ringbuffer *ringbuf = request->ringbuf;
int ret;

-   ret = intel_logical_ring_begin(request, 6 + WA_TAIL_DWORDS);
+   ret = intel_logical_ring_begin(request, 8 + WA_TAIL_DWORDS);
if (ret)
return ret;

+   /* We're using qword write, seqno should be aligned to 8 bytes. */
+   BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
+
/* w/a for post sync ops following a GPGPU operation we
 * need a prior CS_STALL, which is emitted by the flush
 * following the batch.
 */
-   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
+   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
intel_logical_ring_emit(ringbuf,
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
@@ -1961,7 +1964,10 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
+   /* We're thrashing one dword of HWS. */
+   intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
+   intel_logical_ring_emit(ringbuf, MI_NOOP);
return intel_logical_ring_advance_and_submit(request);
  }


In the scheduler+preemption patches, we actually make use of the fact 
that we're writing a QWord, so that we can set the completed-seqno and 
clear the in-progress seqno in one operation (it doesn't actually matter 
if the h/w turns it into two DWord writes, though).


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


Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

2016-04-12 Thread Daniel Vetter
On Tue, Apr 12, 2016 at 01:51:02PM +0100, Lionel Landwerlin wrote:
> On 12/04/16 12:57, Daniel Vetter wrote:
> >On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> >>Color management properties are a bit of an odd use case because
> >>they're not marked as atomic properties. Currently we're not updating
> >>the non atomic values so the drm_crtc_state is out of sync with the
> >>values stored in the crtc object.
> >tbh sounds like this is the bug here - why does the lookup of the correct
> >values stored in the crtc_state drm_atomic_crtc_get_property() not work?
> 
> This is only a problem when the kernel space modifies property values.
> User space ioctls do the right thing and update both places :
> 
> https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/drm_crtc.c#n4916

Nah, the problem is that we check fro DRIVER_ATOMIC in
drm_atomic_get_property, and because i915 is still not fully atomic that
gives us the wrong answer.

Can you pls double-check that enabling i915 atomic (i915.nuclear_flip=1)
also fixes the bug?

i915 is the only driver still transitioning, I definitely don't want to
have hacks all over for it.

> >Duct-taping over this bug in every place we update these properties
> >(you're just patching one of many) won't scale.
> >
> >Also: Where's the igt for this failure?
> >-Daniel
> 
> There is : 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/kms_pipe_color.c#n554
> That's how we caught it.

Needs a Testcase: igt/kms_pipe_color/$name line in the commit message. How
a bug was discovered and tested is a crucial part of a complete commit
message.
-Daniel

> 
> 
> >>v2: Update non atomic values only if commit succeeds (Bob Paauwe)
> >>
> >>v3: Do not access crtc_state after commit, use crtc->state (Maarten
> >> Lankhorst)
> >>
> >>Cc: Maarten Lankhorst 
> >>Cc: Bob Paauwe 
> >>Cc: 
> >>Signed-off-by: Lionel Landwerlin 
> >>---
> >>  drivers/gpu/drm/drm_atomic_helper.c | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >>b/drivers/gpu/drm/drm_atomic_helper.c
> >>index 7bf678e..13b86cf 100644
> >>--- a/drivers/gpu/drm/drm_atomic_helper.c
> >>+++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>@@ -2979,6 +2979,14 @@ retry:
> >>if (ret)
> >>goto fail;
> >>+   drm_object_property_set_value(>base,
> >>+   config->degamma_lut_property, 0);
> >>+   drm_object_property_set_value(>base,
> >>+   config->ctm_property, 0);
> >>+   drm_object_property_set_value(>base,
> >>+   config->gamma_lut_property,
> >>+   crtc->state->gamma_lut->base.id);
> >>+
> >>/* Driver takes ownership of state on successful commit. */
> >>drm_property_unreference_blob(blob);
> >>-- 
> >>2.8.0.rc3
> >>
> >>___
> >>dri-devel mailing list
> >>dri-de...@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev4)

2016-04-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write 
(rev4)
URL   : https://patchwork.freedesktop.org/series/4446/
State : success

== Summary ==

Series 4446v4 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno 
write
http://patchwork.freedesktop.org/api/1.0/series/4446/revisions/4/mbox/


bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:202  pass:163  dwarn:0   dfail:0   fail:0   skip:39 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ivb-t430stotal:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:203  pass:165  dwarn:0   dfail:0   fail:0   skip:38 
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1873/

42189a46296988a9e16b57dca9e25c22745b drm-intel-nightly: 
2016y-04m-12d-14h-35m-43s UTC integration manifest
fb8daf9 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2)

2016-04-12 Thread Patchwork
== Series Details ==

Series: series starting with drm/i915: check for ERR_PTR from 
i915_gem_object_pin_map() (rev2)
URL   : https://patchwork.freedesktop.org/series/5591/
State : failure

== Summary ==

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

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (snb-x220t)

bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:202  pass:162  dwarn:1   dfail:0   fail:0   skip:39 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ivb-t430stotal:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:203  pass:164  dwarn:0   dfail:0   fail:2   skip:37 
BOOT FAILED for ilk-hp8440p
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1872/

d89f227a17b175fce74e11b2d5fa2a41f86fc489 drm-intel-nightly: 
2016y-04m-12d-13h-31m-26s UTC integration manifest
33d810a drm/i915: Mark obj->mapping as dirtying the backing storage
0d172b1 drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

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


Re: [Intel-gfx] [PATCH v4 RESEND 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

2016-04-12 Thread Lyude
Sounds good, I'll have the rebased versions posted in a bit

On Tue, 2016-04-12 at 13:17 +0300, Jani Nikula wrote:
> On Mon, 28 Mar 2016, Lyude  wrote:
> > 
> > Resending this because it looks like replying to my previous series
> > of patches
> > causes patchwork to pick up patches from the original version of
> > this and
> > try to apply them along with this one.
> Lyude, these don't seem to apply cleanly, please rebase and repost,
> and
> we can pick them up once Ville confirms they don't break his display.
> 
> BR,
> Jani.
> 
> 
-- 
Cheers,
Lyude

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


[Intel-gfx] [PATCH 3/5] drm/i915: bail in alloc_pdp when !FULL_48BIT_PPGTT

2016-04-12 Thread Matthew Auld
If we are not in FULL_48BIT_PPGTT mode then we really shouldn't
continue on with our allocations, given that the call to free_dpd would
bail early without freeing everything, thus leaking memory.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index fa583d5..6601b11 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -569,7 +569,8 @@ i915_page_directory_pointer *alloc_pdp(struct drm_device 
*dev)
struct i915_page_directory_pointer *pdp;
int ret = -ENOMEM;
 
-   WARN_ON(!USES_FULL_48BIT_PPGTT(dev));
+   if (WARN_ON(!USES_FULL_48BIT_PPGTT(dev)))
+   return ERR_PTR(-EINVAL);
 
pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
if (!pdp)
-- 
2.4.11

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


[Intel-gfx] [PATCH 4/5] drm/i915: call kunmap_px on pt_vaddr

2016-04-12 Thread Matthew Auld
We need to kunmap pt_vaddr and not pt itself, otherwise we end up
mapping a bunch of pages without ever unmapping them.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6601b11..7aef7bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -746,7 +746,7 @@ static void gen8_ppgtt_clear_pte_range(struct 
i915_address_space *vm,
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr);
 
pte = 0;
if (++pde == I915_PDES) {
-- 
2.4.11

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


[Intel-gfx] [PATCH 2/5] drm/i915: harden allocation paths in allocate_va_range

2016-04-12 Thread Matthew Auld
For the gen6/gen8_allocate_va_range functions remove the WARN_ON range
sanity checks in favour of simply hardening the allocation paths. This
also fixes the inconsistency in which we don't always handle the
potential overflow in our checks.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5ed713d..fa583d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1220,15 +1220,6 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
uint32_t pdpes = I915_PDPES_PER_PDP(dev);
int ret;
 
-   /* Wrap is never okay since we can only represent 48b, and we don't
-* actually use the other side of the canonical address space.
-*/
-   if (WARN_ON(start + length < start))
-   return -ENODEV;
-
-   if (WARN_ON(start + length > vm->total))
-   return -ENODEV;
-
ret = alloc_gen8_temp_bitmaps(_page_dirs, _page_tables, pdpes);
if (ret)
return ret;
@@ -1370,6 +1361,8 @@ static int gen8_alloc_va_range(struct i915_address_space 
*vm,
 {
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
 
+   length = min_t(uint64_t, length, vm->total);
+
if (USES_FULL_48BIT_PPGTT(vm->dev))
return gen8_alloc_va_range_4lvl(vm, >pml4, start, 
length);
else
@@ -1860,11 +1853,9 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
uint32_t pde, temp;
int ret;
 
-   if (WARN_ON(start_in + length_in > ppgtt->base.total))
-   return -ENODEV;
-
start = start_save = start_in;
-   length = length_save = length_in;
+   length = length_save = length_in = min_t(uint64_t, length_in,
+ppgtt->base.total);
 
bitmap_zero(new_page_tables, I915_PDES);
 
-- 
2.4.11

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


[Intel-gfx] [PATCH 1/5] drm/i915: use dev_priv directly in gen8_ppgtt_notify_vgt

2016-04-12 Thread Matthew Auld
Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.

v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen)

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c5cb049..5ed713d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -905,11 +905,10 @@ static int gen8_init_scratch(struct i915_address_space 
*vm)
 static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
 {
enum vgt_g2v_type msg;
-   struct drm_device *dev = ppgtt->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(ppgtt->base.dev);
int i;
 
-   if (USES_FULL_48BIT_PPGTT(dev)) {
+   if (USES_FULL_48BIT_PPGTT(dev_priv)) {
u64 daddr = px_dma(>pml4);
 
I915_WRITE(vgtif_reg(pdp[0].lo), lower_32_bits(daddr));
-- 
2.4.11

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


[Intel-gfx] [PATCH v2 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

Reshuffle the code a bit to move the vlv/chv display irq functions away
from the main irq hooks, next to the other sub (de,gt,etc.) hooks.

v2: Rebased due to changes in vlv_display_irq_reset()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Imre Deak  (v1)
---
 drivers/gpu/drm/i915/i915_irq.c | 102 
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 68981aee35b7..6885c0d12167 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3285,23 +3285,6 @@ static void gen5_gt_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN6_PM);
 }
 
-/* drm_dma.h hooks
-*/
-static void ironlake_irq_reset(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   I915_WRITE(HWSTAM, 0x);
-
-   GEN5_IRQ_RESET(DE);
-   if (IS_GEN7(dev))
-   I915_WRITE(GEN7_ERR_INT, 0x);
-
-   gen5_gt_irq_reset(dev);
-
-   ibx_irq_reset(dev);
-}
-
 static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
 {
enum pipe pipe;
@@ -3320,6 +3303,57 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
dev_priv->irq_mask = ~0;
 }
 
+static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
+{
+   u32 pipestat_mask;
+   u32 iir_mask;
+   enum pipe pipe;
+
+   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
+   PIPE_FIFO_UNDERRUN_STATUS;
+
+   for_each_pipe(dev_priv, pipe)
+   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
+   POSTING_READ(PIPESTAT(PIPE_A));
+
+   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
+   PIPE_CRC_DONE_INTERRUPT_STATUS;
+
+   i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
+   for_each_pipe(dev_priv, pipe)
+   i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
+
+   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
+  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
+  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
+   if (IS_CHERRYVIEW(dev_priv))
+   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
+   dev_priv->irq_mask &= ~iir_mask;
+
+   I915_WRITE(VLV_IIR, iir_mask);
+   I915_WRITE(VLV_IIR, iir_mask);
+   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
+   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
+   POSTING_READ(VLV_IMR);
+}
+
+/* drm_dma.h hooks
+*/
+static void ironlake_irq_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   I915_WRITE(HWSTAM, 0x);
+
+   GEN5_IRQ_RESET(DE);
+   if (IS_GEN7(dev))
+   I915_WRITE(GEN7_ERR_INT, 0x);
+
+   gen5_gt_irq_reset(dev);
+
+   ibx_irq_reset(dev);
+}
+
 static void valleyview_irq_preinstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3656,40 +3690,6 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
return 0;
 }
 
-static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
-{
-   u32 pipestat_mask;
-   u32 iir_mask;
-   enum pipe pipe;
-
-   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
-   PIPE_FIFO_UNDERRUN_STATUS;
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
-   POSTING_READ(PIPESTAT(PIPE_A));
-
-   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
-   PIPE_CRC_DONE_INTERRUPT_STATUS;
-
-   i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
-   for_each_pipe(dev_priv, pipe)
- i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
-
-   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
-  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
-   if (IS_CHERRYVIEW(dev_priv))
-   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
-   dev_priv->irq_mask &= ~iir_mask;
-
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   POSTING_READ(VLV_IMR);
-}
-
 void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
 {
assert_spin_locked(_priv->irq_lock);
-- 
2.7.4

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


[Intel-gfx] [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA

2016-04-12 Thread Tvrtko Ursulin
From: Chris Wilson 

By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).

v2:
  * Rebase on nightly;
  * added kerneldoc. (Tvrtko Ursulin)

Signed-off-by: Chris Wilson 
Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +
 drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +
 drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-
 4 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b37ffea8b458..6a485630595e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
ret = i915_gem_object_put_fence(obj);
if (ret)
return ret;
+
+   i915_vma_iounmap(vma);
}
 
trace_i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c5cb04907525..b2a8a14e8dcb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
return obj->base.size;
}
 }
+
+void *i915_vma_iomap(struct drm_i915_private *dev_priv,
+struct i915_vma *vma)
+{
+   struct drm_i915_gem_object *obj = vma->obj;
+   struct i915_ggtt *ggtt = _priv->ggtt;
+
+   if (WARN_ON(!obj->map_and_fenceable))
+   return ERR_PTR(-ENODEV);
+
+   BUG_ON(!vma->is_ggtt);
+   BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
+   BUG_ON((vma->bound & GLOBAL_BIND) == 0);
+
+   if (vma->iomap == NULL) {
+   void *ptr;
+
+   ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
+obj->base.size);
+   if (ptr == NULL) {
+   int ret;
+
+   /* Too many areas already allocated? */
+   ret = i915_gem_evict_vm(vma->vm, true);
+   if (ret)
+   return ERR_PTR(ret);
+
+   ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
+obj->base.size);
+   if (ptr == NULL)
+   return ERR_PTR(-ENOMEM);
+   }
+
+   vma->iomap = ptr;
+   }
+
+   return vma->iomap;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d7dd3d8a8758..526fdbc71ace 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -175,6 +175,7 @@ struct i915_vma {
struct drm_mm_node node;
struct drm_i915_gem_object *obj;
struct i915_address_space *vm;
+   void *iomap;
 
/** Flags and address space this VMA is bound to */
 #define GLOBAL_BIND(1<<0)
@@ -559,4 +560,41 @@ size_t
 i915_ggtt_view_size(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view);
 
+/**
+ * i915_vma_iomap - calls ioremap_wc to map the GGTT VMA via the aperture
+ * @dev_priv: i915 private pointer
+ * @vma: VMA to iomap
+ *
+ * The passed in VMA has to be pinned in the global GTT mappable region. Or in
+ * other words callers are responsible for managing the VMA pinned lifetime and
+ * ensuring it covers the use of the returned mapping.
+ *
+ * Callers must hold the struct_mutex.
+ *
+ * Returns a valid iomapped pointer or ERR_PTR.
+ */
+void *i915_vma_iomap(struct drm_i915_private *dev_priv,
+struct i915_vma *vma);
+
+/**
+ * i915_vma_iounmap - unmaps the mapping returned from i915_vma_iomap
+ * @dev_priv: i915 private pointer
+ * @vma: VMA to unmap
+ *
+ * Unmaps the previously iomapped VMA using iounmap.
+ *
+ * Users of i915_vma_iomap should not manually unmap by calling this function
+ * if they want to take advantage of the mapping getting cached in the VMA.
+ *
+ * Callers must hold the struct_mutex.
+ */
+static inline void i915_vma_iounmap(struct i915_vma *vma)
+{
+   if (vma->iomap == NULL)
+   return;
+
+   iounmap(vma->iomap);
+   vma->iomap = NULL;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 79ac202f3870..515a2214827e 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -251,12 +251,10 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->fix.smem_start = dev->mode_config.fb_base + 

[Intel-gfx] [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer

2016-04-12 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to decrease the cost
of ringbuf pinning and unpinning.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 20 
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 526fdbc71ace..5dd0ddba5488 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -560,6 +560,8 @@ size_t
 i915_ggtt_view_size(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view);
 
+struct drm_i915_private;
+
 /**
  * i915_vma_iomap - calls ioremap_wc to map the GGTT VMA via the aperture
  * @dev_priv: i915 private pointer
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 41b604e69db7..8ac3342b4bdd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2084,8 +2084,6 @@ void intel_unpin_ringbuffer_obj(struct intel_ringbuffer 
*ringbuf)
 {
if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
i915_gem_object_unpin_map(ringbuf->obj);
-   else
-   iounmap(ringbuf->virtual_start);
ringbuf->vma = NULL;
i915_gem_object_ggtt_unpin(ringbuf->obj);
 }
@@ -2094,8 +2092,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
 struct intel_ringbuffer *ringbuf)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj = ringbuf->obj;
+   struct i915_vma *vma;
+   void *addr;
int ret;
 
if (HAS_LLC(dev_priv) && !obj->stolen) {
@@ -2112,6 +2111,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
ret = -ENOMEM;
goto err_unpin;
}
+
+   vma = i915_gem_obj_to_ggtt(obj);
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
if (ret)
@@ -2124,15 +2125,18 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
 
-   ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +
-   
i915_gem_obj_ggtt_offset(obj), ringbuf->size);
-   if (ringbuf->virtual_start == NULL) {
-   ret = -ENOMEM;
+   vma = i915_gem_obj_to_ggtt(obj);
+
+   addr = i915_vma_iomap(dev_priv, vma);
+   if (IS_ERR(addr)) {
+   ret = PTR_ERR(ringbuf->virtual_start);
goto err_unpin;
}
+
+   ringbuf->virtual_start = addr;
}
 
-   ringbuf->vma = i915_gem_obj_to_ggtt(obj);
+   ringbuf->vma = vma;
return 0;
 
 err_unpin:
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 02/10] drm/i915: Fix up vlv/chv display irq setup

2016-04-12 Thread ville . syrjala
From: Ville Syrjälä 

The vlv/chv display irq setup was a bit of mess after I ran out of steam
when working on it last. Fix it up so that we just have a _reset() and
_postinstall() hooks for the display irqs, and use those consistently.

v2: Clear out pipestat_irq_mask[] and PIPE_FIFO_UNDERRUN_STATUS in
vlv_display_irq_reset() (Imre)

Signed-off-by: Ville Syrjälä 
Reviewed-by: Imre Deak  (v1)
---
 drivers/gpu/drm/i915/i915_irq.c | 109 +++-
 1 file changed, 29 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1d21ebfffd4d..0fcd8b24a1de 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3306,13 +3306,18 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
 {
enum pipe pipe;
 
-   i915_hotplug_interrupt_update(dev_priv, 0x, 0);
+   i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), 0x);
+   for_each_pipe(dev_priv, pipe) {
+   I915_WRITE(PIPESTAT(pipe),
+  PIPE_FIFO_UNDERRUN_STATUS |
+  PIPESTAT_INT_STATUS_MASK);
+   dev_priv->pipestat_irq_mask[pipe] = 0;
+   }
 
GEN5_IRQ_RESET(VLV_);
+   dev_priv->irq_mask = ~0;
 }
 
 static void valleyview_irq_preinstall(struct drm_device *dev)
@@ -3323,7 +3328,9 @@ static void valleyview_irq_preinstall(struct drm_device 
*dev)
 
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
 
+   spin_lock_irq(_priv->irq_lock);
vlv_display_irq_reset(dev_priv);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
@@ -3398,7 +3405,9 @@ static void cherryview_irq_preinstall(struct drm_device 
*dev)
 
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
 
+   spin_lock_irq(_priv->irq_lock);
vlv_display_irq_reset(dev_priv);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 static u32 intel_hpd_enabled_irqs(struct drm_device *dev,
@@ -3645,7 +3654,7 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
return 0;
 }
 
-static void valleyview_display_irqs_install(struct drm_i915_private *dev_priv)
+static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
 {
u32 pipestat_mask;
u32 iir_mask;
@@ -3679,40 +3688,6 @@ static void valleyview_display_irqs_install(struct 
drm_i915_private *dev_priv)
POSTING_READ(VLV_IMR);
 }
 
-static void valleyview_display_irqs_uninstall(struct drm_i915_private 
*dev_priv)
-{
-   u32 pipestat_mask;
-   u32 iir_mask;
-   enum pipe pipe;
-
-   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
-  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
-   if (IS_CHERRYVIEW(dev_priv))
-   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
-
-   dev_priv->irq_mask |= iir_mask;
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   POSTING_READ(VLV_IIR);
-
-   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
-   PIPE_CRC_DONE_INTERRUPT_STATUS;
-
-   i915_disable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
-   for_each_pipe(dev_priv, pipe)
-   i915_disable_pipestat(dev_priv, pipe, pipestat_mask);
-
-   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
-   PIPE_FIFO_UNDERRUN_STATUS;
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
-   POSTING_READ(PIPESTAT(PIPE_A));
-}
-
 void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
 {
assert_spin_locked(_priv->irq_lock);
@@ -3723,7 +3698,7 @@ void valleyview_enable_display_irqs(struct 
drm_i915_private *dev_priv)
dev_priv->display_irqs_enabled = true;
 
if (intel_irqs_enabled(dev_priv))
-   valleyview_display_irqs_install(dev_priv);
+   vlv_display_irq_postinstall(dev_priv);
 }
 
 void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv)
@@ -3736,36 +3711,14 @@ void valleyview_disable_display_irqs(struct 
drm_i915_private *dev_priv)
dev_priv->display_irqs_enabled = false;
 
if (intel_irqs_enabled(dev_priv))
-   valleyview_display_irqs_uninstall(dev_priv);
+   vlv_display_irq_reset(dev_priv);
 }
 
-static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
-{
-   dev_priv->irq_mask = ~0;
-
-   i915_hotplug_interrupt_update(dev_priv, 0x, 0);
-   POSTING_READ(PORT_HOTPLUG_EN);
-
-   

Re: [Intel-gfx] [PATCH 15/16] Revert "drm/i915/bxt: Disable power well support"

2016-04-12 Thread David Weinehall
On Fri, Apr 01, 2016 at 04:02:46PM +0300, Imre Deak wrote:
> With the preceding fixes power well support should be functional on
> Broxton, I could enter/exit DC5 without problems.
> 
> This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9.
> 
> CC: Matt Roper 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

Great work!

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 342f997..4441734 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1948,11 +1948,6 @@ sanitize_disable_power_well_option(const struct 
> drm_i915_private *dev_priv,
>   if (disable_power_well >= 0)
>   return !!disable_power_well;
>  
> - if (IS_BROXTON(dev_priv)) {
> - DRM_DEBUG_KMS("Disabling display power well support\n");
> - return 0;
> - }
> -
>   return 1;
>  }
>  
> -- 
> 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


Re: [Intel-gfx] [PATCH 16/16] drm/i915/bxt: Enable runtime PM

2016-04-12 Thread David Weinehall
On Fri, Apr 01, 2016 at 04:02:47PM +0300, Imre Deak wrote:
> With the preceding fixes runtime PM should be functional, I could
> runtime suspend/resume the device without problems.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0449ebf..099cdee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2661,7 +2661,7 @@ struct drm_i915_cmd_table {
>  #define HAS_RUNTIME_PM(dev)  (IS_GEN6(dev) || IS_HASWELL(dev) || \
>IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
>IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
> -  IS_KABYLAKE(dev))
> +  IS_KABYLAKE(dev) || IS_BROXTON(dev))
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)(INTEL_INFO(dev)->gen == 6 || 
> IS_IVYBRIDGE(dev))
>  
> -- 
> 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


Re: [Intel-gfx] [PATCH v3 14/16] drm/i915/bxt: Add HW state verification for DDI PHY and CDCLK

2016-04-12 Thread David Weinehall
On Mon, Apr 04, 2016 at 05:27:10PM +0300, Imre Deak wrote:
> I caught a few errors in our current PHY/CDCLK programming by sanity
> checking the actual programmed state, so I thought it would be also
> useful for the future. In addition to verifying the state after
> programming it also verify it after exiting DC5, to make sure DMC
> restored/kept intact everything related.
> 
> v2:
> - Inlining __phy_reg_verify_state() doesn't make sense and also
>   incorrect, so don't do it (PW/CI gcc)
> v3:
> - Rebase on latest -nightly
> 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/i915_drv.h |   1 +
>  drivers/gpu/drm/i915/intel_ddi.c| 124 
> +++-
>  drivers/gpu/drm/i915/intel_display.c|   5 ++
>  drivers/gpu/drm/i915/intel_drv.h|   2 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c |   8 +++
>  5 files changed, 138 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dd18772..6f4a721 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1908,6 +1908,7 @@ struct drm_i915_private {
>* crappiness (can't read out DPLL_MD for pipes B & C).
>*/
>   u32 chv_dpll_md[I915_MAX_PIPES];
> + u32 bxt_phy_grc;
>  
>   u32 suspend_count;
>   bool suspended_to_idle;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index d944bff..fd20119 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1753,6 +1753,13 @@ static bool broxton_phy_is_enabled(struct 
> drm_i915_private *dev_priv,
>   return true;
>  }
>  
> +static u32 broxton_get_grc(struct drm_i915_private *dev_priv, enum dpio_phy 
> phy)
> +{
> + u32 val = I915_READ(BXT_PORT_REF_DW6(phy));
> +
> + return (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
> +}
> +
>  static void broxton_phy_init(struct drm_i915_private *dev_priv,
>enum dpio_phy phy)
>  {
> @@ -1762,6 +1769,9 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>   if (broxton_phy_is_enabled(dev_priv, phy)) {
>   DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
>"won't reprogram it\n", phy);
> + /* Still read out the GRC value for state verification */
> + if (phy == DPIO_PHY1)
> + dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
>  
>   return;
>   }
> @@ -1857,8 +1867,8 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>10))
>   DRM_ERROR("timeout waiting for PHY1 GRC\n");
>  
> - val = I915_READ(BXT_PORT_REF_DW6(DPIO_PHY1));
> - val = (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
> + val = dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv,
> +   DPIO_PHY1);
>   grc_code = val << GRC_CODE_FAST_SHIFT |
>  val << GRC_CODE_SLOW_SHIFT |
>  val;
> @@ -1901,6 +1911,116 @@ void broxton_ddi_phy_uninit(struct drm_i915_private 
> *dev_priv)
>   broxton_phy_uninit(dev_priv, DPIO_PHY0);
>  }
>  
> +static bool __printf(6, 7)
> +__phy_reg_verify_state(struct drm_i915_private *dev_priv, enum dpio_phy phy,
> +i915_reg_t reg, u32 mask, u32 expected,
> +const char *reg_fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> + u32 val;
> +
> + val = I915_READ(reg);
> + if ((val & mask) == expected)
> + return true;
> +
> + va_start(args, reg_fmt);
> + vaf.fmt = reg_fmt;
> + vaf.va = 
> +
> + DRM_DEBUG_DRIVER("DDI PHY %d reg %pV [%08x] state mismatch: "
> +  "current %08x, expected %08x (mask %08x)\n",
> +  phy, , reg.reg, val, (val & ~mask) | expected,
> +  mask);
> +
> + va_end(args);
> +
> + return false;
> +}
> +
> +static bool broxton_phy_verify_state(struct drm_i915_private *dev_priv,
> +  enum dpio_phy phy)
> +{
> + enum port port;
> + u32 ports;
> + uint32_t mask;
> + bool ok;
> +
> +#define _CHK(reg, mask, exp, fmt, ...)   
> \
> + __phy_reg_verify_state(dev_priv, phy, reg, mask, exp, fmt,  \
> +## __VA_ARGS__)
> +
> + /* We expect the PHY to be always enabled */
> + if (!broxton_phy_is_enabled(dev_priv, phy))
> + return false;
> +
> + 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 < 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote:
> When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
> suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
> with a plain i915_gem_object_pin_map(). This raised the question of who
> should mark the page as dirty (or the mapping case, the object).
> We can write simpler, safer code if we mark the entire object as dirty
> upon obtaining the obj->mapping. (The counter-argument is that the
> caller should be marking the object as dirty itself, or we should be
> passing in a direction parameter.)

What I particularly dislike about the current obj->dirty is that it is
strictly only valid inside a pin_pages/unpin_pages section. That isn't
clear from the API atm.
-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 v4] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 04:58:07PM +0300, Mika Kuoppala wrote:
> Michał Winiarski  writes:
> 
> > [ text/plain ]
> > We started to use PIPE_CONTROL to write render ring seqno in order to
> > combat seqno write vs interrupt generation problems. This was introduced
> > by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
> > generation on gen8+ execlists").
> >
> > On gen8+ size of PIPE_CONTROL with Post Sync Operation should be
> > 6 dwords. When we're using older 5-dword variant it's possible to
> > observe inconsistent values written by PIPE_CONTROL with Post
> > Sync Operation from user batches, resulting in rendering corruptions.
> >
> > v2: Fix BAT failures
> > v3: Comments on alignment and thrashing high dword of seqno (Chris)
> > v4: Updated commit msg (Mika)
> >
> > Testcase: igt/gem_pipe_control_store_loop/*-qword-write
> > Issue: VIZ-7393
> > Cc: sta...@vger.kernel.org
> > Cc: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Abdiel Janulgue 
> > Signed-off-by: Michał Winiarski 
> 
> Reviewed-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 09/16] drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpers

2016-04-12 Thread David Weinehall
On Fri, Apr 01, 2016 at 04:02:40PM +0300, Imre Deak wrote:
> For internal APIs passing dev_priv is preferred to reduce indirections,
> so convert over a few DDI PHY, CDCLK helpers.
> 
> No functional change.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/i915_drv.c   | 12 
>  drivers/gpu/drm/i915/intel_ddi.c  | 10 --
>  drivers/gpu/drm/i915/intel_display.c  | 18 +++---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  4 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |  8 
>  5 files changed, 21 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aa7df10..3998f6a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1070,12 +1070,10 @@ static int hsw_suspend_complete(struct 
> drm_i915_private *dev_priv)
>  
>  static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
>   /* TODO: when DC5 support is added disable DC5 here. */
>  
> - broxton_ddi_phy_uninit(dev);
> - broxton_uninit_cdclk(dev);
> + broxton_ddi_phy_uninit(dev_priv);
> + broxton_uninit_cdclk(dev_priv);
>   bxt_enable_dc9(dev_priv);
>  
>   return 0;
> @@ -1083,8 +1081,6 @@ static int bxt_suspend_complete(struct drm_i915_private 
> *dev_priv)
>  
>  static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
>   /* TODO: when CSR FW support is added make sure the FW is loaded */
>  
>   bxt_disable_dc9(dev_priv);
> @@ -1093,8 +1089,8 @@ static int bxt_resume_prepare(struct drm_i915_private 
> *dev_priv)
>* TODO: when DC5 support is added enable DC5 here if the CSR FW
>* is available.
>*/
> - broxton_init_cdclk(dev);
> - broxton_ddi_phy_init(dev);
> + broxton_init_cdclk(dev_priv);
> + broxton_ddi_phy_init(dev_priv);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f91306e..29017a4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1834,11 +1834,11 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
>  }
>  
> -void broxton_ddi_phy_init(struct drm_device *dev)
> +void broxton_ddi_phy_init(struct drm_i915_private *dev_priv)
>  {
>   /* Enable PHY1 first since it provides Rcomp for PHY0 */
> - broxton_phy_init(dev->dev_private, DPIO_PHY1);
> - broxton_phy_init(dev->dev_private, DPIO_PHY0);
> + broxton_phy_init(dev_priv, DPIO_PHY1);
> + broxton_phy_init(dev_priv, DPIO_PHY0);
>  }
>  
>  static void broxton_phy_uninit(struct drm_i915_private *dev_priv,
> @@ -1851,10 +1851,8 @@ static void broxton_phy_uninit(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
>  }
>  
> -void broxton_ddi_phy_uninit(struct drm_device *dev)
> +void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
>   broxton_phy_uninit(dev_priv, DPIO_PHY1);
>   broxton_phy_uninit(dev_priv, DPIO_PHY0);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e6b5ee5..d9da89d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5322,9 +5322,8 @@ static void intel_update_cdclk(struct drm_device *dev)
>   intel_update_max_cdclk(dev);
>  }
>  
> -static void broxton_set_cdclk(struct drm_device *dev, int frequency)
> +static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int 
> frequency)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   uint32_t divider;
>   uint32_t ratio;
>   uint32_t current_freq;
> @@ -5438,12 +5437,11 @@ static void broxton_set_cdclk(struct drm_device *dev, 
> int frequency)
>   return;
>   }
>  
> - intel_update_cdclk(dev);
> + intel_update_cdclk(dev_priv->dev);
>  }
>  
> -void broxton_init_cdclk(struct drm_device *dev)
> +void broxton_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   uint32_t val;
>  
>   /*
> @@ -5472,7 +5470,7 @@ void broxton_init_cdclk(struct drm_device *dev)
>* - check if setting the max (or any) cdclk freq is really necessary
>*   here, it belongs to modeset time
>*/
> - broxton_set_cdclk(dev, 624000);
> + broxton_set_cdclk(dev_priv, 624000);
>  
>   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
>   POSTING_READ(DBUF_CTL);
> @@ -5483,10 +5481,8 @@ void broxton_init_cdclk(struct drm_device *dev)
>   DRM_ERROR("DBuf power enable timeout!\n");
>  }
>  
> -void 

Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

2016-04-12 Thread David Weinehall
On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> This register is read-only, so we have never actually set
> OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code
> comment about this. I filed a specification update request to clarify
> this there.
> 
> CC: Arthur J Runyan 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

> 
> ---
> 
> [ Art, CC'ing you in case you know if this would have an effect on
>   anything. ]
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2758622..f91306e 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1798,6 +1798,9 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>* enabled.
>* TODO: port C is only connected on BXT-P, so on BXT0/1 we should
>* power down the second channel on PHY0 as well.
> +  *
> +  * FIXME: Clarify programming of the following, the register is
> +  * read-only with bit 6 fixed at 0 at least in stepping A.
>*/
>   if (phy == DPIO_PHY1)
>   val |= OCL2_LDOFUSE_PWR_DIS;
> -- 
> 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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use new i915_gem_object_pin_map for LRC

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 03:40:42PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We can use the new pin/lazy unpin API for simplicity
> and more performance in the execlist submission paths.
> 
> v2:
>   * Fix error handling and convert more users.
>   * Compact some names for readability.
> 
> v3:
>   * intel_lr_context_free was not unpinning.
>   * Special case for GPU reset which otherwise unbalances
> the HWS object pages pin count by running the engine
> initialization only (not destructors).
> 
> v4:
>   * Rebased on top of hws setup/init split.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 

Minor comments,
both Reviewed-by: Chris Wilson 

> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3fd2ae6ce8e7..b61f8da5d6f3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1091,8 +1091,8 @@ static int intel_lr_context_do_pin(struct intel_context 
> *ctx,
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
>   struct intel_ringbuffer *ringbuf = ctx->engine[engine->id].ringbuf;
> - struct page *lrc_state_page;
> - uint32_t *lrc_reg_state;
> + void *obj_addr;

obj_addr, harking back to a time when it was an unsigned long? Even then
it would be more traditionally be vaddr.

map, base, vaddr, obj_*

>   /* And setup the hardware status page. */
> - lrc_setup_hws(engine, dctx->engine[engine->id].state);
> + ret = lrc_setup_hws(engine, dctx->engine[engine->id].state);
> + if (ret) {
> + DRM_ERROR("Failed to set up hwd %s: %d\n", engine->name, ret);

s/hwd/hws/

I would have put this set of chunks in the previous patch for less churn.
-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] drm/core: Add drm_accurate_vblank_count, v3.

2016-04-12 Thread Ville Syrjälä
On Tue, Apr 12, 2016 at 04:32:19PM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
> 
> intel_pipe_update_start checks if no vblank interrupt will occur
> during vblank evasion, but cannot check whether the vblank handler has
> run to completion. This function uses the timestamps to determine
> when the last vblank has happened, and interpolates from there.
> 
> Changes since v1:
> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
> Changes since v2:
> - Don't return time of last vblank.
> 
> Cc: Mario Kleiner 
> Cc: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3c1a6f18e71c..32bfa4bb8f41 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -303,6 +303,32 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, _vblank, cur_vblank);
>  }
>  
> +/**
> + * drm_accurate_vblank_count - retrieve the master vblank counter
> + * @crtc: which counter to retrieve
> + * @tv_ret: last time counter was updated
> + *
> + * This function is similar to @drm_crtc_vblank_count but this
> + * function interpolates to handle a race with vblank irq's.
> + */
> +
> +u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + u32 vblank, pipe = drm_crtc_index(crtc);

pipe should be 'unsigned int' for consistency.

> + unsigned long flags;
> +
> + spin_lock_irqsave(>vblank_time_lock, flags);
> +
> + drm_update_vblank_count(dev, pipe, 0);

One thing that came to mind is some callers might end up doing the
update twice if the irq wasn't yet enabled when drm_vblank_get() was
called. Eg. drm_wait_one_vblank() might do that. So it might be a bit
more efficient to add a drm_vblank_get_and_update() instead, or something
like that. But I don't really care too much.

Reviewed-by: Ville Syrjälä 

> + vblank = dev->vblank[pipe].count;
> +
> + spin_unlock_irqrestore(>vblank_time_lock, flags);
> +
> + return vblank;
> +}
> +EXPORT_SYMBOL(drm_accurate_vblank_count);
> +
>  /*
>   * Disable vblank irq's on crtc, make sure that last vblank count
>   * of hardware and corresponding consistent software vblank counter
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 31483c2fef51..747c80da70e5 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -995,6 +995,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
>  extern void drm_vblank_cleanup(struct drm_device *dev);
> +extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
>  extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int 
> pipe);
>  
>  extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,

-- 
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 07/10] drm/virtio: Drop dummy gamma table support

2016-04-12 Thread Julia Lawall


On Tue, 12 Apr 2016, Emil Velikov wrote:

> On 30 March 2016 at 10:51, Daniel Vetter  wrote:
> > No need to confuse userspace like this.
> >
> > Cc: Gerd Hoffmann 
> > Cc: Dave Airlie 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> >  1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> > b/drivers/gpu/drm/virtio/virtgpu_display.c
> > index 4854dac87e24..12b72e29678a 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> > @@ -38,13 +38,6 @@
> >  #define XRES_MAX  8192
> >  #define YRES_MAX  8192
> >
> > -static void virtio_gpu_crtc_gamma_set(struct drm_crtc *crtc,
> > - u16 *red, u16 *green, u16 *blue,
> > - uint32_t start, uint32_t size)
> > -{
> > -   /* TODO */
> > -}
> > -
> >  static void
> >  virtio_gpu_hide_cursor(struct virtio_gpu_device *vgdev,
> >struct virtio_gpu_output *output)
> > @@ -173,7 +166,6 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
> >  static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
> > .cursor_set2= virtio_gpu_crtc_cursor_set,
> > .cursor_move= virtio_gpu_crtc_cursor_move,
> > -   .gamma_set  = virtio_gpu_crtc_gamma_set,
> > .set_config = drm_atomic_helper_set_config,
> > .destroy= drm_crtc_cleanup,
> >
> > @@ -416,7 +408,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
> > *vgdev, int index)
> > return PTR_ERR(plane);
> > drm_crtc_init_with_planes(dev, crtc, plane, NULL,
> >   _gpu_crtc_funcs, NULL);
> > -   drm_mode_crtc_set_gamma_size(crtc, 256);
> > drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
> > plane->crtc = crtc;
> >
> Out of curiosity:
>
> Coccinelle should be able to handle/generate such patches, shouldn't
> it ? I believe in the past people used it for similar
> refactoring/cleanups, yet not (m)any of them [the cocci files] got
> checked in the kernel tree.
>
> Thinking about future drivers derived from outdated sources - do you
> think it's a good/bad idea to check/run them along side the existing
> ones ?

The issue is that there is no point to put an empty function in a
structure?

It would be a bit subtle for Coccinelle, because it requires also knowing
that one is allowed to leave that particular field empty.

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


[Intel-gfx] [PATCH 2/2] drm/i915: Use new i915_gem_object_pin_map for LRC

2016-04-12 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We can use the new pin/lazy unpin API for simplicity
and more performance in the execlist submission paths.

v2:
  * Fix error handling and convert more users.
  * Compact some names for readability.

v3:
  * intel_lr_context_free was not unpinning.
  * Special case for GPU reset which otherwise unbalances
the HWS object pages pin count by running the engine
initialization only (not destructors).

v4:
  * Rebased on top of hws setup/init split.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 82 ++---
 drivers/gpu/drm/i915/intel_lrc.h|  7 ++-
 3 files changed, 52 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index fe580cb9501a..91028d9c6269 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -342,7 +342,7 @@ void i915_gem_context_reset(struct drm_device *dev)
struct intel_context *ctx;
 
list_for_each_entry(ctx, _priv->context_list, link)
-   intel_lr_context_reset(dev, ctx);
+   intel_lr_context_reset(dev_priv, ctx);
}
 
for (i = 0; i < I915_NUM_ENGINES; i++) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3fd2ae6ce8e7..b61f8da5d6f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1091,8 +1091,8 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct intel_ringbuffer *ringbuf = ctx->engine[engine->id].ringbuf;
-   struct page *lrc_state_page;
-   uint32_t *lrc_reg_state;
+   void *obj_addr;
+   u32 *lrc_reg_state;
int ret;
 
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
@@ -1102,19 +1102,20 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
if (ret)
return ret;
 
-   lrc_state_page = i915_gem_object_get_dirty_page(ctx_obj, LRC_STATE_PN);
-   if (WARN_ON(!lrc_state_page)) {
-   ret = -ENODEV;
+   obj_addr = i915_gem_object_pin_map(ctx_obj);
+   if (IS_ERR(obj_addr)) {
+   ret = PTR_ERR(obj_addr);
goto unpin_ctx_obj;
}
 
+   lrc_reg_state = obj_addr + LRC_STATE_PN * PAGE_SIZE;
+
ret = intel_pin_and_map_ringbuffer_obj(engine->dev, ringbuf);
if (ret)
-   goto unpin_ctx_obj;
+   goto unpin_map;
 
ctx->engine[engine->id].lrc_vma = i915_gem_obj_to_ggtt(ctx_obj);
intel_lr_context_descriptor_update(ctx, engine);
-   lrc_reg_state = kmap(lrc_state_page);
lrc_reg_state[CTX_RING_BUFFER_START+1] = ringbuf->vma->node.start;
ctx->engine[engine->id].lrc_reg_state = lrc_reg_state;
ctx_obj->dirty = true;
@@ -1125,6 +1126,8 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
 
return ret;
 
+unpin_map:
+   i915_gem_object_unpin_map(ctx_obj);
 unpin_ctx_obj:
i915_gem_object_ggtt_unpin(ctx_obj);
 
@@ -1157,7 +1160,7 @@ void intel_lr_context_unpin(struct intel_context *ctx,
 
WARN_ON(!mutex_is_locked(>i915->dev->struct_mutex));
if (--ctx->engine[engine->id].pin_count == 0) {
-   kunmap(kmap_to_page(ctx->engine[engine->id].lrc_reg_state));
+   i915_gem_object_unpin_map(ctx_obj);
intel_unpin_ringbuffer_obj(ctx->engine[engine->id].ringbuf);
i915_gem_object_ggtt_unpin(ctx_obj);
ctx->engine[engine->id].lrc_vma = NULL;
@@ -2054,7 +2057,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
i915_gem_batch_pool_fini(>batch_pool);
 
if (engine->status_page.obj) {
-   kunmap(sg_page(engine->status_page.obj->pages->sgl));
+   i915_gem_object_unpin_map(engine->status_page.obj);
engine->status_page.obj = NULL;
}
 
@@ -2092,18 +2095,22 @@ logical_ring_default_irqs(struct intel_engine_cs 
*engine, unsigned shift)
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
 }
 
-static void
+static int
 lrc_setup_hws(struct intel_engine_cs *engine,
  struct drm_i915_gem_object *dctx_obj)
 {
-   struct page *page;
+   void *hws;
 
/* The HWSP is part of the default context object in LRC mode. */
engine->status_page.gfx_addr = i915_gem_obj_ggtt_offset(dctx_obj) +
   LRC_PPHWSP_PN * PAGE_SIZE;
-   page = i915_gem_object_get_page(dctx_obj, LRC_PPHWSP_PN);
-   engine->status_page.page_addr = kmap(page);
+   hws = 

[Intel-gfx] [PATCH 1/2] drm/i915: Split execlists hardware status page initialisation from setup

2016-04-12 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Split the hardware status page into setup and initialisation,
where setup means setting up the driver state to support the
engine, and initialization means programming the hardware
with the before set up state.

This way the design matches the design of the engine setup/init
code which is split in the same fashion and it enables the
stages to be used in a balanced fashion (engine setup - hws
setup, engine init - hws init).

This will enable the upcoming improvements to slot in without
any kludges on the GPU reset path.

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 50 ++--
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e6e69c2f2386..3fd2ae6ce8e7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -229,9 +229,6 @@ enum {
 
 static int intel_lr_context_pin(struct intel_context *ctx,
struct intel_engine_cs *engine);
-static void lrc_setup_hardware_status_page(struct intel_engine_cs *engine,
-  struct drm_i915_gem_object 
*default_ctx_obj);
-
 
 /**
  * intel_sanitize_enable_execlists() - sanitize i915.enable_execlists
@@ -1580,14 +1577,22 @@ out:
return ret;
 }
 
+static void lrc_init_hws(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->dev->dev_private;
+
+   I915_WRITE(RING_HWS_PGA(engine->mmio_base),
+  (u32)engine->status_page.gfx_addr);
+   POSTING_READ(RING_HWS_PGA(engine->mmio_base));
+}
+
 static int gen8_init_common_ring(struct intel_engine_cs *engine)
 {
struct drm_device *dev = engine->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned int next_context_status_buffer_hw;
 
-   lrc_setup_hardware_status_page(engine,
-  
dev_priv->kernel_context->engine[engine->id].state);
+   lrc_init_hws(engine);
 
I915_WRITE_IMR(engine,
   ~(engine->irq_enable_mask | engine->irq_keep_mask));
@@ -2087,6 +2092,20 @@ logical_ring_default_irqs(struct intel_engine_cs 
*engine, unsigned shift)
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
 }
 
+static void
+lrc_setup_hws(struct intel_engine_cs *engine,
+ struct drm_i915_gem_object *dctx_obj)
+{
+   struct page *page;
+
+   /* The HWSP is part of the default context object in LRC mode. */
+   engine->status_page.gfx_addr = i915_gem_obj_ggtt_offset(dctx_obj) +
+  LRC_PPHWSP_PN * PAGE_SIZE;
+   page = i915_gem_object_get_page(dctx_obj, LRC_PPHWSP_PN);
+   engine->status_page.page_addr = kmap(page);
+   engine->status_page.obj = dctx_obj;
+}
+
 static int
 logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
 {
@@ -2145,6 +2164,9 @@ logical_ring_init(struct drm_device *dev, struct 
intel_engine_cs *engine)
goto error;
}
 
+   /* And setup the hardware status page. */
+   lrc_setup_hws(engine, dctx->engine[engine->id].state);
+
return 0;
 
 error:
@@ -2605,24 +2627,6 @@ uint32_t intel_lr_context_size(struct intel_engine_cs 
*engine)
return ret;
 }
 
-static void lrc_setup_hardware_status_page(struct intel_engine_cs *engine,
-  struct drm_i915_gem_object 
*default_ctx_obj)
-{
-   struct drm_i915_private *dev_priv = engine->dev->dev_private;
-   struct page *page;
-
-   /* The HWSP is part of the default context object in LRC mode. */
-   engine->status_page.gfx_addr = i915_gem_obj_ggtt_offset(default_ctx_obj)
-   + LRC_PPHWSP_PN * PAGE_SIZE;
-   page = i915_gem_object_get_page(default_ctx_obj, LRC_PPHWSP_PN);
-   engine->status_page.page_addr = kmap(page);
-   engine->status_page.obj = default_ctx_obj;
-
-   I915_WRITE(RING_HWS_PGA(engine->mmio_base),
-   (u32)engine->status_page.gfx_addr);
-   POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-}
-
 /**
  * intel_lr_context_deferred_alloc() - create the LRC specific bits of a 
context
  * @ctx: LR context to create.
-- 
1.9.1

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains

2016-04-12 Thread Tvrtko Ursulin


On 12/04/16 15:29, Patchwork wrote:

== Series Details ==

Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of 
register forcewake domains
URL   : https://patchwork.freedesktop.org/series/5593/
State : failure

== Summary ==

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

Test drv_hangman:
 Subgroup error-state-basic:
 fail   -> PASS   (ilk-hp8440p)
Test kms_flip:
 Subgroup basic-flip-vs-modeset:
 pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE


Sporadic ILK fifo underruns: 
https://bugs.freedesktop.org/show_bug.cgi?id=93787



Test pm_rpm:
 Subgroup basic-rte:
 dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23
bsw-nuc-2total:202  pass:163  dwarn:0   dfail:0   fail:0   skip:39
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19
ilk-hp8440p  total:203  pass:134  dwarn:1   dfail:0   fail:0   skip:68
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1871/

d89f227a17b175fce74e11b2d5fa2a41f86fc489 drm-intel-nightly: 
2016y-04m-12d-13h-31m-26s UTC integration manifest
9bd8d7e drm/i915: Only grab correct forcewake for the engine with execlists
9c6a1ec drm/i915: Remove forcewake request registers from the shadowed table
c6211b2 drm/i915: Extract knowledge of register forcewake domains


Squeaky clean - merged. Thanks for the review.

Hope this makes a difference on some platform.

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

2016-04-12 Thread R, Durgadoss
>-Original Message-
>From: Conselvan De Oliveira, Ander
>Sent: Monday, April 11, 2016 6:07 PM
>To: intel-gfx@lists.freedesktop.org; R, Durgadoss 
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 2/4] drm/i915: Store the dpll config in 
>crtc_state->shared_dpll
>
>On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
>> Currently, the required shared dpll is saved in the crtc_state.
>> Similarly, this patch saves the dpll config values also, so that
>> these values (through crtc_state->shared_dpll->config.hw_state)
>> can be used for upfront link training.
>>
>> Signed-off-by: Durgadoss R 
>> ---
>>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> index 1175eeb..cad10f2 100644
>> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> @@ -248,6 +248,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll 
>> *pll,
>>   pipe_name(crtc->pipe));
>>
>>  intel_shared_dpll_config_get(shared_dpll, pll, crtc);
>> +crtc_state->shared_dpll->config = shared_dpll[i];
>
>This overwrites the state stored in dev_priv->shared_dpll[i].config, so it 
>means
>we loose the current state set in the hardware. If the atomic check fails after
>this, the software tracking of the hw state gets messed up.

But we need the computed dpll_state and crtc_mask set for pll enabling.
So, the only other way I see is to call shared_dpll_commit() in ddi_upfront() 
code
after we do get_shared_dpll(). 
What do you think of this ?

Or any other options ?

Thanks,
Durga

>
>Ander
>
>>  }
>>
>>  void intel_shared_dpll_commit(struct drm_atomic_state *state)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

2016-04-12 Thread Maarten Lankhorst
This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.

Cc: Mario Kleiner 
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f18e71c..32bfa4bb8f41 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -303,6 +303,32 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
store_vblank(dev, pipe, diff, _vblank, cur_vblank);
 }
 
+/**
+ * drm_accurate_vblank_count - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ * @tv_ret: last time counter was updated
+ *
+ * This function is similar to @drm_crtc_vblank_count but this
+ * function interpolates to handle a race with vblank irq's.
+ */
+
+u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   u32 vblank, pipe = drm_crtc_index(crtc);
+   unsigned long flags;
+
+   spin_lock_irqsave(>vblank_time_lock, flags);
+
+   drm_update_vblank_count(dev, pipe, 0);
+   vblank = dev->vblank[pipe].count;
+
+   spin_unlock_irqrestore(>vblank_time_lock, flags);
+
+   return vblank;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count);
+
 /*
  * Disable vblank irq's on crtc, make sure that last vblank count
  * of hardware and corresponding consistent software vblank counter
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 31483c2fef51..747c80da70e5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -995,6 +995,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
 extern void drm_vblank_cleanup(struct drm_device *dev);
+extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
 extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
 
 extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains

2016-04-12 Thread Patchwork
== Series Details ==

Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of 
register forcewake domains
URL   : https://patchwork.freedesktop.org/series/5593/
State : failure

== Summary ==

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

Test drv_hangman:
Subgroup error-state-basic:
fail   -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:180  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:202  pass:163  dwarn:0   dfail:0   fail:0   skip:39 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:203  pass:134  dwarn:1   dfail:0   fail:0   skip:68 
skl-i7k-2total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:192  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37 
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1871/

d89f227a17b175fce74e11b2d5fa2a41f86fc489 drm-intel-nightly: 
2016y-04m-12d-13h-31m-26s UTC integration manifest
9bd8d7e drm/i915: Only grab correct forcewake for the engine with execlists
9c6a1ec drm/i915: Remove forcewake request registers from the shadowed table
c6211b2 drm/i915: Extract knowledge of register forcewake domains

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


[Intel-gfx] [PATCH] drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

2016-04-12 Thread tim . gore
From: Tim Gore 

WaEnableSamplerGPGPUPreemptionSupport fixes a problem
related to mid thread pre-emption.

Signed-off-by: Tim Gore 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cea5a39..ff83c64 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7161,6 +7161,7 @@ enum skl_disp_power_wells {
 
 #define GEN9_HALF_SLICE_CHICKEN7   _MMIO(0xe194)
 #define   GEN9_ENABLE_YV12_BUGFIX  (1<<4)
+#define   GEN9_ENABLE_GPGPU_PREEMPTION (1<<2)
 
 /* Audio */
 #define G4X_AUD_VID_DID
_MMIO(dev_priv->info.display_mmio_offset + 0x62020)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 41b604e..c2603f7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -959,9 +959,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
}
 
/* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt */
-   if (IS_SKL_REVID(dev, SKL_REVID_C0, REVID_FOREVER) || IS_BROXTON(dev))
-   WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
- GEN9_ENABLE_YV12_BUGFIX);
+   /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt */
+   WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
+ GEN9_ENABLE_YV12_BUGFIX |
+ GEN9_ENABLE_GPGPU_PREEMPTION);
 
/* Wa4x4STCOptimizationDisable:skl,bxt */
/* WaDisablePartialResolveInVc:skl,bxt */
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field

2016-04-12 Thread Thierry Reding
On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
> 
> > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > > pwm->period field is not supposed to be changed by PWM users. The only
> > > ones authorized to change it are the PWM core and PWM drivers.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/video/backlight/lm3630a_bl.c | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > Applied, thanks.
> 
> Applied?

You didn't specifically Ack this one, but I presumed that since the
change is essentially the same as for pwm-backlight, and this is another
prerequisite for the remainder of the series it should go in through the
PWM tree as well.

Thierry


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


Re: [Intel-gfx] [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()

2016-04-12 Thread Thierry Reding
On Tue, Apr 12, 2016 at 03:16:53PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
> 
> > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period(), which might mess up with the internal PWM state.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Acked-by: Lee Jones 
> > > ---
> > >  drivers/video/backlight/pwm_bl.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > Applied, thanks.
> 
> Applied?

You Acked it, so I assumed you were fine with me taking it through the
PWM tree to take care of the dependencies.

Did I assume wrongly?

Thierry


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


Re: [Intel-gfx] [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()

2016-04-12 Thread Lee Jones
On Tue, 12 Apr 2016, Thierry Reding wrote:

> On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > The PWM period will be set when calling pwm_config. Remove this useless
> > call to pwm_set_period(), which might mess up with the internal PWM state.
> > 
> > Signed-off-by: Boris Brezillon 
> > Acked-by: Lee Jones 
> > ---
> >  drivers/video/backlight/pwm_bl.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> Applied, thanks.

Applied?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v5 15/46] pwm: introduce the pwm_state concept

2016-04-12 Thread Boris Brezillon
On Tue, 12 Apr 2016 16:05:46 +0200
Thierry Reding  wrote:

> On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 15:11:18 +0200
> > Thierry Reding  wrote:
> > 
> > > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 Apr 2016 14:21:41 +0200
> > > > Thierry Reding  wrote:
> > > > 
> > > > > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > > > > On Tue, 12 Apr 2016 13:49:04 +0200
> > > > > > Thierry Reding  wrote:
> > > > > > 
> > > > > > > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > > > > > > The PWM state, represented by its period, duty_cycle and 
> > > > > > > > polarity,
> > > > > > > > is currently directly stored in the PWM device.
> > > > > > > > Declare a pwm_state structure embedding those field so that we 
> > > > > > > > can later
> > > > > > > > use this struct to atomically update all the PWM parameters at 
> > > > > > > > once.
> > > > > > > > 
> > > > > > > > All pwm_get_xxx() helpers are now implemented as wrappers around
> > > > > > > > pwm_get_state().
> > > > > > > > 
> > > > > > > > Signed-off-by: Boris Brezillon 
> > > > > > > > 
> > > > > > > > ---
> > > > > > > >  drivers/pwm/core.c  |  8 
> > > > > > > >  include/linux/pwm.h | 54 
> > > > > > > > +
> > > > > > > >  2 files changed, 46 insertions(+), 16 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > > > > > > > index 6433059..f3f91e7 100644
> > > > > > > > --- a/drivers/pwm/core.c
> > > > > > > > +++ b/drivers/pwm/core.c
> > > > > > > > @@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct 
> > > > > > > > pwm_chip *chip,
> > > > > > > > pwm->chip = chip;
> > > > > > > > pwm->pwm = chip->base + i;
> > > > > > > > pwm->hwpwm = i;
> > > > > > > > -   pwm->polarity = polarity;
> > > > > > > > +   pwm->state.polarity = polarity;
> > > > > > > 
> > > > > > > Would this not more correctly be assigned to pwm->args.polarity? 
> > > > > > > After
> > > > > > > all this is setting up the "initial" state, much like DT or the 
> > > > > > > lookup
> > > > > > > tables would for duty cycle and period.
> > > > > > 
> > > > > > Yes, I wasn't sure about the pwm_add_with_polarity() meaning. To me,
> > > > > > all the reference info should be extracted from DT, PWM lookup 
> > > > > > table or
> > > > > > driver specific ->request() implementation, but I can definitely
> > > > > > initialize the args.polarity here too.
> > > > > > 
> > > > > > Should I keep the pwm->state.polarity assignment (to set the initial
> > > > > > polarity when the driver does not support hardware readout)?
> > > > > 
> > > > > Wouldn't this work automatically as part of the pwm_apply_args() 
> > > > > helper
> > > > > if we extended it with this setting?
> > > > 
> > > > Well, as you explained in you answer to patch 5, pwm_apply_args()
> > > > should be called on a per-request basis (each time a PWM device is
> > > > requested), while the initial polarity setting should only be applied
> > > > when registering the PWM chip (and its devices). After that, the
> > > > framework takes care of keeping the PWM state in sync with the hardware
> > > > state.
> > > > 
> > > > Let's take a real (though a bit unusual) example. Say you have a single
> > > > PWM device referenced by two different users. Only one user can be
> > > > enabled at a time, but each of them has its own reference config
> > > > (different polarity, different period).
> > > > 
> > > > User1 calls pwm_get() and applies its own polarity and period. Then
> > > > user1 is unregistered and release the PWM device, leaving the polarity
> > > > and period untouched.
> > > > 
> > > > User2 is registered and request the same PWM device, but user2 is
> > > > smarter and tries to extract the current PWM state before adapting the
> > > > config according to pwm_args. If you just reset pwm->state.polarity
> > > > each time pwm_apply_args() is called (and you suggested to call it as
> > > > part of the request procedure), then this means the PWM state is no
> > > > longer in sync with the hardware state.
> > > 
> > > In that case neither will be the period or duty cycle. Essentially this
> > > gets us back to square one where we need to decide how to handle current
> > > state vs. initial arguments.
> > 
> > That's not true. Now we clearly differentiate the reference config
> > (content of pwm_args which is only a subset of what you'll find in
> > pwm_state) and the PWM state (represented by pwm_state).
> > 
> > We should be safe as long as we keep those 2 elements as 2 orthogonal
> > concepts:
> > - pwm_args is supposed to give some hint to the PWM user to help him
> >   configure it's 

Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field

2016-04-12 Thread Lee Jones
On Tue, 12 Apr 2016, Thierry Reding wrote:

> On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > pwm->period field is not supposed to be changed by PWM users. The only
> > ones authorized to change it are the PWM core and PWM drivers.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/video/backlight/lm3630a_bl.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> Applied, thanks.

Applied?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use new i915_gem_object_pin_map for LRC (rev2)

2016-04-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Use new i915_gem_object_pin_map for LRC (rev2)
URL   : https://patchwork.freedesktop.org/series/5580/
State : failure

== Summary ==

Series 5580v2 drm/i915: Use new i915_gem_object_pin_map for LRC
http://patchwork.freedesktop.org/api/1.0/series/5580/revisions/2/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (bsw-nuc-2)
fail   -> PASS   (ilk-hp8440p)
Test drv_module_reload_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_ctx_param_basic:
Subgroup invalid-size-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_exec_basic:
Subgroup gtt-vebox:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write-no-prefault:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-forked:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-default-interruptible:
pass   -> SKIP   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup basic-x-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bo-too-small:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bo-too-small-due-to-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup small-bo:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup unused-pitches:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-plain-flip:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (byt-nuc) UNSTABLE
Test prime_self_import:
Subgroup basic-with_one_bo_two_files:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:203  pass:190  dwarn:1   dfail:0   fail:0   skip:12 
bdw-ultratotal:203  pass:179  dwarn:1   dfail:0   fail:0   skip:23 
bsw-nuc-2total:202  pass:146  dwarn:10  dfail:2   fail:0   skip:44 
byt-nuc  total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:203  pass:184  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:203  pass:134  dwarn:1   dfail:0   fail:0   skip:68 
ivb-t430stotal:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2total:203  pass:177  dwarn:1   dfail:0   fail:0   skip:25 
skl-nuci5total:203  pass:191  dwarn:1   dfail:0   fail:0   skip:11 
snb-x220ttotal:203  pass:165  dwarn:0   dfail:0   fail:1   skip:37 
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1870/

8f2e41ba8d25b39e6a057d3244481771f6054764 drm-intel-nightly: 
2016y-04m-12d-12h-14m-24s UTC integration manifest
d321b00 drm/i915: Use new i915_gem_object_pin_map for LRC

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


Re: [Intel-gfx] [PATCH v5 15/46] pwm: introduce the pwm_state concept

2016-04-12 Thread Thierry Reding
On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 15:11:18 +0200
> Thierry Reding  wrote:
> 
> > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 Apr 2016 14:21:41 +0200
> > > Thierry Reding  wrote:
> > > 
> > > > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > > > On Tue, 12 Apr 2016 13:49:04 +0200
> > > > > Thierry Reding  wrote:
> > > > > 
> > > > > > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > > > > > The PWM state, represented by its period, duty_cycle and polarity,
> > > > > > > is currently directly stored in the PWM device.
> > > > > > > Declare a pwm_state structure embedding those field so that we 
> > > > > > > can later
> > > > > > > use this struct to atomically update all the PWM parameters at 
> > > > > > > once.
> > > > > > > 
> > > > > > > All pwm_get_xxx() helpers are now implemented as wrappers around
> > > > > > > pwm_get_state().
> > > > > > > 
> > > > > > > Signed-off-by: Boris Brezillon 
> > > > > > > 
> > > > > > > ---
> > > > > > >  drivers/pwm/core.c  |  8 
> > > > > > >  include/linux/pwm.h | 54 
> > > > > > > +
> > > > > > >  2 files changed, 46 insertions(+), 16 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > > > > > > index 6433059..f3f91e7 100644
> > > > > > > --- a/drivers/pwm/core.c
> > > > > > > +++ b/drivers/pwm/core.c
> > > > > > > @@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct pwm_chip 
> > > > > > > *chip,
> > > > > > >   pwm->chip = chip;
> > > > > > >   pwm->pwm = chip->base + i;
> > > > > > >   pwm->hwpwm = i;
> > > > > > > - pwm->polarity = polarity;
> > > > > > > + pwm->state.polarity = polarity;
> > > > > > 
> > > > > > Would this not more correctly be assigned to pwm->args.polarity? 
> > > > > > After
> > > > > > all this is setting up the "initial" state, much like DT or the 
> > > > > > lookup
> > > > > > tables would for duty cycle and period.
> > > > > 
> > > > > Yes, I wasn't sure about the pwm_add_with_polarity() meaning. To me,
> > > > > all the reference info should be extracted from DT, PWM lookup table 
> > > > > or
> > > > > driver specific ->request() implementation, but I can definitely
> > > > > initialize the args.polarity here too.
> > > > > 
> > > > > Should I keep the pwm->state.polarity assignment (to set the initial
> > > > > polarity when the driver does not support hardware readout)?
> > > > 
> > > > Wouldn't this work automatically as part of the pwm_apply_args() helper
> > > > if we extended it with this setting?
> > > 
> > > Well, as you explained in you answer to patch 5, pwm_apply_args()
> > > should be called on a per-request basis (each time a PWM device is
> > > requested), while the initial polarity setting should only be applied
> > > when registering the PWM chip (and its devices). After that, the
> > > framework takes care of keeping the PWM state in sync with the hardware
> > > state.
> > > 
> > > Let's take a real (though a bit unusual) example. Say you have a single
> > > PWM device referenced by two different users. Only one user can be
> > > enabled at a time, but each of them has its own reference config
> > > (different polarity, different period).
> > > 
> > > User1 calls pwm_get() and applies its own polarity and period. Then
> > > user1 is unregistered and release the PWM device, leaving the polarity
> > > and period untouched.
> > > 
> > > User2 is registered and request the same PWM device, but user2 is
> > > smarter and tries to extract the current PWM state before adapting the
> > > config according to pwm_args. If you just reset pwm->state.polarity
> > > each time pwm_apply_args() is called (and you suggested to call it as
> > > part of the request procedure), then this means the PWM state is no
> > > longer in sync with the hardware state.
> > 
> > In that case neither will be the period or duty cycle. Essentially this
> > gets us back to square one where we need to decide how to handle current
> > state vs. initial arguments.
> 
> That's not true. Now we clearly differentiate the reference config
> (content of pwm_args which is only a subset of what you'll find in
> pwm_state) and the PWM state (represented by pwm_state).
> 
> We should be safe as long as we keep those 2 elements as 2 orthogonal
> concepts:
> - pwm_args is supposed to give some hint to the PWM user to help him
>   configure it's PWM appropriately
> - pwm_state is here to reflect the real PWM state, and apply new
>   configs
> 
> > 
> > But I don't think this is really going to be an issue because this is
> > all moot until we've moved over to the atomic API, at which point this
> > is all going to go away anyway.
> 
> As stated in my answer to patch 5, I 

Re: [Intel-gfx] [PATCH 07/10] drm/virtio: Drop dummy gamma table support

2016-04-12 Thread Emil Velikov
On 30 March 2016 at 10:51, Daniel Vetter  wrote:
> No need to confuse userspace like this.
>
> Cc: Gerd Hoffmann 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 4854dac87e24..12b72e29678a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -38,13 +38,6 @@
>  #define XRES_MAX  8192
>  #define YRES_MAX  8192
>
> -static void virtio_gpu_crtc_gamma_set(struct drm_crtc *crtc,
> - u16 *red, u16 *green, u16 *blue,
> - uint32_t start, uint32_t size)
> -{
> -   /* TODO */
> -}
> -
>  static void
>  virtio_gpu_hide_cursor(struct virtio_gpu_device *vgdev,
>struct virtio_gpu_output *output)
> @@ -173,7 +166,6 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
>  static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
> .cursor_set2= virtio_gpu_crtc_cursor_set,
> .cursor_move= virtio_gpu_crtc_cursor_move,
> -   .gamma_set  = virtio_gpu_crtc_gamma_set,
> .set_config = drm_atomic_helper_set_config,
> .destroy= drm_crtc_cleanup,
>
> @@ -416,7 +408,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
> *vgdev, int index)
> return PTR_ERR(plane);
> drm_crtc_init_with_planes(dev, crtc, plane, NULL,
>   _gpu_crtc_funcs, NULL);
> -   drm_mode_crtc_set_gamma_size(crtc, 256);
> drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
> plane->crtc = crtc;
>
Out of curiosity:

Coccinelle should be able to handle/generate such patches, shouldn't
it ? I believe in the past people used it for similar
refactoring/cleanups, yet not (m)any of them [the cocci files] got
checked in the kernel tree.

Thinking about future drivers derived from outdated sources - do you
think it's a good/bad idea to check/run them along side the existing
ones ?

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


Re: [Intel-gfx] [PATCH v4] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-04-12 Thread Mika Kuoppala
Michał Winiarski  writes:

> [ text/plain ]
> We started to use PIPE_CONTROL to write render ring seqno in order to
> combat seqno write vs interrupt generation problems. This was introduced
> by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
> generation on gen8+ execlists").
>
> On gen8+ size of PIPE_CONTROL with Post Sync Operation should be
> 6 dwords. When we're using older 5-dword variant it's possible to
> observe inconsistent values written by PIPE_CONTROL with Post
> Sync Operation from user batches, resulting in rendering corruptions.
>
> v2: Fix BAT failures
> v3: Comments on alignment and thrashing high dword of seqno (Chris)
> v4: Updated commit msg (Mika)
>
> Testcase: igt/gem_pipe_control_store_loop/*-qword-write
> Issue: VIZ-7393
> Cc: sta...@vger.kernel.org
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Abdiel Janulgue 
> Signed-off-by: Michał Winiarski 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0d6dc5e..30abe53 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1945,15 +1945,18 @@ static int gen8_emit_request_render(struct 
> drm_i915_gem_request *request)
>   struct intel_ringbuffer *ringbuf = request->ringbuf;
>   int ret;
>  
> - ret = intel_logical_ring_begin(request, 6 + WA_TAIL_DWORDS);
> + ret = intel_logical_ring_begin(request, 8 + WA_TAIL_DWORDS);
>   if (ret)
>   return ret;
>  
> + /* We're using qword write, seqno should be aligned to 8 bytes. */
> + BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
> +
>   /* w/a for post sync ops following a GPGPU operation we
>* need a prior CS_STALL, which is emitted by the flush
>* following the batch.
>*/
> - intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
> + intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
>   intel_logical_ring_emit(ringbuf,
>   (PIPE_CONTROL_GLOBAL_GTT_IVB |
>PIPE_CONTROL_CS_STALL |
> @@ -1961,7 +1964,10 @@ static int gen8_emit_request_render(struct 
> drm_i915_gem_request *request)
>   intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine));
>   intel_logical_ring_emit(ringbuf, 0);
>   intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
> + /* We're thrashing one dword of HWS. */
> + intel_logical_ring_emit(ringbuf, 0);
>   intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
> + intel_logical_ring_emit(ringbuf, MI_NOOP);
>   return intel_logical_ring_advance_and_submit(request);
>  }
>  
> -- 
> 2.8.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


Re: [Intel-gfx] [PATCH] drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

2016-04-12 Thread Chris Wilson
On Tue, Apr 12, 2016 at 02:46:16PM +0100, Dave Gordon wrote:
> The newly-introduced function i915_gem_object_pin_map() returns an
> ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we
> must check for. And it's nicer not to assign such a pointer-or-error to
> a structure being filled in until after it's been validated, so we
> should keep it local and avoid exporting a bogus pointer. Also, for
> clarity and symmetry, we should clear 'virtual_start' along with 'vma'
> when unmapping a ringbuffer.
> 
> Signed-off-by: Dave Gordon 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
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


[Intel-gfx] [PATCH v4] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-04-12 Thread Michał Winiarski
We started to use PIPE_CONTROL to write render ring seqno in order to
combat seqno write vs interrupt generation problems. This was introduced
by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
generation on gen8+ execlists").

On gen8+ size of PIPE_CONTROL with Post Sync Operation should be
6 dwords. When we're using older 5-dword variant it's possible to
observe inconsistent values written by PIPE_CONTROL with Post
Sync Operation from user batches, resulting in rendering corruptions.

v2: Fix BAT failures
v3: Comments on alignment and thrashing high dword of seqno (Chris)
v4: Updated commit msg (Mika)

Testcase: igt/gem_pipe_control_store_loop/*-qword-write
Issue: VIZ-7393
Cc: sta...@vger.kernel.org
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Abdiel Janulgue 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_lrc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0d6dc5e..30abe53 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1945,15 +1945,18 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
struct intel_ringbuffer *ringbuf = request->ringbuf;
int ret;
 
-   ret = intel_logical_ring_begin(request, 6 + WA_TAIL_DWORDS);
+   ret = intel_logical_ring_begin(request, 8 + WA_TAIL_DWORDS);
if (ret)
return ret;
 
+   /* We're using qword write, seqno should be aligned to 8 bytes. */
+   BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
+
/* w/a for post sync ops following a GPGPU operation we
 * need a prior CS_STALL, which is emitted by the flush
 * following the batch.
 */
-   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
+   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
intel_logical_ring_emit(ringbuf,
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
@@ -1961,7 +1964,10 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
+   /* We're thrashing one dword of HWS. */
+   intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
+   intel_logical_ring_emit(ringbuf, MI_NOOP);
return intel_logical_ring_advance_and_submit(request);
 }
 
-- 
2.8.0

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

2016-04-12 Thread Tvrtko Ursulin



On 12/04/16 14:43, Ville Syrjälä wrote:

On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote:


On 08/04/16 08:02, Patchwork wrote:

Test kms_flip:
  Subgroup basic-flip-vs-dpms:
  pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE


Old friend unclaimed access prior to suspending:
https://bugs.freedesktop.org/show_bug.cgi?id=94164


o_O

ILK doesn't even have a way to detect such things.


:D No idea, must be copy and paste error, wrong tab, stack overflow on 
(mental) context switching..


Real one is sporadic fifo underrun: 
https://bugs.freedesktop.org/show_bug.cgi?id=93787


Regards,

Tvrtko




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


[Intel-gfx] [PATCH] drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

2016-04-12 Thread Dave Gordon
The newly-introduced function i915_gem_object_pin_map() returns an
ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we
must check for. And it's nicer not to assign such a pointer-or-error to
a structure being filled in until after it's been validated, so we
should keep it local and avoid exporting a bogus pointer. Also, for
clarity and symmetry, we should clear 'virtual_start' along with 'vma'
when unmapping a ringbuffer.

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 

---
 drivers/gpu/drm/i915/i915_drv.h |  6 --
 drivers/gpu/drm/i915/intel_ringbuffer.c | 15 +--
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9c8211..bc8f0a3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3000,9 +3000,11 @@ static inline void i915_gem_object_unpin_pages(struct 
drm_i915_gem_object *obj)
  * pages and then returns a contiguous mapping of the backing storage into
  * the kernel address space.
  *
- * The caller must hold the struct_mutex.
+ * The caller must hold the struct_mutex, and is responsible for calling
+ * i915_gem_object_unpin_map() when the mapping is no longer required.
  *
- * Returns the pointer through which to access the backing storage.
+ * Returns the pointer through which to access the mapped object, or an
+ * ERR_PTR() on error.
  */
 void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj);
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 41b604e..35231ff 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2086,6 +2086,7 @@ void intel_unpin_ringbuffer_obj(struct intel_ringbuffer 
*ringbuf)
i915_gem_object_unpin_map(ringbuf->obj);
else
iounmap(ringbuf->virtual_start);
+   ringbuf->virtual_start = NULL;
ringbuf->vma = NULL;
i915_gem_object_ggtt_unpin(ringbuf->obj);
 }
@@ -2096,6 +2097,7 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_object *obj = ringbuf->obj;
+   void *addr;
int ret;
 
if (HAS_LLC(dev_priv) && !obj->stolen) {
@@ -2107,9 +2109,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
if (ret)
goto err_unpin;
 
-   ringbuf->virtual_start = i915_gem_object_pin_map(obj);
-   if (ringbuf->virtual_start == NULL) {
-   ret = -ENOMEM;
+   addr = i915_gem_object_pin_map(obj);
+   if (IS_ERR(addr)) {
+   ret = PTR_ERR(addr);
goto err_unpin;
}
} else {
@@ -2124,14 +2126,15 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
 
-   ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +
-   
i915_gem_obj_ggtt_offset(obj), ringbuf->size);
-   if (ringbuf->virtual_start == NULL) {
+   addr = ioremap_wc(ggtt->mappable_base +
+ i915_gem_obj_ggtt_offset(obj), ringbuf->size);
+   if (addr == NULL) {
ret = -ENOMEM;
goto err_unpin;
}
}
 
+   ringbuf->virtual_start = addr;
ringbuf->vma = i915_gem_obj_to_ggtt(obj);
return 0;
 
-- 
1.9.1

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

2016-04-12 Thread Ville Syrjälä
On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote:
> 
> On 08/04/16 08:02, Patchwork wrote:
> > Test kms_flip:
> >  Subgroup basic-flip-vs-dpms:
> >  pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
> 
> Old friend unclaimed access prior to suspending: 
> https://bugs.freedesktop.org/show_bug.cgi?id=94164

o_O

ILK doesn't even have a way to detect such things.

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


  1   2   >