[Intel-gfx] [PATCH] kms_atomic : Added subtest for Single Pipe DBUF validation

2016-10-03 Thread meghanelogal
Existing DDB algorithm divide the DDB wrt data rate,
hence the planes with the less height but same width
will be allocated less blocks and watermark are based
on width which requires more DDB. With this data the flip
may fail.

In new DDB algorithm, the DDB is divided based on
watermark requirement.

In this subtest, dividing the htotal/200 will allocate
~2-4 blocks out of total(512/896), flip may fail with the
exisiting algorithm.But with the new algorithm it will pass.

Signed-off-by: Megha Nelogal 
---
 tests/kms_atomic.c | 77 ++
 1 file changed, 77 insertions(+)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index f27ee46..ff25644 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -1280,6 +1280,60 @@ static void atomic_invalid_params(struct 
kms_atomic_crtc_state *crtc,
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EFAULT);
 }
 
+static void validate_dbuf(struct kms_atomic_crtc_state *crtc,
+   struct kms_atomic_plane_state **plane_array,
+   int plane_count)
+{
+   int i;
+   struct kms_atomic_desc *desc = crtc->state->desc;
+
+   /* for active crtc do modeset on the native resolution */
+   drmModeAtomicReq *req = drmModeAtomicAlloc();
+   struct drm_mode_modeinfo *mode = crtc->mode.data;
+   struct kms_atomic_plane_state plane;
+   struct igt_fb fb;
+
+   crtc_populate_req(crtc, req);
+
+   /* Add plane data to the structure...*/
+   uint32_t crtc_x = 0;
+   uint32_t crtc_y = 0;
+
+   for (i = 0; i < plane_count; i++) {
+   plane = *plane_array[i];
+   uint32_t format = plane_get_igt_format();
+
+   igt_require(format != 0);
+   plane.src_x = 0;
+   plane.src_y = 0;
+   plane.src_w = (mode->hdisplay / (1)) << 16;
+   plane.crtc_x = crtc_x;
+   plane.crtc_y = crtc_y;
+   plane.crtc_w = (mode->hdisplay) / (1);
+   plane.crtc_h = (mode->vdisplay) / (i + 1);
+
+   plane.crtc_id = crtc->obj;
+
+   if (i%2 == 0) {
+   plane.src_h = (mode->vdisplay / (1)) << 16;
+   plane.crtc_h = (mode->vdisplay) / (1);
+   }
+
+   if (i%2 == 1) {
+   plane.src_h = ceil((mode->vdisplay / 200) << 16);
+   plane.crtc_h = ceil((mode->vdisplay / 200));
+   }
+
+   plane.fb_id = igt_create_fb(plane.state->desc->fd,
+   plane.crtc_w, plane.crtc_h,
+   format, I915_TILING_NONE, );
+   plane_populate_req(, req);
+   }
+   do_atomic_commit(desc->fd, req, ATOMIC_RELAX_NONE);
+   drmModeAtomicFree(req);
+}
+
+
 igt_main
 {
struct kms_atomic_desc desc;
@@ -1373,6 +1427,29 @@ igt_main
atomic_state_free(scratch);
}
 
+   igt_subtest("validate_dbuf") {
+   struct kms_atomic_state *scratch = atomic_state_dup(current);
+   struct kms_atomic_crtc_state *crtc = find_crtc(scratch, true);
+   struct kms_atomic_plane_state *plane;
+   struct kms_atomic_connector_state *connector =
+   find_connector(scratch, crtc);
+   struct kms_atomic_plane_state **plane_array = NULL;
+   /* Enabling Two planes */
+   plane_array = calloc(2, sizeof(struct kms_atomic_plane_state 
*));
+   int plane_count = 0;
+
+   igt_require(crtc);
+   plane = find_plane(scratch, PLANE_TYPE_PRIMARY, crtc);
+   igt_require(plane);
+   plane_array[plane_count] = plane; plane_count++;
+   plane = find_plane(scratch, PLANE_TYPE_OVERLAY, crtc);
+   igt_require(plane);
+   plane_array[plane_count] = plane; plane_count++;
+   igt_require(connector);
+   validate_dbuf(crtc, plane_array, plane_count);
+   atomic_state_free(scratch);
+   }
+
atomic_state_free(current);
 
igt_fixture
-- 
1.9.1

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


Re: [Intel-gfx] [i-g-t PATCH 3/3] igt/drv_module_reload_basic: let intel_ips removal errors through

2016-10-03 Thread Joonas Lahtinen
On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote:
> Only try removing intel_ips if it's actually loaded, and let the errors
> through to the logs if removal fails.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [i-g-t PATCH 2/3] igt/drv_module_reload_basic: let snd_hda_intel removal errors through

2016-10-03 Thread Joonas Lahtinen
On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote:
> Only try removing snd_hda_intel if it's actually loaded, and let the
> errors through to the logs if removal fails. This is a clue if i915
> removal fails later.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [i-g-t PATCH 1/3] igt/drv_module_reload_basic: add helper for checking module reloaded

2016-10-03 Thread Joonas Lahtinen
On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote:
> Add a helper for checking whether a module is reloaded, using
> lsmod. Also make the grep stricter than before.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PULL] topic/drm-misc

2016-10-03 Thread Dave Airlie
On 3 October 2016 at 23:39, Daniel Vetter  wrote:
> Hi Dave,
>
> As promised another pull request. A bit late because flu.
> - generic pipe crc from Tomeu, required a backmerge to apply
> - fixes for my fumbled drm_plane.c extraction
> - display_info cleanup/fixes from Ville
> - misc stuff all over

I pulled this, it fell over I force pushed drm-next back to what it
was, I'm sad panda.

Hopefully nobody had pulled drm-next too much in that time period.

The pipe crc stuff is pretty broken wrt driver that still have ->load,
since we register
the minors before we call load, and on ->load driver the mode resources haven't
been configured at that point.

I'd really like the rest of drm-misc, but I might at least cherry-pick
out the major patch
I want which is the drm_plane.c fixup.

Dave.
___
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: KBL - Recommended buffer translation programming for DisplayPort

2016-10-03 Thread Vivi, Rodrigo
On Mon, 2016-10-03 at 13:50 +0300, Jani Nikula wrote:
> On Fri, 30 Sep 2016, Rodrigo Vivi  wrote:
> > According to spec: "KBL re-uses SKL values, except where
> > specific KBL values are listed."
> >
> > And recently spec has changed adding different table for Display Port only.
> > But for all SKUs (H,S,U,Y) we have slightly different values.
> >
> > Cc: Manasi Navare 
> > Cc: Arthur Runyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 88 
> > +++-
> >  1 file changed, 78 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 018964b..1573360 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -167,8 +167,47 @@ static const struct ddi_buf_trans 
> > skl_y_ddi_translations_dp[] = {
> > { 0x80005012, 0x00C0, 0x3 },
> >  };
> >  
> > +/* Kabylake H and S */
> > +static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
> > +   { 0x2016, 0x00A0, 0x0 },
> > +   { 0x5012, 0x009B, 0x0 },
> > +   { 0x7011, 0x0088, 0x0 },
> > +   { 0x80009010, 0x00C0, 0x1 },
> > +   { 0x2016, 0x009B, 0x0 },
> > +   { 0x5012, 0x0088, 0x0 },
> > +   { 0x80007011, 0x00C0, 0x1 },
> > +   { 0x2016, 0x009F, 0x0 },
> > +   { 0x80005012, 0x00C0, 0x1 },
> > +};
> > +
> > +/* Kabylake U */
> > +static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
> > +   { 0x201B, 0x00A1, 0x0 },
> > +   { 0x5012, 0x0088, 0x0 },
> > +   { 0x80007011, 0x00CD, 0x3 },
> > +   { 0x80009010, 0x00C0, 0x3 },
> > +   { 0x201B, 0x009D, 0x0 },
> > +   { 0x80005012, 0x00C0, 0x3 },
> > +   { 0x80007011, 0x00C0, 0x3 },
> > +   { 0x2016, 0x004F, 0x0 },
> > +   { 0x80005012, 0x00C0, 0x3 },
> > +};
> > +
> > +/* Kabylake Y */
> > +static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
> > +   { 0x1017, 0x00A1, 0x0 },
> > +   { 0x5012, 0x0088, 0x0 },
> > +   { 0x80007011, 0x00CD, 0x3 },
> > +   { 0x8000800F, 0x00C0, 0x3 },
> > +   { 0x1017, 0x009D, 0x0 },
> > +   { 0x80005012, 0x00C0, 0x3 },
> > +   { 0x80007011, 0x00C0, 0x3 },
> > +   { 0x1017, 0x004C, 0x0 },
> > +   { 0x80005012, 0x00C0, 0x3 },
> > +};
> > +
> >  /*
> > - * Skylake H and S
> > + * Skylake/Kabylake H and S
> >   * eDP 1.4 low vswing translation parameters
> >   */
> >  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> > @@ -185,7 +224,7 @@ static const struct ddi_buf_trans 
> > skl_ddi_translations_edp[] = {
> >  };
> >  
> >  /*
> > - * Skylake U
> > + * Skylake/Kabylake U
> >   * eDP 1.4 low vswing translation parameters
> >   */
> >  static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
> > @@ -202,7 +241,7 @@ static const struct ddi_buf_trans 
> > skl_u_ddi_translations_edp[] = {
> >  };
> >  
> >  /*
> > - * Skylake Y
> > + * Skylake/Kabylake Y
> >   * eDP 1.4 low vswing translation parameters
> >   */
> >  static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
> > @@ -218,7 +257,7 @@ static const struct ddi_buf_trans 
> > skl_y_ddi_translations_edp[] = {
> > { 0x0018, 0x008A, 0x0 },
> >  };
> >  
> > -/* Skylake U, H and S */
> > +/* Skylake/Kabylake U, H and S */
> >  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
> > { 0x0018, 0x00AC, 0x0 },
> > { 0x5012, 0x009D, 0x0 },
> > @@ -233,7 +272,7 @@ static const struct ddi_buf_trans 
> > skl_ddi_translations_hdmi[] = {
> > { 0x8018, 0x00C0, 0x1 },
> >  };
> >  
> > -/* Skylake Y */
> > +/* Skylake/Kabylake Y */
> >  static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
> > { 0x0018, 0x00A1, 0x0 },
> > { 0x5012, 0x00DF, 0x0 },
> > @@ -334,10 +373,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private 
> > *dev_priv, int *n_entries)
> >  static const struct ddi_buf_trans *
> >  skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> >  {
> > -   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
> > +   if (IS_SKL_ULX(dev_priv)) {
> > *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
> > return skl_y_ddi_translations_dp;
> > -   } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
> > +   } else if (IS_SKL_ULT(dev_priv)) {
> > *n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
> > return skl_u_ddi_translations_dp;
> > } else {
> > @@ -347,6 +386,21 @@ skl_get_buf_trans_dp(struct drm_i915_private 
> > *dev_priv, int *n_entries)
> >  }
> >  
> >  static const struct ddi_buf_trans *
> > +kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> > +{
> > +   if (IS_KBL_ULX(dev_priv)) {
> > +   *n_entries = 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

2016-10-03 Thread Patchwork
== Series Details ==

Series: drm/i915/dp/psr: Enable n + 1 active frame capture for PSR
URL   : https://patchwork.freedesktop.org/series/13249/
State : warning

== Summary ==

Series 13249v1 drm/i915/dp/psr: Enable n + 1 active frame capture for PSR
https://patchwork.freedesktop.org/api/1.0/series/13249/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:244  pass:214  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:181  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2616/

35ceb7ced7dc45fe6db94e36e3d36089557994f4 drm-intel-nightly: 
2016y-10m-03d-20h-05m-29s UTC integration manifest
e67fd82 drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

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


Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

2016-10-03 Thread Manasi Navare
On Thu, Sep 29, 2016 at 04:17:06PM -0700, Manasi Navare wrote:
> On Thu, Sep 29, 2016 at 09:05:01AM -0700, Manasi Navare wrote:
> > On Thu, Sep 29, 2016 at 06:48:43PM +0300, Jani Nikula wrote:
> > > On Thu, 29 Sep 2016, Ville Syrjälä  wrote:
> > > > On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
> > > >> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> > > >> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
> > > >> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> > > >> > >> On Tue, 27 Sep 2016, Manasi Navare  
> > > >> > >> wrote:
> > > >> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> > > >> > >> >> On Fri, 16 Sep 2016, Manasi Navare  
> > > >> > >> >> wrote:
> > > >> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery 
> > > >> > >> >> > failure
> > > >> > >> >> > the link training sequence should fall back to the lower 
> > > >> > >> >> > link rate
> > > >> > >> >> > followed by lower lane count until CR succeeds.
> > > >> > >> >> > On CR success, the sequence proceeds with Channel EQ.
> > > >> > >> >> > In case of Channel EQ failures, it should fallback to
> > > >> > >> >> > lower link rate and lane count and start the CR phase again.
> > > >> > >> >> 
> > > >> > >> >> This change makes the link training start at the max lane 
> > > >> > >> >> count and max
> > > >> > >> >> link rate. This is not ideal, as it wastes the link. And it is 
> > > >> > >> >> not a
> > > >> > >> >> spec requirement. "The Link Policy Maker of the upstream 
> > > >> > >> >> device may
> > > >> > >> >> choose any link count and link rate as long as they do not 
> > > >> > >> >> exceed the
> > > >> > >> >> capabilities of the DP receiver."
> > > >> > >> >> 
> > > >> > >> >> Our current code starts at the minimum required bandwidth for 
> > > >> > >> >> the mode,
> > > >> > >> >> therefore we can't fall back to lower link rate and lane count 
> > > >> > >> >> without
> > > >> > >> >> reducing the mode.
> > > >> > >> >> 
> > > >> > >> >> AFAICT this patch here makes it possible for the link 
> > > >> > >> >> bandwidth to drop
> > > >> > >> >> below what is required for the mode. This is unacceptable.
> > > >> > >> >> 
> > > >> > >> >> BR,
> > > >> > >> >> Jani.
> > > >> > >> >> 
> > > >> > >> >>
> > > >> > >> >
> > > >> > >> > Thanks Jani for your review comments.
> > > >> > >> > Yes in this change we start at the max link rate and lane 
> > > >> > >> > count. This
> > > >> > >> > change was made according to the design document discussions we 
> > > >> > >> > had
> > > >> > >> > before strating this DP Redesign project. The main reason for 
> > > >> > >> > starting
> > > >> > >> > at the maxlink rate and max lane count was for ensuring proper
> > > >> > >> > behavior of DP MST. In case of DP MST, we want to train the 
> > > >> > >> > link at
> > > >> > >> > the maximum supported link rate/lane count based on an early/ 
> > > >> > >> > upfront
> > > >> > >> > link training result so that we dont fail when we try to 
> > > >> > >> > connect a
> > > >> > >> > higher resolution monitor as a second monitor. This a trade off
> > > >> > >> > between wsting the link or higher power vs. needing to retrain 
> > > >> > >> > for
> > > >> > >> > every monitor that requests a higher BW in case of DP MST.
> > > >> > >> 
> > > >> > >> We already train at max bandwidth for DP MST, which seems to be 
> > > >> > >> the
> > > >> > >> sensible thing to do.
> > > >> > >> 
> > > >> > >> > Actually this is also the reason for enabling upfront link 
> > > >> > >> > training in
> > > >> > >> > the following patch where we train the link much ahead in the 
> > > >> > >> > modeset
> > > >> > >> > sequence to understand the link rate and lane count values at 
> > > >> > >> > which
> > > >> > >> > the link can be successfully trained and then the link training
> > > >> > >> > through modeset will always start at the upfront values (maximum
> > > >> > >> > supported values of lane count and link rate based on upfront 
> > > >> > >> > link
> > > >> > >> > training).
> > > >> > >> 
> > > >> > >> I don't see a need to do this for DP SST.
> > > >> > >> 
> > > >> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall 
> > > >> > >> > back to
> > > >> > >> > the lower link rate after trying to train at the maximum link 
> > > >> > >> > rate
> > > >> > >> > advertised through the DPCD registers.
> > > >> > >> 
> > > >> > >> That test does not require the source DUT to default to maximum 
> > > >> > >> lane
> > > >> > >> count or link rate of the sink. The source may freely choose the 
> > > >> > >> lane
> > > >> > >> count and link rate as long as they don't exceed sink 
> > > >> > >> capabilities.
> > > >> > >> 
> > > >> > >> For the purposes of the test, the test setup can request specific
> > > >> > >> parameters to be used, but that does not mean using 

[Intel-gfx] [PATCH RFC] drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

2016-10-03 Thread Jim Bride
On some system + panel combinations the vblank interval is too
short for PSR setup to occur.  While reading the eDP v1.3 spec
I saw that Figure 4-7 describes a solution to this very problem
by configuring PSR to capture the second active frame after the
PSR entry indication in order to provide more time for PSR
setup activities.  This patch changes our PSR configuration
to indicate that the sink should capture the second active
frame after PSR entry indication.

Cc: jani.nik...@linux.intel.com
Cc: ville.syrj...@linux.intel.com
Cc: rodrigo.v...@intel.com

Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_psr.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 108ba1e..4d7e2a8 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -199,10 +199,11 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
 
if (dev_priv->psr.link_standby)
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
-  DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
+  DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
+  DP_PSR_FRAME_CAPTURE);
else
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
-  DP_PSR_ENABLE);
+  DP_PSR_ENABLE | DP_PSR_FRAME_CAPTURE);
 
