[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable LVDS on Radiant P845

[Patchwork]

== Series Details ==

Series: drm/i915: Disable LVDS on Radiant P845
URL   : https://patchwork.freedesktop.org/series/39732/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#101623

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:8   skip:1632 
time:12221s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11580s
shard-snbtotal:3467 pass:1364 dwarn:1   dfail:0   fail:1   skip:2101 
time:7005s
Blacklisted hosts:
shard-kbltotal:3405 pass:1911 dwarn:4   dfail:0   fail:7   skip:1481 
time:8597s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)

[Patchwork]

== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
URL   : https://patchwork.freedesktop.org/series/39571/
State : failure

== Summary ==

 Possible new issues:

Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-xtiled:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> FAIL   (shard-apl) fdo#103375
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3407 pass:1770 dwarn:1   dfail:0   fail:9   skip:1625 
time:11840s
shard-hswtotal:3494 pass:1771 dwarn:1   dfail:0   fail:3   skip:1718 
time:11673s
shard-snbtotal:3494 pass:1365 dwarn:1   dfail:0   fail:1   skip:2127 
time:7011s
Blacklisted hosts:
shard-kbltotal:3331 pass:1849 dwarn:1   dfail:0   fail:5   skip:1474 
time:8608s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Plane Color Properties (rev3)

[Patchwork]

== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : failure

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
pass   -> DMESG-FAIL (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:8   skip:1632 
time:12253s
shard-hswtotal:3467 pass:1770 dwarn:1   dfail:1   fail:2   skip:1692 
time:11436s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6926s
Blacklisted hosts:
shard-kbltotal:3398 pass:1907 dwarn:7   dfail:1   fail:6   skip:1476 
time:8953s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM

[Daniele Ceraolo Spurio]

On 09/03/18 08:01, Michal Wajdeczko wrote:

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

v2: don't forget about reset path (Daniele)
 sanitize uc before gem initiated full reset (Daniele)

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 


Reviewed-by: Daniele Ceraolo Spurio 

a small comment below





diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
  }
  
+void intel_uc_sanitize(struct drm_i915_private *i915)

+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);


With this here, can we now drop the guc_disable_communication in 
intel_uc_init_hw?


Thanks,
Daniele


+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
  void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,


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

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

[Atwood, Matthew S]

On Fri, 2018-03-09 at 14:05 +0200, Jani Nikula wrote:
> On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote:
> > 
> > From: Matt Atwood 
> > 
> > Previously it was assumed that eDP panels would advertise the
> > lowest link
> > rate required for their singular mode to function. With the
> > introduction
> > of more advanced features there are advantages to a panel
> > advertising a
> > higher rate then it needs for a its given mode. For panels that
> > did, the
> > driver previously used a higher rate then necessary for that mode.
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 10 --
> >  1 file changed, 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index a2eeede..aa6d77d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> >       dev_priv->vbt.edp.bpp);
> >     bpp = dev_priv->vbt.edp.bpp;
> >     }
> > -
> > -   /*
> > -    * Use the maximum clock and number of lanes the
> > eDP panel
> > -    * advertizes being capable of. The panels are
> > generally
> > -    * designed to support only a single clock and
> > lane
> > -    * configuration, and typically these values
> > correspond to the
> > -    * native resolution of the panel.
> > -    */
> > -   min_lane_count = max_lane_count;
> > -   min_clock = max_clock;
> Please see my reply to Manasi's identical patch [1]. If we apply this
> as-is, it will regress and will be reverted.
> 
> BR,
> Jani.
> 
> 
> [1] http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-
> git-send-email-manasi.d.nav...@intel.com
to consolidate some of the information the bug that's referenced in
Manasi's patch is https://bugs.freedesktop.org/show_bug.cgi?id=73539. I
understand this bug as the following some panels may advertise a mode
that requires less then MAX_LANE_COUNT, however those panels would fail
if less lanes were used.

When this bug was filed the compute config inner for loop iterated on
rate and the outer iterated on lanes; this is now flipped. It *should*
be the case that the lowest frequency with the max amount of lanes is
preferred. Given the opposite behavior of the alogorithm to select I
dont think we'd come across this again. Even if I'm wrong we could
still min_lane_count = max_lane count and let the clock optimize
itself.

I guess my question is, is there also a bug where if MAX_RATE wasnt
used we saw a panel fail as well?

Matt
> 
> 
> > 
> >     }
> >  
> >     for (; bpp >= 6*3; bpp -= 2*3) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Atwood, Matthew S]

On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote:
> On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> > 
> > From: Matt Atwood 
> > 
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme
> > from 8
> > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> > receiver capabilities. For panels that use this new feature wait
> > interval
> > would be increased by 512 ms, when spec is max 16 ms. This behavior
> > is
> > described in table 2-158 of DP 1.4 spec address eh.
> > 
> > With the introduction of DP 1.4 spec main link clock recovery was
> > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL
> > value.
> > 
> > To avoid breaking panels that are not spec compiant we now warn on
> > invalid values.
> > 
> > V2: commit title/message, masking all 7 bits, warn on out of spec
> > values.
> > V3: commit message, make link train clock recovery follow DP 1.4
> > spec.
> > V4: style changes
> > V5: typo
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> >  include/drm/drm_dp_helper.h |  6 ++
> >  2 files changed, 20 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index adf79be..cdb04c9 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -119,18 +119,28 @@ u8
> > drm_dp_get_adjust_request_pre_emphasis(const u8
> > link_status[DP_LINK_STATUS_SI
> >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> >  
> >  void drm_dp_link_train_clock_recovery_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > +   if (rd_interval > 4)
> > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
> 
> > 
> > +
> > +   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
> >     udelay(100);
> >     else
> > -   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > +   mdelay(rd_interval * 4);
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> >  
> >  void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > +   if (rd_interval > 4)
> > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
> 
> > 
> > +
> > +   if (rd_interval == 0)
> >     udelay(400);
> >     else
> > -   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > +   mdelay(rd_interval * 4);
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> >  
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index da58a42..1269ef8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -64,6 +64,11 @@
> >  /* AUX CH addresses */
> >  /* DPCD */
> >  #define DP_DPCD_REV 0x000
> > +# define DP_REV_10  0x10
> > +# define DP_REV_11  0x11
> > +# define DP_REV_12  0x12
> > +# define DP_REV_13  0x13
> > +# define DP_REV_14  0x14
> I am not sure what good these buy us, but if people think they're the
> way to go, then so be it. Just bear in mind that per spec, "The DPCD
> revision number does not necessarily match the DisplayPort version
> number." so "DP_REV" doesn't actually mean *DP* revision.
> 
> 
> BR,
> Jani.
you're right likely a better name is DPCD_REV_XX. I think we sill want
to base the main-link clock recovery on time on this value. Next
revision will include this naming convention. 
> 
> > 
> >  
> >  #define DP_MAX_LINK_RATE0x001
> >  
> > @@ -118,6 +123,7 @@
> >  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2
> > or higher */
> >  
> >  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> > +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
Rodrigo has shown me a DP 1.2 spec that had this change and conflicts
with my copy so I'll be changing to XXX 1.2

Matt
> >  
> >  #define DP_ADAPTER_CAP 0x00f   /* 1.2
> > */
> >  # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support

[Patchwork]

== Series Details ==

Series: Add NV12 support
URL   : https://patchwork.freedesktop.org/series/39670/
State : failure

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-left-edge:
fail   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-negative:
pass   -> INCOMPLETE (shard-apl)
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-a-scaler-with-rotation:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-rotation:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> DMESG-WARN (shard-snb) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3388 pass:1782 dwarn:1   dfail:0   fail:10  skip:1592 
time:11647s
shard-hswtotal:3467 pass:1772 dwarn:1   dfail:0   fail:1   skip:1692 
time:11578s
shard-snbtotal:3467 pass:1364 dwarn:2   dfail:0   fail:1   skip:2100 
time:6943s
Blacklisted hosts:
shard-kbltotal:3398 pass:1909 dwarn:2   dfail:0   fail:10  skip:1476 
time:8942s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable LVDS on Radiant P845

[Patchwork]

== Series Details ==

Series: drm/i915: Disable LVDS on Radiant P845
URL   : https://patchwork.freedesktop.org/series/39732/
State : success

== Summary ==

Series 39732v1 drm/i915: Disable LVDS on Radiant P845
https://patchwork.freedesktop.org/api/1.0/series/39732/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:500s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:519s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:513s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:505s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:510s

7e5ff4244a75361f62abdb9e484e31a125131920 drm-tip: 2018y-03m-09d-22h-21m-43s UTC 
integration manifest
7985fffe1a0d drm/i915: Disable LVDS on Radiant P845

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39710/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test gem_exec_capture:
Subgroup capture-vebox:
pass   -> FAIL   (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_plane_multiple:
Subgroup atomic-pipe-c-tiling-y:
pass   -> FAIL   (shard-apl) fdo#103166

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166

shard-apltotal:3262 pass:1716 dwarn:2   dfail:0   fail:17  skip:1524 
time:11509s
shard-hswtotal:3467 pass:1770 dwarn:1   dfail:0   fail:3   skip:1692 
time:11547s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6868s
Blacklisted hosts:
shard-kbltotal:3168 pass:1779 dwarn:2   dfail:1   fail:18  skip:1364 
time:8065s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Disable LVDS on Radiant P845

[Ondrej Zary]

Radiant P845 does not have LVDS, only VGA.

Signed-off-by: Ondrej Zary 
---
 drivers/gpu/drm/i915/intel_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index ef80499113ee..6939e63d8bae 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -819,6 +819,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "D525MW"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Radiant P845",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Radiant Systems Inc"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "P845"),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
Ondrej Zary

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)

[Chris Wilson]

Quoting Patchwork (2018-03-09 22:12:20)
> == Series Details ==
> 
> Series: drm/i915: misc fixes in headers (RESEND)
> URL   : https://patchwork.freedesktop.org/series/39589/
> State : failure
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_cursor_legacy:
> Subgroup short-flip-after-cursor-atomic-transitions:
> pass   -> FAIL   (shard-hsw)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-rgb101010-draw-pwrite:
> pass   -> FAIL   (shard-apl)
> 
>  Known issues:
> 
> Test gem_eio:
> Subgroup in-flight:
> incomplete -> PASS   (shard-apl) fdo#105341
> Test kms_cursor_crc:
> Subgroup cursor-128x128-suspend:
> skip   -> PASS   (shard-hsw) fdo#103540
> Test kms_flip:
> Subgroup 2x-modeset-vs-vblank-race:
> pass   -> DMESG-WARN (shard-hsw) fdo#103060
> Subgroup plain-flip-ts-check-interruptible:
> fail   -> PASS   (shard-hsw) fdo#100368
> Test pm_lpsp:
> Subgroup screens-disabled:
> pass   -> FAIL   (shard-hsw) fdo#104941
> 
> fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
> fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941
> 
> shard-apltotal:3398 pass:1792 dwarn:1   dfail:0   fail:8   skip:1596 
> time:11758s
> shard-hswtotal:3467 pass:1770 dwarn:2   dfail:0   fail:3   skip:1691 
> time:11639s
> shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
> time:6999s

As pw is finally happy, pushed. Thanks for the cleanup,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)

[Patchwork]

== Series Details ==

Series: drm/i915: misc fixes in headers (RESEND)
URL   : https://patchwork.freedesktop.org/series/39589/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup short-flip-after-cursor-atomic-transitions:
pass   -> FAIL   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb101010-draw-pwrite:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-modeset-vs-vblank-race:
pass   -> DMESG-WARN (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3398 pass:1792 dwarn:1   dfail:0   fail:8   skip:1596 
time:11758s
shard-hswtotal:3467 pass:1770 dwarn:2   dfail:0   fail:3   skip:1691 
time:11639s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6999s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)

[Patchwork]

== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
URL   : https://patchwork.freedesktop.org/series/39571/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
5d71d7782a830843c7231fbd72ab3edae19b48d7 igt/gem_fd_exhaustion: Modify 
fs.nr_open for duration of the test

with latest DRM-Tip kernel build CI_DRM_3907
b97cfb3880fd drm-tip: 2018y-03m-09d-21h-14m-12s UTC integration manifest

Testlist changes:
+igt@gem_ctx_freq@blt-continuous
+igt@gem_ctx_freq@blt-inflight
+igt@gem_ctx_freq@blt-single
+igt@gem_ctx_freq@bsd1-continuous
+igt@gem_ctx_freq@bsd1-inflight
+igt@gem_ctx_freq@bsd1-single
+igt@gem_ctx_freq@bsd2-continuous
+igt@gem_ctx_freq@bsd2-inflight
+igt@gem_ctx_freq@bsd2-single
+igt@gem_ctx_freq@bsd-continuous
+igt@gem_ctx_freq@bsd-inflight
+igt@gem_ctx_freq@bsd-single
+igt@gem_ctx_freq@default-continuous
+igt@gem_ctx_freq@default-inflight
+igt@gem_ctx_freq@default-single
+igt@gem_ctx_freq@idempotent
+igt@gem_ctx_freq@independent
+igt@gem_ctx_freq@invalid
+igt@gem_ctx_freq@range
+igt@gem_ctx_freq@render-continuous
+igt@gem_ctx_freq@render-inflight
+igt@gem_ctx_freq@render-single
+igt@gem_ctx_freq@sandwich
+igt@gem_ctx_freq@smoketest
+igt@gem_ctx_freq@vebox-continuous
+igt@gem_ctx_freq@vebox-inflight
+igt@gem_ctx_freq@vebox-single

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#104944

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:510s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:589s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:509s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH i-g-t v2] tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()

[Radhakrishna Sripada]

From: Anusha Srivatsa 

Rework the rotate and reflect subtests by checking the
crtc supported properties against the ones that the
test is testing. Remove the hardcoded platform names in
igt_require()

v2: Make use of the property enums to get the supported rotations

Cc: Radhakrishna Sripada 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Maarten Lankhorst 
Cc: Mika Kahola 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Radhakrishna Sripada 
---
 lib/igt_kms.h|  1 +
 tests/kms_rotation_crc.c | 46 +-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 1c46186e8a9d..c306aa1f5b8d 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -289,6 +289,7 @@ typedef enum {
 
 #define IGT_ROTATION_MASK \
(IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 | IGT_ROTATION_270)
+#define IGT_REFLECT_MASK   (IGT_REFLECT_X | IGT_REFLECT_Y)
 
 typedef struct {
/*< private >*/
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 0cd5c6e52b57..8f7e5d4f2dd2 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -38,6 +38,7 @@ typedef struct {
igt_crc_t flip_crc;
igt_pipe_crc_t *pipe_crc;
igt_rotation_t rotation;
+   int **supported_rotation;
int pos_x;
int pos_y;
uint32_t override_fmt;
@@ -373,13 +374,14 @@ static void test_plane_rotation(data_t *data, int 
plane_type, bool test_bad_form
igt_plane_t *plane;
int i, j;
 
-   if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
-   continue;
-
igt_output_set_pipe(output, pipe);
 
plane = igt_output_get_plane_type(output, plane_type);
igt_require(igt_plane_has_prop(plane, IGT_PLANE_ROTATION));
+   igt_require(data->supported_rotation[pipe][plane->index] & 
data->rotation);
+
+   if (data->rotation & IGT_REFLECT_MASK)
+   
igt_require(data->supported_rotation[pipe][plane->index] & IGT_REFLECT_MASK);
 
prepare_crtc(data, output, pipe, plane);
 
@@ -460,6 +462,36 @@ static void test_plane_rotation_exhaust_fences(data_t 
*data,
igt_remove_fb(fd, [i]);
 }
 
+static void igt_supported_rotation_init(data_t *data)
+{
+   igt_display_t *display = >display;
+   bool found;
+   int i, j, k, n_pipes = display->n_pipes;
+   int **s_rotation;
+
+   s_rotation = calloc(sizeof(int *), n_pipes);
+
+   for (i = 0; i < n_pipes; i++) {
+   s_rotation[i] = calloc(sizeof(int), (display->pipes + 
i)->n_planes);
+
+   for (j = 0; j < (display->pipes + i)->n_planes; j++) {
+   drmModePropertyPtr prop;
+   found = kmstest_get_property(data->gfx_fd, 
display->pipes[i].planes[j].drm_plane->plane_id,
+   DRM_MODE_OBJECT_PLANE, 
"rotation", NULL, NULL, );
+   igt_assert(found);
+   igt_assert(prop->flags & DRM_MODE_PROP_BITMASK);
+
+   for (k = 0; k < prop->count_enums; k++) {
+   s_rotation[i][j] |= 1 << (prop->enums[k].value);
+   }
+
+   drmModeFreeProperty(prop);
+   }
+   }
+
+   data->supported_rotation = s_rotation;
+}
+
 static const char *plane_test_str(unsigned plane)
 {
switch (plane) {
@@ -552,15 +584,13 @@ igt_main
igt_require_pipe_crc(data.gfx_fd);
 
igt_display_init(, data.gfx_fd);
+   igt_supported_rotation_init();
}
 
for (subtest = subtests; subtest->rot; subtest++) {
igt_subtest_f("%s-rotation-%s",
  plane_test_str(subtest->plane),
  rot_test_str(subtest->rot)) {
-   igt_require(!(subtest->rot &
-   (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
-   gen >= 9);
data.rotation = subtest->rot;
test_plane_rotation(, subtest->plane, false);
}
@@ -596,9 +626,7 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
  tiling_test_str(reflect_x->tiling),
  rot_test_str(reflect_x->rot)) {
-   igt_require(gen >= 10 ||
-   (IS_CHERRYVIEW(data.devid) && 
reflect_x->rot == IGT_ROTATION_0
-&& reflect_x->tiling == 
LOCAL_I915_FORMAT_MOD_X_TILED));
+

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request
v4: Check the frequencies reported by the kernel across the entire
range.
v5: Rewrite sandwich to create a sandwich between multiple concurrent
engines.

Signed-off-by: Chris Wilson 
Cc: Praveen Paneri 
Cc: Sagar A Kamble 
Cc: Antonio Argenziano 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 691 +
 tests/meson.build  |   1 +
 4 files changed, 694 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..fc5df3d9
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,691 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 7
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(period_us);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+#define N_STEPS 10
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+ 

[Intel-gfx] [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

[Lyude Paul]

While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.

Signed-off-by: Lyude Paul 
Reviewed-by: Manasi Navare 
Cc: Manasi Navare 
Cc: Ville Syrjälä 

V2:
 - Remove accidental duplicate modeset_retry_work in intel_connector
V3:
 - Also check against eDP in intel_hpd_poll_fini() - mdnavare
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/intel_display.c  | 25 +++--
 drivers/gpu/drm/i915/intel_dp.c   | 10 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
 4 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..3b7fa430a84a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
 {
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct work_struct *work;
+   int conn_type;
 
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
}
+
+   conn_type = connector->base.connector_type;
+   if (conn_type != DRM_MODE_CONNECTOR_eDP &&
+   conn_type != DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->mst_port) {
+   work = >mst_port->modeset_retry_work;
+   } else {
+   struct intel_encoder *intel_encoder =
+   connector->encoder;
+   struct intel_dp *intel_dp;
+
+   if (!intel_encoder)
+   continue;
+
+   intel_dp = enc_to_intel_dp(_encoder->base);
+   work = _dp->modeset_retry_work;
+   }
+
+   cancel_work_sync(work);
}
drm_connector_list_iter_end(_iter);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
 static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
 {
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
+   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+   struct drm_connector *connector = _dp->attached_connector->base;
 
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
  connector->name);
 
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
+   INIT_WORK(_dp->modeset_retry_work,
  intel_dp_modeset_retry_work_fn);
 
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
intel_dp->link_rate,
 
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start 
modeset */
-   schedule_work(_connector->modeset_retry_work);
+ 

[Intel-gfx] [PATCH v3 5/5] drm/i915: Implement proper fallback training for MST

[Lyude Paul]

For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.

MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:

- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat

In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.

This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.

So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 342 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c |  42 -
 drivers/gpu/drm/i915/intel_drv.h|   8 +
 3 files changed, 302 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5645a194de92..7626652732b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
 
 #define DP_DPRX_ESI_LEN 14
 
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
 /* Compliance test status bits  */
 #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
 #define INTEL_DP_RESOLUTION_PREFERRED  (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
 }
 
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct intel_connector *intel_connector;
+   struct drm_crtc *crtc;
+   int crtc_mask = 0;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+
+   if (intel_dp->is_mst) {
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   for_each_intel_connector_iter(intel_connector, _iter) {
+   if (intel_connector->mst_port != intel_dp)
+   continue;
+
+   conn_state = intel_connector->base.state;
+   if (!conn_state->crtc)
+   continue;
+
+   crtc_mask |= drm_crtc_mask(conn_state->crtc);
+   }
+   drm_connector_list_iter_end(_iter);
+   } else {
+   connector = _dp->attached_connector->base;
+   crtc = connector->state->crtc;
+
+   if (crtc)
+   crtc_mask |= drm_crtc_mask(crtc);
+   }
+
+   return crtc_mask;
+}
+
+static bool
+intel_dp_needs_link_retrain(struct intel_dp *intel_dp,
+   const u8 esi[DP_DPRX_ESI_LEN])
+{
+   u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)];
+   const u8 *link_status = NULL;
+
+   if (intel_dp->is_mst) {
+   if (!intel_dp->active_mst_links)
+   return false;
+   if (intel_dp->mst_link_is_bad)
+   return false;
+
+   if (esi) {
+   link_status = [10];
+   } else {
+   /* We're not running from the ESI handler, so wait a
+* little bit to see if the ESI handler lets us know
+   

[Intel-gfx] [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

[Lyude Paul]

When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.

So: "lock" the bw config by only using the max DP link rate/lane count
on the first modeset for an MST topology. For every modeset following,
we instead use the last configured link bw for this topology. We only
unlock the bw config when we've detected a new MST sink.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +--
 drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
 drivers/gpu/drm/i915/intel_drv.h|  6 ++
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5abf0c95725a..5645a194de92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
 static void
 intel_dp_configure_mst(struct intel_dp *intel_dp)
 {
+   bool was_mst;
+
if (!i915_modparams.enable_dp_mst)
return;
 
if (!intel_dp->can_mst)
return;
 
+   was_mst = intel_dp->is_mst;
intel_dp->is_mst = intel_dp_can_mst(intel_dp);
 
-   if (intel_dp->is_mst)
+   if (intel_dp->is_mst) {
DRM_DEBUG_KMS("Sink is MST capable\n");
-   else
+
+   if (!was_mst)
+   intel_dp->mst_bw_locked = false;
+   } else {
DRM_DEBUG_KMS("Sink is not MST capable\n");
+   }
 
drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..c0553456b18e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
-   int lane_count, slots;
+   int lane_count, link_rate, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
@@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
  bpp);
}
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* for MST we always configure max link bw if we don't know better -
+* the spec doesn't seem to suggest we should do otherwise. But,
+* ensure it always stays consistent with the rest of this hub's
+* state.
 */
-   lane_count = intel_dp_max_lane_count(intel_dp);
+   if (intel_dp->mst_bw_locked) {
+   lane_count = intel_dp->lane_count;
+   link_rate = intel_dp->link_rate;
+   } else {
+   lane_count = intel_dp_max_lane_count(intel_dp);
+   link_rate = intel_dp_max_link_rate(intel_dp);
+   }
 
pipe_config->lane_count = lane_count;
-
pipe_config->pipe_bpp = bpp;
-
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+   pipe_config->port_clock = link_rate;
 
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
@@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
 
+   intel_dp->mst_bw_locked = true;
+
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f19dc80997f..fc338529e918 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1107,6 +1107,12 @@ struct intel_dp {
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
+   /* Set when we've already decided 

[Intel-gfx] [PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

[Lyude Paul]

Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCID allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCID allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.

Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.

This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.

Since the work of figuring out which connectors live downstream on an
MST topology and updating their link status is something that any driver
supporting MST is going to need to do in order to retrain MST links
properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper
which simply recalculates the pbn_div for a given mst topology, then
marks the link status of all connectors living in that topology as bad.
We'll make use of it in i915 later in this series.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++-
 include/drm/drm_dp_mst_helper.h   |  3 ++
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..0d6604500b29 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
 {
switch (dp_link_bw) {
default:
-   DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: 
%d)\n",
+   DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
  dp_link_bw, dp_link_count);
return false;
 
@@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
 }
 
+static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb,
+   enum drm_link_status status)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   drm_dp_set_mstb_link_status(rmstb, status);
+   drm_dp_put_mst_branch_device(rmstb);
+   }
+
+   if (port->connector)
+   port->connector->state->link_status = status;
+   }
+}
+
+/**
+ * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count
+ * for all connectors in a given MST topology
+ * @mgr: manager to set state for
+ * @dp_link_bw: The new DP link bandwidth
+ * @dp_link_count: The new DP link count
+ *
+ * This is called by the driver when it detects that the current DP link for
+ * the given topology manager is unstable, and needs to be retrained at a
+ * lower link rate.
+ *
+ * This takes care of updating the link status on all downstream connectors
+ * along with recalculating the VC payloads. The driver should send a hotplug
+ * event after calling this function to notify userspace of the link status
+ * change.
+ *
+ * RETURNS:
+ *
+ * True for success, or negative error code on failure.
+ */
+int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr 
*mgr,
+   int dp_link_bw, int dp_link_count)
+{
+   struct drm_device *dev = mgr->dev;
+   struct drm_dp_mst_branch *mst_primary;
+   int new_pbn_div;
+   int ret = 0;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+
+   if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw),
+ dp_link_count, _pbn_div)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary);
+   if (!mst_primary)
+   goto out;
+
+   DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n",
+ new_pbn_div);
+   mgr->pbn_div = new_pbn_div;
+
+   drm_dp_set_mstb_link_status(mst_primary, 

[Intel-gfx] [PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

[Lyude Paul]

Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for every driver at some point, so let's save
ourselves some trouble and just implement these atomic checks as
a single helper.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++
 include/drm/drm_dp_mst_helper.h   |   2 +
 2 files changed, 225 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d6604500b29..c4a91b1ba61b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate);
 
+static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct 
drm_atomic_state *state,
+   struct 
drm_dp_mst_topology_mgr *mgr,
+   struct 
drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_state_only_disables_mstbs(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (!ret)
+   return false;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_new_connector_state(
+   state, connector);
+   if (!conn_state)
+   continue;
+
+   crtc = conn_state->crtc;
+   if (!crtc)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   return true;
+}
+
+static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr 
*mgr,
+   struct drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_all_mstbs_disabled(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (ret <= 0)
+   return ret;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_connector_state(
+   state, connector);
+   if (IS_ERR(conn_state))
+   return PTR_ERR(conn_state);
+
+   if (conn_state->crtc)
+   return false;
+   }
+
+   /* No enabled CRTCs found */
+   return true;
+}
+
+static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ bool full_modeset)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_retrain_mstb(
+   state, mgr, rmstb, full_modeset);
+   drm_dp_put_mst_branch_device(rmstb);
+ 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: Sanitize uC (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Sanitize uC (rev2)
URL   : https://patchwork.freedesktop.org/series/39634/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +2
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3338 pass:1754 dwarn:2   dfail:0   fail:14  skip:1566 
time:11690s
shard-hswtotal:3467 pass:1766 dwarn:1   dfail:0   fail:8   skip:1691 
time:11581s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6947s
Blacklisted hosts:
shard-kbltotal:2994 pass:1678 dwarn:2   dfail:1   fail:13  skip:1293 
time:7175s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier

[Eric Anholt]

Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> Only create framebuffers with supported format/modifier combinations by
> checking that at least one plane supports the requested combination.
>
> Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
> the planes have (mostly) uniform capabilities. But I was lazy and
> didn't feel like exporting drm_plane_format_check() and hand rolling
> anything better. Also I really just wanted to come up with another
> user for drm_any_plane_has_format() ;)

I'm not excited about vc4 having error-return behavior that other
drivers don't have.  Actually, I don't really see why we should be doing
this check in fb create at all, given that you have to do so again at
atomic_check time with the specific plane.

Could you just delete the i915 fb format check code?


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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

[Lucas De Marchi]

On Fri, Mar 09, 2018 at 11:55:47AM -0800, Rodrigo Vivi wrote:
> On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote:
> > This patch creates a new macro to get PORT_TX register for any given DW.
> > This will remove the need of defining register address for each port & DW.
> 
> please squash patches 1 and 2. I had to open both simultaneously to review it
> what indicates that they should be 1 patch.
> 
> > 
> > Signed-off-by: Mahesh Kumar 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 28 
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e6a8c0ee7df1..30ef3513dc6f 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1964,6 +1964,34 @@ enum i915_power_well_id {
> > _CNL_PORT_PCS_DW1_LN0_F)
> >  #define   COMMON_KEEPER_EN (1 << 26)
> >  
> > +/* CNL Port TX registers */
> > +#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
> > +#define _CNL_PORT_TX_B_GRP_OFFSET  0x1623C0
> > +#define _CNL_PORT_TX_C_GRP_OFFSET  0x162B40
> > +#define _CNL_PORT_TX_D_GRP_OFFSET  0x162BC0
> > +#define _CNL_PORT_TX_F_GRP_OFFSET  0x162A40
> > +#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440
> > +#define _CNL_PORT_TX_B_LN0_OFFSET  0x162640
> > +#define _CNL_PORT_TX_C_LN0_OFFSET  0x162C40
> > +#define _CNL_PORT_TX_D_LN0_OFFSET  0x162E40
> > +#define _CNL_PORT_TX_F_LN0_OFFSET  0x162840
> > +#define CNL_PORT_TX_DW_GRP(port, dw)   (_PICK((port), \
> > +  _CNL_PORT_TX_AE_GRP_OFFSET, \
> > +  _CNL_PORT_TX_B_GRP_OFFSET, \
> > +  _CNL_PORT_TX_B_GRP_OFFSET, \
> > +  _CNL_PORT_TX_D_GRP_OFFSET, \
> > +  _CNL_PORT_TX_AE_GRP_OFFSET, \
> > +  _CNL_PORT_TX_F_GRP_OFFSET) + \
> > +  4*(dw))
> 
> the math is right. I'm glad someone could see some logic on all these
> numbers. I with we had a basic offset and math for all the port registers, 
> but...
> 
> > +#define CNL_PORT_TX_DW_LN0(port, dw)   (_PICK((port), \
> 
> who converts the offset to MMIO reg now?

I don't think this is supposed to be used outside the header is it?
I think it should have a underscore, because otherwise it's confusing
that CNL_PORT_TX_DW_LN0 returns an offsed and CNL_PORT_TX_DW[0-5]_LN0
return an mmio reg.

And if it's used elsewhere, maybe append _OFFSET to the macro?

Lucas De Marchi

> 
> > +  _CNL_PORT_TX_AE_LN0_OFFSET, \
> > +  _CNL_PORT_TX_B_LN0_OFFSET, \
> > +  _CNL_PORT_TX_B_LN0_OFFSET, \
> > +  _CNL_PORT_TX_D_LN0_OFFSET, \
> > +  _CNL_PORT_TX_AE_LN0_OFFSET, \
> > +  _CNL_PORT_TX_F_LN0_OFFSET) + \
> > +  4*(dw))
> > +
> >  #define _CNL_PORT_TX_DW2_GRP_AE0x162348
> >  #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
> >  #define _CNL_PORT_TX_DW2_GRP_C 0x162B48
> > -- 
> > 2.14.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-09 11:54:13)
> From: Tvrtko Ursulin 
> 
> We need to use absolute tolerance when asserting on percentages. Relative
> tolerance in this case is unfair and inaccurate since it's strictness
> varies with relative target busyness.
> 
> v2:
>  * Do not include spin batch edit and submit into measured time.
>  * Open PMU before child is in test PWM phase.
>  * No need to emit test PWM for twice as long with the new explicit
>synchroniazation via pipe.
>  * Log test duration in ms for better readability.
>  * Drop inverse assert. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  # v1
Reviewed-by: Chris Wilson 

Would be nice to add a comment now we have a reasonable suspicion:

> @@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct 
> intel_execution_engine2 *e,
>  
> igt_nsec_elapsed(_start);
> do {
> -   struct timespec t_busy = { };
> -   unsigned int target_idle_us;
> -
> -   igt_nsec_elapsed(_busy);
> +   unsigned int target_idle_us, t_busy;
>  
> /* Restart the spinbatch. */
> __rearm_spin_batch(spin);
> __submit_spin_batch(gem_fd, , e);

/*
 * Note that the submission may be delayed to a tasklet (ksoftirqd)
 * which cannot run until we sleep as we hog the cpu (we are RT).
 */

> -   measured_usleep(busy_us);
> +   t_busy = measured_usleep(busy_us);
> igt_spin_batch_end(spin);
> gem_sync(gem_fd, obj.handle);

And back to thinking how we can kick the tasklet, or kick the habit.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-09 19:15:45)
> 
> 
> On 08/03/18 17:03, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-03-09 00:45:42)
> >>
> >>
> >> On 08/03/18 09:13, Chris Wilson wrote:
> >>> Exercise some new API that allows applications to request that
> >>> individual contexts are executed within a desired frequency range.
> >>>
> >>> v2: Split single/continuous set_freq subtests
> >>>
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Paneri, Praveen 
> >>> Cc: Kamble, Sagar A 
> >>> Cc: Antonio Argenziano 
> >>> ---
> >>>tests/Makefile.am  |   1 +
> >>>tests/Makefile.sources |   1 +
> >>>tests/gem_ctx_freq.c   | 604 
> >>> +
> >>>tests/meson.build  |   1 +
> >>>4 files changed, 607 insertions(+)
> >>>create mode 100644 tests/gem_ctx_freq.c
> >>>
> >>
> 
> >>> + uint32_t cur, discard;
> >>> +
> >>> + set_freq(fd, ctx, freq, freq);
> >>> + get_freq(fd, ctx, , );
> >>
> >> igt_assert_eq(freq, cur)?
> > 
> > Not quite. The trick is that the interface is not strictly idempotent,
> > since we pass in MHz, the driver converts that into freq bins and spits
> > it back out to the nearest MHz. So cur is not strictly freq, it just
> > happens that 50MHz is the bin size on gen9.
> > 
> > The idea here is that we grab the adjusted freq from the driver to
> > validate with.
> 
> I see, can we enforce a tolerance? It feels like we are trusting the 
> kernel too much, but if that is the only thing we can do...

for (i = min; i <= max; i++)
igt_assert(min <= set_and_fetch_freq(i) <= max);

I don't think we want to constrain the ABI any more than that.
But adding that level of check seems ok.

The behaviour is we ask the kernel for a range, the kernel tells us what
range it can provide based on the request. Then we expect that the
kernel upholds that contract. (Except where we make a conflicting
contract with another party, either parallel execution or sysadmin
override.)

Binding ourselves into a tighter contract feels overly prescriptive and
not flexible enough to weasel our way out of bad situations in future.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro

[Rodrigo Vivi]

On Fri, Mar 09, 2018 at 06:28:58PM +0530, Mahesh Kumar wrote:
> This patch replaces use of remaining _MMIO_PORT6 macro and removes the
> macro.

Thanks... I hope that we don't need to bring it back for the ICL patches...

> 
> Signed-off-by: Mahesh Kumar 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7987a3f85d04..37742d774ba0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
>  #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
> -#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
> f))
> -#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f)  
> \
> - _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
>  #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
>  #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>  
> @@ -1948,20 +1945,21 @@ enum i915_power_well_id {
>  #define _CNL_PORT_PCS_DW1_LN0_C  0x162C04
>  #define _CNL_PORT_PCS_DW1_LN0_D  0x162E04
>  #define _CNL_PORT_PCS_DW1_LN0_F  0x162804
> -#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO_PORT6(port, \
> +#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO(_PICK(port, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
>   _CNL_PORT_PCS_DW1_GRP_B, \
>   _CNL_PORT_PCS_DW1_GRP_C, \
>   _CNL_PORT_PCS_DW1_GRP_D, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
> - _CNL_PORT_PCS_DW1_GRP_F)
> -#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO_PORT6(port, \
> + _CNL_PORT_PCS_DW1_GRP_F))
> +
> +#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO(_PICK(port, \
>   _CNL_PORT_PCS_DW1_LN0_AE, \
>   _CNL_PORT_PCS_DW1_LN0_B, \
>   _CNL_PORT_PCS_DW1_LN0_C, \
>   _CNL_PORT_PCS_DW1_LN0_D, \
>   _CNL_PORT_PCS_DW1_LN0_AE, \
> - _CNL_PORT_PCS_DW1_LN0_F)
> + _CNL_PORT_PCS_DW1_LN0_F))
>  #define   COMMON_KEEPER_EN   (1 << 26)
>  
>  /* CNL Port TX registers */
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

[Rodrigo Vivi]

On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote:
> This patch creates a new macro to get PORT_TX register for any given DW.
> This will remove the need of defining register address for each port & DW.

please squash patches 1 and 2. I had to open both simultaneously to review it
what indicates that they should be 1 patch.

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e6a8c0ee7df1..30ef3513dc6f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1964,6 +1964,34 @@ enum i915_power_well_id {
>   _CNL_PORT_PCS_DW1_LN0_F)
>  #define   COMMON_KEEPER_EN   (1 << 26)
>  
> +/* CNL Port TX registers */
> +#define _CNL_PORT_TX_AE_GRP_OFFSET   0x162340
> +#define _CNL_PORT_TX_B_GRP_OFFSET0x1623C0
> +#define _CNL_PORT_TX_C_GRP_OFFSET0x162B40
> +#define _CNL_PORT_TX_D_GRP_OFFSET0x162BC0
> +#define _CNL_PORT_TX_F_GRP_OFFSET0x162A40
> +#define _CNL_PORT_TX_AE_LN0_OFFSET   0x162440
> +#define _CNL_PORT_TX_B_LN0_OFFSET0x162640
> +#define _CNL_PORT_TX_C_LN0_OFFSET0x162C40
> +#define _CNL_PORT_TX_D_LN0_OFFSET0x162E40
> +#define _CNL_PORT_TX_F_LN0_OFFSET0x162840
> +#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \
> +_CNL_PORT_TX_AE_GRP_OFFSET, \
> +_CNL_PORT_TX_B_GRP_OFFSET, \
> +_CNL_PORT_TX_B_GRP_OFFSET, \
> +_CNL_PORT_TX_D_GRP_OFFSET, \
> +_CNL_PORT_TX_AE_GRP_OFFSET, \
> +_CNL_PORT_TX_F_GRP_OFFSET) + \
> +4*(dw))