aux_ctl_reg = psr_aux_ctl_reg(dev_priv, port);
 
-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for HuC Loading Patches

2016-10-03 Thread Patchwork
== Series Details ==

Series: HuC Loading Patches
URL   : https://patchwork.freedesktop.org/series/13244/
State : warning

== Summary ==

Series 13244v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/13244/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6700k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:244  pass:214  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:244  pass:210  dwarn:2   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-byt-n2820 failed to collect. IGT log at Patchwork_2615/fi-byt-n2820/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2615/

71d126590e2fa6d65d93fe3586d55ddf9f6c39a6 drm-intel-nightly: 
2016y-10m-03d-13h-22m-56s UTC integration manifest
7372b66 drm/i915/get_params: Add HuC status to getparams
9b67dd6 drm/i915/get_params: Add GuC status to getparams
1ae3938 drm/i915/huc: Add BXT HuC Loading Support
5fa24fe drm/i915/huc: Support HuC authentication
9a038e2 drm/i915/huc: Add debugfs for HuC loading status check
52144f2 drm/i915/huc: Add HuC fw loading support
e5c48b1 drm/i915/huc: Unified css_header struct for GuC and HuC
e69b469 drm/i915/guc: Make the GuC fw loading helper functions general

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


[Intel-gfx] [PATCH 7/8] drm/i915/get_params: Add GuC status to getparams

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

This patch returns the GuC status to the caller. It is used so
that the userspace knows if the GuC has been loaded.

v4: rebase.
v5: rebased.

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/intel_guc.h|  2 +-
 drivers/gpu/drm/i915/intel_guc_loader.c | 18 ++
 include/uapi/drm/i915_drm.h |  1 +
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7af7bd6..ff1c18d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
+#include "intel_guc.h"
 
 static struct drm_driver driver;
 
@@ -339,6 +340,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 */
value = 1;
break;
+   case I915_PARAM_HAS_GUC:
+   value = intel_is_guc_valid(dev_priv);
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index af76ffe..3a7fa7e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -168,5 +168,5 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv);
 int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
-
+int intel_is_guc_valid(struct drm_i915_private *dev_priv);
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 31a2b0a..5d2a703 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -801,3 +801,21 @@ void intel_guc_fini(struct drm_device *dev)
 
guc_fw->fetch_status = UC_FIRMWARE_NONE;
 }
+
+/**
+ * intel_is_guc_valid() - Check to see if the GuC is fully loaded.
+ * @dev:   drm dedvice to check.
+ *
+ * This function will return true if the guc has been loaded and
+ * has valid firmware.
+ */
+int intel_is_guc_valid(struct drm_i915_private *dev_priv)
+{
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
+
+   if (guc_fw->load_status == UC_FIRMWARE_SUCCESS)
+   return 1;
+   else
+   return 0;
+}
+
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 03725fe..629fb5e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -388,6 +388,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_POOLED_EU38
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_HAS_GUC  41
 
 typedef struct drm_i915_getparam {
__s32 param;
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.
v5: rebased.
v7: rebased.
v8: rebased.

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 
 drivers/gpu/drm/i915/intel_guc_loader.c| 156 ++---
 4 files changed, 106 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4fb9d82..44258a8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2416,7 +2416,7 @@ static int i915_llc(struct seq_file *m, void *data)
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;
 
if (!HAS_GUC_UCODE(dev_priv))
@@ -2424,15 +2424,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
 
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 43358e1..4b92943 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1072,7 +1072,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
@@ -1098,7 +1098,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b1ba869..b134a41 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -91,29 +91,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };
 
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-   enum intel_guc_fw_statusguc_fw_load_status;
-
-   uint16_tguc_fw_major_wanted;
-   uint16_tguc_fw_minor_wanted;
-   uint16_t   

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not usable until it is verified.

v2: removed the forewakes as the registers are already force-woken.
 (T.Ursulin)
v4: rebased.
v5: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/intel_huc.h|  2 +-
 drivers/gpu/drm/i915/intel_huc_loader.c | 14 ++
 include/uapi/drm/i915_drm.h |  1 +
 4 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ff1c18d..0d7b290 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
+#include "intel_huc.h"
 #include "intel_guc.h"
 
 static struct drm_driver driver;
@@ -343,6 +344,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_GUC:
value = intel_is_guc_valid(dev_priv);
break;
+   case I915_PARAM_HAS_HUC:
+   value = intel_is_huc_valid(dev_priv);
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 946caa7..5eac625 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -40,5 +40,5 @@ extern void intel_huc_init(struct drm_device *dev);
 extern int intel_huc_load(struct drm_device *dev);
 extern void intel_huc_auth(struct drm_device *dev);
 extern void intel_huc_fini(struct drm_device *dev);
-
+extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 87a6948..d574183 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -273,3 +273,17 @@ void intel_huc_fini(struct drm_device *dev)
 
huc_fw->fetch_status = UC_FIRMWARE_NONE;
 }
+
+/**
+ * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
+ * @dev_priv:  drm device to check.
+ *
+ * This function will return true if the guc has been loaded and
+ * has valid firmware. The simplest way of doing this is to check
+ * if the HuC has been validated, if so it must have been loaded.
+ */
+int intel_is_huc_valid(struct drm_i915_private *dev_priv)
+{
+   return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
+}
+
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 629fb5e..d236520 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -389,6 +389,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 #define I915_PARAM_HAS_GUC  41
+#define I915_PARAM_HAS_HUC  42
 
 typedef struct drm_i915_getparam {
__s32 param;
-- 
2.7.4

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


[Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.

v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5: rebased.
v7: rebased.
v8: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  2 +
 3 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4b92943..984b529 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -25,6 +25,7 @@
 #include 
 #include "i915_drv.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 
 /**
  * DOC: GuC-based command submission
@@ -1110,3 +,67 @@ int intel_guc_resume(struct drm_device *dev)
 
return host2guc_action(guc, data, ARRAY_SIZE(data));
 }
+
+/**
+ * intel_huc_auth() - authenticate ucode
+ * @dev: the drm device
+ *
+ * Triggers a HuC fw authentication request to the GuC via host-2-guc
+ * interface.
+ */
+void intel_huc_auth(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
+   struct i915_vma *vma;
+   int ret;
+   u32 data[2];
+
+   /* Bypass the case where there is no HuC firmware */
+   if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
+   huc->huc_fw.load_status == UC_FIRMWARE_NONE)
+   return;
+
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
+   return;
+   }
+
+   if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
+   return;
+   }
+
+   vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0);
+   if (IS_ERR(vma)) {
+   DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
+   return;
+   }
+
+
+   /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+   I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+   /* Specify auth action and where public signature is. It's stored
+* at the beginning of the gem object, before the fw bits
+*/
+   data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
+   data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
+
+   ret = host2guc_action(guc, data, ARRAY_SIZE(data));
+   if (ret) {
+   DRM_ERROR("HuC: GuC did not ack Auth request\n");
+   goto out;
+   }
+
+   /* Check authentication status, it should be done by now */
+   ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
+   if (ret) {
+   DRM_ERROR("HuC: Authentication failed\n");
+   goto out;
+   }
+
+out:
+   i915_vma_unpin(vma);
+}
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index b38b6b4..57e6466 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -438,6 +438,7 @@ enum host2guc_action {
HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
+   HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
HOST2GUC_ACTION_LIMIT
 };
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 0d214b4..31a2b0a 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -527,6 +527,8 @@ int intel_guc_setup(struct drm_device *dev)
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
 
+   intel_huc_auth(dev);
+
if (i915.enable_guc_submission) {
err = i915_guc_submission_enable(dev_priv);
if (err)
-- 
2.7.4

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


[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc.h|   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
 drivers/gpu/drm/i915/intel_huc.h|  44 ++
 drivers/gpu/drm/i915/intel_huc_loader.c | 268 
 8 files changed, 327 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e6fe004..6e99c51 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -53,6 +53,7 @@ i915-y += i915_cmd_parser.o \
 
 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 31b2b63..7af7bd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
 
+   intel_huc_init(dev);
intel_guc_init(dev);
 
ret = i915_gem_init(dev);
@@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 cleanup_gem:
i915_gem_fini(dev);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
 
+   intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0cb71c..625aa92 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
@@ -1766,6 +1767,7 @@ struct drm_i915_private {
 
struct intel_gvt gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2822,6 +2824,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))
 
 #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index a47e1e4..64e942a 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define DMA_COPY_SIZE  _MMIO(0xc310)
 #define DMA_CTRL   _MMIO(0xc314)
+#define   HUC_UKERNEL(1<<9)
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   HUC_LOADING_AGENT_VCR  (0<<1)
+#define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 812e4ca..af76ffe 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -160,6 +160,7 @@ extern const char *intel_uc_fw_status_repr(enum 
intel_uc_fw_status status);
 extern int intel_guc_suspend(struct drm_device *dev);
 extern int 

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

Add debugfs entry for HuC loading status check.

v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 44258a8..7bd0e23 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2413,6 +2413,36 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
 }
 
+static int i915_huc_load_status_info(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct intel_uc_fw *huc_fw = _priv->huc.huc_fw;
+
+   if (!HAS_HUC_UCODE(dev_priv))
+   return 0;
+
+   seq_puts(m, "HuC firmware status:\n");
+   seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
+   seq_printf(m, "\tfetch: %s\n",
+   intel_uc_fw_status_repr(huc_fw->fetch_status));
+   seq_printf(m, "\tload: %s\n",
+   intel_uc_fw_status_repr(huc_fw->load_status));
+   seq_printf(m, "\tversion wanted: %d.%d\n",
+   huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
+   seq_printf(m, "\tversion found: %d.%d\n",
+   huc_fw->major_ver_found, huc_fw->minor_ver_found);
+   seq_printf(m, "\theader: offset is %d; size = %d\n",
+   huc_fw->header_offset, huc_fw->header_size);
+   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+   huc_fw->ucode_offset, huc_fw->ucode_size);
+   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+   huc_fw->rsa_offset, huc_fw->rsa_size);
+
+   seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+
+   return 0;
+}
+
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4427,6 +4457,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
-- 
2.7.4

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


[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add BXT HuC Loading Support

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased.
changed file name to match the install package format.
v7: rebased.
v8: rebased.

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
Reviewed-by: David Gordon 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 1aaff67..87a6948 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -50,6 +50,9 @@
 #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 
+#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
 /**
  * intel_huc_load_ucode() - DMA's the firmware
  * @dev: the drm device
@@ -158,6 +161,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = 1;
huc_fw->minor_ver_wanted = 7;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = 1;
+   huc_fw->minor_ver_wanted = 7;
}
 
if (fw_path == NULL)
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

2016-10-03 Thread Anusha Srivatsa
From: Peter Antoine 

HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.

v2: rebased on-top of drm-intel-nightly
v3: rebased on-top of drm-intel-nightly (again).
v4: rebased + spaces.
v7: rebased.
v8: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_guc.h|  4 
 drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
 drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++---
 3 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b134a41..812e4ca 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -98,6 +98,9 @@ enum intel_uc_fw_status {
UC_FIRMWARE_SUCCESS
 };
 
+#define UC_FW_TYPE_GUC 0
+#define UC_FW_TYPE_HUC 1
+
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
@@ -115,6 +118,7 @@ struct intel_uc_fw {
uint16_t major_ver_found;
uint16_t minor_ver_found;
 
+   uint32_t fw_type;
uint32_t header_size;
uint32_t header_offset;
uint32_t rsa_size;
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e40db2d..b38b6b4 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -154,7 +154,7 @@
  * The GuC firmware layout looks like this:
  *
  * +---+
- * |guc_css_header |
+ * | uc_css_header |
  * |   |
  * | contains major/minor version  |
  * +---+
@@ -181,9 +181,16 @@
  * 3. Length info of each component can be found in header, in dwords.
  * 4. Modulus and exponent key are not required by driver. They may not appear
  *in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
  */
 
-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
 * key, modulus key and exponent data. */
@@ -214,7 +221,10 @@ struct guc_css_header {
 
char username[8];
char buildnumber[12];
-   uint32_t device_id;
+   union {
+   uint32_t device_id;
+   uint32_t huc_sw_version;
+   };
uint32_t guc_sw_version;
uint32_t prod_preprod_fw;
uint32_t reserved[12];
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 493295d..0b863a1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
struct pci_dev *pdev = dev->pdev;
struct drm_i915_gem_object *obj;
const struct firmware *fw;
-   struct guc_css_header *css;
+   struct uc_css_header *css;
size_t size;
int err;
 
@@ -603,19 +603,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
uc_fw->uc_fw_path, fw);
 
/* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct guc_css_header)) {
+   if (fw->size < sizeof(struct uc_css_header)) {
DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
-   css = (struct guc_css_header *)fw->data;
+   css = (struct uc_css_header *)fw->data;
 
/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
-   if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
@@ -639,21 +639,36 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
goto fail;
}
 
-   /* Header and uCode will 

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

2016-10-03 Thread Anusha Srivatsa
These patches add HuC loading support. The userspace
patches that check for a fully loaded HuC firmware and use
it can be found at:
https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/2016-September/004555.html
 
v2: rebased.


Peter Antoine (8):
  drm/i915/guc: Make the GuC fw loading helper functions general
  drm/i915/huc: Unified css_header struct for GuC and HuC
  drm/i915/huc: Add HuC fw loading support
  drm/i915/huc: Add debugfs for HuC loading status check
  drm/i915/huc: Support HuC authentication
  drm/i915/huc: Add BXT HuC Loading Support
  drm/i915/get_params: Add GuC status to getparams
  drm/i915/get_params: Add HuC status to getparams

 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  43 -
 drivers/gpu/drm/i915/i915_drv.c|  11 ++
 drivers/gpu/drm/i915/i915_drv.h|   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  69 ++-
 drivers/gpu/drm/i915/intel_guc.h   |  48 ++---
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  17 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 215 -
 drivers/gpu/drm/i915/intel_huc.h   |  44 +
 drivers/gpu/drm/i915/intel_huc_loader.c| 289 +
 include/uapi/drm/i915_drm.h|   2 +
 12 files changed, 624 insertions(+), 121 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

-- 
2.7.4

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


Re: [Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

2016-10-03 Thread Daniel Vetter
On Mon, Oct 3, 2016 at 3:06 PM, Petri Latvala  wrote:
> Add myself, remove Daniel by request.
>
> Signed-off-by: Petri Latvala 
> ---
>
> For the record.
>
> Daniel requested to be removed from the list (Daniel, please confirm,
> that's how I understood), and I'm going to be maintaining IGT with
> Marius until Marius steps down.

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/8] drm/i915: Share the computation of ring size for RING_CTL register

2016-10-03 Thread Patchwork
== Series Details ==

Series: series starting with [1/8] drm/i915: Share the computation of ring size 
for RING_CTL register
URL   : https://patchwork.freedesktop.org/series/13231/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-byt-n2820)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-bsw-n3050)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:201  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:244  pass:214  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:244  pass:212  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2614/

71d126590e2fa6d65d93fe3586d55ddf9f6c39a6 drm-intel-nightly: 
2016y-10m-03d-13h-22m-56s UTC integration manifest
eac1ec0 drm/i915: Show waiters in i915_hangcheck_info
32b82cc drm/i915: Show RING registers through debugfs
884a554 drm/i915: Show bounds of active request in the ring on GPU hang
cd5fc2b drm/i915: Double check hangcheck.seqno after reset
cd8a938 drm/i915: Disable irqs across GPU reset
51bba8d drm/i915/execlists: Move clearing submission count from reset to init
aeb2793 drm/i915/execlists: Reinitialise context image after GPU hang
fb86a24 drm/i915: Share the computation of ring size for RING_CTL register

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


[Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

2016-10-03 Thread Lionel Landwerlin
Some of the Intel platforms have odd numbers of LUT entries and we
need to tests a couple of values around the expected result. Bring
back the CRC equal function we need that doesn't trigger an assert
right away, while we still assert if we can't find a correct result in
the outter loop.

v2: update Fixes field (Jani)

v3: Use memcmp (Ville)

v4: missing signed-off

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97691
Fixes: 582ce4cd19c6 ("lib/debugs: nuke igt_crc_equal again")
Cc: Daniel Vetter 
Cc: Christophe Prigent 
Cc: Ville Syrjälä 
Signed-off-by: Lionel Landwerlin 
---
 tests/kms_pipe_color.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
index b0a2f07..f120e26 100644
--- a/tests/kms_pipe_color.c
+++ b/tests/kms_pipe_color.c
@@ -652,6 +652,13 @@ static void test_pipe_legacy_gamma_reset(data_t *data,
free(gamma_zero);
 }
 
+static bool crc_equal(igt_crc_t *a, igt_crc_t *b)
+{
+  int i;
+
+  return memcmp(a->crc, b->crc, sizeof(a->crc[0]) * a->n_words) == 0;
+}
+
 /*
  * Draw 3 rectangles using before colors with the ctm matrix apply and verify
  * the CRC is equal to using after colors with an identify ctm matrix.
@@ -724,7 +731,7 @@ static bool test_pipe_ctm(data_t *data,
/* Verify that the CRC of the software computed output is
 * equal to the CRC of the CTM matrix transformation output.
 */
-   igt_assert_crc_equal(_software, _hardware);
+   ret &= crc_equal(_software, _hardware);
 
igt_output_set_pipe(output, PIPE_ANY);
}
-- 
2.8.1

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