the math is right. I'm glad someone could see some logic on all these
numbers. I with we had a basic offset and math for all the port registers, 
but...

> +#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \

who converts the offset to MMIO reg now?

> +_CNL_PORT_TX_AE_LN0_OFFSET, \
> +_CNL_PORT_TX_B_LN0_OFFSET, \
> +_CNL_PORT_TX_B_LN0_OFFSET, \
> +_CNL_PORT_TX_D_LN0_OFFSET, \
> +_CNL_PORT_TX_AE_LN0_OFFSET, \
> +_CNL_PORT_TX_F_LN0_OFFSET) + \
> +4*(dw))
> +
>  #define _CNL_PORT_TX_DW2_GRP_AE  0x162348
>  #define _CNL_PORT_TX_DW2_GRP_B   0x1623C8
>  #define _CNL_PORT_TX_DW2_GRP_C   0x162B48
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/4] drm: Add drm_any_plane_has_format()

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
URL   : https://patchwork.freedesktop.org/series/39700/
State : failure

== Summary ==

 Possible new issues:

Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
pass   -> SKIP   (shard-snb)
Test kms_properties:
Subgroup plane-properties-atomic:
pass   -> DMESG-WARN (shard-hsw)
Test pm_rpm:
Subgroup cursor:
pass   -> FAIL   (shard-hsw)
Subgroup cursor-dpms:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:3467 pass:1826 dwarn:1   dfail:0   fail:8   skip:1632 
time:12225s
shard-hswtotal:3467 pass:1769 dwarn:2   dfail:0   fail:3   skip:1692 
time:11554s
shard-snbtotal:3467 pass:1364 dwarn:1   dfail:0   fail:1   skip:2101 
time:6936s
Blacklisted hosts:
shard-kbltotal:3467 pass:1950 dwarn:1   dfail:1   fail:7   skip:1508 
time:9378s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

[Tvrtko Ursulin]

On 09/03/2018 18:47, Daniele Ceraolo Spurio wrote:

On 09/03/18 01:53, Tvrtko Ursulin wrote:


On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're 
running

on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 


---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated 
versus simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, 
but what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this 
scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array 
should be simpler than combined new code from this patch, especially 
if you add the test as Chris suggested. So separate engine info 
arrays would win I think overall - when considering size of text + 
size of data + size of source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


Yes, but we cannot exclude its source since selftests for separate 
tables wouldn't be needed.



add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines    160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 1247    1264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Okay I was off in my estimates. But in general I was coming from the 
angle of thinking that every new mmio base difference in this scheme 
grows the size for all engines. So if just VCS grows one new base, 
impact is multiplied by NUM_ENGINES. But maybe separate tables are 
also not a solution. Perhaps pulling out mmio_base arrays to outside 
struct engine_info in another set of static tables, so they could be 
null terminated would be best of both worlds?


struct engine_mmio_base {
 u32 gen : 8;
 u32 base : 24;
};

static const struct engine_mmio_base vcs0_mmio_bases[] = {
 { .gen = 11, .base = GEN11_BSD_RING_BASE },
 { .gen = 6, .base = GEN6_BSD_RING_BASE },
 { .gen = 4, .base = BSD_RING_BASE },
 { },
};

And then in intel_engines array, for BSD:

    {
 ...
 .mmio_bases = _mmio_bases;
 ...
    },

This way we limit data growth only to engines which change their mmio 
bases frequently.


Just an idea.



I gave this a try and the code actually grows:

add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120)

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Antonio Argenziano]

On 08/03/18 17:03, Chris Wilson wrote:

Quoting Antonio Argenziano (2018-03-09 00:45:42)



On 08/03/18 09:13, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
   tests/Makefile.am  |   1 +
   tests/Makefile.sources |   1 +
   tests/gem_ctx_freq.c   | 604 
+
   tests/meson.build  |   1 +
   4 files changed, 607 insertions(+)
   create mode 100644 tests/gem_ctx_freq.c






+ uint32_t cur, discard;
+
+ set_freq(fd, ctx, freq, freq);
+ get_freq(fd, ctx, , );


igt_assert_eq(freq, cur)?


Not quite. The trick is that the interface is not strictly idempotent,
since we pass in MHz, the driver converts that into freq bins and spits
it back out to the nearest MHz. So cur is not strictly freq, it just
happens that 50MHz is the bin size on gen9.

The idea here is that we grab the adjusted freq from the driver to
validate with.


I see, can we enforce a tolerance? It feels like we are trusting the 
kernel too much, but if that is the only thing we can do...



+static void smoketest(int fd, int timeout)
+{
+ unsigned int engines[16];


use a macro instead of magic number 16.


#define 
THIS_IS_FAR_MORE_MAGIC_THAN_A_MEANINGLESS_BARE_NUMBER_THAT_YOU_SHOULD_NOT_BE_READING_ANYTHING_INTO
 16
/rant


We call that MAX_EGINES in gem_exec_schedule ;).

Thanks,
Antonio




+static void invalid_param(int fd)
+{


gem_ctx_param is going to be upset again pretty soon ;).


Poor thing.
-Chris


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

Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

[Daniele Ceraolo Spurio]

On 08/03/18 17:33, Chris Wilson wrote:

Give the compiler a helping hand in mapping (bank,bit) to our struct
intel_engine_cs by trading object code size for data cache:

add/remove: 2/0 grow/shrink: 0/1 up/down: 48/-135 (-87)
Function old new   delta
bank1_map  -  32 +32
bank0_map  -  16 +16
gen11_irq_handler706 571-135

v2: u8 arrays for tighter packing

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_irq.c | 53 +++--
  1 file changed, 14 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..e423ec58e5d2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2762,44 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915;  \
 __fini_wedge((W)))
  
-static void

-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
  static u32
  gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
  gen11_gt_irq_handler(struct drm_i915_private * const i915,
 const u32 master_ctl)
  {
+   static const u8 bank0_map[] = {
+   [GEN11_RCS0] = RCS,
+   [GEN11_BCS]  = BCS,
+   };
+   static const u8 bank1_map[] = {
+   [GEN11_VCS(0)]  = _VCS(0),
+   [GEN11_VCS(1)]  = _VCS(1),
+   [GEN11_VCS(2)]  = _VCS(2),
+   [GEN11_VCS(3)]  = _VCS(3),
+   [GEN11_VECS(0)] = _VECS(0),
+   [GEN11_VECS(1)] = _VECS(1),
+   };
void __iomem * const regs = i915->regs;
unsigned int bank;
  
  	for (bank = 0; bank < 2; bank++) {

+   const u8 *map = bank ? bank1_map : bank0_map;
unsigned long intr_dw;
unsigned int bit;
  
@@ -2859,7 +2834,7 @@ gen11_gt_irq_handler(struct drm_i915_private * const i915,

if (unlikely(!iir))
continue;
  
-			gen11_gt_engine_irq_handler(i915, bank, bit, iir);

+   gen8_cs_irq_handler(i915->engine[map[bit]], iir);


With guc and PM interrupts we get a couple of non-engine interrupts on 
bank0, so this may not scale very well depending how we approach it.


My vote still goes to deriving class and instance from the register 
(bits 16-18 and 20-25 respectively). If we return the full register 
value from gen11_gt_engine_intr, we can then do something like:


for_each_set_bit(bit, _dw, 32) {
const u32 ident = gen11_gt_engine_intr(i915, bank, bit);
u16 iir = ident & GEN11_INTR_ENGINE_MASK;
u8 class, instance;

if (unlikely(!iir))
continue;

class = (ident >> 16) & (BIT(3) - 1);
instance = (ident >> 20) &
(BIT(GEN11_ENGINE_INSTANCE_WIDTH) - 1);

gen8_cs_irq_handler(i915->engine_class[class][instance], iir);
}

Which saves a bit more code and is more adaptable to non-engine 
interrupts IMHO, since we have the class and all non-engine interrupts 
come under class 4.


add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-137 (-137)
Function old new   delta
gen11_irq_handler   

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

[Daniele Ceraolo Spurio]

On 09/03/18 01:53, Tvrtko Ursulin wrote:


On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated versus 
simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, 
but what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array 
should be simpler than combined new code from this patch, especially 
if you add the test as Chris suggested. So separate engine info 
arrays would win I think overall - when considering size of text + 
size of data + size of source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


Yes, but we cannot exclude its source since selftests for separate 
tables wouldn't be needed.



add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines    160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 1247    1264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Okay I was off in my estimates. But in general I was coming from the 
angle of thinking that every new mmio base difference in this scheme 
grows the size for all engines. So if just VCS grows one new base, 
impact is multiplied by NUM_ENGINES. But maybe separate tables are also 
not a solution. Perhaps pulling out mmio_base arrays to outside struct 
engine_info in another set of static tables, so they could be null 
terminated would be best of both worlds?


struct engine_mmio_base {
 u32 gen : 8;
 u32 base : 24;
};

static const struct engine_mmio_base vcs0_mmio_bases[] = {
 { .gen = 11, .base = GEN11_BSD_RING_BASE },
 { .gen = 6, .base = GEN6_BSD_RING_BASE },
 { .gen = 4, .base = BSD_RING_BASE },
 { },
};

And then in intel_engines array, for BSD:

    {
 ...
 .mmio_bases = _mmio_bases;
 ...
    },

This way we limit data growth only to engines which change their mmio 
bases frequently.


Just an idea.



I gave this a try and the code actually grows:

add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120)
Function old new   

[Intel-gfx] ✓ Fi.CI.BAT: success for Add Plane Color Properties (rev3)

[Patchwork]

== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : success

== Summary ==

Series 30875v3 Add Plane Color Properties
https://patchwork.freedesktop.org/api/1.0/series/30875/revisions/3/mbox/

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-cnl-y3) fdo#103167

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:508s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  
time:582s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:411s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:506s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:515s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
f68e8e8bf982 drm/i915: Load plane color luts from atomic flip
c78c5ef1ab64 drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
d950a92e81f3 drm/i915: Enable plane color features
2ef90e536d90 drm: Define helper function for plane color enabling
25248846877a drm: Add Plane Gamma properties
a3b85657b9c9 drm: Add Plane CTM property
f7fc900392ed drm: Add Plane Degamma properties
09fc571cdbfc drm: Add Enhanced Gamma LUT precision structure

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Plane Color Properties (rev3)

[Patchwork]

== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Add Enhanced Gamma LUT precision structure
+drivers/gpu/drm/drm_plane.c:433:10: warning: symbol 
'drm_color_lut_extract_ext' was not declared. Should it be static?

Commit: drm: Add Plane Degamma properties
Okay!

Commit: drm: Add Plane CTM property
Okay!

Commit: drm: Add Plane Gamma properties
Okay!

Commit: drm: Define helper function for plane color enabling
Okay!

Commit: drm/i915: Enable plane color features
Okay!

Commit: drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Okay!

Commit: drm/i915: Load plane color luts from atomic flip
Okay!

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

[Intel-gfx] [RFC v3 8/8] drm/i915: Load plane color luts from atomic flip

[Uma Shankar]

Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 4 
 drivers/gpu/drm/i915/intel_color.c| 8 
 drivers/gpu/drm/i915/intel_drv.h  | 1 +
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..e519eab 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -231,6 +231,10 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
intel_atomic_get_new_plane_state(state, intel_plane);
struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc;
 
+   if (new_plane_state->base.color_mgmt_changed) {
+   intel_color_load_plane_luts(_plane_state->base);
+   }
+
if (new_plane_state->base.visible) {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, 
to_intel_crtc(crtc));
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index a40fafa..f67115b 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -670,6 +670,14 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state)
dev_priv->display.load_luts(crtc_state);
 }
 
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->display.load_plane_luts(plane_state);
+}
+
 int intel_color_check(struct drm_crtc *crtc,
  struct drm_crtc_state *crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0a58fce..1da5a35 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2132,6 +2132,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
 void intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.9.1

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

[Intel-gfx] [RFC v3 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms

[Uma Shankar]

Implement Plane Gamma feature for BDW and Gen9 platforms.

v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_pci.c  |  5 +++-
 drivers/gpu/drm/i915/i915_reg.h  | 24 +++
 drivers/gpu/drm/i915/intel_color.c   | 58 
 drivers/gpu/drm/i915/intel_display.c |  4 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  4 +++
 5 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26e8f5c..c14b8f3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,7 +54,10 @@
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }
 
 #define BDW_COLORS \
-   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
+   .plane_color = { .plane_degamma_lut_size = 0, \
+.plane_gamma_lut_size = 16 }
+
 #define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 #define GLK_COLORS \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86e..385c3fc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -159,6 +159,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
 #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
 
+#define _MMIO_PLANE_GAMC(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+#define _MMIO_PLANE_GAMC16(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
 #define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
@@ -9142,6 +9145,27 @@ enum skl_power_gate {
 #define PRE_CSC_GAMC_INDEX(pipe)   _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A, 
_PRE_CSC_GAMC_INDEX_B)
 #define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe, 
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
 
+/* Plane Gamma in Gen9+ */
+#define _PLANE_GAMC_1_A0x701d0
+#define _PLANE_GAMC_1_B0x711d0
+#define _PLANE_GAMC_2_A0x702d0
+#define _PLANE_GAMC_2_B0x712d0
+#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
+#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
+#define PLANE_GAMC(pipe, plane, i) \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
+
+#define _PLANE_GAMC16_1_A  0x70210
+#define _PLANE_GAMC16_1_B  0x71210
+#define _PLANE_GAMC16_2_A  0x70310
+#define _PLANE_GAMC16_2_B  0x71310
+#define _PLANE_GAMC16_1(pipe)  _PIPE(pipe, _PLANE_GAMC16_1_A, \
+_PLANE_GAMC16_1_B)
+#define _PLANE_GAMC16_2(pipe)  _PIPE(pipe, _PLANE_GAMC16_2_A, \
+_PLANE_GAMC16_2_B)
+#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
+   _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
+
 /* pipe CSC & degamma/gamma LUTs on CHV */
 #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
 #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 2d38ab8..a40fafa 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -496,6 +496,59 @@ static void broadwell_load_luts(struct drm_crtc_state 
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
 }
 
+static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
+u32 offset)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   uint32_t i, lut_size =
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
+
+   if (state->gamma_lut) {
+   struct drm_color_lut_ext *lut =
+   (struct drm_color_lut_ext *) state->gamma_lut->data;
+
+   for (i = 0; i < lut_size; i++) {
+   uint32_t word =
+   (drm_color_lut_extract(lut[i].red, 10) << 20) |
+   (drm_color_lut_extract(lut[i].green, 10) << 10) |
+   drm_color_lut_extract(lut[i].blue, 10);
+
+   I915_WRITE(PLANE_GAMC(pipe, plane, i), word);
+   }
+
+   /* Program the max register to clamp values > 1.0. */
+   i = lut_size - 1;
+   I915_WRITE(PLANE_GAMC16(pipe, plane, 0),
+  drm_color_lut_extract(lut[i].red, 16));
+  

[Intel-gfx] [RFC v3 6/8] drm/i915: Enable plane color features

[Uma Shankar]

Enable and initialize plane color features.

v2: Rebase and some cleanup

v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/intel_color.c   | 14 ++
 drivers/gpu/drm/i915/intel_device_info.h |  5 +
 drivers/gpu/drm/i915/intel_drv.h |  9 +
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..cfbb0e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -434,6 +434,11 @@ struct drm_i915_display_funcs {
 
void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
void (*load_luts)(struct drm_crtc_state *crtc_state);
+   /* Add Plane Color callbacks */
+   void (*load_plane_csc_matrix)(const struct drm_plane_state
+ *plane_state);
+   void (*load_plane_luts)(const struct drm_plane_state
+   *plane_state);
 };
 
 #define CSR_VERSION(major, minor)  ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 89ab0f7..2d38ab8 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -648,6 +648,20 @@ int intel_color_check(struct drm_crtc *crtc,
return -EINVAL;
 }
 
+void intel_plane_color_init(struct drm_plane *plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   drm_plane_color_create_prop(plane->dev, plane);
+
+   /* Enable color management support when we have degamma & gamma LUTs. */
+   if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 &&
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0)
+   drm_plane_enable_color_mgmt(plane,
+   INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size,
+   true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size);
+}
+
 void intel_color_init(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index ab5bfd3..d277926 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -167,6 +167,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   struct plane_color_luts {
+   u16 plane_degamma_lut_size;
+   u16 plane_gamma_lut_size;
+   } plane_color;
 };
 
 struct intel_driver_caps {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a7c5ad..0a58fce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -529,6 +529,14 @@ struct intel_plane_state {
 */
int scaler_id;
 
+   /*
+* Use reduced/limited/broadcast rbg range, compressing from the full
+* range fed into the crtcs.
+*/
+   bool limited_color_range;
+   /* Gamma mode programmed on the plane */
+   uint32_t gamma_mode;
+
struct drm_intel_sprite_colorkey ckey;
 };
 
@@ -2123,6 +2131,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
+void intel_plane_color_init(struct drm_plane *plane);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.9.1

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

[Intel-gfx] [RFC v3 3/8] drm: Add Plane CTM property

[Uma Shankar]

Add a blob property for plane CSC usage.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  3 +++
 drivers/gpu/drm/drm_atomic.c| 10 ++
 drivers/gpu/drm/drm_atomic_helper.c |  3 +++
 drivers/gpu/drm/drm_plane.c | 12 
 include/drm/drm_plane.h | 16 
 5 files changed, 44 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2c943f6..69b0b56 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -541,6 +541,9 @@ Plane Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: degamma_lut_size_property
 
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: ctm_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 409c058..f86384fa 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -771,6 +771,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
val, -1, );
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -837,6 +845,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+   } else if (property == plane->ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d9384fd..76b4b41 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3507,6 +3507,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->degamma_lut)
drm_property_reference_blob(state->degamma_lut);
+   if (state->ctm)
+   drm_property_reference_blob(state->ctm);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3554,6 +3556,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
 
drm_property_unreference_blob(state->degamma_lut);
+   drm_property_unreference_blob(state->ctm);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 543a693..e635b63 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -485,6 +485,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
  *
  * degamma_lut_size_property:
  * Range Property to indicate size of the plane degamma LUT.
+ *
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
  */
 int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -505,6 +510,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->degamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   plane->ctm_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_color_create_prop);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 03291b1..35535c5 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -147,6 +147,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;
 