[Intel-gfx] [i-g-t PATCH 0/3] igt/drv_module_reload_basic: let more error messages through

2016-10-03 Thread Jani Nikula
Thes might leave us some more breadcrumbs on module removal errors.

BR,
Jani.

Jani Nikula (3):
  igt/drv_module_reload_basic: add helper for checking module reloaded
  igt/drv_module_reload_basic: let snd_hda_intel removal errors through
  igt/drv_module_reload_basic: let intel_ips removal errors through

 tests/drv_module_reload_basic | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

-- 
2.1.4

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


[Intel-gfx] [i-g-t PATCH 2/3] igt/drv_module_reload_basic: let snd_hda_intel removal errors through

2016-10-03 Thread Jani Nikula
Only try removing snd_hda_intel if it's actually loaded, and let the
errors through to the logs if removal fails. This is a clue if i915
removal fails later.

Signed-off-by: Jani Nikula 
---
 tests/drv_module_reload_basic | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
index 4f3172788eca..a221d65f725a 100755
--- a/tests/drv_module_reload_basic
+++ b/tests/drv_module_reload_basic
@@ -32,7 +32,9 @@ function reload() {
# The sound driver uses our power well
pkill alsactl
snd_hda_intel_unloaded=0
-   rmmod snd_hda_intel &> /dev/null && snd_hda_intel_unloaded=1
+   if mod_loaded snd_hda_intel; then
+   rmmod snd_hda_intel && snd_hda_intel_unloaded=1
+   fi
 
#ignore errors in ips - gen5 only
rmmod intel_ips &> /dev/null
-- 
2.1.4

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


[Intel-gfx] [i-g-t PATCH 1/3] igt/drv_module_reload_basic: add helper for checking module reloaded

2016-10-03 Thread Jani Nikula
Add a helper for checking whether a module is reloaded, using
lsmod. Also make the grep stricter than before.

Signed-off-by: Jani Nikula 
---
 tests/drv_module_reload_basic | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
index 3bba796f0306..4f3172788eca 100755
--- a/tests/drv_module_reload_basic
+++ b/tests/drv_module_reload_basic
@@ -10,6 +10,12 @@ SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 
 # no other drm service should be running, so we can just unbind
 
+# return 0 if module by name $1 is loaded according to lsmod
+function mod_loaded()
+{
+   lsmod | grep -w "^$1" &> /dev/null
+}
+
 function reload() {
local snd_hda_intel_unloaded
 
@@ -37,7 +43,7 @@ function reload() {
rmmod drm_kms_helper &> /dev/null
rmmod drm &> /dev/null
 
-   if lsmod | grep i915 &> /dev/null ; then
+   if mod_loaded i915; then
echo WARNING: i915.ko still loaded!
return $IGT_EXIT_FAILURE
else
-- 
2.1.4

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


[Intel-gfx] [i-g-t PATCH 3/3] igt/drv_module_reload_basic: let intel_ips removal errors through

2016-10-03 Thread Jani Nikula
Only try removing intel_ips if it's actually loaded, and let the errors
through to the logs if removal fails.

Signed-off-by: Jani Nikula 
---
 tests/drv_module_reload_basic | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
index a221d65f725a..93cf7c005638 100755
--- a/tests/drv_module_reload_basic
+++ b/tests/drv_module_reload_basic
@@ -36,8 +36,10 @@ function reload() {
rmmod snd_hda_intel && snd_hda_intel_unloaded=1
fi
 
-   #ignore errors in ips - gen5 only
-   rmmod intel_ips &> /dev/null
+   # gen5 only
+   if mod_loaded intel_ips; then
+   rmmod intel_ips
+   fi
rmmod i915 || return $IGT_EXIT_SKIP
#ignore errors in intel-gtt, often built-in
rmmod intel-gtt &> /dev/null
-- 
2.1.4

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Just clear the mmiodebug before a register access

2016-10-03 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Just clear the mmiodebug before 
a register access
URL   : https://patchwork.freedesktop.org/series/13230/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:244  pass:214  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:244  pass:210  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2613/

71d126590e2fa6d65d93fe3586d55ddf9f6c39a6 drm-intel-nightly: 
2016y-10m-03d-13h-22m-56s UTC integration manifest
1ca3cc8 drm/i915: Use correct index for backtracking HUNG semaphores
d586412 drm/i915: Unalias obj->phys_handle and obj->userptr
60c4f4e drm/i915: Just clear the mmiodebug before a register access

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


Re: [Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

2016-10-03 Thread Chris Wilson
On Mon, Oct 03, 2016 at 04:14:39PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > Check that there was not a late recovery between us declaring the GPU
> > hung and processing the reset. If the GPU did recover by itself, let the
> > request remain on the active list and see if it hangs again!
> >
> 
> Did you see this in action? Makes sense to recheck
> after reset. I don't remember how TDR will deal with multiple
> reset on the same engine but we should start tracking the seqno
> that cause it and make sure we don't get stuck by replaying the same.

Not observed. All my testing is with true hangs, not slow batches at
~hangcheck interval, i.e. nothing that would unstick between us
detecting the hang and sending the reset request.
 
> Do we check the banning on resubmission and/or do we trust that
> the breadcrumb update always succeedes?

Breadcrumb update has to succeed as we are not the only observers.
Issuing it from the GPU is the only way we can do the reset without
shooting ourselves in the foot with nasty races (and general explosions
from use-after-free).
 
> I envision that if we get multiple resets on same seqno, we
> just write the breadcrumbs through cpu and move on. But let's
> hope we don't need to and the gpu breadcrumps are always enough.

Can't do. The only time we can take over with the GPU is if we declare
the machine wedged and drain everything and all observers (including
external). That is quite impractical. :|
-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] [drm-intel:topic/drm-misc 3/3] htmldocs: include/drm/drm_fb_helper.h:222: warning: Cannot understand * @DRM_FB_HELPER_DEFAULT_OPS:

2016-10-03 Thread Daniel Vetter
On Mon, Oct 3, 2016 at 11:35 AM, Jani Nikula
 wrote:
>>220/**
>>221 * @DRM_FB_HELPER_DEFAULT_OPS:
>
> Superfluous @.

Stefan, pls fix this and run

$ make htmldocs

to make sure the output looks correct. Cargo-culting kerneldoc without
checking the output doesn't work too well ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PULL] topic/drm-misc

2016-10-03 Thread Daniel Vetter
Hi Dave,

As promised another pull request. A bit late because flu.
- generic pipe crc from Tomeu, required a backmerge to apply
- fixes for my fumbled drm_plane.c extraction
- display_info cleanup/fixes from Ville
- misc stuff all over

Cheers, Daniel


The following changes since commit c0d5fb4d0d9224ccaad0475c9b58740873970e7e:

  Merge tag 'drm-qemu-20160921' of git://git.kraxel.org/linux into drm-next 
(2016-09-28 13:23:07 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-10-03

for you to fetch changes up to 262f75a6288346db44038c63b7a95ee68f8b7bea:

  drm: Undo damage to page_flip_ioctl (2016-10-03 15:13:38 +0200)


Baoyou Xie (4):
  drm/rockchip: add missing header dependencies
  drm/rockchip: mark symbols static where possible
  drm/mediatek: mark symbols static where possible
  drm/sti: mark symbols static where possible

Chris Wilson (2):
  drm: Restore lost drm_framebuffer_unreference in drm_mode_page_flip_ioctl
  drm: Convert prime dma-buf <-> handle to rbtree

Daniel Vetter (3):
  Merge remote-tracking branch 'airlied/drm-next' into topic/drm-misc
  drm: Document caveats around atomic event handling
  drm: Undo damage to page_flip_ioctl

Dhinakaran Pandiyan (1):
  drm: Add frame CRC debugfs files only for drivers that have CRTC

Emilio López (1):
  uapi: add missing install of sync_file.h

Joe Perches (1):
  drm: Simplify drm_printk to reduce object size quite a bit

Stefan Christ (1):
  drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Tomeu Vizoso (7):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines
  drm/i915: Fix build when !CONFIG_DEBUG_FS
  drm/bridge: analogix_dp: Add analogix_dp_psr_supported
  drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support 
it

Ville Syrjälä (10):
  drm/edid: Clear old audio latency values before parsing the new EDID
  drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID
  drm/edid: Make max_tmds_clock kHz instead of MHz
  drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info
  drm/edid: Don't pass around drm_display_info needlessly
  drm/edid: Reduce the number of times we parse the CEA extension block
  drm/edid: Clear the old cea_rev when there's no CEA extension in the new 
EDID
  drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()
  drm/i915: Replace a bunch of connector->base.display_info with a local 
variable
  drm/i915: Account for sink max TMDS clock when checking the port clock

 Documentation/gpu/drm-uapi.rst |6 +
 drivers/gpu/drm/Makefile   |3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |4 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |8 +
 drivers/gpu/drm/drm_crtc.c |   29 +-
 drivers/gpu/drm/drm_debugfs.c  |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c  |  351 +++
 drivers/gpu/drm/drm_drv.c  |   28 +-
 drivers/gpu/drm/drm_edid.c |  248 ++---
 drivers/gpu/drm/drm_internal.h |   16 +
 drivers/gpu/drm/drm_irq.c  |   32 +-
 drivers/gpu/drm/drm_plane.c|   83 +-
 drivers/gpu/drm/drm_prime.c|   85 +-
 drivers/gpu/drm/i915/Makefile  |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c|  886 +
 drivers/gpu/drm/i915/i915_drv.c|2 +-
 drivers/gpu/drm/i915/i915_drv.h|5 +-
 drivers/gpu/drm/i915/i915_irq.c|   83 +-
 drivers/gpu/drm/i915/intel_display.c   |   15 +-
 drivers/gpu/drm/i915/intel_drv.h   |   13 +
 drivers/gpu/drm/i915/intel_hdmi.c  |9 +-
 drivers/gpu/drm/i915/intel_pipe_crc.c  | 1014 
 drivers/gpu/drm/mediatek/mtk_hdmi.c|   11 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |4 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|3 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |1 +
 include/drm/bridge/analogix_dp.h   |1 +
 include/drm/drmP.h |   35 +-
 include/drm/drm_connector.h|   15 +-
 include/drm/drm_crtc.h |   97 +-
 include/drm/drm_debugfs_crc.h  |   73 ++
 include/drm/drm_fb_helper.h|   13 +
 include/uapi/linux/Kbuild  |1 +
 34 files changed, 2069 

Re: [Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

2016-10-03 Thread Jani Nikula
On Mon, 03 Oct 2016, Petri Latvala  wrote:
> Add myself, remove Daniel by request.
>
> Signed-off-by: Petri Latvala 

Acked-by: Jani Nikula 


> ---
>
> For the record.
>
> Daniel requested to be removed from the list (Daniel, please confirm,
> that's how I understood), and I'm going to be maintaining IGT with
> Marius until Marius steps down.
>
> MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 58f9efb..bf3e530 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,2 +1,2 @@
> -Daniel Vetter 
>  Marius Vlad 
> +Petri Latvala 

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> Check that there was not a late recovery between us declaring the GPU
> hung and processing the reset. If the GPU did recover by itself, let the
> request remain on the active list and see if it hangs again!
>

Did you see this in action? Makes sense to recheck
after reset. I don't remember how TDR will deal with multiple
reset on the same engine but we should start tracking the seqno
that cause it and make sure we don't get stuck by replaying the same.

Do we check the banning on resubmission and/or do we trust that
the breadcrumb update always succeedes?

I envision that if we get multiple resets on same seqno, we
just write the breadcrumbs through cpu and move on. But let's
hope we don't need to and the gpu breadcrumps are always enough.

Regardless, it's improvement and should weed out false positives
on some hangs.

Reviewed-by: Mika Kuoppala 
-Mika

> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0cae8acdf906..a89a88922448 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2589,6 +2589,9 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   return;
>  
>   ring_hung = engine->hangcheck.score >= HANGCHECK_SCORE_RING_HUNG;
> + if (engine->hangcheck.seqno != intel_engine_get_seqno(engine))
> + ring_hung = false;
> +
>   i915_set_reset_status(request->ctx, ring_hung);
>   if (!ring_hung)
>   return;
> -- 
> 2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/8] drm/i915: Disable irqs across GPU reset

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> Whilst we reset the GPU, we want to prevent execlists from submitting
> new work (which it does via an interrupt handler). To achieve this we
> disable the irq (and drain the irq tasklet) around the reset. When we
> enable it again afters, the interrupt queue should be empty and we can
> reinitialise from a known state without fear of the tasklet running
> concurrently.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Restamping

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 19 +++
>  drivers/gpu/drm/i915/i915_gem.c |  2 --
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 31b2b6300d8d..7ce498898217 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1728,6 +1728,21 @@ int i915_resume_switcheroo(struct drm_device *dev)
>   return i915_drm_resume(dev);
>  }
>  
> +static void disable_engines_irq(struct drm_i915_private *dev_priv)
> +{
> + struct intel_engine_cs *engine;
> +
> + /* Ensure irq handler finishes, and not run again. */
> + disable_irq(dev_priv->drm.irq);
> + for_each_engine(engine, dev_priv)
> + tasklet_kill(>irq_tasklet);
> +}
> +
> +static void enable_engines_irq(struct drm_i915_private *dev_priv)
> +{
> + enable_irq(dev_priv->drm.irq);
> +}
> +
>  /**
>   * i915_reset - reset chip after a hang
>   * @dev: drm device to reset
> @@ -1761,7 +1776,11 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   error->reset_count++;
>  
>   pr_notice("drm/i915: Resetting chip after gpu hang\n");
> +
> + disable_engines_irq(dev_priv);
>   ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
> + enable_engines_irq(dev_priv);
> +
>   if (ret) {
>   if (ret != -ENODEV)
>   DRM_ERROR("Failed to reset chip: %i\n", ret);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1418c1c522cb..0cae8acdf906 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2581,8 +2581,6 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   struct i915_gem_context *incomplete_ctx;
>   bool ring_hung;
>  
> - /* Ensure irq handler finishes, and not run again. */
> - tasklet_kill(>irq_tasklet);
>   if (engine->irq_seqno_barrier)
>   engine->irq_seqno_barrier(engine);
>  
> -- 
> 2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/8] drm/i915/execlists: Move clearing submission count from reset to init

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> After a GPU reset, we want to replay our queue of requests. However, the
> GPU reset clobbered the state and we only fixup the state for the
> guitly

s/guitly/guilty.

Reviewed-by: Mika Kuoppala 

> request - and engines deemed innocent we try to leave untouched so that
> we recover as completely as possible. However, we need to clear the sw
> tracking of the ELSP ports even for innocent requests, so move the clear
> to the common path of init_hw (from reset_hw).
>
> Reported-by: Mika Kuoppala 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0ea992ba2723..936f6f63f626 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1242,8 +1242,12 @@ static int gen8_init_common_ring(struct 
> intel_engine_cs *engine)
>  
>   intel_engine_init_hangcheck(engine);
>  
> - if (!execlists_elsp_idle(engine))
> + /* After a GPU reset, we may have requests to replay */
> + if (!execlists_elsp_idle(engine)) {
> + engine->execlist_port[0].count = 0;
> + engine->execlist_port[1].count = 0;
>   execlists_submit_ports(engine);
> + }
>  
>   return 0;
>  }
> @@ -1318,10 +1322,7 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   memset([1], 0, sizeof(port[1]));
>   }
>  
> - /* CS is stopped, and we will resubmit both ports on resume */
>   GEM_BUG_ON(request->ctx != port[0].request->ctx);
> - port[0].count = 0;
> - port[1].count = 0;
>  
>   /* Reset WaIdleLiteRestore:bdw,skl as well */
>   request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
> -- 
> 2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

2016-10-03 Thread Petri Latvala
Add myself, remove Daniel by request.

Signed-off-by: Petri Latvala 
---

For the record.

Daniel requested to be removed from the list (Daniel, please confirm,
that's how I understood), and I'm going to be maintaining IGT with
Marius until Marius steps down.

MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 58f9efb..bf3e530 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,2 +1,2 @@
-Daniel Vetter 
 Marius Vlad 
+Petri Latvala 
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH 1/8] drm/i915: Share the computation of ring size for RING_CTL register

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> Since both legacy and execlists want to poopulate the RING_CTL
> register,

A bit too graphic, lets switch to populate.

Reviewed-by: Mika Kuoppala 

> share the computation of the right bits for the ring->size. We can then
> stop masking errors and explicitly forbid them during creation!
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  drivers/gpu/drm/i915/intel_lrc.c| 2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 5 ++---
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8d44cee710f0..acc767a52d8e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1605,6 +1605,7 @@ enum skl_disp_power_wells {
>  #define RING_HEAD(base)  _MMIO((base)+0x34)
>  #define RING_START(base) _MMIO((base)+0x38)
>  #define RING_CTL(base)   _MMIO((base)+0x3c)
> +#define   RING_CTL_SIZE(size)((size) - PAGE_SIZE) /* in bytes -> 
> pages */
>  #define RING_SYNC_0(base)_MMIO((base)+0x40)
>  #define RING_SYNC_1(base)_MMIO((base)+0x44)
>  #define RING_SYNC_2(base)_MMIO((base)+0x48)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 2d8eb2eb2b72..5ede272eb4d2 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1946,7 +1946,7 @@ populate_lr_context(struct i915_gem_context *ctx,
>  RING_START(engine->mmio_base), 0);
>   ASSIGN_CTX_REG(reg_state, CTX_RING_BUFFER_CONTROL,
>  RING_CTL(engine->mmio_base),
> -((ring->size - PAGE_SIZE) & RING_NR_PAGES) | RING_VALID);
> +RING_CTL_SIZE(ring->size) | RING_VALID);
>   ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_U,
>  RING_BBADDR_UDW(engine->mmio_base), 0);
>   ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_L,
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 67ea9dd5921e..26aa4c5e268f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -585,9 +585,7 @@ static int init_ring_common(struct intel_engine_cs 
> *engine)
>   I915_WRITE_TAIL(engine, ring->tail);
>   (void)I915_READ_TAIL(engine);
>  
> - I915_WRITE_CTL(engine,
> - ((ring->size - PAGE_SIZE) & RING_NR_PAGES)
> - | RING_VALID);
> + I915_WRITE_CTL(engine, RING_CTL_SIZE(ring->size) | RING_VALID);
>  
>   /* If the head is still not zero, the ring is dead */
>   if (intel_wait_for_register_fw(dev_priv, RING_CTL(engine->mmio_base),
> @@ -1951,6 +1949,7 @@ intel_engine_create_ring(struct intel_engine_cs 
> *engine, int size)
>   struct i915_vma *vma;
>  
>   GEM_BUG_ON(!is_power_of_2(size));
> + GEM_BUG_ON(size & ~RING_NR_PAGES);
>  
>   ring = kzalloc(sizeof(*ring), GFP_KERNEL);
>   if (!ring)
> -- 
> 2.9.3
>
> ___
> 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 1/8] drm/i915: Share the computation of ring size for RING_CTL register

2016-10-03 Thread Chris Wilson
On Mon, Oct 03, 2016 at 01:52:39PM +0100, Chris Wilson wrote:
> Since both legacy and execlists want to poopulate the RING_CTL register,
> share the computation of the right bits for the ring->size. We can then
> stop masking errors and explicitly forbid them during creation!
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  drivers/gpu/drm/i915/intel_lrc.c| 2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 5 ++---
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8d44cee710f0..acc767a52d8e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1605,6 +1605,7 @@ enum skl_disp_power_wells {
>  #define RING_HEAD(base)  _MMIO((base)+0x34)
>  #define RING_START(base) _MMIO((base)+0x38)
>  #define RING_CTL(base)   _MMIO((base)+0x3c)
> +#define   RING_CTL_SIZE(size)((size) - PAGE_SIZE) /* in bytes -> 
> pages */
>  #define RING_SYNC_0(base)_MMIO((base)+0x40)
>  #define RING_SYNC_1(base)_MMIO((base)+0x44)
>  #define RING_SYNC_2(base)_MMIO((base)+0x48)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 2d8eb2eb2b72..5ede272eb4d2 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1946,7 +1946,7 @@ populate_lr_context(struct i915_gem_context *ctx,
>  RING_START(engine->mmio_base), 0);
>   ASSIGN_CTX_REG(reg_state, CTX_RING_BUFFER_CONTROL,
>  RING_CTL(engine->mmio_base),
> -((ring->size - PAGE_SIZE) & RING_NR_PAGES) | RING_VALID);
> +RING_CTL_SIZE(ring->size) | RING_VALID);
>   ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_U,
>  RING_BBADDR_UDW(engine->mmio_base), 0);
>   ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_L,
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 67ea9dd5921e..26aa4c5e268f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -585,9 +585,7 @@ static int init_ring_common(struct intel_engine_cs 
> *engine)
>   I915_WRITE_TAIL(engine, ring->tail);
>   (void)I915_READ_TAIL(engine);
>  
> - I915_WRITE_CTL(engine,
> - ((ring->size - PAGE_SIZE) & RING_NR_PAGES)
> - | RING_VALID);
> + I915_WRITE_CTL(engine, RING_CTL_SIZE(ring->size) | RING_VALID);
>  
>   /* If the head is still not zero, the ring is dead */
>   if (intel_wait_for_register_fw(dev_priv, RING_CTL(engine->mmio_base),
> @@ -1951,6 +1949,7 @@ intel_engine_create_ring(struct intel_engine_cs 
> *engine, int size)
>   struct i915_vma *vma;
>  
>   GEM_BUG_ON(!is_power_of_2(size));
> + GEM_BUG_ON(size & ~RING_NR_PAGES);

(size - PAGE_SIZE) & ~RING_NR_PAGES
-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 v2 13/22] drm/i915: Update reset path to fix incomplete requests

2016-10-03 Thread Chris Wilson
On Mon, Oct 03, 2016 at 01:44:14PM +0100, Tvrtko Ursulin wrote:
> >+static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
> 
> I am aware this is a late comment, but wanted to say that the name
> above is not ideal since we have both i915_gem_cleanup_engines and
> dev_priv->gt.cleanup_engine which do completely different type of
> thing than this.

A long time ago we were heading to a world where
dev_priv->gt.cleanup_engines was replaced by a vfunc within the engine
itself. Not a good excuse, but one day the naming will resolve itself.
-Chris

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


[Intel-gfx] [PATCH 2/8] drm/i915/execlists: Reinitialise context image after GPU hang

2016-10-03 Thread Chris Wilson
On Braswell, at least, we observe that the context image is written in
multiple phases. The first phase is to clear the register state, and
subsequently rewrite it. A GPU reset at the right moment can interrupt
the context update leaving it corrupt, and our update of the RING_HEAD
is not sufficient to restart the engine afterwards. To recover, we need
to reset the registers back to their original values. The context state
is lost. What we need is a better mechanism to serialise the reset with
pending flushes from the GPU.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 103 +++
 1 file changed, 62 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5ede272eb4d2..0ea992ba2723 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -226,10 +226,16 @@ enum {
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 
+#define WA_TAIL_DWORDS 2
+
 static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine);
 static int intel_lr_context_pin(struct i915_gem_context *ctx,
struct intel_engine_cs *engine);
+static void execlists_init_reg_state(u32 *reg_state,
+struct i915_gem_context *ctx,
+struct intel_engine_cs *engine,
+struct intel_ring *ring);
 
 /**
  * intel_sanitize_enable_execlists() - sanitize i915.enable_execlists
@@ -707,7 +713,6 @@ static int intel_lr_context_pin(struct i915_gem_context 
*ctx,
 {
struct intel_context *ce = >engine[engine->id];
void *vaddr;
-   u32 *lrc_reg_state;
int ret;
 
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -726,17 +731,16 @@ static int intel_lr_context_pin(struct i915_gem_context 
*ctx,
goto unpin_vma;
}
 
-   lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
-
ret = intel_ring_pin(ce->ring);
if (ret)
goto unpin_map;
 
intel_lr_context_descriptor_update(ctx, engine);
 
-   lrc_reg_state[CTX_RING_BUFFER_START+1] =
+   ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
+   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state = lrc_reg_state;
+
ce->state->obj->dirty = true;
 
/* Invalidate GuC TLB. */
@@ -1284,8 +1288,21 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
struct execlist_port *port = engine->execlist_port;
struct intel_context *ce = >ctx->engine[engine->id];
 
+   /* We want a simple context + ring to execute the breadcrumb update.
+* We cannot rely on the context being intact across the GPU hang,
+* so clear it and rebuild just what we need for the breadcrumb.
+* All pending requests for this context will be zapped, and any
+* future request will be after userspace has had the opportunity
+* to recreate its own state.
+*/
+   execlists_init_reg_state(ce->lrc_reg_state,
+request->ctx, engine, ce->ring);
+
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
+   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
+   i915_ggtt_offset(ce->ring->vma);
ce->lrc_reg_state[CTX_RING_HEAD+1] = request->postfix;
+
request->ring->head = request->postfix;
request->ring->last_retired_head = -1;
intel_ring_update_space(request->ring);
@@ -1305,6 +1322,9 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_BUG_ON(request->ctx != port[0].request->ctx);
port[0].count = 0;
port[1].count = 0;
+
+   /* Reset WaIdleLiteRestore:bdw,skl as well */
+   request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
 }
 
 static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
@@ -1542,7 +1562,6 @@ static void bxt_a_seqno_barrier(struct intel_engine_cs 
*engine)
  * used as a workaround for not being allowed to do lite
  * restore with HEAD==TAIL (WaIdleLiteRestore).
  */
-#define WA_TAIL_DWORDS 2
 
 static int gen8_emit_request(struct drm_i915_gem_request *request)
 {
@@ -1889,38 +1908,13 @@ static u32 intel_lr_indirect_ctx_offset(struct 
intel_engine_cs *engine)
return indirect_ctx_offset;
 }
 
-static int
-populate_lr_context(struct i915_gem_context *ctx,
-   struct drm_i915_gem_object *ctx_obj,
-   struct intel_engine_cs *engine,
-   struct 

[Intel-gfx] [PATCH 7/8] drm/i915: Show RING registers through debugfs

2016-10-03 Thread Chris Wilson
Knowing where the RINGs are pointing is extremely useful in diagnosing
if the engines are executing the ringbuffers you expect - and igt may be
suppressing the usual method of looking in the GPU error state.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 230 +++-
 drivers/gpu/drm/i915/intel_engine_cs.c  |  30 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  16 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
 4 files changed, 170 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4fb9d829884e..9c95ce73f2aa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -635,6 +635,23 @@ static int i915_gem_batch_pool_info(struct seq_file *m, 
void *data)
return 0;
 }
 
+static void print_request(struct seq_file *m,
+ struct drm_i915_gem_request *rq,
+ const char *prefix)
+{
+   struct pid *pid = rq->ctx->pid;
+   struct task_struct *task;
+
+   rcu_read_lock();
+   task = pid ? pid_task(pid, PIDTYPE_PID) : NULL;
+   seq_printf(m, "%s%x [%x:%x] @ %d: %s [%d]\n", prefix,
+  rq->fence.seqno, rq->ctx->hw_id, rq->fence.seqno,
+  jiffies_to_msecs(jiffies - rq->emitted_jiffies),
+  task ? task->comm : "",
+  task ? task->pid : -1);
+   rcu_read_unlock();
+}
+
 static int i915_gem_request_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -658,19 +675,8 @@ static int i915_gem_request_info(struct seq_file *m, void 
*data)
continue;
 
seq_printf(m, "%s requests: %d\n", engine->name, count);
-   list_for_each_entry(req, >request_list, link) {
-   struct pid *pid = req->ctx->pid;
-   struct task_struct *task;
-
-   rcu_read_lock();
-   task = pid ? pid_task(pid, PIDTYPE_PID) : NULL;
-   seq_printf(m, "%x @ %d: %s [%d]\n",
-  req->fence.seqno,
-  (int) (jiffies - req->emitted_jiffies),
-  task ? task->comm : "",
-  task ? task->pid : -1);
-   rcu_read_unlock();
-   }
+   list_for_each_entry(req, >request_list, link)
+   print_request(m, req, "");
 