/**
+* @ctm:
+*
+* Color transformation matrix. See 

[Intel-gfx] [RFC v3 5/8] drm: Define helper function for plane color enabling

[Uma Shankar]

Define helper function to enable Plane color features
to attach plane color properties to plane structure.

v2: Rebase

v3: Modiefied the function to use updated property names.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_plane.c  | 42 ++
 include/drm/drm_color_mgmt.h |  5 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index b837020..bbf55c5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
 }
 
 /**
+ * drm_plane_enable_color_mgmt - enable color management properties
+ * @plane: DRM Plane
+ * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
+ * @plane_has_ctm: whether to attach ctm_property for CSC matrix
+ * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a plane. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+   uint plane_degamma_lut_size,
+   bool plane_has_ctm,
+   uint plane_gamma_lut_size)
+{
+   if (plane_degamma_lut_size) {
+   drm_object_attach_property(>base,
+   plane->degamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   plane->degamma_lut_size_property,
+   plane_degamma_lut_size);
+   }
+
+   if (plane_has_ctm)
+   drm_object_attach_property(>base,
+   plane->ctm_property, 0);
+
+   if (plane_gamma_lut_size) {
+   drm_object_attach_property(>base,
+   plane->gamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   plane->gamma_lut_size_property,
+   plane_gamma_lut_size);
+   }
+}
+EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
+
+/**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
  * @plane: plane object to init
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d30..e220019 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -56,4 +56,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
  u32 supported_ranges,
  enum drm_color_encoding default_encoding,
  enum drm_color_range default_range);
+
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+uint plane_degamma_lut_size,
+bool plane_has_ctm,
+uint plane_gamma_lut_size);
 #endif
-- 
1.9.1

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

[Intel-gfx] [RFC v3 4/8] drm: Add Plane Gamma properties

[Uma Shankar]

Add plane gamma as blob property and size as a
range property.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  6 ++
 drivers/gpu/drm/drm_atomic.c|  8 
 drivers/gpu/drm/drm_atomic_helper.c |  3 +++
 drivers/gpu/drm/drm_plane.c | 23 +++
 include/drm/drm_plane.h | 24 
 5 files changed, 64 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 69b0b56..3561deb 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -544,6 +544,12 @@ Plane Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: ctm_property
 
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: gamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: gamma_lut_size_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f86384fa..d636a81 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -779,6 +779,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->gamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >gamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -847,6 +853,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+   } else if (property == plane->gamma_lut_property) {
+   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 76b4b41..3337e04 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3509,6 +3509,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
drm_property_reference_blob(state->degamma_lut);
if (state->ctm)
drm_property_reference_blob(state->ctm);
+   if (state->gamma_lut)
+   drm_property_reference_blob(state->gamma_lut);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3557,6 +3559,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
drm_property_unreference_blob(state->degamma_lut);
drm_property_unreference_blob(state->ctm);
+   drm_property_unreference_blob(state->gamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e635b63..b837020 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -490,6 +490,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
  * Blob property which allows a userspace to provide CTM coefficients
  * to do color space conversion or any other enhancement by doing a
  * matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma/tone-mapping curve using the h/w plane gamma
+ * processing engine, thereby making the content as non-linear
+ * or to perform any tone mapping operation for HDR usecases.
+ *
+ * gamma_lut_size_property:
+ * Range Property to indicate size of the plane gamma LUT.
  */
 int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -517,6 +526,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->ctm_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_GAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+   plane->gamma_lut_property = prop;
+
+   prop = 

[Intel-gfx] [RFC v3 2/8] drm: Add Plane Degamma properties

[Uma Shankar]

Add Plane Degamma as a blob property and plane degamma size as
a range property.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  9 +
 drivers/gpu/drm/drm_atomic.c| 12 
 drivers/gpu/drm/drm_atomic_helper.c |  6 ++
 drivers/gpu/drm/drm_plane.c | 35 +++
 include/drm/drm_plane.h | 26 ++
 5 files changed, 88 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 56a3780..2c943f6 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -532,6 +532,15 @@ Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
 
+Plane Color Management Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: degamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: degamma_lut_size_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d42..409c058 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;
 
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
@@ -763,6 +765,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+   } else if (property == plane->degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -826,6 +834,9 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+   } else if (property == plane->degamma_lut_property) {
+   *val = (state->degamma_lut) ?
+   state->degamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
@@ -958,6 +969,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
   drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
   drm_get_color_range_name(state->color_range));
+   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
 
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe..d9384fd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3504,6 +3504,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
state->fence = NULL;
state->commit = NULL;
+
+   if (state->degamma_lut)
+   drm_property_reference_blob(state->degamma_lut);
+   state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
 
@@ -3548,6 +3552,8 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+   drm_property_unreference_blob(state->degamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e706da6..543a693 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -474,6 +474,41 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
 }
 EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
 
+/**
+ * DOC: degamma_lut_property
+ *
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, 

[Intel-gfx] [RFC v3 0/8] Add Plane Color Properties

[Uma Shankar]

This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to another, one color space to another etc.

Usersapce can take smart blending decisions and utilize these hardware
supported plane color features to get accurate color profile. The same
can help in consistent color quality from source to panel taking
advantage of advanced color features in hardware.

These patches just add the property interfaces and enable helper
functions.

This series adds Intel Gen9 specific plane gamma feature. We can
build up and add other platform/hardware specific implementation
on top of this series

Note: This is just to get a design feedback whether these interfaces
look ok. Based on community feedback on interfaces, we will implement
IGT tests to validate plane color features. This is un-tested currently.
Also, userspace implementation to use these properties is currently not
available.

v2: Dropped legacy gamma table for plane as suggested by Maarten. Added
Gen9/BDW plane gamma feature and rebase on tot.

v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision
entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul
comments and moved plane color properties to drm_plane instead of
mode_config. Added property documentation as suggested by Daniel, Vetter.
Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.

Uma Shankar (8):
  drm: Add Enhanced Gamma LUT precision structure
  drm: Add Plane Degamma properties
  drm: Add Plane CTM property
  drm: Add Plane Gamma properties
  drm: Define helper function for plane color enabling
  drm/i915: Enable plane color features
  drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
  drm/i915: Load plane color luts from atomic flip

 Documentation/gpu/drm-kms.rst |  18 
 drivers/gpu/drm/drm_atomic.c  |  30 +++
 drivers/gpu/drm/drm_atomic_helper.c   |  12 +++
 drivers/gpu/drm/drm_plane.c   | 131 ++
 drivers/gpu/drm/i915/i915_drv.h   |   5 ++
 drivers/gpu/drm/i915/i915_pci.c   |   5 +-
 drivers/gpu/drm/i915/i915_reg.h   |  24 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +
 drivers/gpu/drm/i915/intel_color.c|  80 ++
 drivers/gpu/drm/i915/intel_device_info.h  |   5 ++
 drivers/gpu/drm/i915/intel_display.c  |   4 +
 drivers/gpu/drm/i915/intel_drv.h  |  10 +++
 drivers/gpu/drm/i915/intel_sprite.c   |   4 +
 include/drm/drm_color_mgmt.h  |   5 ++
 include/drm/drm_plane.h   |  66 +++
 include/uapi/drm/drm_mode.h   |  15 
 16 files changed, 417 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[Intel-gfx] [RFC v3 1/8] drm: Add Enhanced Gamma LUT precision structure

[Uma Shankar]

Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_plane.c | 19 +++
 include/uapi/drm/drm_mode.h | 15 +++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7..e706da6 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -426,6 +426,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_force_disable);
 
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision)
+{
+   uint32_t val = user_input;
+   uint32_t max = 0x >> (32 - bit_precision);
+
+   /* Round only if we're not using full precision. */
+   if (bit_precision < 32) {
+   val += 1UL << (32 - bit_precision - 1);
+   val >>= 32 - bit_precision;
+   }
+
+   return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract_ext);
+
 /**
  * drm_mode_plane_set_obj_prop - set the value of a property
  * @plane: drm plane object to set property value for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b5d7d9e..5f3ed88 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -615,6 +615,21 @@ struct drm_color_lut {
__u16 reserved;
 };
 
+/*
+ * Creating 32 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+   /*
+* Data is U0.32 fixed point format.
+*/
+   __u32 red;
+   __u32 green;
+   __u32 blue;
+   __u32 reserved;
+};
+
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
-- 
1.9.1

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

[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up
last week.

drm-misc-next-2018-03-09-3:
drm-misc-next for 4.17:

UAPI Changes:
 plane: Add color encoding/range properties (Jyri)
 nouveau: Replace iturbt_709 property with color_encoding property (Ville)

Core Changes:
 atomic: Move plane clipping into plane check helper (Ville)
 property: Multiple new property checks/verification (Ville)

Driver Changes:
 rockchip: Fixes & improvements for rk3399/chromebook plus (various)
 sun4i: Add H3/H5 HDMI support (Jernej)
 i915: Add support for limited/full-range ycbcr toggling (Ville)
 pl111: Add bandwidth checking/limiting (Linus)

Cc: Jernej Skrabec 
Cc: Jyri Sarha 
Cc: Ville Syrjälä 
Cc: Linus Walleij 

Cheers, Sean


The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:

  drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-09-3

for you to fetch changes up to 60beeccc72cabefcb8874fec542b3142e262b6c2:

  drm/rockchip: Don't use atomic constructs for psr (2018-03-08 23:28:53 +0100)


drm-misc-next for 4.17:

UAPI Changes:
 plane: Add color encoding/range properties (Jyri)
 nouveau: Replace iturbt_709 property with color_encoding property (Ville)

Core Changes:
 atomic: Move plane clipping into plane check helper (Ville)
 property: Multiple new property checks/verification (Ville)

Driver Changes:
 rockchip: Fixes & improvements for rk3399/chromebook plus (various)
 sun4i: Add H3/H5 HDMI support (Jernej)
 i915: Add support for limited/full-range ycbcr toggling (Ville)
 pl111: Add bandwidth checking/limiting (Linus)

Cc: Jernej Skrabec 
Cc: Jyri Sarha 
Cc: Ville Syrjälä 
Cc: Linus Walleij 


Arnd Bergmann (2):
  drm: fix drm_get_max_iomem type mismatch
  tinydrm: add backlight dependency

Baruch Siach (1):
  drm: of: simplify component probe code

Benjamin Gaignard (1):
  drm/stm: check pitch and size calculations even if !CONFIG_MMU

Chris Wilson (1):
  drm/mm: Fix caching of leftmost node in the interval tree

Christian König (2):
  drm/prime: fix potential race in drm_gem_map_detach
  drm/prime: make the pages array optional for 
drm_prime_sg_to_page_addr_arrays

Daniel Stone (1):
  drm/vc4: Advertise supported modifiers for planes

Jeffy Chen (10):
  drm/rockchip: Add device links for master and components
  drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()
  drm/bridge: analogix: Do not use device's drvdata
  drm/bridge: analogix_dp: Fix connector and encoder cleanup
  drm/rockchip: analogix_dp: Add a sanity check for 
rockchip_drm_psr_register()
  drm/rockchip: analogix_dp: reorder psr_unregister call in unbind
  drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.
  drm/rockchip: inno_hdmi: Fix error handling path.
  drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind
  drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()

Jernej Skrabec (8):
  dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
  drm/sun4i: Add support for H3 display engine
  drm/sun4i: Add support for H3 mixer 0
  drm/sun4i: Fix polarity configuration for DW HDMI PHY
  drm/sun4i: Add support for variants to DW HDMI PHY
  drm/sun4i: Move and expand DW HDMI PHY register macros
  drm/sun4i: Add support for H3 HDMI PHY variant
  drm/sun4i: Allow building on arm64

Joe Moriarty (2):
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

Jyri Sarha (1):
  drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

Linus Walleij (7):
  drm/panel: Fix ARM Versatile panel clocks
  bridge: Elaborate a bit on dumb VGA bridges in Kconfig
  drm: simple_kms_helper: Fix .mode_valid() documentation
  drm/pl111: Make the default BPP a per-variant variable
  drm/pl111: Handle the RealView variant separately
  drm/bridge: sii902x: Retry status read after DDI I2C
  drm/pl111: Use max memory bandwidth for resolution

Maarten Lankhorst (1):
  drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

Marek Szyprowski (2):
  drm/bridge: analogix_dp: Postpone enabling runtime power management
  drm/bridge: analogix_dp: Don't create useless connectors

Maxime Ripard (4):
  drm/sun4i: backend: Assign the pipes automatically
  drm/sun4i: Remove the plane description structure
  drm/sun4i: backend: Make zpos configurable
  drm/sun4i: 

[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support

[Patchwork]

== Series Details ==

Series: Add NV12 support
URL   : https://patchwork.freedesktop.org/series/39670/
State : success

== Summary ==

Series 39670v1 Add NV12 support
https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:519s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:472s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:503s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:520s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
749e844cfff1 drm/i915: Display WA 827
e6555c173591 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
8ca8611bf6b0 drm/i915: Add NV12 support to intel_framebuffer_init
7531f149aa78 drm/i915: Add NV12 as supported format for sprite plane
0534f14fde9e drm/i915: Add NV12 as supported format for primary plane
614617ba6b50 drm/i915: Upscale scaler max scale for NV12
5f5596d38394 drm/i915: Update format_is_yuv() to include NV12
3ff123d5f468 drm/i915: Set scaler mode for NV12
42e536b29b4c drm/i915/skl: split skl_compute_ddb function
593a17e31721 drm/i915/skl+: nv12 workaround disable WM level 1-7
e007283a4b5a drm/i915/skl+: make sure higher latency level has higher wm value
02129257ecd5 drm/i915/skl+: pass skl_wm_level struct to wm compute func
7cd21a2a8f90 drm/i915/skl+: NV12 related changes for WM
883e1369e215 drm/i915/skl+: support verification of DDB HW state for NV12
0992f20891ee drm/i915/skl+: add NV12 in skl_format_to_fourcc
5453c9d856f6 drm/i915/skl+: refactor WM calculation for NV12
48faccbb411f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/issues.html
___
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 [CI,1/4] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39710/
State : success

== Summary ==

Series 39710v1 series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control
https://patchwork.freedesktop.org/api/1.0/series/39710/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:482s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:409s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:508s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:512s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
59dcd0fe0c8f HAX: Enable GuC for CI
d4bc41a8a9d6 drm/i915/guc: Move GuC notification handling to separate function
9ab68c44f5e7 drm/i915/guc: Create common entry points for log 
register/unregister
e0ff1976b21c drm/i915/guc: Tidy guc_log_control

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-09 17:24:33)
> 
> On 08/03/2018 14:07, Chris Wilson wrote:
> > There is some redundancy between dma_fence->ops->enable_signaling (via
> > i915_fence_enable_signaling) and our backend,
> > intel_engine_enable_signaling() in that both levels recheck the fence
> > status multiple times. If we convert intel_engine_enable_signaling() to
> > return the information desired by dma_fence->ops->enable_signaling, we
> > can reduce i915_fence_enable_signaling to a simple stub and avoid
> > trying to reinterpret the same information.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > Cc: Michal Winiarski 
> > ---
> >   drivers/gpu/drm/i915/i915_request.c  |  6 +-
> >   drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 +
> >   drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
> >   3 files changed, 15 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index d437beac3969..2a841800d4cf 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence)
> >   
> >   static bool i915_fence_enable_signaling(struct dma_fence *fence)
> >   {
> > - if (i915_fence_signaled(fence))
> > - return false;
> 
> This was based on hws seqno check...
> 
> > -
> > - intel_engine_enable_signaling(to_request(fence), true);
> > - return !i915_fence_signaled(fence);
> > + return intel_engine_enable_signaling(to_request(fence), true);
> >   }

> > @@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct 
> > i915_request *request, bool wakeup)
> >*/
> >   spin_lock(>rb_lock);
> >   insert_signal(b, request, seqno);
> > - wakeup &= __intel_engine_add_wait(engine, >signaling.wait);
> > + wakeup &= __intel_engine_add_wait(engine, wait);
> >   spin_unlock(>rb_lock);
> >   
> > - if (wakeup)
> > + if (wakeup) {
> >   wake_up_process(b->signaler);
> > + return !intel_wait_complete(wait);
> 
> ... and would now be based on breadcrumb waiter waking up and removing 
> itself from the tree.

And don't forget the same HWS check before the waiter is inserted. So we
have the same guards as before, just inside yet another spinlock.

> So some potential latency where it wasn't before, well, enable-disable 
> signalling cycles actually.

The extra steps would be the insert_signal(). Fwiw, we could reorder the
insert_signal() but frankly this, dma_fence enable signaling of an
inflight request, is not a fast path. More commonly we will be enabling
signaling on the request as it is submitted (where wakeup is false and
we know that the HWS cannot be complete).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for CNL port refactoring (rev2)

[Patchwork]

== Series Details ==

Series: CNL port refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/38334/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_vblank:
Subgroup pipe-a-ts-continuation-dpms-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3381 pass:1778 dwarn:1   dfail:0   fail:9   skip:1591 
time:11749s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11736s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6959s
Blacklisted hosts:
shard-kbltotal:3390 pass:1905 dwarn:1   dfail:0   fail:9   skip:1473 
time:8543s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-09 17:06:45)
> 
> On 09/03/2018 13:46, Chris Wilson wrote:
> > Exercise some new API that allows applications to request that
> > individual contexts are executed within a desired frequency range.
> > 
> > v2: Split single/continuous set_freq subtests
> > v3: Do an up/down ramp for individual freq request, check nothing
> > changes after each invalid request
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Paneri, Praveen 
> > Cc: Kamble, Sagar A 
> > Cc: Antonio Argenziano 
> > ---
> >   tests/Makefile.am  |   1 +
> >   tests/Makefile.sources |   1 +
> >   tests/gem_ctx_freq.c   | 648 
> > +
> >   tests/meson.build  |   1 +
> >   4 files changed, 651 insertions(+)
> >   create mode 100644 tests/gem_ctx_freq.c
> > 
> 
> [snip]
> 
> > +static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
> > +{
> > + const struct test {
> > + uint32_t min, max;
> > + } tests[] = {
> > + { min - 50, max - 50 },
> > + { min - 50, max },
> > + { min - 50, max + 50 },
> > + { min, max + 50 },
> > + { min + 50, max + 50 },
> > +
> > + { min - 50, min - 50 },
> > +
> > + { min - 50, min },
> > + { min + 50, min },
> > + { min, min - 50 },
> > +
> > + { max + 50, max },
> > + { max, max + 50 },
> > + { max, max - 50 },
> > +
> > + { max + 50, max + 50 },
> 
> Is unprivileged "{ max, max }" allowed? In other words pin to max 
> frequency by anyone? If so, what happens when all userspace learns about 
> this and wants to use it just so to be lower latency than the other guy?

I've gone with allow, since (a) it's always constrained by the global
user imposed limit and (b) userspace can already keep the gpu at max
frequency by load. At the start I opined that only CAP_SYS_NICE would be
allowed to raise the frequency bounds, but realised that in practice it
is immaterial as they were already running at max frequency anyway.

/*
 * As we constrain the frequency request from the
 * context (application) by the sysadmin imposed limits,
 * it is reasonable to allow the application to
 * specify its preferred range within those limits.
 * That is we do not need to restrict requesting
 * a higher frequency to privileged (CAP_SYS_NICE)
 * processes.
 */

> Or even on our integrated graphics, such userspace would unwisely take 
> away power budget from the CPU. Or could it even harm itself by 
> triggering too much thermal throttling and run slower than if it let the 
> balance be controlled by the system?

It will indeed. Running at max frequency is not a sensible idea for
anything but a few applications (dare we say miners? ;). I thought
compositors might benefit from reduced latency by starting at max,
https://bugs.freedesktop.org/show_bug.cgi?id=102199
but realistically they care more about power consumption and gain most of
the latency reduction from priority sorting and preemption.

On the bright side, we give them a loaded gun with which they can shoot
both feet off. They have to be confident that they do know their
behaviour better than the hw (which for a few will be true). We give
them the means to do so, we do not say it is wise.

> Or will this be tied with the cgroup work to allow only clients allowed 
> by sysadmin to do this?

That's what I think as well. I think we will end up with everything that
can be adjusted via CONTEXT_SETPARAM will be constrained by cgroup.

Once again, we can only look at the integration of schedfreq and CFS as
being the direction the GPUs will also eventually take.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

[Tvrtko Ursulin]

On 08/03/2018 14:07, Chris Wilson wrote:

There is some redundancy between dma_fence->ops->enable_signaling (via
i915_fence_enable_signaling) and our backend,
intel_engine_enable_signaling() in that both levels recheck the fence
status multiple times. If we convert intel_engine_enable_signaling() to
return the information desired by dma_fence->ops->enable_signaling, we
can reduce i915_fence_enable_signaling to a simple stub and avoid
trying to reinterpret the same information.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Michal Winiarski 
---
  drivers/gpu/drm/i915/i915_request.c  |  6 +-
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 +
  drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
  3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index d437beac3969..2a841800d4cf 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence)
  
  static bool i915_fence_enable_signaling(struct dma_fence *fence)

  {
-   if (i915_fence_signaled(fence))
-   return false;


This was based on hws seqno check...


-
-   intel_engine_enable_signaling(to_request(fence), true);
-   return !i915_fence_signaled(fence);
+   return intel_engine_enable_signaling(to_request(fence), true);
  }
  
  static signed long i915_fence_wait(struct dma_fence *fence,

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 1f79e7a47433..671a6d61e29d 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -730,10 +730,11 @@ static void insert_signal(struct intel_breadcrumbs *b,
list_add(>signaling.link, >signaling.link);
  }
  
-void intel_engine_enable_signaling(struct i915_request *request, bool wakeup)

+bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup)
  {
struct intel_engine_cs *engine = request->engine;
struct intel_breadcrumbs *b = >breadcrumbs;
+   struct intel_wait *wait = >signaling.wait;
u32 seqno;
  
  	/*

@@ -750,12 +751,12 @@ void intel_engine_enable_signaling(struct i915_request 
*request, bool wakeup)
  
  	seqno = i915_request_global_seqno(request);

if (!seqno) /* will be enabled later upon execution */
-   return;
+   return true;
  
-	GEM_BUG_ON(request->signaling.wait.seqno);

-   request->signaling.wait.tsk = b->signaler;
-   request->signaling.wait.request = request;
-   request->signaling.wait.seqno = seqno;
+   GEM_BUG_ON(wait->seqno);
+   wait->tsk = b->signaler;
+   wait->request = request;
+   wait->seqno = seqno;
  
  	/*

 * Add ourselves into the list of waiters, but registering our
@@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct i915_request 
*request, bool wakeup)
 */
spin_lock(>rb_lock);
insert_signal(b, request, seqno);
-   wakeup &= __intel_engine_add_wait(engine, >signaling.wait);
+   wakeup &= __intel_engine_add_wait(engine, wait);
spin_unlock(>rb_lock);
  
-	if (wakeup)

+   if (wakeup) {
wake_up_process(b->signaler);
+   return !intel_wait_complete(wait);


... and would now be based on breadcrumb waiter waking up and removing 
itself from the tree.


So some potential latency where it wasn't before, well, enable-disable 
signalling cycles actually.


If I got it right.. breadcrumbs code confuses me massively these days.

Regards,

Tvrtko


+   }
+
+   return true;
  }
  
  void intel_engine_cancel_signaling(struct i915_request *request)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0320c2c4cfba..aa34b2ff04bc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -939,7 +939,7 @@ bool intel_engine_add_wait(struct intel_engine_cs *engine,
   struct intel_wait *wait);
  void intel_engine_remove_wait(struct intel_engine_cs *engine,
  struct intel_wait *wait);
-void intel_engine_enable_signaling(struct i915_request *request, bool wakeup);
+bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup);
  void intel_engine_cancel_signaling(struct i915_request *request);
  
  static inline bool intel_engine_has_waiter(const struct intel_engine_cs *engine)



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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: misc fixes in headers (RESEND)

[Patchwork]

== Series Details ==

Series: drm/i915: misc fixes in headers (RESEND)
URL   : https://patchwork.freedesktop.org/series/39589/
State : success

== Summary ==

Series 39589v1 drm/i915: misc fixes in headers (RESEND)
https://patchwork.freedesktop.org/api/1.0/series/39589/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:424s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:509s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:481s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:592s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:422s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:525s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:514s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:511s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
2b518e87976b drm/i915: Move i915_gpu_error into its own header
f2969e101bac drm/i915: Make header i915_pmu.h more robust
87481ecfb862 drm/i915: Change parameters order in i915_gem_batch_pool_init
c055bfc9c223 drm/i915: Include i915_reg.h in intel_ringbuffer.h

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Tvrtko Ursulin]

On 09/03/2018 13:46, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
  tests/Makefile.am  |   1 +
  tests/Makefile.sources |   1 +
  tests/gem_ctx_freq.c   | 648 +
  tests/meson.build  |   1 +
  4 files changed, 651 insertions(+)
  create mode 100644 tests/gem_ctx_freq.c



[snip]


+static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   const struct test {
+   uint32_t min, max;
+   } tests[] = {
+   { min - 50, max - 50 },
+   { min - 50, max },
+   { min - 50, max + 50 },
+   { min, max + 50 },
+   { min + 50, max + 50 },
+
+   { min - 50, min - 50 },
+
+   { min - 50, min },
+   { min + 50, min },
+   { min, min - 50 },
+
+   { max + 50, max },
+   { max, max + 50 },
+   { max, max - 50 },
+
+   { max + 50, max + 50 },


Is unprivileged "{ max, max }" allowed? In other words pin to max 
frequency by anyone? If so, what happens when all userspace learns about 
this and wants to use it just so to be lower latency than the other guy?


Or even on our integrated graphics, such userspace would unwisely take 
away power budget from the CPU. Or could it even harm itself by 
triggering too much thermal throttling and run slower than if it let the 
balance be controlled by the system?


Or will this be tied with the cgroup work to allow only clients allowed 
by sysadmin to do this?


Regards,

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

[Intel-gfx] [CI 1/4] drm/i915/guc: Tidy guc_log_control

[Chris Wilson]

From: Michał Winiarski 

We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.

v2: Tidy macros, keep debug messages, use helper var for enable,
correct typo (Michał)
Fix incorrect input validaction (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-1-michal.winiar...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 ++---
 drivers/gpu/drm/i915/intel_guc_log.c | 80 +---
 drivers/gpu/drm/i915/intel_guc_log.h |  3 +-
 3 files changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 34d12522a1da..c4cc8fef11a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2499,13 +2499,10 @@ static int i915_guc_log_control_get(void *data, u64 
*val)
 {
struct drm_i915_private *dev_priv = data;
 
-   if (!HAS_GUC(dev_priv))
+   if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   if (!dev_priv->guc.log.vma)
-   return -EINVAL;
-
-   *val = i915_modparams.guc_log_level;
+   *val = intel_guc_log_control_get(_priv->guc);
 
return 0;
 }
@@ -2514,10 +2511,10 @@ static int i915_guc_log_control_set(void *data, u64 val)
 {
struct drm_i915_private *dev_priv = data;
 
-   if (!HAS_GUC(dev_priv))
+   if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   return intel_guc_log_control(_priv->guc, val);
+   return intel_guc_log_control_set(_priv->guc, val);
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index c0c2e7d1c7d7..7e59fb07b06b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -659,51 +659,63 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>log.vma);
 }
 
-int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
+int intel_guc_log_control_get(struct intel_guc *guc)
+{
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
+
+   return i915_modparams.guc_log_level;
+}
+
+#define GUC_LOG_LEVEL_DISABLED 0
+#define LOG_LEVEL_TO_ENABLED(x)((x) > 0)
+#define LOG_LEVEL_TO_VERBOSITY(x) ({   \
+   typeof(x) _x = (x); \
+   LOG_LEVEL_TO_ENABLED(_x) ? _x - 1 : 0;  \
+})
+#define VERBOSITY_TO_LOG_LEVEL(x)  ((x) + 1)
+int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   bool enable_logging = control_val > 0;
-   u32 verbosity;
+   bool enabled = LOG_LEVEL_TO_ENABLED(val);
int ret;
 
-   if (!guc->log.vma)
-   return -ENODEV;
+   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
 
-   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
-   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
+   /*
+* GuC is recognizing log levels starting from 0 to max, we're using 0
+* as indication that logging should be disabled.
+*/
+   if (val < GUC_LOG_LEVEL_DISABLED ||
+   val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX))
return -EINVAL;
 
-   /* This combination doesn't make sense & won't have any effect */
-   if (!enable_logging && !i915_modparams.guc_log_level)
-   return 0;
+   mutex_lock(_priv->drm.struct_mutex);
 
-   verbosity = enable_logging ? control_val - 1 : 0;
+   if (i915_modparams.guc_log_level == val) {
+   ret = 0;
+   goto out_unlock;
+   }
 
-   ret = mutex_lock_interruptible(_priv->drm.struct_mutex);
-   if (ret)
-   return ret;
intel_runtime_pm_get(dev_priv);
-   ret = guc_log_control(guc, enable_logging, verbosity);
+   ret = guc_log_control(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   if (ret < 0) {
-   DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
-   return ret;
+   if (ret) {
+   DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret);
+   goto out_unlock;
}
 
-   if (enable_logging) {
-   i915_modparams.guc_log_level = 1 + verbosity;
+   

[Intel-gfx] [CI 2/4] drm/i915/guc: Create common entry points for log register/unregister

[Chris Wilson]

From: Michał Winiarski 

We have many functions responsible for allocating different parts of
GuC log runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.

v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał)
s/dev_priv/i915 (Sagar)
Make guc_log_relay_* static (sparse)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-2-michal.winiar...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.c  |   6 +-
 drivers/gpu/drm/i915/intel_guc_log.c | 156 ++-
 drivers/gpu/drm/i915/intel_guc_log.h |   6 +-
 drivers/gpu/drm/i915/intel_uc.c  |  41 +
 drivers/gpu/drm/i915/intel_uc.h  |   2 +
 5 files changed, 95 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de45644d..987c6770d1a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1238,9 +1238,11 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   i915_guc_log_register(dev_priv);
i915_setup_sysfs(dev_priv);
 
+   /* Depends on debugfs having been initialized */
+   intel_uc_register(dev_priv);
+
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
} else
@@ -1298,7 +1300,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_pmu_unregister(dev_priv);
 
i915_teardown_sysfs(dev_priv);
-   i915_guc_log_unregister(dev_priv);
+   intel_uc_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
 
i915_gem_shrinker_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7e59fb07b06b..90b395f34808 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,7 +443,7 @@ void intel_guc_log_init_early(struct intel_guc *guc)
INIT_WORK(>log.runtime.flush_work, capture_logs_work);
 }
 
-int intel_guc_log_relay_create(struct intel_guc *guc)
+static int guc_log_relay_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
@@ -496,7 +496,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc)
return ret;
 }
 
-void intel_guc_log_relay_destroy(struct intel_guc *guc)
+static void guc_log_relay_destroy(struct intel_guc *guc)
 {
mutex_lock(>log.runtime.relay_lock);
 
@@ -514,49 +514,6 @@ void intel_guc_log_relay_destroy(struct intel_guc *guc)
mutex_unlock(>log.runtime.relay_lock);
 }
 
-static int guc_log_late_setup(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   int ret;
-
-   if (!guc_log_has_runtime(guc)) {
-   /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/
-   ret = intel_guc_log_relay_create(guc);
-   if (ret)
-   goto err;
-
-   mutex_lock(_priv->drm.struct_mutex);
-   intel_runtime_pm_get(dev_priv);
-   ret = guc_log_runtime_create(guc);
-   intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   if (ret)
-   goto err_relay;
-   }
-
-   ret = guc_log_relay_file_create(guc);
-   if (ret)
-   goto err_runtime;
-
-   return 0;
-
-err_runtime:
-   mutex_lock(_priv->drm.struct_mutex);
-   guc_log_runtime_destroy(guc);
-   mutex_unlock(_priv->drm.struct_mutex);
-err_relay:
-   intel_guc_log_relay_destroy(guc);
-err:
-   /* logging will remain off */
-   i915_modparams.guc_log_level = 0;
-   return ret;
-}
-
 static void guc_log_capture_logs(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,16 +533,6 @@ static void guc_flush_logs(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   if (!USES_GUC_SUBMISSION(dev_priv) || !i915_modparams.guc_log_level)
-   return;
-
-   /* First disable the interrupts, will be renabled afterwards */
-   

[Intel-gfx] [CI 3/4] drm/i915/guc: Move GuC notification handling to separate function

[Chris Wilson]

From: Michal Wajdeczko 

To allow future code reuse. While here, fix comment style.

v2: Notifications are a separate thing - rename the handler (Sagar)

Suggested-by: Oscar Mateo 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-3-michal.winiar...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c  | 33 ++---
 drivers/gpu/drm/i915/intel_guc.c | 37 +
 drivers/gpu/drm/i915/intel_guc.h |  1 +
 3 files changed, 40 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..828f3104488c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1766,37 +1766,8 @@ static void gen6_rps_irq_handler(struct drm_i915_private 
*dev_priv, u32 pm_iir)
 
 static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir)
 {
-   if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
-   /* Sample the log buffer flush related bits & clear them out now
-* itself from the message identity register to minimize the
-* probability of losing a flush interrupt, when there are back
-* to back flush interrupts.
-* There can be a new flush interrupt, for different log buffer
-* type (like for ISR), whilst Host is handling one (for DPC).
-* Since same bit is used in message register for ISR & DPC, it
-* could happen that GuC sets the bit for 2nd interrupt but Host
-* clears out the bit on handling the 1st interrupt.
-*/
-   u32 msg, flush;
-
-   msg = I915_READ(SOFT_SCRATCH(15));
-   flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
-  INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
-   if (flush) {
-   /* Clear the message bits that are handled */
-   I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
-
-   /* Handle flush interrupt in bottom half */
-   queue_work(dev_priv->guc.log.runtime.flush_wq,
-  _priv->guc.log.runtime.flush_work);
-
-   dev_priv->guc.log.flush_interrupt_count++;
-   } else {
-   /* Not clearing of unhandled event bits won't result in
-* re-triggering of the interrupt.
-*/
-   }
-   }
+   if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT)
+   intel_guc_to_host_event_handler(_priv->guc);
 }
 
 static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..25f92291fd40 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -364,6 +364,43 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
return ret;
 }
 