any++;
}
@@ -2036,84 +2042,6 @@ static int i915_dump_lrc(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int i915_execlists(struct seq_file *m, void *data)
-{
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
-   struct intel_engine_cs *engine;
-   u32 status_pointer;
-   u8 read_pointer;
-   u8 write_pointer;
-   u32 status;
-   u32 ctx_id;
-   struct list_head *cursor;
-   int i, ret;
-
-   if (!i915.enable_execlists) {
-   seq_puts(m, "Logical Ring Contexts are disabled\n");
-   return 0;
-   }
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   intel_runtime_pm_get(dev_priv);
-
-   for_each_engine(engine, dev_priv) {
-   struct drm_i915_gem_request *head_req = NULL;
-   int count = 0;
-
-   seq_printf(m, "%s\n", engine->name);
-
-   status = I915_READ(RING_EXECLIST_STATUS_LO(engine));
-   ctx_id = I915_READ(RING_EXECLIST_STATUS_HI(engine));
-   seq_printf(m, "\tExeclist status: 0x%08X, context: %u\n",
-  status, ctx_id);
-
-   status_pointer = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
-   seq_printf(m, "\tStatus pointer: 0x%08X\n", status_pointer);
-
-   read_pointer = GEN8_CSB_READ_PTR(status_pointer);
-   write_pointer = GEN8_CSB_WRITE_PTR(status_pointer);
-   if (read_pointer > write_pointer)
-   write_pointer += GEN8_CSB_ENTRIES;
-   seq_printf(m, "\tRead pointer: 0x%08X, write pointer 0x%08X\n",
-  read_pointer, write_pointer);
-
-   for (i = 0; i < GEN8_CSB_ENTRIES; i++) {
-   status = I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, 
i));
-   ctx_id = I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, 
i));
-
-   seq_printf(m, "\tStatus buffer %d: 0x%08X, context: 
%u\n",
-  i, status, ctx_id);
-   }
-
-   spin_lock_bh(>execlist_lock);
-   list_for_each(cursor, >execlist_queue)
-   count++;
-   

[Intel-gfx] [PATCH 8/8] drm/i915: Show waiters in i915_hangcheck_info

2016-10-03 Thread Chris Wilson
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c95ce73f2aa..39b76c24c84f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1343,6 +1343,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Hangcheck inactive\n");
 
for_each_engine_id(engine, dev_priv, id) {
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   struct rb_node *rb;
+
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
   engine->hangcheck.seqno,
@@ -1352,6 +1355,15 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
   yesno(intel_engine_has_waiter(engine)),
   yesno(test_bit(engine->id,
  
_priv->gpu_error.missed_irq_rings)));
+   spin_lock(>lock);
+   for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
+   struct intel_wait *w = container_of(rb, typeof(*w), 
node);
+
+   seq_printf(m, "\t%s [%d] waiting for %x\n",
+  w->tsk->comm, w->tsk->pid, w->seqno);
+   }
+   spin_unlock(>lock);
+
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
   (long long)engine->hangcheck.acthd,
   (long long)acthd[id]);
-- 
2.9.3

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


[Intel-gfx] [PATCH 4/8] drm/i915: Disable irqs across GPU reset

2016-10-03 Thread Chris Wilson
Whilst we reset the GPU, we want to prevent execlists from submitting
new work (which it does via an interrupt handler). To achieve this we
disable the irq (and drain the irq tasklet) around the reset. When we
enable it again afters, the interrupt queue should be empty and we can
reinitialise from a known state without fear of the tasklet running
concurrently.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.c | 19 +++
 drivers/gpu/drm/i915/i915_gem.c |  2 --
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 31b2b6300d8d..7ce498898217 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1728,6 +1728,21 @@ int i915_resume_switcheroo(struct drm_device *dev)
return i915_drm_resume(dev);
 }
 
+static void disable_engines_irq(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   /* Ensure irq handler finishes, and not run again. */
+   disable_irq(dev_priv->drm.irq);
+   for_each_engine(engine, dev_priv)
+   tasklet_kill(>irq_tasklet);
+}
+
+static void enable_engines_irq(struct drm_i915_private *dev_priv)
+{
+   enable_irq(dev_priv->drm.irq);
+}
+
 /**
  * i915_reset - reset chip after a hang
  * @dev: drm device to reset
@@ -1761,7 +1776,11 @@ void i915_reset(struct drm_i915_private *dev_priv)
error->reset_count++;
 
pr_notice("drm/i915: Resetting chip after gpu hang\n");
+
+   disable_engines_irq(dev_priv);
ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
+   enable_engines_irq(dev_priv);
+
if (ret) {
if (ret != -ENODEV)
DRM_ERROR("Failed to reset chip: %i\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1418c1c522cb..0cae8acdf906 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2581,8 +2581,6 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
struct i915_gem_context *incomplete_ctx;
bool ring_hung;
 
-   /* Ensure irq handler finishes, and not run again. */
-   tasklet_kill(>irq_tasklet);
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 3/8] drm/i915/execlists: Move clearing submission count from reset to init

2016-10-03 Thread Chris Wilson
After a GPU reset, we want to replay our queue of requests. However, the
GPU reset clobbered the state and we only fixup the state for the guitly
request - and engines deemed innocent we try to leave untouched so that
we recover as completely as possible. However, we need to clear the sw
tracking of the ELSP ports even for innocent requests, so move the clear
to the common path of init_hw (from reset_hw).

Reported-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0ea992ba2723..936f6f63f626 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1242,8 +1242,12 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)
 
intel_engine_init_hangcheck(engine);
 
-   if (!execlists_elsp_idle(engine))
+   /* After a GPU reset, we may have requests to replay */
+   if (!execlists_elsp_idle(engine)) {
+   engine->execlist_port[0].count = 0;
+   engine->execlist_port[1].count = 0;
execlists_submit_ports(engine);
+   }
 
return 0;
 }
@@ -1318,10 +1322,7 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
memset([1], 0, sizeof(port[1]));
}
 
-   /* CS is stopped, and we will resubmit both ports on resume */
GEM_BUG_ON(request->ctx != port[0].request->ctx);
-   port[0].count = 0;
-   port[1].count = 0;
 
/* Reset WaIdleLiteRestore:bdw,skl as well */
request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
-- 
2.9.3

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


[Intel-gfx] [PATCH 1/8] drm/i915: Share the computation of ring size for RING_CTL register

2016-10-03 Thread Chris Wilson
Since both legacy and execlists want to poopulate the RING_CTL register,
share the computation of the right bits for the ring->size. We can then
stop masking errors and explicitly forbid them during creation!

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_lrc.c| 2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 5 ++---
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8d44cee710f0..acc767a52d8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1605,6 +1605,7 @@ enum skl_disp_power_wells {
 #define RING_HEAD(base)_MMIO((base)+0x34)
 #define RING_START(base)   _MMIO((base)+0x38)
 #define RING_CTL(base) _MMIO((base)+0x3c)
+#define   RING_CTL_SIZE(size)  ((size) - PAGE_SIZE) /* in bytes -> pages */
 #define RING_SYNC_0(base)  _MMIO((base)+0x40)
 #define RING_SYNC_1(base)  _MMIO((base)+0x44)
 #define RING_SYNC_2(base)  _MMIO((base)+0x48)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2d8eb2eb2b72..5ede272eb4d2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1946,7 +1946,7 @@ populate_lr_context(struct i915_gem_context *ctx,
   RING_START(engine->mmio_base), 0);
ASSIGN_CTX_REG(reg_state, CTX_RING_BUFFER_CONTROL,
   RING_CTL(engine->mmio_base),
-  ((ring->size - PAGE_SIZE) & RING_NR_PAGES) | RING_VALID);
+  RING_CTL_SIZE(ring->size) | RING_VALID);
ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_U,
   RING_BBADDR_UDW(engine->mmio_base), 0);