+void intel_guc_to_host_event_handler(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   u32 msg, flush;
+
+   /*
+* Sample the log buffer flush related bits & clear them out now
+* itself from the message identity register to minimize the
+* probability of losing a flush interrupt, when there are back
+* to back flush interrupts.
+* There can be a new flush interrupt, for different log buffer
+* type (like for ISR), whilst Host is handling one (for DPC).
+* Since same bit is used in message register for ISR & DPC, it
+* could happen that GuC sets the bit for 2nd interrupt but Host
+* clears out the bit on handling the 1st interrupt.
+*/
+
+   msg = I915_READ(SOFT_SCRATCH(15));
+   flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
+  INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
+   if (flush) {
+   /* Clear the message bits that are handled */
+   I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
+
+   /* Handle flush interrupt in bottom half */
+   queue_work(guc->log.runtime.flush_wq,
+  >log.runtime.flush_work);
+
+   guc->log.flush_interrupt_count++;
+   } else {
+   /*
+* Not clearing of unhandled event bits won't result in
+* re-triggering of the 

[Intel-gfx] [CI 4/4] HAX: Enable GuC for CI

[Chris Wilson]

From: Michal Wajdeczko 

v2: except running with HYPERVISOR
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 1c1a00df010b..cfa21f6058a5 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

[Chris Wilson]

Quoting Michał Winiarski (2018-03-09 16:30:42)
> On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote:
> > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski
> >  wrote:
> > 
> > > Those two concepts are really separate. Since GuC is writing data into
> > > its own buffer and we even provide a way for userspace to read directly
> > > from it using i915_guc_log_dump debugfs, there's no real reason to tie
> > > log level with relay creation.
> > > Let's create a separate debugfs, giving userspace a way to create a
> > > relay on demand, when it wants to read a continuous log rather than a
> > > snapshot.
> > > 
> > > v2: Don't touch guc_log_level on relay creation error, adjust locking
> > > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
> > > Use struct_mutex rather than runtime.lock for set_log_level
> > > 
> > > Signed-off-by: Michał Winiarski 
> > > Cc: Chris Wilson 
> > > Cc: Daniele Ceraolo Spurio 
> > > Cc: Sagar Arun Kamble 
> > > Cc: Michal Wajdeczko 
> > > ---
> > 
> > /snip/
> > 
> > > diff --git a/drivers/gpu/drm/i915/intel_uc.c
> > > b/drivers/gpu/drm/i915/intel_uc.c
> > > index 90d2f38e22c9..abce0e38528a 100644
> > > --- a/drivers/gpu/drm/i915/intel_uc.c
> > > +++ b/drivers/gpu/drm/i915/intel_uc.c
> > > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc
> > > *guc)
> > > i915_gem_object_put(guc->load_err_log);
> > >  }
> > > -int intel_uc_register(struct drm_i915_private *i915)
> > > -{
> > > -   int ret = 0;
> > > -
> > > -   if (!USES_GUC(i915))
> > > -   return 0;
> > > -
> > > -   if (i915_modparams.guc_log_level)
> > > -   ret = intel_guc_log_register(>guc);
> > > -
> > > -   return ret;
> > > -}
> > > -
> > > -void intel_uc_unregister(struct drm_i915_private *i915)
> > > -{
> > > -   if (!USES_GUC(i915))
> > > -   return;
> > > -
> > > -   if (i915_modparams.guc_log_level)
> > > -   intel_guc_log_unregister(>guc);
> > > -}
> > > -
> > >  static int guc_enable_communication(struct intel_guc *guc)
> > >  {
> > > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > > diff --git a/drivers/gpu/drm/i915/intel_uc.h
> > > b/drivers/gpu/drm/i915/intel_uc.h
> > > index d6af984cd789..f76d51d1ce70 100644
> > > --- a/drivers/gpu/drm/i915/intel_uc.h
> > > +++ b/drivers/gpu/drm/i915/intel_uc.h
> > > @@ -31,8 +31,6 @@
> > >  void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
> > >  void intel_uc_init_early(struct drm_i915_private *dev_priv);
> > >  void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
> > > -int intel_uc_register(struct drm_i915_private *dev_priv);
> > > -void intel_uc_unregister(struct drm_i915_private *dev_priv);
> > 
> > hmm, it looks that timelines of these two functions were very short
> > (from patch 2 till patch 8) - so maybe by doing some patch re-order
> > can we fully skip them ?
> 
> I could drop patch 2 entirely and go straight to the decoupling - but that 
> means
> more code movement overall and way more content in this one.
> 
> I don't really see a better split (but since I'm the author I'm biased :) ).
> I'm open for suggestions.

I can settle the argument by grabbing the first 3 patches as code
movement, before we get into the details. Ok?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Sanitize uC (rev2)
URL   : https://patchwork.freedesktop.org/series/39634/
State : success

== Summary ==

Series 39634v2 drm/i915/uc: Sanitize uC
https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/2/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-guc) fdo#103191

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:428s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:480s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:538s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-guc   total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:511s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:524s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
ae3a1d7d7e62 HAX: Enable GuC for CI
11f207630fb0 drm/i915/uc: Sanitize uC together with GEM
70549b8cf2c8 drm/i915/uc: Sanitize uC options early

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

[Michał Winiarski]

On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote:
> On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski
>  wrote:
> 
> > Those two concepts are really separate. Since GuC is writing data into
> > its own buffer and we even provide a way for userspace to read directly
> > from it using i915_guc_log_dump debugfs, there's no real reason to tie
> > log level with relay creation.
> > Let's create a separate debugfs, giving userspace a way to create a
> > relay on demand, when it wants to read a continuous log rather than a
> > snapshot.
> > 
> > v2: Don't touch guc_log_level on relay creation error, adjust locking
> > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
> > Use struct_mutex rather than runtime.lock for set_log_level
> > 
> > Signed-off-by: Michał Winiarski 
> > Cc: Chris Wilson 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Sagar Arun Kamble 
> > Cc: Michal Wajdeczko 
> > ---
> 
> /snip/
> 
> > diff --git a/drivers/gpu/drm/i915/intel_uc.c
> > b/drivers/gpu/drm/i915/intel_uc.c
> > index 90d2f38e22c9..abce0e38528a 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/intel_uc.c
> > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc
> > *guc)
> > i915_gem_object_put(guc->load_err_log);
> >  }
> > -int intel_uc_register(struct drm_i915_private *i915)
> > -{
> > -   int ret = 0;
> > -
> > -   if (!USES_GUC(i915))
> > -   return 0;
> > -
> > -   if (i915_modparams.guc_log_level)
> > -   ret = intel_guc_log_register(>guc);
> > -
> > -   return ret;
> > -}
> > -
> > -void intel_uc_unregister(struct drm_i915_private *i915)
> > -{
> > -   if (!USES_GUC(i915))
> > -   return;
> > -
> > -   if (i915_modparams.guc_log_level)
> > -   intel_guc_log_unregister(>guc);
> > -}
> > -
> >  static int guc_enable_communication(struct intel_guc *guc)
> >  {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > diff --git a/drivers/gpu/drm/i915/intel_uc.h
> > b/drivers/gpu/drm/i915/intel_uc.h
> > index d6af984cd789..f76d51d1ce70 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.h
> > +++ b/drivers/gpu/drm/i915/intel_uc.h
> > @@ -31,8 +31,6 @@
> >  void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
> >  void intel_uc_init_early(struct drm_i915_private *dev_priv);
> >  void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
> > -int intel_uc_register(struct drm_i915_private *dev_priv);
> > -void intel_uc_unregister(struct drm_i915_private *dev_priv);
> 
> hmm, it looks that timelines of these two functions were very short
> (from patch 2 till patch 8) - so maybe by doing some patch re-order
> can we fully skip them ?

I could drop patch 2 entirely and go straight to the decoupling - but that means
more code movement overall and way more content in this one.

I don't really see a better split (but since I'm the author I'm biased :) ).
I'm open for suggestions.

-Michał

> 
> >  void intel_uc_init_fw(struct drm_i915_private *dev_priv);
> >  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
> >  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Fix audio issue on BXT (rev2)

[Patchwork]

== Series Details ==

Series: drm: i915: Fix audio issue on BXT (rev2)
URL   : https://patchwork.freedesktop.org/series/35955/
State : failure

== Summary ==

Series 35955v2 drm: i915: Fix audio issue on BXT
https://patchwork.freedesktop.org/api/1.0/series/35955/revisions/2/mbox/

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> INCOMPLETE (fi-bsw-n3050)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-hsw-4770)

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:224  pass:194  dwarn:0   dfail:0   fail:0   skip:29 
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:245  pass:221  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:537s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:516s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:508s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:518s
fi-bxt-dsi failed to collect. IGT log at Patchwork_8292/fi-bxt-dsi/run0.log

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
c90b8bf68afb drm: i915: Fix audio issue on BXT

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8292/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: misc fixes in headers (RESEND)

[Arkadiusz Hiler]

On Thu, Mar 08, 2018 at 04:22:55PM +0100, Michal Wajdeczko wrote:
> On Thu, 08 Mar 2018 13:58:48 +0100, Petri Latvala 
> wrote:
> 
> > On Thu, Mar 08, 2018 at 02:20:41PM +0200, Jani Nikula wrote:
> > > On Thu, 08 Mar 2018, Chris Wilson  wrote:
> > > > Quoting Michal Wajdeczko (2018-03-08 09:50:33)
> > > >> This is a resend, to make patchwork happy.
> > > >> All patches already been reviewed.
> > > >
> > > > It's still being ignored. :(
> > > 
> > > At least patchwork detected this as a series [1], often that's the
> > > problem.
> > 
> > 
> > Patchwork is not seeing patch 4/4, and due to its weird logic, it's
> > still waiting for it instead of considering the series "incomplete".
> > 
> > Looking at the series page, it doesn't even have a revision number.
> > 
> > This causes the pw REST api to show the series as one with 0 patches
> > when listing series, there's no series-new-revision event (CI is
> > watching that), and it also causes the below:
> > 
> > > I tried to start testing manually from patchwork, it gives me "failed!".
> > 
> > 
> > Arek checked the logs and patch 4/4 hasn't been received by pw at
> > all. Maybe it's still on the way, who knows.
> > 
> 
> I'm not sure if this is related, but list archive decided to assign
> patch 1/4 [1] to old series [2] instead new one [3]
> 
> [1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158080.html
> [2] 
> https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#157974
> [3] 
> https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#158081
> 
> ps. patch 4/4 is already in archive [4]
> 
> [4] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158082.html

The patch got lost in time and space and has never reached patchwork's
mail server.

I feed the patchwork with a copy of the mail manually. Expect results soon.

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

[Intel-gfx] [PATCH v2 3/3] HAX: Enable GuC for CI

[Michal Wajdeczko]

v2: except running with HYPERVISOR

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index abd1f7b..cb77b0e 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/3] drm/i915/uc: Sanitize uC options early

[Michal Wajdeczko]

We are sanitizing uC related modparams together with other driver
modparams in intel_sanitize_options called from i915_driver_init_hw,
but this is too late for us as we will want to use USES_GUC/USES_HUC
macros at earlier stage. Since our sanitizing does not require any
MMIO access, we can do it in intel_uc_init_early right after we resolve
firmware names.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 --
 drivers/gpu/drm/i915/intel_uc.c | 6 --
 drivers/gpu/drm/i915/intel_uc.h | 1 -
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de4..5ba6d6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1074,8 +1074,6 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
i915_modparams.enable_ppgtt);
DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
 
-   intel_uc_sanitize_options(dev_priv);
-
intel_gvt_sanitize_options(dev_priv);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e5bf0d3..a45171c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -83,7 +83,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
 }
 
 /**
- * intel_uc_sanitize_options - sanitize uC related modparam options
+ * sanitize_options_early - sanitize uC related modparam options
  * @dev_priv: device private
  *
  * In case of "enable_guc" option this function will attempt to modify
@@ -99,7 +99,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
  * unless GuC is enabled on given platform and the driver is compiled with
  * debug config when this modparam will default to "enable(1..4)".
  */
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *dev_priv)
 {
struct intel_uc_fw *guc_fw = _priv->guc.fw;
struct intel_uc_fw *huc_fw = _priv->huc.fw;
@@ -163,6 +163,8 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
intel_guc_init_early(_priv->guc);
intel_huc_init_early(_priv->huc);
+
+   sanitize_options_early(dev_priv);
 }
 
 void intel_uc_init_fw(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f76d51d..dce4813 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -28,7 +28,6 @@
 #include "intel_huc.h"
 #include "i915_params.h"
 
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
 void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
 void intel_uc_init_fw(struct drm_i915_private *dev_priv);
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM

[Michal Wajdeczko]

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

v2: don't forget about reset path (Daniele)
sanitize uc before gem initiated full reset (Daniele)

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_huc.h   |  6 ++
 drivers/gpu/drm/i915/intel_uc.c| 18 ++
 drivers/gpu/drm/i915/intel_uc.h|  1 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
 6 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e58b741..05b0724 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2998,6 +2998,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
}
 
i915_gem_revoke_fences(dev_priv);
+   intel_uc_sanitize(dev_priv);
 
return err;
 }
@@ -4978,6 +4979,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 * machines is a good idea, we don't - just in case it leaves the
 * machine in an unusable condition.
 */
+   intel_uc_sanitize(dev_priv);
i915_gem_sanitize(dev_priv);
 
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
+static inline int intel_guc_sanitize(struct intel_guc *guc)
+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
 void intel_huc_init_early(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
 
+static inline int intel_huc_sanitize(struct intel_huc *huc)
+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
 }
 
+void intel_uc_sanitize(struct drm_i915_private *i915)
+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);
+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_misc(struct drm_i915_private *dev_priv);
 void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
 }
 
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)
+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
 int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 0/3] drm/i915/uc: Sanitize uC

[Michal Wajdeczko]

Attempt to sanitize uC for better alignment with rest of GEM driver.

v2: cover reset path and sanitize uc before gem

Michal Wajdeczko (3):
  drm/i915/uc: Sanitize uC options early
  drm/i915/uc: Sanitize uC together with GEM
  HAX: Enable GuC for CI

 drivers/gpu/drm/i915/i915_drv.c|  2 --
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/i915_params.h |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_huc.h   |  6 ++
 drivers/gpu/drm/i915/intel_uc.c| 26 --
 drivers/gpu/drm/i915/intel_uc.h|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
 8 files changed, 46 insertions(+), 6 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

[Gaurav K Singh]

On Apollolake, with stress test warm reboot, audio card
was not getting enumerated after reboot. This was a
spurious issue happening on Apollolake. HW codec and
HD audio controller link was going out of sync for which
there was a fix in i915 driver but was not getting invoked
for BXT. Extending this fix to BXT as well.

Bspec: 21829
Tested on apollolake chromebook by stress test warm reboot
with 2500 iterations.

v2:
* Mention Bspec Index in commit message(Dhinakaran Pandiyan)

Signed-off-by: Gaurav K Singh 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 709d6ca68074..656f6c931341 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct 
device *kdev,
struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
u32 tmp;
 
-   if (!IS_GEN9_BC(dev_priv))
+   if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
return;
 
i915_audio_component_get_power(kdev);
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: enable perf support on ICL

[Patchwork]

== Series Details ==

Series: drm/i915/perf: enable perf support on ICL
URL   : https://patchwork.freedesktop.org/series/39689/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375
Test kms_vblank:
Subgroup pipe-a-ts-continuation-dpms-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:8   skip:1632 
time:12305s
shard-hswtotal:3467 pass:1772 dwarn:1   dfail:0   fail:2   skip:1691 
time:11713s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6906s
Blacklisted hosts:
shard-kbltotal:3381 pass:1882 dwarn:14  dfail:1   fail:10  skip:1473 
time:8809s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/shards.html
___
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 [v3,1/4] drm: Add drm_any_plane_has_format()

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
URL   : https://patchwork.freedesktop.org/series/39700/
State : success

== Summary ==

Series 39700v1 series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
https://patchwork.freedesktop.org/api/1.0/series/39700/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:500s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:505s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:513s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
d866fde8c9bc drm/vc4: Validate framebuffer pixel format/modifier
95156651bb61 drm: Fix some coding style issues
e82cc7382b48 drm/i915: Eliminate the horrendous format check code
06e78ca5ab60 drm: Add drm_any_plane_has_format()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm: Fix some coding style issues

[Ville Syrjala]

From: Ville Syrjälä 

Put an empty line between the variable declarations and the code, and
use tabs for alignment.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..7df025669067 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -162,9 +162,10 @@ static int framebuffer_check(struct drm_device *dev,
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- _name));
+ drm_get_format_name(r->pixel_format,
+ _name));
return -EINVAL;
}
 
-- 
2.16.1

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

[Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier

[Ville Syrjala]

From: Ville Syrjälä 

Only create framebuffers with supported format/modifier combinations by
checking that at least one plane supports the requested combination.

Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
the planes have (mostly) uniform capabilities. But I was lazy and
didn't feel like exporting drm_plane_format_check() and hand rolling
anything better. Also I really just wanted to come up with another
user for drm_any_plane_has_format() ;)

Compile tested only.

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..b6f15102dda0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -184,6 +184,17 @@ static struct drm_framebuffer *vc4_fb_create(struct 
drm_device *dev,
mode_cmd = _cmd_local;
}
 
+   if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ _name),
+ mode_cmd->modifier[0]);
+   return ERR_PTR(-EINVAL);
+   }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
 }
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v3 2/4] drm/i915: Eliminate the horrendous format check code

[Ville Syrjala]

From: Ville Syrjälä 

Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.

v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 90 
 1 file changed, 8 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..7f06fa83d894 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13989,7 +13989,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
-   struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14020,33 +14019,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
}
}
 
-   /* Passed in modifier sanity checking. */
-   switch (mode_cmd->modifier[0]) {
-   case I915_FORMAT_MOD_Y_TILED_CCS:
-   case I915_FORMAT_MOD_Yf_TILED_CCS:
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_ABGR:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   default:
-   DRM_DEBUG_KMS("RC supported only with RGB 
formats\n");
-   goto err;
-   }
-   /* fall through */
-   case I915_FORMAT_MOD_Y_TILED:
-   case I915_FORMAT_MOD_Yf_TILED:
-   if (INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
-   goto err;
-   }
-   case DRM_FORMAT_MOD_LINEAR:
-   case I915_FORMAT_MOD_X_TILED:
-   break;
-   default:
-   DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+   if (!drm_any_plane_has_format(_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ _name),
  mode_cmd->modifier[0]);
goto err;
}
@@ -14081,60 +14061,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
-   /* Reject formats not supported by any plane early. */
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   case DRM_FORMAT_XRGB1555:
-   if (INTEL_GEN(dev_priv) > 3) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-   INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   if (INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR2101010:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_VYUY:
-   if (INTEL_GEN(dev_priv) < 5 

[Intel-gfx] [PATCH v3 1/4] drm: Add drm_any_plane_has_format()

[Ville Syrjala]

From: Ville Syrjälä 

Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().

v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both
v3: Don't do the check in the core since we may not know the
modifier yet, instead export the function and let drivers
call it themselves

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_plane.c   | 23 +++
 include/drm/drm_mode_config.h |  6 ++
 include/drm/drm_plane.h   |  2 ++
 3 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7e8a37..3b2d6f8d889d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -578,6 +578,29 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
return 0;
 }
 
+/**
+ * drm_any_plane_has_format - Check whether any plane supports this format and 
modifier combination
+ * @dev: DRM device
+ * @format: pixel format (DRM_FORMAT_*)
+ * @modifier: data layout modifier
+ *
+ * Returns:
+ * Whether at least one plane supports the specified format and modifier 
combination.
+ */
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier)
+{
+   struct drm_plane *plane;
+
+   drm_for_each_plane(plane, dev) {
+   if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+   return true;
+   }
+
+   return false;
+}
+EXPORT_SYMBOL(drm_any_plane_has_format);
+
 /*
  * __setplane_internal - setplane handler for internal callers
  *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..9b894de9a75d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -52,6 +52,12 @@ struct drm_mode_config_funcs {
 * requested metadata, but most of that is left to the driver. See
 *  drm_mode_fb_cmd2 for details.
 *
+* To validate the pixel format and modifier drivers can use
+* drm_any_plane_has_format() to make sure at least one plane supports
+* the requested values. Note that the driver must first determine the
+* actual modifier used if the request doesn't have it specified,
+* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+*
 * If the parameters are deemed valid and the backing storage objects in
 * the underlying memory manager all exist, then the driver allocates
 * a new _framebuffer structure, subclassed to contain
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..930e8fdd90f8 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -683,5 +683,7 @@ static inline struct drm_plane *drm_plane_find(struct 
drm_device *dev,
 #define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
 
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier);
 
 #endif
-- 
2.16.1

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

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling

[Michał Winiarski]

On Fri, Mar 09, 2018 at 10:42:40AM +, Chris Wilson wrote:
> On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart
> within our desired interval. Improve the likelihood of the inspection
> passing by idling the GPU and waiting for 2 Evaluation Intervals before
> we start polling of RC6 residency.

I'd stick with pure gem_quiescent_gpu() since we're already polling for waay
longer than that.

Either way:

Reviewed-by: Michał Winiarski 

-Michał

> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/gem_mocs_settings.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
> index 9705fbfd..85fd637a 100644
> --- a/tests/gem_mocs_settings.c
> +++ b/tests/gem_mocs_settings.c
> @@ -336,12 +336,15 @@ static uint32_t rc6_residency(int dir)
>  
>  static void rc6_wait(int fd)
>  {
> - int sysfs;
>   uint32_t residency;
> + int sysfs;
>  
>   sysfs = igt_sysfs_open(fd, NULL);
>   igt_assert_lte(0, sysfs);
>  
> + gem_quiescent_gpu(fd);
> + usleep(320e3); /* Wait for 2 EIs before polling; should now be active */
> +
>   residency = rc6_residency(sysfs);
>   igt_require(igt_wait(rc6_residency(sysfs) != residency, 1, 2));
>  
> -- 
> 2.16.2
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

[Chris Wilson]

Quoting Chris Wilson (2018-03-09 14:10:34)
> Quoting Chris Wilson (2018-03-07 13:42:26)
> > tasklet_kill() will spin waiting for the current tasklet to be executed.
> > However, if tasklet_disable() has been called, then the tasklet is never
> > executed but permanently put back onto the runlist until
> > tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> > disable/enable pair. This is the case when we call set-wedge from inside
> > i915_reset(), and another request was submitted to us concurrent to the
> > reset.
> > 
> > Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3b44952e089f..e75af06904b7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
> > *engine)
> >  * Turning off the execlists->tasklet until the reset is over
> >  * prevents the race.
> >  */
> > -   tasklet_kill(>execlists.tasklet);
> > +   if (!atomic_read(>execlists.tasklet.count))
> > +   tasklet_kill(>execlists.tasklet);
> 
> Note this is racy; two separate atomic operations. The only race we have
> is with set-wedge vs reset, which is a rare and already contentious
> issue. The upside of preventing the lockup is that we don't lose the
> machine.
> 
> +* Note that this needs to be a single atomic operation on the
> +* tasklet (flush existing tasks, prevent new tasks) to prevent
> +* a race between reset and set-wedged. It is not, so we do the best
> +* we can atm and make sure we don't lock the machine up in the more
> +* common case of recursing calling set-wedged from inside i915_reset.

The alternative is to not try and do tasklet_kill() here. But that has
the side-effect of leaving it spinning if it was running at the same
time as the suspend. Hmm, for the moment I'll go with the comment and
see how inspired we are once gem_eio stops dieing.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL

[Lionel Landwerlin]

On 09/03/18 13:49, Matthew Auld wrote:

On 9 March 2018 at 11:58, Lionel Landwerlin
 wrote:

No significant changes from either context offsets, nor report
formats, nor register whitelist.

Signed-off-by: Lionel Landwerlin 
---

The usual spiel about disabling clock-ratio-change reports, do we need it?


Dammit :)



So this will need the timestamp frequency stuff for gen11, should that
go in before this, or don't we care?


I'll wait for that to land indeed.

Thanks a lot!



Reviewed-by: Matthew Auld 



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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

[Chris Wilson]

Quoting Chris Wilson (2018-03-07 13:42:26)
> tasklet_kill() will spin waiting for the current tasklet to be executed.
> However, if tasklet_disable() has been called, then the tasklet is never
> executed but permanently put back onto the runlist until
> tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> disable/enable pair. This is the case when we call set-wedge from inside
> i915_reset(), and another request was submitted to us concurrent to the
> reset.
> 
> Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3b44952e089f..e75af06904b7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
> *engine)
>  * Turning off the execlists->tasklet until the reset is over
>  * prevents the race.
>  */
> -   tasklet_kill(>execlists.tasklet);
> +   if (!atomic_read(>execlists.tasklet.count))
> +   tasklet_kill(>execlists.tasklet);

Note this is racy; two separate atomic operations. The only race we have
is with set-wedge vs reset, which is a rare and already contentious
issue. The upside of preventing the lockup is that we don't lose the
machine.

+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to prevent
+* a race between reset and set-wedged. It is not, so we do the best
+* we can atm and make sure we don't lock the machine up in the more
+* common case of recursing calling set-wedged from inside i915_reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

[Mika Kuoppala]

Chris Wilson  writes:

> tasklet_kill() will spin waiting for the current tasklet to be executed.
> However, if tasklet_disable() has been called, then the tasklet is never
> executed but permanently put back onto the runlist until
> tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> disable/enable pair. This is the case when we call set-wedge from inside
> i915_reset(), and another request was submitted to us concurrent to the
> reset.
>
> Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3b44952e089f..e75af06904b7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
> *engine)
>* Turning off the execlists->tasklet until the reset is over
>* prevents the race.
>*/
> - tasklet_kill(>execlists.tasklet);
> + if (!atomic_read(>execlists.tasklet.count))
> + tasklet_kill(>execlists.tasklet);

As discussed in irc, this might warrant  comment that it is
our tasklet of which count we are racily investigating here,
so the race does not matter in the path we avoid killing.

Reviewed-by: Mika Kuoppala 

>   tasklet_disable(>execlists.tasklet);
>  
>   /*
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 648 +
 tests/meson.build  |   1 +
 4 files changed, 651 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..f3cee838
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 7
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(period_us);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+#define N_STEPS 10
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 

[Intel-gfx] ✓ Fi.CI.BAT: success for CNL port refactoring (rev2)

[Patchwork]

== Series Details ==

Series: CNL port refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/38334/
State : success

== Summary ==

Series 38334v2 CNL port refactoring
https://patchwork.freedesktop.org/api/1.0/series/38334/revisions/2/mbox/

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3) fdo#103167
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#103191

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:509s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:514s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:519s

074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC 
integration manifest
d271c009a148 drm/i915/cnl: Kill _MMIO_PORT6 macro
5a42fe815c97 drm/i915/cnl: Replace PORT_TX register macros with new ones
08448452816c drm/i915/cnl; Add macro to get PORT_TX register

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-09 13:38:37)
> Chris Wilson  writes:
> 
> > When wedged, we do not update the ring->tail as we submit the requests
> > causing us to leak the ring->space upon cleaning up the wedged driver.
> > We can just use the value stored in rq->tail, and keep the submission
> > backend details away from set-wedge.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_request.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index efa9ee557f31..69b378a323fc 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request)
> >* is just about to be. Either works, if we miss the last two
> >* noops - they are safe to be replayed on a reset.
> >*/
> > - tail = READ_ONCE(request->ring->tail);
> > + tail = READ_ONCE(request->tail);
> 
> I tried to think if we need the READ_ONCE here anymore.

I tried as well to see if the comment was still correct. It still is due
to that we can retire before we see the context-switch interrupt.
 
> But as this is the safest version,
> Reviewed-by: Mika Kuoppala 
> 
> Noticed that request->tail is not cleared on i915_request_alloc.
> 
> If we would set rq->head = rq->tail = rq->ring->emit
> we could use rq->head == rq->tail to assert that
> we screw up something major during the request lifetime.

Heh, if we get a stray write here, we're going to get stray writes
everywhere :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

[Mika Kuoppala]

Chris Wilson  writes:

> Similar to the staging around handling of engine->submit_request, we
> need to stop adding to the execlists->queue prior to calling
> engine->cancel_requests. cancel_requests will move requests from the
> queue onto the timeline, so if we add a request onto the queue after that
> point, it will be lost.
>
> Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in 
> set_wedged")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
>  drivers/gpu/drm/i915/i915_request.c |  2 ++
>  2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 30cd07ebcb8e..3b44952e089f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence 
> *fence, int prio)
>  
>   rq = to_request(fence);
>   engine = rq->engine;
> - if (!engine->schedule)
> - return;
>  
> - engine->schedule(rq, prio);
> + rcu_read_lock();
> + if (engine->schedule)
> + engine->schedule(rq, prio);
> + rcu_read_unlock();
>  }
>  
>  static void fence_set_priority(struct dma_fence *fence, int prio)
> @@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>*/
>   for_each_engine(engine, i915, id) {
>   i915_gem_reset_prepare_engine(engine);
> +
>   engine->submit_request = nop_submit_request;
> + engine->schedule = NULL;
>   }
> + i915->caps.scheduler = 0;
>  
>   /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3233,11 +3237,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* start to complete all requests.
>*/
>   engine->submit_request = nop_complete_submit_request;
> - engine->schedule = NULL;
>   }
>  
> - i915->caps.scheduler = 0;
> -
>   /*
>* Make sure no request can slip through without getting completed by
>* either this call here to intel_engine_init_global_seqno, or the one
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 69b378a323fc..0258449579f8 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1082,8 +1082,10 @@ void __i915_request_add(struct i915_request *request, 
> bool flush_caches)
>* decide whether to preempt the entire chain so that it is ready to
>* run at the earliest possible convenience.
>*/
> + rcu_read_lock();
>   if (engine->schedule)
>   engine->schedule(request, request->ctx->priority);
> + rcu_read_unlock();
>  
>   local_bh_disable();
>   i915_sw_fence_commit(>submit);
> -- 
> 2.16.2
>
> ___
> 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 4/6] drm/i915: Include ring->emit in debugging

[Mika Kuoppala]

Chris Wilson  writes:

> Include ring->emit and ring->space alongside ring->(head,tail) when
> printing debug information.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  4 ++--
>  drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++---
>  2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e838c765b251..4de0a52f14a9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1923,8 +1923,8 @@ static int i915_gem_framebuffer_info(struct seq_file 
> *m, void *data)
>  
>  static void describe_ctx_ring(struct seq_file *m, struct intel_ring *ring)
>  {
> - seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u)",
> -ring->space, ring->head, ring->tail);
> + seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, emit: %u)",
> +ring->space, ring->head, ring->tail, ring->emit);
>  }
>  
>  static int i915_context_status(struct seq_file *m, void *unused)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4ba139c27fba..e71bd6951d9b 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1929,12 +1929,16 @@ void intel_engine_dump(struct intel_engine_cs *engine,
>  rq->head, rq->postfix, rq->tail,
>  rq->batch ? upper_32_bits(rq->batch->node.start) : 
> ~0u,
>  rq->batch ? lower_32_bits(rq->batch->node.start) : 
> ~0u);
> - drm_printf(m, "\t\tring->start: 0x%08x\n",
> + drm_printf(m, "\t\tring->start : 0x%08x\n",

Please check the space before ':', seems unintentional.

Reviewed-by: Mika Kuoppala 

>  i915_ggtt_offset(rq->ring->vma));
> - drm_printf(m, "\t\tring->head:  0x%08x\n",
> + drm_printf(m, "\t\tring->head:   0x%08x\n",
>  rq->ring->head);
> - drm_printf(m, "\t\tring->tail:  0x%08x\n",
> + drm_printf(m, "\t\tring->tail:   0x%08x\n",
>  rq->ring->tail);
> + drm_printf(m, "\t\tring->emit:   0x%08x\n",
> +rq->ring->emit);
> + drm_printf(m, "\t\tring->space:  0x%08x\n",
> +rq->ring->space);
>   }
>  
>   rcu_read_unlock();
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL

[Matthew Auld]

On 9 March 2018 at 11:58, Lionel Landwerlin
 wrote:
> No significant changes from either context offsets, nor report
> formats, nor register whitelist.
>
> Signed-off-by: Lionel Landwerlin 
> ---

The usual spiel about disabling clock-ratio-change reports, do we need it?

So this will need the timestamp frequency stuff for gen11, should that
go in before this, or don't we care?

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

[Mika Kuoppala]

Chris Wilson  writes:

> When wedged, we do not update the ring->tail as we submit the requests
> causing us to leak the ring->space upon cleaning up the wedged driver.
> We can just use the value stored in rq->tail, and keep the submission
> backend details away from set-wedge.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index efa9ee557f31..69b378a323fc 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request)
>* is just about to be. Either works, if we miss the last two
>* noops - they are safe to be replayed on a reset.
>*/
> - tail = READ_ONCE(request->ring->tail);
> + tail = READ_ONCE(request->tail);

I tried to think if we need the READ_ONCE here anymore.

But as this is the safest version,
Reviewed-by: Mika Kuoppala 

Noticed that request->tail is not cleared on i915_request_alloc.

If we would set rq->head = rq->tail = rq->ring->emit
we could use rq->head == rq->tail to assert that
we screw up something major during the request lifetime.

-Mika


>   } else {
>   tail = request->postfix;
>   }
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-09 13:17:09)
> Chris Wilson  writes:
> 
> > With a series of unusual events (a sequence of interrupted request
> > allocations), we could gradually leak the ring->space estimate by
> > unwinding the ring back to the start of the request, but not return the
> > used space back to the ring. Eventually and with great misfortune, it
> > would be possible to trigger ring->space exhaustion with no requests on
> > the ring.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_request.c | 1 +
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index d437beac3969..efa9ee557f31 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, 
> > struct i915_gem_context *ctx)
> >  
> >  err_unwind:
> >   rq->ring->emit = rq->head;
> > + intel_ring_update_space(rq->ring);
> >  
> >   /* Make sure we didn't add ourselves to external state before freeing 
> > */
> >   GEM_BUG_ON(!list_empty(>active_list));
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 1d599524a759..88eeb64041ae 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring 
> > *ring, unsigned int bytes)
> >   if (intel_ring_update_space(ring) >= bytes)
> >   return 0;
> >  
> > + GEM_BUG_ON(list_empty(>request_list));
> 
> At some point, after long series of misfortunate events, we
> will add a first request and need actually wait a space for this
> and then we kaboom in here?

That's the experience. However, I don't think this patch helps because
we do the intel_ring_update_space() here inside wait_for_space anyway,
so it should come out in the wash so long as we aren't corrupting
the ring space calculation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

[Mika Kuoppala]

Chris Wilson  writes:

> With a series of unusual events (a sequence of interrupted request
> allocations), we could gradually leak the ring->space estimate by
> unwinding the ring back to the start of the request, but not return the
> used space back to the ring. Eventually and with great misfortune, it
> would be possible to trigger ring->space exhaustion with no requests on
> the ring.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index d437beac3969..efa9ee557f31 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
> i915_gem_context *ctx)
>  
>  err_unwind:
>   rq->ring->emit = rq->head;
> + intel_ring_update_space(rq->ring);
>  
>   /* Make sure we didn't add ourselves to external state before freeing */
>   GEM_BUG_ON(!list_empty(>active_list));
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1d599524a759..88eeb64041ae 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring 
> *ring, unsigned int bytes)
>   if (intel_ring_update_space(ring) >= bytes)
>   return 0;
>  
> + GEM_BUG_ON(list_empty(>request_list));

At some point, after long series of misfortunate events, we
will add a first request and need actually wait a space for this
and then we kaboom in here?

-Mika

>   list_for_each_entry(target, >request_list, ring_link) {
>   /* Would completion of this request free enough space? */
>   if (bytes <= __intel_ring_space(target->postfix,
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

[Chris Wilson]

Quoting Chris Wilson (2018-03-07 13:42:22)
> With a series of unusual events (a sequence of interrupted request
> allocations), we could gradually leak the ring->space estimate by
> unwinding the ring back to the start of the request, but not return the
> used space back to the ring. Eventually and with great misfortune, it
> would be possible to trigger ring->space exhaustion with no requests on
> the ring.
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index d437beac3969..efa9ee557f31 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
> i915_gem_context *ctx)
>  
>  err_unwind:
> rq->ring->emit = rq->head;
> +   intel_ring_update_space(rq->ring);

Ok, skip this one as we will correct ourselves next time we
wait_for_space. It's just the next one where we weren't maintaining
ring->tail that was the issue.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

[Maxime Ripard]

On Fri, Mar 09, 2018 at 12:55:24PM +0100, Maarten Lankhorst wrote:
> Op 06-03-18 om 16:57 schreef Maxime Ripard:
> > Hi,
> >
> > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote:
> >> Only try to set those values if the properties are supported.
> >> This fixes the kms_chameium tests to run on vc4 again.
> >>
> >> Reported-by: Maxime Ripard 
> >> Cc: Paul Kocialkowski 
> >> Cc: Eric Anholt 
> >> Cc: Boris Brezillon 
> >> Signed-off-by: Maarten Lankhorst 
> > This works like a charm now, thanks!
> > Tested-by: Maxime Ripard 
> >
> > Maxime
> >
> Can you upgrade this to a reviewed-by so I can apply this change?

Yep, of course:
Reviewed-by: Maxime Ripard 

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

[Mika Kuoppala]

Chris Wilson  writes:

> Before we reset the GPU after marking the device as wedged, we wait for
> all the remaining requests to be completed (and marked as EIO).
> Afterwards, we should flush the request lists so the next batch start
> with the driver in an idle start.

s/start/state?

>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a5bd07338b46..30cd07ebcb8e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3273,7 +3273,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private 
> *i915)
>   if (!test_bit(I915_WEDGED, >gpu_error.flags))
>   return true;
>  
> - /* Before unwedging, make sure that all pending operations
> + /*
> +  * Before unwedging, make sure that all pending operations
>* are flushed and errored out - we may have requests waiting upon
>* third party fences. We marked all inflight requests as EIO, and
>* every execbuf since returned EIO, for consistency we want all
> @@ -3291,7 +3292,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private 
> *i915)
>   if (!rq)
>   continue;
>  
> - /* We can't use our normal waiter as we want to
> + /*
> +  * We can't use our normal waiter as we want to
>* avoid recursively trying to handle the current
>* reset. The basic dma_fence_default_wait() installs
>* a callback for dma_fence_signal(), which is
> @@ -3306,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private 
> *i915)
>   return false;
>   }
>   }
> + i915_retire_requests(i915);
> + GEM_BUG_ON(i915->gt.active_requests);
>  
> - /* Undo nop_submit_request. We prevent all new i915 requests from
> + /*
> +  * Undo nop_submit_request. We prevent all new i915 requests from
>* being queued (by disallowing execbuf whilst wedged) so having
>* waited for all active requests above, we know the system is idle
>* and do not have to worry about a thread being inside
> -- 
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915/cnl: Replace PORT_TX register macros with new ones

[Mahesh Kumar]

This patch replaces CNL_PORT_TX register macros with new macros defined
in previous patch.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h | 107 +---
 1 file changed, 11 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 30ef3513dc6f..7987a3f85d04 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1992,30 +1992,8 @@ enum i915_power_well_id {
   _CNL_PORT_TX_F_LN0_OFFSET) + \
   4*(dw))
 
-#define _CNL_PORT_TX_DW2_GRP_AE0x162348
-#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
-#define _CNL_PORT_TX_DW2_GRP_C 0x162B48
-#define _CNL_PORT_TX_DW2_GRP_D 0x162BC8
-#define _CNL_PORT_TX_DW2_GRP_F 0x162A48
-#define _CNL_PORT_TX_DW2_LN0_AE0x162448
-#define _CNL_PORT_TX_DW2_LN0_B 0x162648
-#define _CNL_PORT_TX_DW2_LN0_C 0x162C48
-#define _CNL_PORT_TX_DW2_LN0_D 0x162E48
-#define _CNL_PORT_TX_DW2_LN0_F 0x162848
-#define CNL_PORT_TX_DW2_GRP(port)  _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW2_GRP_AE, \
-   _CNL_PORT_TX_DW2_GRP_B, \
-   _CNL_PORT_TX_DW2_GRP_C, \
-   _CNL_PORT_TX_DW2_GRP_D, \
-   _CNL_PORT_TX_DW2_GRP_AE, \
-   _CNL_PORT_TX_DW2_GRP_F)
-#define CNL_PORT_TX_DW2_LN0(port)  _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW2_LN0_AE, \
-   _CNL_PORT_TX_DW2_LN0_B, \
-   _CNL_PORT_TX_DW2_LN0_C, \
-   _CNL_PORT_TX_DW2_LN0_D, \
-   _CNL_PORT_TX_DW2_LN0_AE, \
-   _CNL_PORT_TX_DW2_LN0_F)
+#define CNL_PORT_TX_DW2_GRP(port)  _MMIO(CNL_PORT_TX_DW_GRP((port), 2))
+#define CNL_PORT_TX_DW2_LN0(port)  _MMIO(CNL_PORT_TX_DW_LN0((port), 2))
 #define   SWING_SEL_UPPER(x)   ((x >> 3) << 15)
 #define   SWING_SEL_UPPER_MASK (1 << 15)
 #define   SWING_SEL_LOWER(x)   ((x & 0x7) << 11)
@@ -2023,32 +2001,13 @@ enum i915_power_well_id {
 #define   RCOMP_SCALAR(x)  ((x) << 0)
 #define   RCOMP_SCALAR_MASK(0xFF << 0)
 
-#define _CNL_PORT_TX_DW4_GRP_AE0x162350
-#define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
-#define _CNL_PORT_TX_DW4_GRP_C 0x162B50
-#define _CNL_PORT_TX_DW4_GRP_D 0x162BD0
-#define _CNL_PORT_TX_DW4_GRP_F 0x162A50
 #define _CNL_PORT_TX_DW4_LN0_AE0x162450
 #define _CNL_PORT_TX_DW4_LN1_AE0x1624D0
-#define _CNL_PORT_TX_DW4_LN0_B 0x162650
-#define _CNL_PORT_TX_DW4_LN0_C 0x162C50
-#define _CNL_PORT_TX_DW4_LN0_D 0x162E50
-#define _CNL_PORT_TX_DW4_LN0_F 0x162850
-#define CNL_PORT_TX_DW4_GRP(port)   _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW4_GRP_AE, \
-   _CNL_PORT_TX_DW4_GRP_B, \
-   _CNL_PORT_TX_DW4_GRP_C, \
-   _CNL_PORT_TX_DW4_GRP_D, \
-   _CNL_PORT_TX_DW4_GRP_AE, \
-   _CNL_PORT_TX_DW4_GRP_F)
-#define CNL_PORT_TX_DW4_LN(port, ln)   _MMIO_PORT6_LN(port, ln,\
-   _CNL_PORT_TX_DW4_LN0_AE, \
-   _CNL_PORT_TX_DW4_LN1_AE, \
-   _CNL_PORT_TX_DW4_LN0_B, \
-   _CNL_PORT_TX_DW4_LN0_C, \
-   _CNL_PORT_TX_DW4_LN0_D, \
-   _CNL_PORT_TX_DW4_LN0_AE, \
-   _CNL_PORT_TX_DW4_LN0_F)
+#define CNL_PORT_TX_DW4_GRP(port)  _MMIO(CNL_PORT_TX_DW_GRP((port), 4))
+#define CNL_PORT_TX_DW4_LN0(port)  _MMIO(CNL_PORT_TX_DW_LN0((port), 4))
+#define CNL_PORT_TX_DW4_LN(port, ln)   _MMIO(CNL_PORT_TX_DW_LN0((port), 4) + \
+(ln * (_CNL_PORT_TX_DW4_LN1_AE - \
+   _CNL_PORT_TX_DW4_LN0_AE)))
 #define   LOADGEN_SELECT   (1 << 31)
 #define   POST_CURSOR_1(x) ((x) << 12)
 #define   POST_CURSOR_1_MASK   (0x3F << 12)
@@ -2057,30 +2016,8 @@ enum 

[Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

[Mahesh Kumar]

This patch creates a new macro to get PORT_TX register for any given DW.
This will remove the need of defining register address for each port & DW.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..30ef3513dc6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1964,6 +1964,34 @@ enum i915_power_well_id {
_CNL_PORT_PCS_DW1_LN0_F)
 #define   COMMON_KEEPER_EN (1 << 26)
 
+/* CNL Port TX registers */
+#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
+#define _CNL_PORT_TX_B_GRP_OFFSET  0x1623C0
+#define _CNL_PORT_TX_C_GRP_OFFSET  0x162B40
+#define _CNL_PORT_TX_D_GRP_OFFSET  0x162BC0
+#define _CNL_PORT_TX_F_GRP_OFFSET  0x162A40
+#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440
+#define _CNL_PORT_TX_B_LN0_OFFSET  0x162640
+#define _CNL_PORT_TX_C_LN0_OFFSET  0x162C40
+#define _CNL_PORT_TX_D_LN0_OFFSET  0x162E40
+#define _CNL_PORT_TX_F_LN0_OFFSET  0x162840
+#define CNL_PORT_TX_DW_GRP(port, dw)   (_PICK((port), \
+  _CNL_PORT_TX_AE_GRP_OFFSET, \
+  _CNL_PORT_TX_B_GRP_OFFSET, \
+  _CNL_PORT_TX_B_GRP_OFFSET, \
+  _CNL_PORT_TX_D_GRP_OFFSET, \
+  _CNL_PORT_TX_AE_GRP_OFFSET, \
+  _CNL_PORT_TX_F_GRP_OFFSET) + \
+  4*(dw))
+#define CNL_PORT_TX_DW_LN0(port, dw)   (_PICK((port), \
+  _CNL_PORT_TX_AE_LN0_OFFSET, \
+  _CNL_PORT_TX_B_LN0_OFFSET, \
+  _CNL_PORT_TX_B_LN0_OFFSET, \
+  _CNL_PORT_TX_D_LN0_OFFSET, \
+  _CNL_PORT_TX_AE_LN0_OFFSET, \
+  _CNL_PORT_TX_F_LN0_OFFSET) + \
+  4*(dw))
+
 #define _CNL_PORT_TX_DW2_GRP_AE0x162348
 #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
 #define _CNL_PORT_TX_DW2_GRP_C 0x162B48