ASSIGN_CTX_REG(reg_state, CTX_BB_HEAD_L,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 67ea9dd5921e..26aa4c5e268f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -585,9 +585,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
I915_WRITE_TAIL(engine, ring->tail);
(void)I915_READ_TAIL(engine);
 
-   I915_WRITE_CTL(engine,
-   ((ring->size - PAGE_SIZE) & RING_NR_PAGES)
-   | RING_VALID);
+   I915_WRITE_CTL(engine, RING_CTL_SIZE(ring->size) | RING_VALID);
 
/* If the head is still not zero, the ring is dead */
if (intel_wait_for_register_fw(dev_priv, RING_CTL(engine->mmio_base),
@@ -1951,6 +1949,7 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
struct i915_vma *vma;
 
GEM_BUG_ON(!is_power_of_2(size));
+   GEM_BUG_ON(size & ~RING_NR_PAGES);
 
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
-- 
2.9.3

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


[Intel-gfx] [PATCH 6/8] drm/i915: Show bounds of active request in the ring on GPU hang

2016-10-03 Thread Chris Wilson
Include the position of the active request in the ring, and display that
alongside the current RING registers (on a GPU hang).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h   | 3 +++
 drivers/gpu/drm/i915/i915_gpu_error.c | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 91ac283d733e..e48044b3a447 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -776,6 +776,9 @@ struct drm_i915_error_state {
struct i915_address_space *vm;
int num_requests;
 
+   /* position of active request inside the ring */
+   u32 rq_head, rq_post, rq_tail;
+
/* our own tracking of ring head and tail */
u32 cpu_ring_head;
u32 cpu_ring_tail;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2bbab226a46c..8b85efbdfa04 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -262,8 +262,9 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
 {
err_printf(m, "%s command stream:\n", engine_str(ee->engine_id));
err_printf(m, "  START: 0x%08x\n", ee->start);
-   err_printf(m, "  HEAD:  0x%08x\n", ee->head);
-   err_printf(m, "  TAIL:  0x%08x\n", ee->tail);
+   err_printf(m, "  HEAD:  0x%08x\n [0x%08x]", ee->head, ee->rq_head);
+   err_printf(m, "  TAIL:  0x%08x [0x%08x, 0x%08x]\n",
+  ee->tail, ee->rq_post, ee->rq_tail);
err_printf(m, "  CTL:   0x%08x\n", ee->ctl);
err_printf(m, "  MODE:  0x%08x\n", ee->mode);
err_printf(m, "  HWS:   0x%08x\n", ee->hws);
@@ -1230,6 +1231,10 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
error->simulated |=
request->ctx->flags & CONTEXT_NO_ERROR_CAPTURE;
 
+   ee->rq_head = request->head;
+   ee->rq_post = request->postfix;
+   ee->rq_tail = request->tail;
+
ring = request->ring;
ee->cpu_ring_head = ring->head;
ee->cpu_ring_tail = ring->tail;
-- 
2.9.3

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


[Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

2016-10-03 Thread Chris Wilson
Check that there was not a late recovery between us declaring the GPU
hung and processing the reset. If the GPU did recover by itself, let the
request remain on the active list and see if it hangs again!

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0cae8acdf906..a89a88922448 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2589,6 +2589,9 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
return;
 
ring_hung = engine->hangcheck.score >= HANGCHECK_SCORE_RING_HUNG;
+   if (engine->hangcheck.seqno != intel_engine_get_seqno(engine))
+   ring_hung = false;
+
i915_set_reset_status(request->ctx, ring_hung);
if (!ring_hung)
return;
-- 
2.9.3

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


[Intel-gfx] [CI 1/3] drm/i915: Just clear the mmiodebug before a register access

2016-10-03 Thread Chris Wilson
When we enable the per-register access mmiodebug, it is to detect which
access is illegal. Reporting on earlier untraced access outside of the
mmiodebug does not help debugging (as the suspicion is immediately put
upon the current register which is not at fault)!

References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_uncore.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index a9b6c936aadd..ee2306a79747 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -796,10 +796,9 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
  const bool read,
  const bool before)
 {
-   if (WARN(check_for_unclaimed_mmio(dev_priv),
-"Unclaimed register detected %s %s register 0x%x\n",
-before ? "before" : "after",
-read ? "reading" : "writing to",
+   if (WARN(check_for_unclaimed_mmio(dev_priv) && !before,
+"Unclaimed %s register 0x%x\n",
+read ? "read from" : "write to",
 i915_mmio_reg_offset(reg)))
i915.mmio_debug--; /* Only report the first N failures */
 }
-- 
2.9.3

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


[Intel-gfx] [CI 3/3] drm/i915: Use correct index for backtracking HUNG semaphores

2016-10-03 Thread Chris Wilson
When decoding the semaphores inside hangcheck, we need to use the hw-id
and not the local array index.

Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...")
Testcase: igt/gem_exec_whisper/hang # gen6-7
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: sta...@vger.kernel.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_irq.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6ed5b240ee06..238a353454e9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2877,7 +2877,7 @@ semaphore_wait_to_signaller_ring(struct intel_engine_cs 
*engine, u32 ipehr,
if (engine == signaller)
continue;
 
-   if (offset == 
signaller->semaphore.signal_ggtt[engine->id])
+   if (offset == 
signaller->semaphore.signal_ggtt[engine->hw_id])
return signaller;
}
} else {
@@ -2887,13 +2887,13 @@ semaphore_wait_to_signaller_ring(struct intel_engine_cs 
*engine, u32 ipehr,
if(engine == signaller)
continue;
 
-   if (sync_bits == 
signaller->semaphore.mbox.wait[engine->id])
+   if (sync_bits == 
signaller->semaphore.mbox.wait[engine->hw_id])
return signaller;
}
}
 
-   DRM_DEBUG_DRIVER("No signaller ring found for ring %i, ipehr 0x%08x, 
offset 0x%016llx\n",
-engine->id, ipehr, offset);
+   DRM_DEBUG_DRIVER("No signaller ring found for %s, ipehr 0x%08x, offset 
0x%016llx\n",
+engine->name, ipehr, offset);
 
return ERR_PTR(-ENODEV);
 }
-- 
2.9.3

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


[Intel-gfx] [CI 2/3] drm/i915: Unalias obj->phys_handle and obj->userptr

2016-10-03 Thread Chris Wilson
We use obj->phys_handle to choose the pread/pwrite path, but as
obj->phys_handle is a union with obj->userptr, we then mistakenly use
the phys_handle path for userptr objects within pread/pwrite.

Testcase: igt/gem_userptr_blits/forbidden-operations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
Signed-off-by: Chris Wilson 
Cc: sta...@vger.kernel.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0cb71c9c52e..91ac283d733e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2282,21 +2282,19 @@ struct drm_i915_gem_object {
/** Record of address bit 17 of each page at last unbind. */
unsigned long *bit_17;
 
-   union {
-   /** for phy allocated objects */
-   struct drm_dma_handle *phys_handle;
-
-   struct i915_gem_userptr {
-   uintptr_t ptr;
-   unsigned read_only :1;
-   unsigned workers :4;
+   struct i915_gem_userptr {
+   uintptr_t ptr;
+   unsigned read_only :1;
+   unsigned workers :4;
 #define I915_GEM_USERPTR_MAX_WORKERS 15
 
-   struct i915_mm_struct *mm;
-   struct i915_mmu_object *mmu_object;
-   struct work_struct *work;
-   } userptr;
-   };
+   struct i915_mm_struct *mm;
+   struct i915_mmu_object *mmu_object;
+   struct work_struct *work;
+   } userptr;
+
+   /** for phys allocated objects */
+   struct drm_dma_handle *phys_handle;
 };
 
 static inline struct drm_i915_gem_object *
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests

2016-10-03 Thread Tvrtko Ursulin


On 07/09/2016 15:45, Chris Wilson wrote:

Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.

The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This allows us to resume from where we left-off.
Since this request didn't complete normally we also need to cleanup elsp
queue manually. This is vital if we employ nonblocking request
submission where we may have a web of dependencies upon the hung request
and so advancing the seqno manually is no longer trivial.

ABI: gem_reset_stats / DRM_IOCTL_I915_GET_RESET_STATS

We change the way we count pending batches. Only the active context
involved in the reset is marked as either innocent or guilty, and not
mark the entire world as pending. By inspection this only affects
igt/gem_reset_stats (which assumes implementation details) and not
piglit.

ARB_robustness gives this guide on how we expect the user of this
interface to behave:

  * Provide a mechanism for an OpenGL application to learn about
graphics resets that affect the context.  When a graphics reset
occurs, the OpenGL context becomes unusable and the application
must create a new context to continue operation. Detecting a
graphics reset happens through an inexpensive query.

And with regards to the actual meaning of the reset values:

Certain events can result in a reset of the GL context. Such a reset
causes all context state to be lost. Recovery from such events
requires recreation of all objects in the affected context. The
current status of the graphics reset state is returned by

enum GetGraphicsResetStatusARB();

The symbolic constant returned indicates if the GL context has been
in a reset state at any point since the last call to
GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context
has not been in a reset state since the last call.
GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected
that is attributable to the current GL context.
INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that
is not attributable to the current GL context.
UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose
cause is unknown.

The language here is explicit in that we must mark up the guilty batch,
but is loose enough for us to relax the innocent (i.e. pending)
accounting as only the active batches are involved with the reset.

In the future, we are looking towards single engine resetting (with
minimal locking), where it seems inappropriate to mark the entire world
as innocent since the reset occurred on a different engine. Reducing the
information available means we only have to encounter the pain once, and
also reduces the information leaking from one context to another.

v2: Legacy ringbuffer submission required a reset following hibernation,
or else we restore stale values to the RING_HEAD and walked over
stolen garbage.

v3: GuC requires replaying the requests after a reset.

v4: Restore engine IRQ after reset (so waiters will be woken!)
 Rearm hangcheck if resetting with a waiter.

Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Arun Siluvery 
Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.c|   8 +-
  drivers/gpu/drm/i915/i915_drv.h|   5 +-
  drivers/gpu/drm/i915/i915_gem.c| 123 +
  drivers/gpu/drm/i915/i915_gem_context.c|  16 
  drivers/gpu/drm/i915/i915_guc_submission.c |   8 +-
  drivers/gpu/drm/i915/intel_engine_cs.c |  15 +++-
  drivers/gpu/drm/i915/intel_lrc.c   |  49 ++--
  drivers/gpu/drm/i915/intel_lrc.h   |   3 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c|  47 +++
  drivers/gpu/drm/i915/intel_ringbuffer.h|   7 +-
  10 files changed, 183 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c1b890dbd6cc..2b0727d1467d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -559,7 +559,6 @@ static void i915_gem_fini(struct drm_device *dev)
}
  
  	mutex_lock(>struct_mutex);

-   i915_gem_reset(dev);
i915_gem_cleanup_engines(dev);
i915_gem_context_fini(dev);
mutex_unlock(>struct_mutex);
@@ -1579,7 +1578,7 @@ static int i915_drm_resume(struct drm_device *dev)
mutex_lock(>struct_mutex);
if (i915_gem_init_hw(dev)) {
DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
-   set_bit(I915_WEDGED, _priv->gpu_error.flags);
+   i915_gem_set_wedged(dev_priv);
}
mutex_unlock(>struct_mutex);
  
@@ -1756,8 +1755,6 @@ int i915_reset(struct drm_i915_private 

Re: [Intel-gfx] [PATCH] drm/i915: Disable irqs across GPU reset

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> Whilst we reset the GPU, we want to prevent execlists from submitting
> new work (which it does via an interrupt handler). To achieve this we
> disable the irq (and drain the irq tasklet) around the reset. When we
> enable it again afters, the interrupt queue should be empty and we can
> reinitialise from a known state without fear of the tasklet running
> concurrently.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 19 +++
>  drivers/gpu/drm/i915/i915_gem.c |  2 --
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 31b2b6300d8d..7ce498898217 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1728,6 +1728,21 @@ int i915_resume_switcheroo(struct drm_device *dev)
>   return i915_drm_resume(dev);
>  }
>  
> +static void disable_engines_irq(struct drm_i915_private *dev_priv)
> +{
> + struct intel_engine_cs *engine;
> +
> + /* Ensure irq handler finishes, and not run again. */
> + disable_irq(dev_priv->drm.irq);
> + for_each_engine(engine, dev_priv)
> + tasklet_kill(>irq_tasklet);
> +}
> +
> +static void enable_engines_irq(struct drm_i915_private *dev_priv)
> +{
> + enable_irq(dev_priv->drm.irq);
> +}
> +
>  /**
>   * i915_reset - reset chip after a hang
>   * @dev: drm device to reset
> @@ -1761,7 +1776,11 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   error->reset_count++;
>  
>   pr_notice("drm/i915: Resetting chip after gpu hang\n");
> +
> + disable_engines_irq(dev_priv);
>   ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
> + enable_engines_irq(dev_priv);
> +
>   if (ret) {
>   if (ret != -ENODEV)
>   DRM_ERROR("Failed to reset chip: %i\n", ret);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1418c1c522cb..0cae8acdf906 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2581,8 +2581,6 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   struct i915_gem_context *incomplete_ctx;
>   bool ring_hung;
>  
> - /* Ensure irq handler finishes, and not run again. */
> - tasklet_kill(>irq_tasklet);
>   if (engine->irq_seqno_barrier)
>   engine->irq_seqno_barrier(engine);
>  
> -- 
> 2.9.3
>
> ___
> 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 1/3] drm/i915/execlists: Reinitialise context image after GPU hang

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> On Braswell, at least, we observe that the context image is written in
> multiple phases. The first phase is to clear the register state, and
> subsequently rewrite it. A GPU reset at the right moment can interrupt
> the context update leaving it corrupt, and our update of the RING_HEAD
> is not sufficient to restart the engine afterwards. To recover, we need
> to reset the registers back to their original values. The context state
> is lost. What we need is a better mechanism to serialise the reset with
> pending flushes from the GPU.
>
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 95 
> +++-
>  1 file changed, 56 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 2d8eb2eb2b72..d6e762718ff4 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -226,10 +226,16 @@ enum {
>  /* Typical size of the average request (2 pipecontrols and a MI_BB) */
>  #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
>  
> +#define WA_TAIL_DWORDS 2
> +
>  static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
>   struct intel_engine_cs *engine);
>  static int intel_lr_context_pin(struct i915_gem_context *ctx,
>   struct intel_engine_cs *engine);
> +static void execlists_init_reg_state(u32 *reg_state,
> +  struct i915_gem_context *ctx,
> +  struct intel_engine_cs *engine,
> +  struct intel_ring *ring);
>  
>  /**
>   * intel_sanitize_enable_execlists() - sanitize i915.enable_execlists
> @@ -707,7 +713,6 @@ static int intel_lr_context_pin(struct i915_gem_context 
> *ctx,
>  {
>   struct intel_context *ce = >engine[engine->id];
>   void *vaddr;
> - u32 *lrc_reg_state;
>   int ret;
>  
>   lockdep_assert_held(>i915->drm.struct_mutex);
> @@ -726,17 +731,16 @@ static int intel_lr_context_pin(struct i915_gem_context 
> *ctx,
>   goto unpin_vma;
>   }
>  
> - lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
> -
>   ret = intel_ring_pin(ce->ring);
>   if (ret)
>   goto unpin_map;
>  
>   intel_lr_context_descriptor_update(ctx, engine);
>  
> - lrc_reg_state[CTX_RING_BUFFER_START+1] =
> + ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
> + ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
>   i915_ggtt_offset(ce->ring->vma);
> - ce->lrc_reg_state = lrc_reg_state;
> +
>   ce->state->obj->dirty = true;
>  
>   /* Invalidate GuC TLB. */
> @@ -1284,8 +1288,14 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   struct execlist_port *port = engine->execlist_port;
>   struct intel_context *ce = >ctx->engine[engine->id];
>  
> + execlists_init_reg_state(ce->lrc_reg_state,
> +  request->ctx, engine, ce->ring);
> +
>   /* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
> + ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
> + i915_ggtt_offset(ce->ring->vma);
>   ce->lrc_reg_state[CTX_RING_HEAD+1] = request->postfix;
> +
>   request->ring->head = request->postfix;
>   request->ring->last_retired_head = -1;
>   intel_ring_update_space(request->ring);
> @@ -1305,6 +1315,9 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>   GEM_BUG_ON(request->ctx != port[0].request->ctx);
>   port[0].count = 0;
>   port[1].count = 0;
> +
> + /* Reset WaIdleLiteRestore:bdw,skl as well */
> + request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
>  }
>  
>  static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
> @@ -1542,7 +1555,6 @@ static void bxt_a_seqno_barrier(struct intel_engine_cs 
> *engine)
>   * used as a workaround for not being allowed to do lite
>   * restore with HEAD==TAIL (WaIdleLiteRestore).
>   */
> -#define WA_TAIL_DWORDS 2
>  
>  static int gen8_emit_request(struct drm_i915_gem_request *request)
>  {
> @@ -1889,38 +1901,13 @@ static u32 intel_lr_indirect_ctx_offset(struct 
> intel_engine_cs *engine)
>   return indirect_ctx_offset;
>  }
>  
> -static int
> -populate_lr_context(struct i915_gem_context *ctx,
> - struct drm_i915_gem_object *ctx_obj,
> - struct intel_engine_cs *engine,
> - struct intel_ring *ring)
> +static void execlists_init_reg_state(u32 *reg_state,
> +  struct i915_gem_context *ctx,
> +  struct intel_engine_cs *engine,
> +  struct intel_ring *ring)
>  {
> -   

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move long hpd handling into the hotplug work

2016-10-03 Thread Ander Conselvan De Oliveira
On Mon, 2016-10-03 at 10:55 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We can't rely on connector->status in the detect() hook if the long hpd
> was already handled by the dig_port_work as that won't update
> connector->status. Thus we have to defer the long hpd handling entirely
> until the hotplug work runs to avoid the double long hpd handling
> the "detect_done" flag is trying to prevent.

This is better indeed. But perhaps add a note here about the next patch, since
this one doesn't actually change the use of connector->status usage in detect().

For both patches:

Reviewed-by: Ander Conselvan de Oliveira 

> 
> Cc: Damien Cassou 
> Cc: freedesktop@gp.mailgun.org
> Cc: Arno 
> Cc: Shubhangi Shrivastava 
> Cc: Sivakumar Thulasimani 
> Cc: Ander Conselvan de Oliveira 
> Cc: sta...@vger.kernel.org
> Tested-by: Arno 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 48 --
> ---
>  1 file changed, 23 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9448d898d80b..96caa469e3a8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4827,36 +4827,34 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
>     port_name(intel_dig_port->port),
>     long_hpd ? "long" : "short");
>  
> + if (long_hpd) {
> + intel_dp->detect_done = false;
> + return IRQ_NONE;
> + }
> +
>   power_domain = intel_display_port_aux_power_domain(intel_encoder);
>   intel_display_power_get(dev_priv, power_domain);
>  
> - if (long_hpd) {
> - intel_dp_long_pulse(intel_dp->attached_connector);
> - if (intel_dp->is_mst)
> - ret = IRQ_HANDLED;
> - goto put_power;
> -
> - } else {
> - if (intel_dp->is_mst) {
> - if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> - /*
> -  * If we were in MST mode, and device is not
> -  * there, get out of MST mode
> -  */
> - 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 put_power;
> - }
> + if (intel_dp->is_mst) {
> + if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> + /*
> +  * If we were in MST mode, and device is not
> +  * there, get out of MST mode
> +  */
> + 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_dp->detect_done = false;
> + goto put_power;
>   }
> + }
>  
> - if (!intel_dp->is_mst) {
> - if (!intel_dp_short_pulse(intel_dp)) {
> - intel_dp_long_pulse(intel_dp-
> >attached_connector);
> - goto put_power;
> - }
> + if (!intel_dp->is_mst) {
> + if (!intel_dp_short_pulse(intel_dp)) {
> + intel_dp->detect_done = false;
> + goto put_power;
>   }
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 0/7] drm/i915: Add pipe scaler for Gen9 in atomic path

2016-10-03 Thread Ville Syrjälä
On Wed, Sep 21, 2016 at 07:47:37PM +0530, Maiti, Nabendu Bikash wrote:
> Hi,
> 
> 
> On 9/20/2016 1:55 PM, Ville Syrjälä wrote:
> > On Tue, Aug 30, 2016 at 10:30:54AM +0530, Nabendu Maiti wrote:
> >> Following patch series add pipe scaler functionality in atomic path.The 
> >> pipe
> >> scaler can be changed dynamically without modeset.Apart from default panel
> >> fitter supported scaling modes -CENTER/ASPECT/FULLSCREEN custom scaling 
> >> mode
> >> mode is added as there is no such restriction on GEn9 pipe scaler.
> >
> > Some quick observations:
> > - missing any interaction with drm core, so all generic fb size checks
> >   and whatnot will not work out, I think
> Pipe scaler is not dependent on fp I think. We have fb size checks are 
> done in plane check.

You need to explain how this all interacts with the legacy pipe/plane
size == mode hdisplay/vdisplay stuff.

> 
> > - the way it's done goes against what I've suggested in the past. My
> >   idea has been to add a "fixed mode" property to connectors instead,
> >   which I think would minimize the impact on the core, and it would
> >   follow closely the way eDP/LVDS/DSI already works today.
> yes using fixed mode we can do also but I wanted to be part of crtc 
> property instead of connector property. As fixed mode is basically 
> intended for fixed mode panels.But we may use pipe scaler for fixed mode 
> and dynamic mode panels.

That doesn't say much. The fixed mode apporach, I think, might be easier
to incorporate in a way that keeps the legacy apporach working. Adding a
totally different way to configure the pipe src size will mean more weird
interactions between the properties.

Also it culd be supported with non-atomic userspace reasonably easily.
We'll need some sort of userspace for this anyway, otherwise it's just
untested/unused code.

> 
> > - There's no need to restrict the feature to gen9+ only. It should work
> >   out just fine for at least all pch platforms. gmch platforms would be
> >   more challenging
> This code I designed to use gen9+, and properties like crtc destination 
> size and offsets also exposed.There is no restrictions on modes (eg. 
> pillerbox/letterbox) and down scaling ratios as previous platforms. 
> Currently scaling mode is part of connector property and implemented as 
> legacy property. I created new scaling mode as atomic property. I think 
> gen9+ onward platforms may have proper atomic pipe scaling properties 
> and user space may use it fully dynamically without modeset.

None of that tells me why it's gen9+ only. IIRC the panel fitter
configuration been very flexible ever since ILK, so the only real
difference should be which registers to write.

> 
> > - the pfiter_recalculate thing looks pretty wrong atomic wise
> Sorry, I couldn't get it. Are you referring pipe scaler registers are 
> not written together with other registers?  pfiter_calculate only 
> calculate and stores the data for later commit. Please provide more 
> details on it.

It's going through encoder->crtc links and whanot. That's not going
to fly.

> >
> >>
> >>
> >>
> >> Nabendu Maiti (7):
> >>   drm/i915: Add pipe scaler pipe source drm property
> >>   drm/i915: Add pipe_src size property calculations in atomic path.
> >>   drm/i915: Panel fitting calculation for GEN9
> >>   drm/i915: Adding atomic fitting mode property for GEN9
> >>   drm/i915: Add pipe scaler co-ordinate and size property for Gen9
> >>   drm/i915: Update pipe-scaler according to destination size
> >>   drm/i915: Pipescaler destination size limit check on Gen9
> >>
> >>  drivers/gpu/drm/drm_atomic.c |  35 ++
> >>  drivers/gpu/drm/drm_crtc.c   |  56 +++
> >>  drivers/gpu/drm/i915/intel_display.c | 128 
> >> +--
> >>  drivers/gpu/drm/i915/intel_drv.h |   3 +
> >>  drivers/gpu/drm/i915/intel_panel.c   |  34 +-
> >>  include/drm/drm_crtc.h   |  14 
> >>  include/uapi/drm/drm_mode.h  |   1 +
> >>  7 files changed, 263 insertions(+), 8 deletions(-)
> >>
> >> --
> >> 1.9.1
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> 
> -- 
> Regards,
> Nabendu

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

2016-10-03 Thread Jani Nikula
On Fri, 30 Sep 2016, Rodrigo Vivi  wrote:
> According to spec: "KBL re-uses SKL values, except where
> specific KBL values are listed."
>
> And recently spec has changed adding different table for Display Port only.
> But for all SKUs (H,S,U,Y) we have slightly different values.
>
> Cc: Manasi Navare 
> Cc: Arthur Runyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 88 
> +++-
>  1 file changed, 78 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 018964b..1573360 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -167,8 +167,47 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_dp[] = {
>   { 0x80005012, 0x00C0, 0x3 },
>  };
>  
> +/* Kabylake H and S */
> +static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
> + { 0x2016, 0x00A0, 0x0 },
> + { 0x5012, 0x009B, 0x0 },
> + { 0x7011, 0x0088, 0x0 },
> + { 0x80009010, 0x00C0, 0x1 },
> + { 0x2016, 0x009B, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00C0, 0x1 },
> + { 0x2016, 0x009F, 0x0 },
> + { 0x80005012, 0x00C0, 0x1 },
> +};
> +
> +/* Kabylake U */
> +static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
> + { 0x201B, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x80009010, 0x00C0, 0x3 },
> + { 0x201B, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x2016, 0x004F, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
> +/* Kabylake Y */
> +static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
> + { 0x1017, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x8000800F, 0x00C0, 0x3 },
> + { 0x1017, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x1017, 0x004C, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
>  /*
> - * Skylake H and S
> + * Skylake/Kabylake H and S
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> @@ -185,7 +224,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake U
> + * Skylake/Kabylake U
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
> @@ -202,7 +241,7 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake Y
> + * Skylake/Kabylake Y
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
> @@ -218,7 +257,7 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_edp[] = {
>   { 0x0018, 0x008A, 0x0 },
>  };
>  
> -/* Skylake U, H and S */
> +/* Skylake/Kabylake U, H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00AC, 0x0 },
>   { 0x5012, 0x009D, 0x0 },
> @@ -233,7 +272,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_hdmi[] = {
>   { 0x8018, 0x00C0, 0x1 },
>  };
>  
> -/* Skylake Y */
> +/* Skylake/Kabylake Y */
>  static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00A1, 0x0 },
>   { 0x5012, 0x00DF, 0x0 },
> @@ -334,10 +373,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private 
> *dev_priv, int *n_entries)
>  static const struct ddi_buf_trans *
>  skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> - if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
> + if (IS_SKL_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
>   return skl_y_ddi_translations_dp;
> - } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
> + } else if (IS_SKL_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
>   return skl_u_ddi_translations_dp;
>   } else {
> @@ -347,6 +386,21 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>  }
>  
>  static const struct ddi_buf_trans *
> +kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +{
> + if (IS_KBL_ULX(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
> + return kbl_y_ddi_translations_dp;
> + } else if (IS_KBL_ULT(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
> + return 

Re: [Intel-gfx] [PATCH] drm/i915: Just clear the mmiodebug before a register access

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> When we enable the per-register access mmiodebug, it is to detect which
> access is illegal. Reporting on earlier untraced access outside of the
> mmiodebug does not help debugging (as the suspicion is immediately put
> upon the current register which is not at fault)!
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index a9b6c936aadd..ee2306a79747 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -796,10 +796,9 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
> const bool read,
> const bool before)
>  {
> - if (WARN(check_for_unclaimed_mmio(dev_priv),
> -  "Unclaimed register detected %s %s register 0x%x\n",
> -  before ? "before" : "after",
> -  read ? "reading" : "writing to",
> + if (WARN(check_for_unclaimed_mmio(dev_priv) && !before,
> +  "Unclaimed %s register 0x%x\n",
> +  read ? "read from" : "write to",
>i915_mmio_reg_offset(reg)))
>   i915.mmio_debug--; /* Only report the first N failures */
>  }
> -- 
> 2.9.3
>
> ___
> 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: Just clear the mmiodebug before a register access

2016-10-03 Thread Chris Wilson
On Mon, Oct 03, 2016 at 01:09:31PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > When we enable the per-register access mmiodebug, it is to detect which
> > access is illegal. Reporting on earlier untraced access outside of the
> > mmiodebug does not help debugging (as the suspicion is immediately put
> > upon the current register which is not at fault)!
> >
> 
> I think the original intent here was that if the unclaimed access was
> before driver register access, it would be sometimes possible to assess
> the real culprit by understanding what happened before this moment.

We have warnings elsewhere to catch this, and since we provide no debug
output in these cases flagging an error to the user is just noise for
them *and* us.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Just clear the mmiodebug before a register access

2016-10-03 Thread Mika Kuoppala
Chris Wilson  writes:

> When we enable the per-register access mmiodebug, it is to detect which
> access is illegal. Reporting on earlier untraced access outside of the
> mmiodebug does not help debugging (as the suspicion is immediately put
> upon the current register which is not at fault)!
>

I think the original intent here was that if the unclaimed access was
before driver register access, it would be sometimes possible to assess
the real culprit by understanding what happened before this moment.

For example if it is before first register access after resume, you can blame
BIOS.

On the other hand we should have now the checks from and after
suspending in place so perhaps it is not worthwhile anymore to keep
reporting the prior unclaimed access in generic case.

However as the check also clears the unclaimed bit, we might
really squels some real problems with this change.

-Mika

> References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index a9b6c936aadd..ee2306a79747 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -796,10 +796,9 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
> const bool read,
> const bool before)
>  {
> - if (WARN(check_for_unclaimed_mmio(dev_priv),
> -  "Unclaimed register detected %s %s register 0x%x\n",
> -  before ? "before" : "after",
> -  read ? "reading" : "writing to",
> + if (WARN(check_for_unclaimed_mmio(dev_priv) && !before,
> +  "Unclaimed %s register 0x%x\n",
> +  read ? "read from" : "write to",
>i915_mmio_reg_offset(reg)))
>   i915.mmio_debug--; /* Only report the first N failures */
>  }
> -- 
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [drm-intel:topic/drm-misc 3/3] htmldocs: include/drm/drm_fb_helper.h:222: warning: Cannot understand * @DRM_FB_HELPER_DEFAULT_OPS:

2016-10-03 Thread Jani Nikula
On Fri, 30 Sep 2016, kbuild test robot  wrote:
> tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
> head:   6c4d6f9f997c5dafccb54b52167f0c4d0ea37874
> commit: 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874 [3/3] drm/fb-helper: add 
> DRM_FB_HELPER_DEFAULT_OPS for fb_ops
> reproduce: make htmldocs
>
> All warnings (new ones prefixed by >>):
>
>>> include/drm/drm_fb_helper.h:222: warning: Cannot understand  * 
>>> @DRM_FB_HELPER_DEFAULT_OPS:
> on line 222 - I thought it was a doc line
>
> vim +222 include/drm/drm_fb_helper.h
>
>206 * Entry on the global kernel_fb_helper_list, used for 
> kgdb entry/exit.
>207 */
>208struct list_head kernel_fb_list;
>209
>210/**
>211 * @delayed_hotplug:
>212 *
>213 * A hotplug was received while fbdev wasn't in control 
> of the DRM
>214 * device, i.e. another KMS master was active. The 
> output configuration
>215 * needs to be reprobe when fbdev is in control again.
>216 */
>217bool delayed_hotplug;
>218};
>219
>220/**
>221 * @DRM_FB_HELPER_DEFAULT_OPS:

Superfluous @.

BR,
Jani.

>  > 222 *
>223 * Helper define to register default implementations of 
> drm_fb_helper
>224 * functions. To be used in struct fb_ops of drm drivers.
>225 */
>226#define DRM_FB_HELPER_DEFAULT_OPS \
>227.fb_check_var   = drm_fb_helper_check_var, \
>228.fb_set_par = drm_fb_helper_set_par, \
>229.fb_setcmap = drm_fb_helper_setcmap, \
>230.fb_blank   = drm_fb_helper_blank, \
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for Forcewake binary search & code shrink (rev6)

2016-10-03 Thread Patchwork
== Series Details ==

Series: Forcewake binary search & code shrink (rev6)
URL   : https://patchwork.freedesktop.org/series/13080/
State : warning

== Summary ==

Series 13080v6 Forcewake binary search & code shrink
https://patchwork.freedesktop.org/api/1.0/series/13080/revisions/6/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700k)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)

fi-bdw-5557u total:236  pass:220  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:236  pass:205  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:236  pass:202  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:245  pass:208  dwarn:0   dfail:0   fail:2   skip:35 
fi-hsw-4770  total:236  pass:213  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:245  pass:222  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:236  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
fi-skl-6700k total:236  pass:209  dwarn:2   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:245  pass:228  dwarn:1   dfail:0   fail:2   skip:14 
fi-snb-2520m total:245  pass:208  dwarn:0   dfail:0   fail:1   skip:36 
fi-snb-2600  total:236  pass:198  dwarn:0   dfail:0   fail:0   skip:37 
fi-ivb-3520m failed to connect after reboot
fi-ivb-3770 failed to collect. IGT log at Patchwork_2612/fi-ivb-3770/igt.log
fi-skl-6260u failed to collect. IGT log at Patchwork_2612/fi-skl-6260u/igt.log
fi-skl-6700hq failed to collect. IGT log at Patchwork_2612/fi-skl-6700hq/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2612/

d0534bd0217c83c083ba146b9c987e19b219e0e4 drm-intel-nightly: 
2016y-09m-30d-10h-31m-00s UTC integration manifest
c5237e5 drm/i915: Inline binary search
9b4e3c9 drm/i915: Use binary search when looking for shadowed registers
0b12dbd drm/i915: Sort the shadow register table
7978e69 drm/i915: Remove identical write mmmio functions
b0960d1 drm/i915: Remove identical mmio read functions
354b09a drm/i915: Remove identical macros
e608845 drm/i915: Store the active forcewake range table pointer
79f3cb4 drm/i915: Eliminate Gen9 special case
7fe1499 drm/i915: Use binary search when looking up forcewake domains
1a71a14 drm/i915: Sort forcewake mapping tables
d34328e drm/i915: Data driven register to forcewake domains lookup
82e0e23 drm/i915: Do not inline forcewake taking in mmio accessors
920037b drm/i915: Keep track of active forcewake domains in a bitmask
e6741b5 drm/i915: Remove redundant hsw_write* mmio functions

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


[Intel-gfx] [PATCH 12/14] drm/i915: Sort the shadow register table

2016-10-03 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Also verify the order at runtime. This was we can start using
binary search on it in a following patch.

v2: Add comment on the sorted array and only check it when
debug option is enabled.

v3: Use IS_ENABLED. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen  (v1)
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uncore.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1e9061b22e0f..7d6f87acf661 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -663,16 +663,34 @@ static const struct intel_forcewake_range 
__vlv_fw_ranges[] = {
__fwd; \
 })
 
+/* *Must* be sorted by offset! See intel_shadow_table_check(). */
 static const i915_reg_t gen8_shadowed_regs[] = {
-   GEN6_RPNSWREQ,
-   GEN6_RC_VIDEO_FREQ,
-   RING_TAIL(RENDER_RING_BASE),
-   RING_TAIL(GEN6_BSD_RING_BASE),
-   RING_TAIL(VEBOX_RING_BASE),
-   RING_TAIL(BLT_RING_BASE),
+   RING_TAIL(RENDER_RING_BASE),/* 0x2000 (base) */
+   GEN6_RPNSWREQ,  /* 0xA008 */
+   GEN6_RC_VIDEO_FREQ, /* 0xA00C */
+   RING_TAIL(GEN6_BSD_RING_BASE),  /* 0x12000 (base) */
+   RING_TAIL(VEBOX_RING_BASE), /* 0x1a000 (base) */
+   RING_TAIL(BLT_RING_BASE),   /* 0x22000 (base) */
/* TODO: Other registers are not yet used */
 };
 
+static void intel_shadow_table_check(void)
+{
+   const i915_reg_t *reg = gen8_shadowed_regs;
+   s32 prev;
+   u32 offset;
+   unsigned int i;
+
+   if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
+   return;
+
+   for (i = 0, prev = -1; i < ARRAY_SIZE(gen8_shadowed_regs); i++, reg++) {
+   offset = i915_mmio_reg_offset(*reg);
+   WARN_ON_ONCE(prev >= (s32)offset);
+   prev = offset;
+   }
+}
+
 static bool is_gen8_shadowed(u32 offset)
 {
int i;
@@ -1284,6 +1302,8 @@ void intel_uncore_init(struct drm_i915_private *dev_priv)
}
 
intel_fw_table_check(dev_priv);
+   if (INTEL_GEN(dev_priv) >= 8)
+   intel_shadow_table_check();
 
if (intel_vgpu_active(dev_priv)) {
ASSIGN_WRITE_MMIO_VFUNCS(vgpu);
-- 
2.7.4

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


[Intel-gfx] [PATCH 08/14] drm/i915: Store the active forcewake range table pointer

2016-10-03 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

If we store this in the uncore structure we are on a good way to
show more commonality between the per-platform implementations.

v2: Constify table pointer and correct coding style. (Chris Wilson)
v3: Rebase.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 10 ++
 drivers/gpu/drm/i915/intel_uncore.c | 68 ++---
 2 files changed, 44 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b1997fd8c87..3b14938aa09e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -582,9 +582,19 @@ struct intel_uncore_funcs {
uint32_t val, bool trace);
 };
 
+struct intel_forcewake_range {
+   u32 start;
+   u32 end;
+
+   enum forcewake_domains domains;
+};
+
 struct intel_uncore {
spinlock_t lock; /** lock is also taken in irq contexts. */
 
+   const struct intel_forcewake_range *fw_domains_table;
+   unsigned int fw_domains_table_entries;
+
struct intel_uncore_funcs funcs;
 
unsigned fifo_count;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ba90a7e9d3b2..c813bdef8ded 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -582,14 +582,6 @@ void assert_forcewakes_inactive(struct drm_i915_private 
*dev_priv)
__fwd; \
 })
 
-struct intel_forcewake_range
-{
-   u32 start;
-   u32 end;
-
-   enum forcewake_domains domains;
-};
-
 static int fw_range_cmp(const void *key, const void *elt)
 {
const struct intel_forcewake_range *entry = elt;
@@ -604,28 +596,38 @@ static int fw_range_cmp(const void *key, const void *elt)
 }
 
 static enum forcewake_domains
-find_fw_domain(u32 offset, const struct intel_forcewake_range *ranges,
-  unsigned int num_ranges)
+find_fw_domain(struct drm_i915_private *dev_priv, u32 offset)
 {
-   struct intel_forcewake_range *entry;
+   const struct intel_forcewake_range *table, *entry;
+   unsigned int num_entries;
 
-   entry = bsearch((void *)(unsigned long)offset, (const void *)ranges,
-   num_ranges, sizeof(struct intel_forcewake_range),
+   table = dev_priv->uncore.fw_domains_table;
+   num_entries = dev_priv->uncore.fw_domains_table_entries;
+
+   entry = bsearch((void *)(unsigned long)offset, (const void *)table,
+   num_entries, sizeof(struct intel_forcewake_range),
fw_range_cmp);
 
return entry ? entry->domains : 0;
 }
 
 static void
-intel_fw_table_check(const struct intel_forcewake_range *ranges,
-unsigned int num_ranges)
+intel_fw_table_check(struct drm_i915_private *dev_priv)
 {
+   const struct intel_forcewake_range *ranges;
+   unsigned int num_ranges;
s32 prev;
unsigned int i;
 
if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
return;
 
+   ranges = dev_priv->uncore.fw_domains_table;
+   if (!ranges)
+   return;
+
+   num_ranges = dev_priv->uncore.fw_domains_table_entries;
+
for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
WARN_ON_ONCE(prev >= (s32)ranges->start);
prev = ranges->start;
@@ -652,8 +654,7 @@ static const struct intel_forcewake_range __vlv_fw_ranges[] 
= {
 ({ \
enum forcewake_domains __fwd = 0; \
if (NEEDS_FORCE_WAKE((offset))) \
-   __fwd = find_fw_domain(offset, __vlv_fw_ranges, \
-  ARRAY_SIZE(__vlv_fw_ranges)); \
+   __fwd = find_fw_domain(dev_priv, offset); \
__fwd; \
 })
 
@@ -711,8 +712,7 @@ static const struct intel_forcewake_range __chv_fw_ranges[] 
= {
 ({ \
enum forcewake_domains __fwd = 0; \
if (NEEDS_FORCE_WAKE((offset))) \
-   __fwd = find_fw_domain(offset, __chv_fw_ranges, \
-  ARRAY_SIZE(__chv_fw_ranges)); \
+   __fwd = find_fw_domain(dev_priv, offset); \
__fwd; \
 })
 
@@ -720,8 +720,7 @@ static const struct intel_forcewake_range __chv_fw_ranges[] 
= {
 ({ \
enum forcewake_domains __fwd = 0; \
if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
-   __fwd = find_fw_domain(offset, __chv_fw_ranges, \
-  ARRAY_SIZE(__chv_fw_ranges)); \
+   __fwd = find_fw_domain(dev_priv, offset); \
__fwd; \
 })
 
@@ -765,8 +764,7 @@ static const struct intel_forcewake_range 
__gen9_fw_ranges[] = {
 ({ \
enum forcewake_domains __fwd = 0; \
if (NEEDS_FORCE_WAKE((offset))) \
-   __fwd = find_fw_domain(offset, __gen9_fw_ranges, \
-  

[Intel-gfx] [PATCH 05/14] drm/i915: Sort forcewake mapping tables

2016-10-03 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Sorting the tables (verified at runtime to help during
development) is another prerequisite for interesting
work which will follow.

v2:
 * Remove const away cast and improve comments. (Chris Wilson)
 * Check tables only when debug option is enabled.

v3: Use IS_ENABLED. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uncore.c | 56 -
 1 file changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index e21e65ab2a16..7110c8fdfb88 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -605,16 +605,35 @@ find_fw_domain(u32 offset, const struct 
intel_forcewake_range *ranges,
return -1;
 }
 
+static void
+intel_fw_table_check(const struct intel_forcewake_range *ranges,
+unsigned int num_ranges)
+{
+   s32 prev;
+   unsigned int i;
+
+   if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
+   return;
+
+   for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
+   WARN_ON_ONCE(prev >= (s32)ranges->start);
+   prev = ranges->start;
+   WARN_ON_ONCE(prev >= (s32)ranges->end);
+   prev = ranges->end;
+   }
+}
+
 #define GEN_FW_RANGE(s, e, d) \
{ .start = (s), .end = (e), .domains = (d) }
 
+/* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
 static const struct intel_forcewake_range __vlv_fw_ranges[] = {
GEN_FW_RANGE(0x2000, 0x3fff, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x5000, 0x7fff, FORCEWAKE_RENDER),
GEN_FW_RANGE(0xb000, 0x11fff, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0x2e000, 0x2, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x12000, 0x13fff, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_MEDIA),
+   GEN_FW_RANGE(0x2e000, 0x2, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_MEDIA),
 };
 
@@ -660,23 +679,24 @@ static bool is_gen8_shadowed(u32 offset)
__fwd; \
 })
 
+/* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
 static const struct intel_forcewake_range __chv_fw_ranges[] = {
GEN_FW_RANGE(0x2000, 0x3fff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0x4000, 0x4fff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x5200, 0x7fff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0x8000, 0x82ff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x8300, 0x84ff, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0xb000, 0xb47f, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0xe000, 0xe7ff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0x8500, 0x85ff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x8800, 0x88ff, FORCEWAKE_MEDIA),
+   GEN_FW_RANGE(0x9000, 0xafff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
+   GEN_FW_RANGE(0xb000, 0xb47f, FORCEWAKE_RENDER),
GEN_FW_RANGE(0xd000, 0xd7ff, FORCEWAKE_MEDIA),
+   GEN_FW_RANGE(0xe000, 0xe7ff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0xf000, 0x, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x12000, 0x13fff, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x1a000, 0x1bfff, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x1e800, 0x1e9ff, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x3, 0x37fff, FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x4000, 0x4fff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x8000, 0x82ff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x8500, 0x85ff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x9000, 0xafff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0xf000, 0x, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
 };
 
 #define __chv_reg_read_fw_domains(offset) \
@@ -703,23 +723,24 @@ static const struct intel_forcewake_range 
__chv_fw_ranges[] = {
__fwd; \
 })
 
+/* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
 static const struct intel_forcewake_range __gen9_fw_ranges[] = {
GEN_FW_RANGE(0xb00, 0x1fff, 0), /* uncore range */
GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x3000, 0x3fff, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x5200, 0x7fff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0x8130, 0x813f, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x8140, 0x815f, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x8300, 0x84ff, FORCEWAKE_RENDER),
+   GEN_FW_RANGE(0x8800, 0x89ff, FORCEWAKE_MEDIA),
GEN_FW_RANGE(0x8c00, 0x8cff, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0xb000, 0xb47f, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0xe000, 0xe8ff, FORCEWAKE_RENDER),
-   GEN_FW_RANGE(0x24400, 0x247ff, FORCEWAKE_RENDER),
GEN_FW_RANGE(0x9400, 0x97ff, FORCEWAKE_RENDER | FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x8130, 0x813f, FORCEWAKE_MEDIA),
-   GEN_FW_RANGE(0x8800, 0x89ff, FORCEWAKE_MEDIA),
+   GEN_FW_RANGE(0xb000, 0xb47f, 

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use binary search when looking for shadowed registers

2016-10-03 Thread Tvrtko Ursulin


On 03/10/2016 09:05, Joonas Lahtinen wrote:

On pe, 2016-09-30 at 19:08 +0100, Chris Wilson wrote:

On Fri, Sep 30, 2016 at 06:48:48PM +0100, Tvrtko Ursulin wrote:

+static int mmio_reg_cmp(const void *key, const void *elt)
+{
+   u32 offset = (u32)(unsigned long)key;
+   i915_reg_t *reg = (i915_reg_t *)elt;
+
+   if (offset < i915_mmio_reg_offset(*reg))
+   return -1;
+   else if (offset > i915_mmio_reg_offset(*reg))
+   return 1;
+   else
+   return 0;

There's no issue with using

return offset - i915_mmio_reg_offset(*reg)

here.


Why not?


+   reg = bsearch((void *)(unsigned long)offset,
+ (const void *)gen8_shadowed_regs,
+ ARRAY_SIZE(gen8_shadowed_regs),
+ sizeof(i915_reg_t),
+ mmio_reg_cmp);
+
+   return reg;

Or just return bseearch() ? (Probably like this for easing future
patches.)

Suggested that too, but obviously he has something in mind.


It becomes a direct return in a following patch. It is just a virtue of 
me wanting to split out the series a lot for easier review, and then not 
picking up all relevant places to tidy when acting on review feedback. 
But this one as I said happens in a following patch.


Regards,

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move long hpd handling into the hotplug work

2016-10-03 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Move long hpd handling into the 
hotplug work
URL   : https://patchwork.freedesktop.org/series/13225/
State : success

== Summary ==

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


fi-bdw-5557u total:236  pass:220  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:236  pass:205  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:236  pass:203  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:236  pass:199  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:245  pass:222  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:236  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:236  pass:210  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:245  pass:230  dwarn:0   dfail:0   fail:1   skip:14 
fi-skl-6700k total:245  pass:219  dwarn:1   dfail:0   fail:1   skip:24 
fi-skl-6770hqtotal:236  pass:219  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:236  pass:199  dwarn:0   dfail:0   fail:0   skip:36 
fi-hsw-4770r failed to connect after reboot
fi-ivb-3770 failed to collect. IGT log at Patchwork_2611/fi-ivb-3770/igt.log
fi-skl-6700hq failed to collect. IGT log at Patchwork_2611/fi-skl-6700hq/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2611/

d0534bd0217c83c083ba146b9c987e19b219e0e4 drm-intel-nightly: 
2016y-09m-30d-10h-31m-00s UTC integration manifest
de4d435 drm/i915: Allow DP to work w/o EDID
b3de65d drm/i915: Move long hpd handling into the hotplug work

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


Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use binary search when looking for shadowed registers

2016-10-03 Thread Joonas Lahtinen
On pe, 2016-09-30 at 19:08 +0100, Chris Wilson wrote:
> On Fri, Sep 30, 2016 at 06:48:48PM +0100, Tvrtko Ursulin wrote: 
> > +static int mmio_reg_cmp(const void *key, const void *elt)
> > +{
> > +   u32 offset = (u32)(unsigned long)key;
> > +   i915_reg_t *reg = (i915_reg_t *)elt;
> > +
> > +   if (offset < i915_mmio_reg_offset(*reg))
> > +   return -1;
> > +   else if (offset > i915_mmio_reg_offset(*reg))
> > +   return 1;
> > +   else
> > +   return 0;
> 
> There's no issue with using
> 
>   return offset - i915_mmio_reg_offset(*reg)
> 
> here.
> 

Why not?

> > +   reg = bsearch((void *)(unsigned long)offset,
> > +     (const void *)gen8_shadowed_regs,
> > +     ARRAY_SIZE(gen8_shadowed_regs),
> > +     sizeof(i915_reg_t),
> > +     mmio_reg_cmp);
> > +
> > +   return reg;
> 
> Or just return bseearch() ? (Probably like this for easing future
> patches.)

Suggested that too, but obviously he has something in mind.

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


Re: [Intel-gfx] [PATCH 04/14] drm/i915: Data driven register to forcewake domains lookup

2016-10-03 Thread Joonas Lahtinen
On pe, 2016-09-30 at 18:48 +0100, Tvrtko Ursulin wrote:
> 
> +find_fw_domain(u32 offset, const struct intel_forcewake_range *ranges,
> +    unsigned int num_ranges)

Gotta remind that generally "fw" is associated with firmware.
"forcewake" might be appropriate word in function names too.

> +{
> + unsigned int i;
> + struct intel_forcewake_range *entry =
> + (struct intel_forcewake_range *)ranges;
> +
> + for (i = 0; i < num_ranges; i++, entry++) {
> + if (offset >= entry->start && offset <= entry->end)
> + return entry->domains;
> + }
> +
> + return -1;
> +}
> 

This could be a binary search, too, with some sorting.

Already as is;

Reviewed-by: Joonas Lahtinen 

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


[Intel-gfx] [PATCH 1/2] drm/i915: Move long hpd handling into the hotplug work

2016-10-03 Thread ville . syrjala
From: Ville Syrjälä 

We can't rely on connector->status in the detect() hook if the long hpd
was already handled by the dig_port_work as that won't update
connector->status. Thus we have to defer the long hpd handling entirely
until the hotplug work runs to avoid the double long hpd handling
the "detect_done" flag is trying to prevent.

Cc: Damien Cassou 
Cc: freedesktop@gp.mailgun.org
Cc: Arno 
Cc: Shubhangi Shrivastava 
Cc: Sivakumar Thulasimani 
Cc: Ander Conselvan de Oliveira 
Cc: sta...@vger.kernel.org
Tested-by: Arno 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 48 -
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9448d898d80b..96caa469e3a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4827,36 +4827,34 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  port_name(intel_dig_port->port),
  long_hpd ? "long" : "short");
 
+   if (long_hpd) {
+   intel_dp->detect_done = false;
+   return IRQ_NONE;
+   }
+
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
 
-   if (long_hpd) {
-   intel_dp_long_pulse(intel_dp->attached_connector);
-   if (intel_dp->is_mst)
-   ret = IRQ_HANDLED;
-   goto put_power;
-
-   } else {
-   if (intel_dp->is_mst) {
-   if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
-   /*
-* If we were in MST mode, and device is not
-* there, get out of MST mode
-*/
-   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 put_power;
-   }
+   if (intel_dp->is_mst) {
+   if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
+   /*
+* If we were in MST mode, and device is not
+* there, get out of MST mode
+*/
+   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_dp->detect_done = false;
+   goto put_power;
}
+   }
 
-   if (!intel_dp->is_mst) {
-   if (!intel_dp_short_pulse(intel_dp)) {
-   
intel_dp_long_pulse(intel_dp->attached_connector);
-   goto put_power;
-   }
+   if (!intel_dp->is_mst) {
+   if (!intel_dp_short_pulse(intel_dp)) {
+   intel_dp->detect_done = false;
+   goto put_power;
}
}
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/2] drm/i915: Allow DP to work w/o EDID

2016-10-03 Thread ville . syrjala
From: Ville Syrjälä 

Allow returning "connected" or "unknown" connector status for DP branch
devices that don't have an EDID. Currently we'd claim the thing as
"disconnected" if there is no EDID.

This stuff used to broken already, I think, but it got more broken by
commit f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")

Cc: Damien Cassou 
Cc: freedesktop@gp.mailgun.org
Cc: Arno 
Cc: Shubhangi Shrivastava 
Cc: Sivakumar Thulasimani 
Cc: Ander Conselvan de Oliveira 
Cc: sta...@vger.kernel.org
Tested-by: Arno 
Fixes: f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 96caa469e3a8..5992093e1814 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4333,7 +4333,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = false;
 }
 
-static void
+static enum drm_connector_status
 intel_dp_long_pulse(struct intel_connector *intel_connector)
 {
struct drm_connector *connector = _connector->base;
@@ -4357,7 +4357,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
else
status = connector_status_disconnected;
 
-   if (status != connector_status_connected) {
+   if (status == connector_status_disconnected) {
intel_dp->compliance_test_active = 0;
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
@@ -4419,8 +4419,8 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->aux.i2c_defer_count = 0;
 
intel_dp_set_edid(intel_dp);
-
-   status = connector_status_connected;
+   if (is_edp(intel_dp) || intel_connector->detect_edid)
+   status = connector_status_connected;
intel_dp->detect_done = true;
 
/* Try to read the source of the interrupt */
@@ -4439,12 +4439,11 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
}
 
 out:
-   if ((status != connector_status_connected) &&
-   (intel_dp->is_mst == false))
+   if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
 
intel_display_power_put(to_i915(dev), power_domain);
-   return;
+   return status;
 }
 
 static enum drm_connector_status
@@ -4453,7 +4452,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = _dig_port->base;
-   struct intel_connector *intel_connector = to_intel_connector(connector);
+   enum drm_connector_status status = connector->status;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
@@ -4468,14 +4467,11 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
 
/* If full detect is not performed yet, do a full detect */
if (!intel_dp->detect_done)
-   intel_dp_long_pulse(intel_dp->attached_connector);
+   status = intel_dp_long_pulse(intel_dp->attached_connector);
 
intel_dp->detect_done = false;
 
-   if (is_edp(intel_dp) || intel_connector->detect_edid)
-   return connector_status_connected;
-   else
-   return connector_status_disconnected;
+   return status;
 }
 
 static void
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/prime: Passing the right owner through to dma_buf_export()

2016-10-03 Thread Joonas Lahtinen
On pe, 2016-09-30 at 11:38 +0100, Chris Wilson wrote:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
> to the dmabuf). However, drm_gem_prime_export() was passing its own
> THIS_MODULE (i.e. drm.ko) rather than the driver. Expand the interface
> so that driver passes the struct module to the helper.
> 
> Testcase: igt/vgem_reload_basic
> Reported-by: Petri Latvala 
> Signed-off-by: Chris Wilson 
> Cc: Petri Latvala 
> Cc: sta...@vger.kernel.org

From previous experience (with the BIT() conversion), expectation is to
CC all driver maintainers, even for simple changes. Should not be hard
to split this change either.

Code is anyway;

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH] drm/i915: Use correct index for backtracking HUNG semaphores

2016-10-03 Thread Joonas Lahtinen
On la, 2016-10-01 at 20:42 +0100, Chris Wilson wrote:
> When decoding the semaphores inside hangcheck, we need to use the hw-id
> and not the local array index.
> 
> Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...")
> Testcase: igt/gem_exec_whisper/hang # gen6-7
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: sta...@vger.kernel.org

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH] drm/i915: Unalias obj->phys_handle and obj->userptr

2016-10-03 Thread Joonas Lahtinen
On pe, 2016-09-30 at 18:31 +0100, Chris Wilson wrote:
> We use obj->phys_handle to choose the pread/pwrite path, but as
> obj->phys_handle is a union with obj->userptr, we then mistakenly use
> the phys_handle path for userptr objects within pread/pwrite.
> 
> Testcase: igt/gem_userptr_blits/forbidden-operations
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
> Signed-off-by: Chris Wilson 
> Cc: sta...@vger.kernel.org

Reviewed-by: Joonas Lahtinen 

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