-- 
2.14.1

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

[Intel-gfx] [PATCH 0/3] CNL port refactoring

[Mahesh Kumar]

This series fixes CNL PORT_TX_DW5/7_LNO_D register address.
This series also introduces macros to get register address of
CNL_PORT_TX registers instead of defining for each DW instance.

changes since V1:
 completely kill _MMIO_PORT6 macro

Mahesh Kumar (3):
  drm/i915/cnl; Add macro to get PORT_TX register
  drm/i915/cnl: Replace PORT_TX register macros with new ones
  drm/i915/cnl: Kill _MMIO_PORT6 macro

 drivers/gpu/drm/i915/i915_reg.h | 147 
 1 file changed, 44 insertions(+), 103 deletions(-)

-- 
2.14.1

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

[Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro

[Mahesh Kumar]

This patch replaces use of remaining _MMIO_PORT6 macro and removes the
macro.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7987a3f85d04..37742d774ba0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
 #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
 #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
-#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
f))
-#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f)
\
-   _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
 #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
 #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
 
@@ -1948,20 +1945,21 @@ enum i915_power_well_id {
 #define _CNL_PORT_PCS_DW1_LN0_C0x162C04
 #define _CNL_PORT_PCS_DW1_LN0_D0x162E04
 #define _CNL_PORT_PCS_DW1_LN0_F0x162804
-#define CNL_PORT_PCS_DW1_GRP(port) _MMIO_PORT6(port, \
+#define CNL_PORT_PCS_DW1_GRP(port) _MMIO(_PICK(port, \
_CNL_PORT_PCS_DW1_GRP_AE, \
_CNL_PORT_PCS_DW1_GRP_B, \
_CNL_PORT_PCS_DW1_GRP_C, \
_CNL_PORT_PCS_DW1_GRP_D, \
_CNL_PORT_PCS_DW1_GRP_AE, \
-   _CNL_PORT_PCS_DW1_GRP_F)
-#define CNL_PORT_PCS_DW1_LN0(port) _MMIO_PORT6(port, \
+   _CNL_PORT_PCS_DW1_GRP_F))
+
+#define CNL_PORT_PCS_DW1_LN0(port) _MMIO(_PICK(port, \
_CNL_PORT_PCS_DW1_LN0_AE, \
_CNL_PORT_PCS_DW1_LN0_B, \
_CNL_PORT_PCS_DW1_LN0_C, \
_CNL_PORT_PCS_DW1_LN0_D, \
_CNL_PORT_PCS_DW1_LN0_AE, \
-   _CNL_PORT_PCS_DW1_LN0_F)
+   _CNL_PORT_PCS_DW1_LN0_F))
 #define   COMMON_KEEPER_EN (1 << 26)
 
 /* CNL Port TX registers */
-- 
2.14.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: enable perf support on ICL

[Patchwork]

== Series Details ==

Series: drm/i915/perf: enable perf support on ICL
URL   : https://patchwork.freedesktop.org/series/39689/
State : success

== Summary ==

Series 39689v1 drm/i915/perf: enable perf support on ICL
https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/1/mbox/

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3) fdo#103167
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#103191

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:507s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:509s

074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC 
integration manifest
07c313f0dad2 drm/i915/perf: enable perf support on ICL

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
URL   : https://patchwork.freedesktop.org/series/39674/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup cursorb-vs-flipb-atomic-transitions-varying-size:
pass   -> DMESG-WARN (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-indfb-fliptrack:
pass   -> FAIL   (shard-apl)
Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-snb) fdo#103167 +1
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3467 pass:1822 dwarn:1   dfail:0   fail:11  skip:1632 
time:12231s
shard-hswtotal:3467 pass:1769 dwarn:2   dfail:0   fail:4   skip:1691 
time:11689s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6891s
Blacklisted hosts:
shard-kbltotal:3381 pass:1899 dwarn:1   dfail:0   fail:9   skip:1471 
time:9138s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

[Jani Nikula]

On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
>
> Previously it was assumed that eDP panels would advertise the lowest link
> rate required for their singular mode to function. With the introduction
> of more advanced features there are advantages to a panel advertising a
> higher rate then it needs for a its given mode. For panels that did, the
> driver previously used a higher rate then necessary for that mode.
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a2eeede..aa6d77d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> dev_priv->vbt.edp.bpp);
>   bpp = dev_priv->vbt.edp.bpp;
>   }
> -
> - /*
> -  * Use the maximum clock and number of lanes the eDP panel
> -  * advertizes being capable of. The panels are generally
> -  * designed to support only a single clock and lane
> -  * configuration, and typically these values correspond to the
> -  * native resolution of the panel.
> -  */
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;

Please see my reply to Manasi's identical patch [1]. If we apply this
as-is, it will regress and will be reverted.

BR,
Jani.


[1] 
http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-git-send-email-manasi.d.nav...@intel.com


>   }
>  
>   for (; bpp >= 6*3; bpp -= 2*3) {

-- 
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] [PATCH] drm/i915/perf: enable perf support on ICL

[Lionel Landwerlin]

No significant changes from either context offsets, nor report
formats, nor register whitelist.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_oa_icl.c | 118 +
 drivers/gpu/drm/i915/i915_oa_icl.h |  34 +++
 drivers/gpu/drm/i915/i915_perf.c   |   5 +-
 4 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4eee91a3a236..ead1e4ff1575 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -171,7 +171,8 @@ i915-y += i915_perf.o \
  i915_oa_glk.o \
  i915_oa_cflgt2.o \
  i915_oa_cflgt3.o \
- i915_oa_cnl.o
+ i915_oa_cnl.o \
+ i915_oa_icl.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_icl.c 
b/drivers/gpu/drm/i915/i915_oa_icl.c
new file mode 100644
index ..a5667926e3de
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_icl.c
@@ -0,0 +1,118 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_icl.h"
+
+static const struct i915_oa_reg b_counter_config_test_oa[] = {
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2770), 0x0004 },
+   { _MMIO(0x2774), 0x },
+   { _MMIO(0x2778), 0x0003 },
+   { _MMIO(0x277c), 0x },
+   { _MMIO(0x2780), 0x0007 },
+   { _MMIO(0x2784), 0x },
+   { _MMIO(0x2788), 0x0012 },
+   { _MMIO(0x278c), 0xfff7 },
+   { _MMIO(0x2790), 0x0012 },
+   { _MMIO(0x2794), 0xffcf },
+   { _MMIO(0x2798), 0x00100082 },
+   { _MMIO(0x279c), 0xffef },
+   { _MMIO(0x27a0), 0x001000c2 },
+   { _MMIO(0x27a4), 0xffe7 },
+   { _MMIO(0x27a8), 0x0011 },
+   { _MMIO(0x27ac), 0xffe7 },
+};
+
+static const struct i915_oa_reg flex_eu_config_test_oa[] = {
+};
+
+static const struct i915_oa_reg mux_config_test_oa[] = {
+   { _MMIO(0xd04), 0x0200 },
+   { _MMIO(0x9840), 0x },
+   { _MMIO(0x9884), 0x },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9888), 0x1606 },
+   { _MMIO(0x9888), 0x2406 },
+   { _MMIO(0x9888), 0x1806 },
+   { _MMIO(0x9888), 0x1a06 },
+   { _MMIO(0x9888), 0x1206 },
+   { _MMIO(0x9888), 0x1406 },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9884), 0x0003 },
+   { _MMIO(0x9888), 0x1613 },
+   { _MMIO(0x9888), 0x2401 },
+   { _MMIO(0x9888), 0x0e130056 },
+   { _MMIO(0x9888), 0x1013 },
+   { _MMIO(0x9888), 0x1a13 },
+   { _MMIO(0x9888), 0x541f0001 },
+   { _MMIO(0x9888), 0x181f },
+   { _MMIO(0x9888), 0x4c1f },
+   { _MMIO(0x9888), 0x301f },
+};
+
+static ssize_t
+show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "1\n");
+}
+
+void
+i915_perf_load_test_config_icl(struct drm_i915_private *dev_priv)
+{
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
+   "a291665e-244b-4b76-9b9a-01de9d3c8068",
+   sizeof(dev_priv->perf.oa.test_config.uuid));
+   dev_priv->perf.oa.test_config.id = 1;
+
+   dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
+   

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

[Maarten Lankhorst]

Op 06-03-18 om 16:57 schreef Maxime Ripard:
> Hi,
>
> On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote:
>> Only try to set those values if the properties are supported.
>> This fixes the kms_chameium tests to run on vc4 again.
>>
>> Reported-by: Maxime Ripard 
>> Cc: Paul Kocialkowski 
>> Cc: Eric Anholt 
>> Cc: Boris Brezillon 
>> Signed-off-by: Maarten Lankhorst 
> This works like a charm now, thanks!
> Tested-by: Maxime Ripard 
>
> Maxime
>
Can you upgrade this to a reviewed-by so I can apply this change?

~Maarten

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

[Sagar Arun Kamble]

On 3/9/2018 2:30 AM, Michal Wajdeczko wrote:

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c|  2 ++
  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
  drivers/gpu/drm/i915/intel_huc.h   |  6 ++
  drivers/gpu/drm/i915/intel_uc.c| 18 ++
  drivers/gpu/drm/i915/intel_uc.h|  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca5..49c81ae 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
above intel_gpu_reset also resets uC. Should we just let it reset only 
real engines with this change then?

+
+   intel_uc_sanitize(i915);
  }
  
  int i915_gem_suspend(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
+static inline int intel_guc_sanitize(struct intel_guc *guc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
  void intel_huc_init_early(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  
+static inline int intel_huc_sanitize(struct intel_huc *huc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
  }
  
+void intel_uc_sanitize(struct drm_i915_private *i915)

+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);
+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
  void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,


--
Thanks,
Sagar

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

[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We need to use absolute tolerance when asserting on percentages. Relative
tolerance in this case is unfair and inaccurate since it's strictness
varies with relative target busyness.

v2:
 * Do not include spin batch edit and submit into measured time.
 * Open PMU before child is in test PWM phase.
 * No need to emit test PWM for twice as long with the new explicit
   synchroniazation via pipe.
 * Log test duration in ms for better readability.
 * Drop inverse assert. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v1
---
 tests/perf_pmu.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 9ebffc64d1f1..ff9f71540ee4 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1459,7 +1459,15 @@ static void __rearm_spin_batch(igt_spin_t *spin)
__sync_synchronize();
 }
 
-#define div_round_up(a, b) (((a) + (b) - 1) / (b))
+#define __assert_within(x, ref, tol_up, tol_down) \
+   igt_assert_f((double)(x) <= ((double)(ref) + (tol_up)) && \
+(double)(x) >= ((double)(ref) - (tol_down)), \
+"%f not within +%f/-%f of %f! ('%s' vs '%s')\n", \
+(double)(x), (double)(tol_up), (double)(tol_down), \
+(double)(ref), #x, #ref)
+
+#define assert_within(x, ref, tolerance) \
+   __assert_within(x, ref, tolerance, tolerance)
 
 static void
 accuracy(int gem_fd, const struct intel_execution_engine2 *e,
@@ -1493,8 +1501,8 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
while (test_us < min_test_us)
test_us += busy_us + idle_us;
 
-   igt_info("calibration=%luus, test=%luus; ratio=%.2f%% (%luus/%luus)\n",
-pwm_calibration_us, test_us,
+   igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n",
+pwm_calibration_us / 1000, test_us / 1000,
 (double)busy_us / (busy_us + idle_us) * 100.0,
 busy_us, idle_us);
 
@@ -1507,7 +1515,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
igt_fork(child, 1) {
struct sched_param rt = { .sched_priority = 99 };
const unsigned long timeout[] = {
-   pwm_calibration_us * 1000, test_us * 2 * 1000
+   pwm_calibration_us * 1000, test_us * 1000
};
struct drm_i915_gem_exec_object2 obj = {};
uint64_t total_busy_ns = 0, total_idle_ns = 0;
@@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct 
intel_execution_engine2 *e,
 
igt_nsec_elapsed(_start);
do {
-   struct timespec t_busy = { };
-   unsigned int target_idle_us;
-
-   igt_nsec_elapsed(_busy);
+   unsigned int target_idle_us, t_busy;
 
/* Restart the spinbatch. */
__rearm_spin_batch(spin);
__submit_spin_batch(gem_fd, , e);
-   measured_usleep(busy_us);
+   t_busy = measured_usleep(busy_us);
igt_spin_batch_end(spin);
gem_sync(gem_fd, obj.handle);
 
-   total_busy_ns += igt_nsec_elapsed(_busy);
+   total_busy_ns += t_busy;
 
target_idle_us =
(100 * total_busy_ns / target_busy_pct 
- (total_busy_ns + total_idle_ns)) / 1000;
@@ -1569,12 +1574,13 @@ accuracy(int gem_fd, const struct 
intel_execution_engine2 *e,
igt_spin_batch_free(gem_fd, spin);
}
 
+   fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
+
/* Let the child run. */
read(link[0], , sizeof(expected));
-   assert_within_epsilon(expected, target_busy_pct/100., 0.05);
+   assert_within(100.0 * expected, target_busy_pct, 5);
 
/* Collect engine busyness for an interesting part of child runtime. */
-   fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
val[0] = __pmu_read_single(fd, [0]);
read(link[0], , sizeof(expected));
val[1] = __pmu_read_single(fd, [1]);
@@ -1590,8 +1596,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
igt_info("error=%.2f%% (%.2f%% vs %.2f%%)\n",
 __error(busy_r, expected), 100 * busy_r, 100 * expected);
 
-   assert_within_epsilon(busy_r, expected, 0.15);
-   assert_within_epsilon(1 - busy_r, 1 - expected, 0.15);
+   assert_within(100.0 * busy_r, 100.0 * expected, 2);
 }
 
 igt_main
-- 
2.14.1