Re: [Intel-gfx] [PATCH] drm/i915: Remove pre-production pooled-EU w/a for Broxton

[Jani Nikula]

On Thu, 16 Nov 2017, Rodrigo Vivi  wrote:
> On Thu, Nov 16, 2017 at 09:22:23AM +, Jani Nikula wrote:
>> On Wed, 15 Nov 2017, Chris Wilson  wrote:
>> > Quoting David Weinehall (2017-11-15 18:01:41)
>> >> On Tue, Nov 14, 2017 at 01:51:16PM +, Chris Wilson wrote:
>> >> > WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported
>> >> > since commit 0102ba1fd8af ("drm/i915: Add early BXT sdv to the list of
>> >> > preproduction machines").
>> >> > 
>> >> > Signed-off-by: Chris Wilson 
>> >> > Cc: Jani Nikula 
>> >> 
>> >> Reviewed-by: David Weinehall 
>> >
>> > Ta, hope your sdp is ok in the bin ;)
>> >
>> > Any volunteers for IS_GLK_REVID, IS_KBL_REVID ?
>> >
>> > I see one IS_SKL_REVID that can easily be removed.
>> 
>> Need to know what the first shipped rev was. For example with bxt we
>> apparently can't remove some of the rev checks.
>> 
>> Seems like we should add more checks to intel_detect_preproduction_hw()
>> too.
>
> With the IS_*_REVID in place I'd advocate to leave the workarounds around.
>
> I understand that codes get cleaner if we remove them from here,
> but usually previous pre-prod workarounds are useful reference for
> new platforms power-on...

Perhaps for the gen-1, but not older.

BR,
Jani.

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

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.

[Sagar Arun Kamble]

On 11/17/2017 3:17 AM, Michal Wajdeczko wrote:
On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble 
 wrote:



Typo in the subject.
GLK showing failure to load GuC with this approach on CI.

On 11/15/2017 10:47 PM, Jackie Li wrote:

Static WOPCM partitioning will lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enables the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset is  set to
HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM space.

v2:
  - Removed intel_wopcm_init (Ville/Sagar/Joonas)
  - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
  - Removed unnecessary function calls (Joonas)
  - Init GuC WOPCM partition as soon as firmware fetching is completed

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
  drivers/gpu/drm/i915/i915_guc_reg.h |  18 +++--
  drivers/gpu/drm/i915/intel_guc.c    |  25 ---
  drivers/gpu/drm/i915/intel_guc.h    |  25 +++
  drivers/gpu/drm/i915/intel_huc.c    |   2 +-
  drivers/gpu/drm/i915/intel_uc.c | 116 
+++-

  drivers/gpu/drm/i915/intel_uc_fw.c  |  11 ++-
  7 files changed, 163 insertions(+), 38 deletions(-)

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

index 2db0406..285c310 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,12 @@ __create_hw_context(struct drm_i915_private 
*dev_priv,

  ctx->desc_template =
  default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
  -    /* GuC requires the ring to be placed above GUC_WOPCM_TOP. If 
GuC is not
+    /* GuC requires the ring to be placed above GuC WOPCM top. if 
GuC is not
   * present or not in use we still need a small bias as ring 
wraparound

   * at offset 0 sometimes hangs. No idea why.
   */
  if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
-    ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+    ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
  else
  ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
  diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h

index bc1ae7d..567df12 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -67,17 +67,27 @@
  #define DMA_GUC_WOPCM_OFFSET    _MMIO(0xc340)
  #define   HUC_LOADING_AGENT_VCR  (0<<1)
  #define   HUC_LOADING_AGENT_GUC  (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE  0x8    /* 512KB */
  #define GUC_MAX_IDLE_COUNT    _MMIO(0xC3E4)
    #define HUC_STATUS2 _MMIO(0xD3B0)
  #define   HUC_FW_VERIFIED   (1<<7)
    /* Defines WOPCM space available to GuC firmware */
+/* Default WOPCM size 1MB */
+#define WOPCM_DEFAULT_SIZE    (0x1 << 20)
possible to get this size from register GEN6_STOLEN_RESERVED 
(ggtt->stolen_reserved_size)

+/* Reserved WOPCM size 16KB */
+#define WOPCM_RESERVED_SIZE    (0x4000)
+/* GUC WOPCM Offset need to be 16KB aligned */
+#define WOPCM_OFFSET_ALIGNMENT    (0x4000)

prefix this with GUC_ as it is specific to GuC in WOPCM

+/* 8KB stack reserved for GuC FW*/
+#define GUC_WOPCM_STACK_RESERVED    (0x2000)
+/* 24KB WOPCM reserved for RC6 CTX on BXT */
+#define BXT_WOPCM_RC6_RESERVED    (0x6000)
+
+#define GEN9_GUC_WOPCM_DELTA    4
+#define GEN9_GUC_WOPCM_OFFSET    (0x24000)


I'm not sure that definitions unrelated to register bits shall
be defined here


+
  #define GUC_WOPCM_SIZE    _MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)    /* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED  (0x10 << 12)    /* 64KB  */
    /* GuC addresses above GUC_GGTT_TOP also don't map through the 
GTT */

  #define GUC_GGTT_TOP    0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 9678630..0c6bd63 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -337,7 +337,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)
   * This is a wrapper to create an object for use with the GuC. In 
order to
   * use it inside the GuC, an object needs to be pinned lifetime, 
so we allocate
   * both some backing 

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:56 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_edid.c | 23 +--
   1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
   {
+   enum hdmi_picture_aspect picture_aspect;
int err;
   
   	if (!frame || !mode)

@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);

This is slightly going in the loop.
- During the modeset the driver cant specify the aspect ratio
information, as DRM layer lacks this support.
- So we fill the VIC field, by comparing the mode with the
DRM_CEA_MODES[] list. This will pick the first mode
available in the list (regardless of its aspect ratio), and fill the
VIC, as we don't consider aspect ratio while comparing timings.
- Again, now while sending the aspect ratio, we are picking up the VIC,
which may not be correct.

So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is
first in list, we will always pick 4:3 aspect ratio.

Yes. The user didn't care about the aspect ratio (or rather couldn't
specify one) so we just pick one. Which is exactly what we've been
doing ever since we started sending the VIC in the infoframe.
Correct, and we are hoping that this should be better (if not fixed) 
with the aspect ratio support
patches + DRM cap. If the userspace doesn't set the cap, then anyways 
there is no aspect ratio

field available, and VIC would be always 0, as this becomes a Non CEA mode.

Or do you think it would be a better idea to send some VIC instead of No 
VIC, when userspace doesn't

set the DRM cap for aspect ratio ?

- Shashank

- Shashank
   
+	/*

+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
   


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

Re: [Intel-gfx] [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:53 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_edid.c | 18 ++
   1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
   static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

This doesn't look right. This means we are expecting a CEA mode without
a pic aspect ratio field,
which is invalid.

No, it's perfectly valid. It's what we currently get from userspace.
Yep, but that's due to missing Aspect ratio handling in the DRM layer. 
If that's fixed, as per the list of CEA modes,
each CEA VIC contains an aspect ratio, which is a part of its unique 
identity.


I guess once we have the aspect ratio handling in DRM layer, it 
would/should look like this:

- EDID gives you all supported modes, including CEA modes with Aspect ratio
- Userspcae gets the mode information, with aspect ratio (for CEA modes)
If ( Userspace picks one of the CEA modes)
- sends a modeset
- we find a matching CEA VIC, found one from modedb
- we load this VIC = nonzero information in AVI IF VIC field,
else
- sends a modeset
- we could not find a matching CEA VIC, as aspect ratio is 0
- we make VIC field in AVI IF as 0

This is important, as HDMI compliance test 7-27 inspects if the VIC 
field in the AVI IF is accurate.


- Shashank

Ankit is going to publish the aspect ratio patch
series again, with proper DRM cap and flags check. Would it be
ok if we have a look that handling first ?

This patch will be needed by that work. Otherwise we're going to stop
sending a VIC for CEA modes with current userspace.
I guess we should force userspaces to start bothering about aspect ratio 
field, right now we
are doing this for Wayland based compositors, may be we should extend it 
to X based too.


- Shashank



+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
   
   		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
*/
   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

same here, and probably in other CEA match functions.

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct 

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:51 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which
talks about
switch from 3D to 2D.  To me it looks like:
If (sending_to_hdmi2_sinks) {
  - for 3d modes send HF-VSIF
  - for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
When you switch from 3d->2d {
   - send_HF-VSIF with 3D_valid bit = 0/1
   }
} else { /* HDMI 1.4b sinks from Appendix F */
  -  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
}

Should we add a is_hdmi2 check and separate these cases ?

We don't support the HDMI forum infoframe. Maybe someone forgot to
implement that when adding the rest of HDMI 2.0 support? ;)

How to make an 'embarrassed smile ' smiley :) ?
Will start looking into it. Meanwhile
Reviewed-by: Shashank Sharma 

v2: Fix the getting has_hdmi_infoframe from display_info
  Always fail constructing the infoframe if the display
  possibly can't handle it

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
   drivers/gpu/drm/drm_edid.c| 34 
+--
   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
   drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
   drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
   drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
   drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
   drivers/gpu/drm/zte/zx_hdmi.c |  1 +
   include/drm/drm_connector.h   |  5 +
   include/drm/drm_edid.h|  1 +
   12 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..4417276ba02e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
union hdmi_infoframe frm;
u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
   
+			/* FIXME: We need the connector here */

drm_hdmi_vendor_infoframe_from_display_mode(
-   , adjusted_mode);
+   , NULL, adjusted_mode);
vic = frm.vendor.hdmi.vic;
if (vic >= ARRAY_SIZE(mhl_vic))
vic = 0;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a64ce7112288..b172139502d6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct 
dw_hdmi *hdmi,
u8 buffer[10];
ssize_t err;
   
-	err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode);
if (err < 0)
/*
 * Going into that statement does not means vendor infoframe
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..9ada0ccf50df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3393,6 +3393,7 @@ static int
   do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
   const u8 *video_db, u8 video_len)
   {
+   struct drm_display_info *info = 

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:46 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.

v2: Handle unpack() as well
  Pull the length calculation into a helper

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Reviewed-by: Andrzej Hajda  #v1
Signed-off-by: Ville Syrjälä 
---
   drivers/video/hdmi.c | 51 +++
   1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
hdmi_vendor_infoframe *frame)
   }
   EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
   
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)

+{
+   /* for side by side (half) we also need to provide 3D_Ext_Data */
+   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   return 6;
+   else if (frame->vic != 0 || frame->s3d_struct != 
HDMI_3D_STRUCTURE_INVALID)
+   return 5;
+   else
+   return 4;
+}
+
   /**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
   
-	/* empty info frame */

-   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
-   return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
   
-	/* for side by side (half) we also need to provide 3D_Ext_Data */

-   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
-   frame->length = 6;
-   else
-   frame->length = 5;
+   frame->length = hdmi_vendor_infoframe_length(frame);
   
   	length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
   
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,

ptr[5] = 0x0c;
ptr[6] = 0x00;
   
-	if (frame->vic) {

-   ptr[7] = 0x1 << 5;/* video format */
-   ptr[8] = frame->vic;
-   } else {
+   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5;/* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+   } else if (frame->vic) {

Please correct me if I dint understand this properly, but for a HDMI 2.0
sink + 3D transmission, wouldn't I be sending
HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

That vic will be in the AVI infoframe. Here we're concerned about the
VIC in the HDMI vendor infoframe.
Yep, I was thinking if there is any way we can cross check that there is 
a valid HDMI 2 vic

before we do anything here, but seems like a long shot.

Reviewed-by: Shashank Sharma 

- Shashank

+   ptr[7] = 0x1 << 5;/* video format */
+   ptr[8] = frame->vic;
+   } else {
+   ptr[7] = 0x0 << 5;/* video format */
}
   
   	hdmi_infoframe_set_checksum(buffer, length);

@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
   
   	if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||

ptr[1] != 1 ||
-   (ptr[2] != 5 && ptr[2] != 6))
+   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
   
   	length = ptr[2];

@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
   
   	hvf->length = length;
   
-	if (hdmi_video_format == 0x1) {

-   hvf->vic = ptr[4];
-   } else if (hdmi_video_format == 0x2) {
+   if (hdmi_video_format == 0x2) {
+   if (length != 5 && length != 6)
+   return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= 

[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"
URL   : https://patchwork.freedesktop.org/series/33969/
State : success

== Summary ==

Test drv_selftest:
Subgroup mock_sanitycheck:
dmesg-warn -> PASS   (shard-hsw) fdo#103719
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (shard-hsw) fdo#103375
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-toggle:
pass   -> FAIL   (shard-hsw) fdo#102670
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#103719 https://bugs.freedesktop.org/show_bug.cgi?id=103719
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2584 pass:1471 dwarn:1   dfail:1   fail:12  skip:1099 
time:9470s
shard-snbtotal:2584 pass:1259 dwarn:2   dfail:1   fail:11  skip:1311 
time:8014s
Blacklisted hosts:
shard-apltotal:2584 pass:1622 dwarn:2   dfail:2   fail:22  skip:936 
time:13351s
shard-kbltotal:2482 pass:1634 dwarn:15  dfail:4   fail:21  skip:805 
time:9835s

== Logs ==

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

Re: [Intel-gfx] [GIT PULL] gvt-next for 4.16

[Zhenyu Wang]

On 2017.11.16 12:20:14 -0800, Rodrigo Vivi wrote:
> Hi Zhenyu,
> 
> On Thu, Nov 16, 2017 at 09:20:07AM +, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > As we missed 4.15 cycle, here's the bigger initial 4.16 gvt-next pull,
> > which includes many improvements as noted below.
> > 
> > thanks
> > 
> > --
> > The following changes since commit 34cc9efc27e2623c76a69d2ad1fa2b972e27a2c1:
> > 
> >   drm/i915: Remove pre-production pooled-EU w/a for Broxton (2017-11-15 
> > 18:04:18 +)
> > 
> > are available in the Git repository at:
> 
> this capital "G" broke dim here... It took me a while to figure out what
> was going wrong.
> 
> How did you generate this pull request? Why this "g" is in capital?
>

I'm using git 2.15-rc2, so found below one.

commit e66d7c37a5f123f1dcede06ac0e11f9254c3ef46
Author: Ann T Ropea 
Date:   Tue Oct 3 00:08:38 2017 +

request-pull: capitalise "Git" to make it a proper noun

Of the many ways to spell the three-letter word, the variant "Git"
should be used when referring to a repository in a description; or, in
general, when it is used as a proper noun.

We thus change the pull-request template message so that it reads

   "...in the Git repository at:"

Besides, this brings us in line with the documentation, see
Documentation/howto/using-signed-tag-in-pull-request.txt

Signed-off-by: Ann T Ropea 
Acked-by: Jonathan Nieder 
Reviewed-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano 

diff --git a/git-request-pull.sh b/git-request-pull.sh
index eebd33276da9..13c172bd94fc 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -128,7 +128,7 @@ git show -s --format='The following changes since commit %H:

   %s (%ci)

-are available in the git repository at:
+are available in the Git repository at:
 ' $merge_base &&
  echo "  $url $pretty_remote" &&
   git show -s --format='


> Anyway I workarounded it here and pulled your changes into dinq.
>

thanks!

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"
URL   : https://patchwork.freedesktop.org/series/33969/
State : success

== Summary ==

Series 33969v1 Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"
https://patchwork.freedesktop.org/api/1.0/series/33969/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#103163

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:454s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:280s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:508s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:497s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:435s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:467s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:534s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:575s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s
Blacklisted hosts:
fi-cfl-s2total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:471s

6e008f5fb186b924d5a31f284b564b6955e9a511 drm-tip: 2017y-11m-16d-20h-16m-50s UTC 
integration manifest
3afde6f1ff39 Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

== Logs ==

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

[Intel-gfx] [PATCH] Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

[Radhakrishna Sripada]

This reverts commit 8f067837c4b713ce2e69be95af7b2a5eb3bd7de8.

HSD says "WA withdrawn. It was causing corruption with some images.
WA is not strictly necessary since this bug just causes loss of FBC
compression with some sizes and images, but doesn't break anything."

Cc: Rodrigo Vivi 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 ---
 drivers/gpu/drm/i915/intel_pm.c | 12 
 2 files changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 107e2d7c9fba..96c80fa0fcac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2985,9 +2985,6 @@ enum i915_power_well_id {
 #define ILK_DPFC_CHICKEN   _MMIO(0x43224)
 #define   ILK_DPFC_DISABLE_DUMMY0 (1<<8)
 #define   ILK_DPFC_NUKE_ON_ANY_MODIFICATION(1<<23)
-#define   GLK_SKIP_SEG_EN  (1<<12)
-#define   GLK_SKIP_SEG_COUNT_MASK  (3<<10)
-#define   GLK_SKIP_SEG_COUNT(x)((x)<<10)
 #define ILK_FBC_RT_BASE_MMIO(0x2128)
 #define   ILK_FBC_RT_VALID (1<<0)
 #define   SNB_FBC_FRONT_BUFFER (1<<1)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8c69ec9eb6ee..4d2a7e4d91a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -121,7 +121,6 @@ static void bxt_init_clock_gating(struct drm_i915_private 
*dev_priv)
 
 static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
 {
-   u32 val;
gen9_init_clock_gating(dev_priv);
 
/*
@@ -141,11 +140,6 @@ static void glk_init_clock_gating(struct drm_i915_private 
*dev_priv)
I915_WRITE(CHICKEN_MISC_2, val);
}
 
-   /* Display WA #1133: WaFbcSkipSegments:glk */
-   val = I915_READ(ILK_DPFC_CHICKEN);
-   val &= ~GLK_SKIP_SEG_COUNT_MASK;
-   val |= GLK_SKIP_SEG_EN | GLK_SKIP_SEG_COUNT(1);
-   I915_WRITE(ILK_DPFC_CHICKEN, val);
 }
 
 static void i915_pineview_get_mem_freq(struct drm_i915_private *dev_priv)
@@ -8478,12 +8472,6 @@ static void cnl_init_clock_gating(struct 
drm_i915_private *dev_priv)
if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
val |= SARBUNIT_CLKGATE_DIS;
I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
-
-   /* Display WA #1133: WaFbcSkipSegments:cnl */
-   val = I915_READ(ILK_DPFC_CHICKEN);
-   val &= ~GLK_SKIP_SEG_COUNT_MASK;
-   val |= GLK_SKIP_SEG_EN | GLK_SKIP_SEG_COUNT(1);
-   I915_WRITE(ILK_DPFC_CHICKEN, val);
 }
 
 static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v2 10/10] drm/i915: Add rudimentary plane state verification

[James Ausmus]

On Thu, Nov 02, 2017 at 06:38:32PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Check that the planes are in the state we expect them to be. For
> now we can only check whether each plane is correctly enabled or
> disabled. In the future we may want to expand the plane state
> readout to support a more through verification.

s/through/thorough/

> 
> v2: Verify all planes part of the state as long as at lest

s/lest/least

> one crtc is doing a modeset (Daniel)
> 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

With those nits fixed:

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c23dad6d3c24..96e0a5fd69cf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11537,6 +11537,18 @@ verify_crtc_state(struct drm_crtc *crtc,
>  }
>  
>  static void
> +intel_verify_planes(struct intel_atomic_state *state)
> +{
> + struct intel_plane *plane;
> + const struct intel_plane_state *plane_state;
> + int i;
> +
> + for_each_new_intel_plane_in_state(state, plane,
> +   plane_state, i)
> + assert_plane(plane, plane_state->base.visible);
> +}
> +
> +static void
>  verify_single_dpll_state(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll,
>struct drm_crtc *crtc,
> @@ -12329,6 +12341,9 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   intel_modeset_verify_crtc(crtc, state, old_crtc_state, 
> new_crtc_state);
>   }
>  
> + if (intel_state->modeset)
> + intel_verify_planes(intel_state);
> +
>   if (intel_state->modeset && intel_can_enable_sagv(state))
>   intel_enable_sagv(dev_priv);
>  
> -- 
> 2.13.6
> 
> ___
> 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 09/10] drm/i915: Use plane->get_hw_state() for initial plane fb readout

[James Ausmus]

On Fri, Oct 13, 2017 at 04:58:38PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Since we now have a ->get_hw_state() method for planes, let's use
> that during the initial plane fb readout.
> 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 30 --
>  1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2da670628e35..268d320690f4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7465,19 +7465,20 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
>   struct drm_framebuffer *fb;
>   struct intel_framebuffer *intel_fb;
>  
> + if (!plane->get_hw_state(plane))
> + return;
> +
> + intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
> + if (!intel_fb) {
> + DRM_DEBUG_KMS("failed to alloc fb\n");
> + return;
> + }
> +
> + fb = _fb->base;
> +
> + fb->dev = dev;
> +
>   val = I915_READ(DSPCNTR(plane_id));
> - if (!(val & DISPLAY_PLANE_ENABLE))
> - return;
> -
> - intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
> - if (!intel_fb) {
> - DRM_DEBUG_KMS("failed to alloc fb\n");
> - return;
> - }
> -
> - fb = _fb->base;
> -
> - fb->dev = dev;
>  
>   if (INTEL_GEN(dev_priv) >= 4) {
>   if (val & DISPPLANE_TILED) {
> @@ -8496,6 +8497,9 @@ skylake_get_initial_plane_config(struct intel_crtc 
> *crtc,
>   struct drm_framebuffer *fb;
>   struct intel_framebuffer *intel_fb;
>  
> + if (!plane->get_hw_state(plane))
> + return;
> +
>   intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
>   if (!intel_fb) {
>   DRM_DEBUG_KMS("failed to alloc fb\n");
> @@ -8507,8 +8511,6 @@ skylake_get_initial_plane_config(struct intel_crtc 
> *crtc,
>   fb->dev = dev;
>  
>   val = I915_READ(PLANE_CTL(pipe, plane_id));
> - if (!(val & PLANE_CTL_ENABLE))
> - goto error;
>  
>   pixel_format = val & PLANE_CTL_FORMAT_MASK;
>   fourcc = skl_format_to_fourcc(pixel_format,
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

[Chris Wilson]

Quoting Chris Wilson (2017-11-16 22:25:45)
> Quoting Chris Wilson (2017-11-16 22:11:30)
> > If we are about to do another context-switch in the near future skip
> > doing performing a lite-restore now. (Forcing a lite-restore just before
> > a context-switch effectively doubles the cost of that context-switch, so
> > long as we can handle the interrupt and resubmit before the GPU powers
> > down, which under normal conditions is expected.)
> > 
> > Coincidentally, skipping a lite-restore just before idling also prevents
> > (not entirely, but the window for occurrence now depends on the next
> > context completing within the same period and we have already noted that
> > we can resubmit faster than the GPU can context switch to make this
> > worthwhile) an issue on bxt/glk where it may become confused in an attempt
> > to lite-restore an already idle context, after which nothing is quite the
> > same again.
> 
> Well only testing will tell...

The answer is no. (Though BAT hit an entirely new and scary problem.)

We can go back to the discussion of when we might not want to
lite-restore in peace, without the nuisance of trying to w/a hw features.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 03/10] drm/i915: s/enum plane/enum i9xx_plane_id/

[James Ausmus]

On Mon, Oct 23, 2017 at 05:50:32PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Rename enum plane to enum i9xx_plane_id to make it clear that it only
> applies to pre-SKL platforms.
> 
> enum i9xx_plane_id is a global identifier, whereas enum plane_id is
> per-pipe. We need the old global identifier to index the primary plane
> (and the pre-g4x sprite C if we ever expose it) registers on pre-SKL
> platforms.
> 
> v2: Reorder patches
> v3: s/old_plane_id/i9xx_plane_id/ (Daniel)
> Pimp the commit message a bit
> Note that i9xx_plane_id doesn't apply to SKL+
> v4: Rebase due to power domain handling in plane readout
> v5: Rebase due to crtc->dspaddr_offset removal
> 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  6 +--
>  drivers/gpu/drm/i915/intel_display.c | 87 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h |  6 +--
>  3 files changed, 49 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 54b5d4c582b6..a6b912c646f9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -305,9 +305,9 @@ static inline bool transcoder_is_dsi(enum transcoder 
> transcoder)
>  
>  /*
>   * Global legacy plane identifier. Valid only for primary/sprite
> - * planes on pre-g4x, and only for primary planes on g4x+.
> + * planes on pre-g4x, and only for primary planes on g4x-bdw.
>   */
> -enum plane {
> +enum i9xx_plane_id {
>   PLANE_A,
>   PLANE_B,
>   PLANE_C,
> @@ -1137,7 +1137,7 @@ struct intel_fbc {
>  
>   struct {
>   enum pipe pipe;
> - enum plane plane;
> + enum i9xx_plane_id plane;
>   unsigned int fence_y_offset;
>   } crtc;
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4ea0f1ef249e..e726b65588aa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3223,16 +3223,16 @@ int i9xx_check_plane_surface(struct intel_plane_state 
> *plane_state)
>   return 0;
>  }
>  
> -static void i9xx_update_primary_plane(struct intel_plane *primary,
> -   const struct intel_crtc_state *crtc_state,
> -   const struct intel_plane_state 
> *plane_state)
> +static void i9xx_update_plane(struct intel_plane *plane,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct intel_plane_state *plane_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(primary->base.dev);
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
>   const struct drm_framebuffer *fb = plane_state->base.fb;
> - enum plane plane = primary->plane;
> + enum i9xx_plane_id plane_id = plane->plane;

It feels a bit ugly and counter-intuitive to have the two "plane"s in
"plane->plane" be different types - since i9xx_plane_id is a global id,
would it make sense to change the member naming to plane_gid or some
such (both in struct intel_plane and in struct intel_fbc->crtc)? It
feels like struct intel_plane should continue to be "plane", but we need
something else for enum i9xx_plane_id just for clarity's sake.

>   u32 linear_offset;
>   u32 dspcntr = plane_state->ctl;
> - i915_reg_t reg = DSPCNTR(plane);
> + i915_reg_t reg = DSPCNTR(plane_id);
>   int x = plane_state->main.x;
>   int y = plane_state->main.y;
>   unsigned long irqflags;
> @@ -3251,34 +3251,34 @@ static void i9xx_update_primary_plane(struct 
> intel_plane *primary,
>   /* pipesrc and dspsize control the size that is scaled from,
>* which should always be the user's requested size.
>*/
> - I915_WRITE_FW(DSPSIZE(plane),
> + I915_WRITE_FW(DSPSIZE(plane_id),
> ((crtc_state->pipe_src_h - 1) << 16) |
> (crtc_state->pipe_src_w - 1));
> - I915_WRITE_FW(DSPPOS(plane), 0);
> - } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
> - I915_WRITE_FW(PRIMSIZE(plane),
> + I915_WRITE_FW(DSPPOS(plane_id), 0);
> + } else if (IS_CHERRYVIEW(dev_priv) && plane_id == PLANE_B) {
> + I915_WRITE_FW(PRIMSIZE(plane_id),
> ((crtc_state->pipe_src_h - 1) << 16) |
> (crtc_state->pipe_src_w - 1));
> - I915_WRITE_FW(PRIMPOS(plane), 0);
> - I915_WRITE_FW(PRIMCNSTALPHA(plane), 0);
> + I915_WRITE_FW(PRIMPOS(plane_id), 0);
> + I915_WRITE_FW(PRIMCNSTALPHA(plane_id), 0);
>   }
>  
>   I915_WRITE_FW(reg, dspcntr);
>  
> - I915_WRITE_FW(DSPSTRIDE(plane), 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Skip a lite-restore immediately prior to a 
context-completion
URL   : https://patchwork.freedesktop.org/series/33965/
State : failure

== Summary ==

Series 33965v1 drm/i915/execlists: Skip a lite-restore immediately prior to a 
context-completion
https://patchwork.freedesktop.org/api/1.0/series/33965/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-uc-pro-default:
pass   -> DMESG-FAIL (fi-bdw-5557u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-bdw-5557u)

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

fi-bdw-5557u total:289  pass:266  dwarn:1   dfail:1   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:460s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:547s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:519s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:499s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:427s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:261s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:439s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:433s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:535s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:568s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:463s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
Blacklisted hosts:
fi-cfl-s2total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-cnl-y total:239  pass:213  dwarn:1   dfail:0   fail:0   skip:24 

6e008f5fb186b924d5a31f284b564b6955e9a511 drm-tip: 2017y-11m-16d-20h-16m-50s UTC 
integration manifest
dfbe71af19cd drm/i915/execlists: Skip a lite-restore immediately prior to a 
context-completion

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v5,1/2] drm/i915/selftests: Add a GuC doorbells selftest

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/2] drm/i915/selftests: Add a GuC doorbells 
selftest
URL   : https://patchwork.freedesktop.org/series/33964/
State : warning

== Summary ==

Series 33964v1 series starting with [v5,1/2] drm/i915/selftests: Add a GuC 
doorbells selftest
https://patchwork.freedesktop.org/api/1.0/series/33964/revisions/1/mbox/

Test gem_sync:
Subgroup basic-many-each:
pass   -> FAIL   (fi-kbl-7567u) fdo#103165
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:454s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:388s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:508s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:497s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:439s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:436s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:481s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:289  pass:268  dwarn:0   dfail:0   fail:1   skip:20  
time:485s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:581s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:526s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:34 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:419s
Blacklisted hosts:
fi-cfl-s2total:289  pass:260  dwarn:0   dfail:0   fail:1   skip:28  
time:474s

6e008f5fb186b924d5a31f284b564b6955e9a511 drm-tip: 2017y-11m-16d-20h-16m-50s UTC 
integration manifest
e2e46dc388fb HAX enable GuC submission for CI
0d5e9efc2643 drm/i915/selftests: Add a GuC doorbells selftest

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

[Chris Wilson]

Quoting Chris Wilson (2017-11-16 22:11:30)
> If we are about to do another context-switch in the near future skip
> doing performing a lite-restore now. (Forcing a lite-restore just before
> a context-switch effectively doubles the cost of that context-switch, so
> long as we can handle the interrupt and resubmit before the GPU powers
> down, which under normal conditions is expected.)
> 
> Coincidentally, skipping a lite-restore just before idling also prevents
> (not entirely, but the window for occurrence now depends on the next
> context completing within the same period and we have already noted that
> we can resubmit faster than the GPU can context switch to make this
> worthwhile) an issue on bxt/glk where it may become confused in an attempt
> to lite-restore an already idle context, after which nothing is quite the
> same again.

Well only testing will tell...

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102035
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 5a22bdffd387..5272eb23d98a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -584,6 +584,25 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
> if (port_count([1]))
> goto unlock;
>  
> +   /*
> +* If we are about to do another context-switch in
> +* the near future skip doing performing a 
> lite-restore
> +* now. (Forcing a lite-restore just before a
> +* context-switch effectively doubles the cost of that
> +* context-switch, so long as we can handle the
> +* interrupt and resubmit before the GPU powers down,
> +* which under normal conditions is expected.)
> +*
> +* Skipping a lite-restore just before idling also
> +* prevents an issue on bxt/glk where it may become
> +* confused in an attempt to lite-restore an already
> +* idle context, after which nothing is quite the same
> +* again.
> +*/
> +   if (i915_seqno_passed(intel_engine_get_seqno(engine),
> + last->global_seqno - 1))
> +   goto unlock;
> +
> /* WaIdleLiteRestore:bdw,skl
>  * Apply the wa NOOPs to prevent
>  * ring:HEAD == req:TAIL as we resubmit the

The subtext is that lite-restore are pointless... Not sure I fully agree
yet; in most scenarios pointless. The last time I was thinking of only
doing the lite-restore iff we were on the last request, otherwise we are
just interrupting a request which already has a continuation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/execlists: Skip a lite-restore immediately prior to a context-completion

[Chris Wilson]

If we are about to do another context-switch in the near future skip
doing performing a lite-restore now. (Forcing a lite-restore just before
a context-switch effectively doubles the cost of that context-switch, so
long as we can handle the interrupt and resubmit before the GPU powers
down, which under normal conditions is expected.)

Coincidentally, skipping a lite-restore just before idling also prevents
(not entirely, but the window for occurrence now depends on the next
context completing within the same period and we have already noted that
we can resubmit faster than the GPU can context switch to make this
worthwhile) an issue on bxt/glk where it may become confused in an attempt
to lite-restore an already idle context, after which nothing is quite the
same again.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102035
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5a22bdffd387..5272eb23d98a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -584,6 +584,25 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
if (port_count([1]))
goto unlock;
 
+   /*
+* If we are about to do another context-switch in
+* the near future skip doing performing a lite-restore
+* now. (Forcing a lite-restore just before a
+* context-switch effectively doubles the cost of that
+* context-switch, so long as we can handle the
+* interrupt and resubmit before the GPU powers down,
+* which under normal conditions is expected.)
+*
+* Skipping a lite-restore just before idling also
+* prevents an issue on bxt/glk where it may become
+* confused in an attempt to lite-restore an already
+* idle context, after which nothing is quite the same
+* again.
+*/
+   if (i915_seqno_passed(intel_engine_get_seqno(engine),
+ last->global_seqno - 1))
+   goto unlock;
+
/* WaIdleLiteRestore:bdw,skl
 * Apply the wa NOOPs to prevent
 * ring:HEAD == req:TAIL as we resubmit the
-- 
2.15.0

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

[Intel-gfx] [PATCH v5 2/2] HAX enable GuC submission for CI

[Michel Thierry]

From: Michal Wajdeczko 

Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
 drivers/gpu/drm/i915/i915_params.h  | 4 ++--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f92a39fc511c..5bbb3be85f11 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3590,17 +3590,13 @@ int i915_ggtt_enable_hw(struct drm_i915_private 
*dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c7292268ed43..c38cef07b9fe 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -44,8 +44,8 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc_loading, 0) \
-   param(int, enable_guc_submission, 0) \
+   param(int, enable_guc_loading, 1) \
+   param(int, enable_guc_submission, 1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.15.0

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

[Intel-gfx] [PATCH v5 1/2] drm/i915/selftests: Add a GuC doorbells selftest

[Michel Thierry]

The first test aims to check guc_init_doorbell_hw, changing the existing
guc clients and doorbells state before calling it.

The second test tries to create as many clients as it is currently possible
(currently limited to max number of doorbells) and exercise the doorbell
alloc/dealloc code.

Since our usage mode require very few clients/doorbells, this code has
been exercised very lightly and it's good to have a simple test for it.

As reference, this test already helped identify the bug fixed by
commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").

v2: Extend number of clients; check for client allocation failure when
number of doorbells is exceeded; validate client properties; reuse
guc_init_doorbell_hw (Chris).

v3: guc_init_doorbell_hw test added per Chris suggestion.

v4: Try to explain why guc_init_doorbell_hw exist and comment some
details in the subtest.

v5: Remove redundant pr_info at the beginning of each subtest (Chris);
rebase (s/i915_guc_client/intel_guc_client/).

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c|   4 +
 .../gpu/drm/i915/selftests/i915_live_selftests.h   |   1 +
 drivers/gpu/drm/i915/selftests/intel_guc.c | 360 +
 3 files changed, 365 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/intel_guc.c

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 9c9e6edfd5be..cbf5a96f5806 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1475,3 +1475,7 @@ void intel_guc_submission_disable(struct intel_guc *guc)
 
guc_clients_destroy(guc);
 }
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftests/intel_guc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h 
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index d7dd98a6acad..088f45bc6199 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -20,3 +20,4 @@ selftest(evict, i915_gem_evict_live_selftests)
 selftest(hugepages, i915_gem_huge_page_live_selftests)
 selftest(contexts, i915_gem_context_live_selftests)
 selftest(hangcheck, intel_hangcheck_live_selftests)
+selftest(guc, intel_guc_live_selftest)
diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
b/drivers/gpu/drm/i915/selftests/intel_guc.c
new file mode 100644
index ..048545a79285
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -0,0 +1,360 @@
+/*
+ * Copyright © 2017 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 "../i915_selftest.h"
+
+/* max doorbell number + negative test for each client type */
+#define ATTEMPTS (GUC_NUM_DOORBELLS + GUC_CLIENT_PRIORITY_NUM)
+
+struct intel_guc_client *clients[ATTEMPTS];
+
+static bool available_dbs(struct intel_guc *guc, u32 priority)
+{
+   unsigned long offset;
+   unsigned long end;
+   u16 id;
+
+   /* first half is used for normal priority, second half for high */
+   offset = 0;
+   end = GUC_NUM_DOORBELLS/2;
+   if (priority <= GUC_CLIENT_PRIORITY_HIGH) {
+   offset = end;
+   end += offset;
+   }
+
+   id = find_next_zero_bit(guc->doorbell_bitmap, end, offset);
+   if (id < end)
+   return true;
+
+   return false;
+}
+
+static int check_all_doorbells(struct intel_guc *guc)
+{
+   u16 db_id;
+
+   pr_info_once("Max number of doorbells: %d", GUC_NUM_DOORBELLS);
+   for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id) {
+   if (!doorbell_ok(guc, 

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/selftests: Add a GuC doorbells selftest

[Michel Thierry]

On 11/16/2017 7:10 AM, Chris Wilson wrote:

Quoting Michel Thierry (2017-11-15 18:30:27)

The first test aims to check guc_init_doorbell_hw, changing the existing
guc clients and doorbells state before calling it.

The second test tries to create as many clients as it is currently possible
(currently limited to max number of doorbells) and exercise the doorbell
alloc/dealloc code.

Since our usage mode require very few clients/doorbells, this code has
been exercised very lightly and it's good to have a simple test for it.

As reference, this test already helped identify the bug fixed by
commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").

v2: Extend number of clients; check for client allocation failure when
number of doorbells is exceeded; validate client properties; reuse
guc_init_doorbell_hw (Chris).

v3: guc_init_doorbell_hw test added per Chris suggestion.

v4: Try to explain why guc_init_doorbell_hw exist and comment some
details in the subtest.

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


Rebase, resend with r-bs and lets land this monster.


Thanks, and I will think about ways to mock this.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.

[Michal Wajdeczko]

On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble  
 wrote:



Typo in the subject.
GLK showing failure to load GuC with this approach on CI.

On 11/15/2017 10:47 PM, Jackie Li wrote:

Static WOPCM partitioning will lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enables the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset is  set to
HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM space.

v2:
  - Removed intel_wopcm_init (Ville/Sagar/Joonas)
  - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
  - Removed unnecessary function calls (Joonas)
  - Init GuC WOPCM partition as soon as firmware fetching is completed

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
  drivers/gpu/drm/i915/i915_guc_reg.h |  18 +++--
  drivers/gpu/drm/i915/intel_guc.c|  25 ---
  drivers/gpu/drm/i915/intel_guc.h|  25 +++
  drivers/gpu/drm/i915/intel_huc.c|   2 +-
  drivers/gpu/drm/i915/intel_uc.c | 116  
+++-

  drivers/gpu/drm/i915/intel_uc_fw.c  |  11 ++-
  7 files changed, 163 insertions(+), 38 deletions(-)

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

index 2db0406..285c310 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,12 @@ __create_hw_context(struct drm_i915_private  
*dev_priv,

ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
  -	/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC  
is not
+	/* GuC requires the ring to be placed above GuC WOPCM top. if GuC is  
not
  	 * present or not in use we still need a small bias as ring  
wraparound

 * at offset 0 sometimes hangs. No idea why.
 */
if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
-   ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+   ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
  diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h  
b/drivers/gpu/drm/i915/i915_guc_reg.h

index bc1ae7d..567df12 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -67,17 +67,27 @@
  #define DMA_GUC_WOPCM_OFFSET  _MMIO(0xc340)
  #define   HUC_LOADING_AGENT_VCR (0<<1)
  #define   HUC_LOADING_AGENT_GUC (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
  #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4)
#define HUC_STATUS2 _MMIO(0xD3B0)
  #define   HUC_FW_VERIFIED   (1<<7)
/* Defines WOPCM space available to GuC firmware */
+/* Default WOPCM size 1MB */
+#define WOPCM_DEFAULT_SIZE (0x1 << 20)
possible to get this size from register GEN6_STOLEN_RESERVED  
(ggtt->stolen_reserved_size)

+/* Reserved WOPCM size 16KB */
+#define WOPCM_RESERVED_SIZE(0x4000)
+/* GUC WOPCM Offset need to be 16KB aligned */
+#define WOPCM_OFFSET_ALIGNMENT (0x4000)

prefix this with GUC_ as it is specific to GuC in WOPCM

+/* 8KB stack reserved for GuC FW*/
+#define GUC_WOPCM_STACK_RESERVED   (0x2000)
+/* 24KB WOPCM reserved for RC6 CTX on BXT */
+#define BXT_WOPCM_RC6_RESERVED (0x6000)
+
+#define GEN9_GUC_WOPCM_DELTA   4
+#define GEN9_GUC_WOPCM_OFFSET  (0x24000)


I'm not sure that definitions unrelated to register bits shall
be defined here


+
  #define GUC_WOPCM_SIZE_MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)/* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)/* 64KB  */
/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT  
*/

  #define GUC_GGTT_TOP  0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc.c  
b/drivers/gpu/drm/i915/intel_guc.c

index 9678630..0c6bd63 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -337,7 +337,7 @@ int intel_guc_resume(struct drm_i915_private  
*dev_priv)
   * This is a wrapper to create an object for use with the GuC. In  
order to
   * use it inside the GuC, an object needs to 

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

[Chris Wilson]

Quoting Paulo Zanoni (2017-11-16 20:45:26)
> Em Qui, 2017-11-16 às 20:24 +0200, David Weinehall escreveu:
> > On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote:
> > > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote:
> > > > Now that we have CI, and that pm_rpm fully passes (I guess the
> > > > audio
> > > > folks have implemented proper runtime pm for snd-hda, hooray, pls
> > > > confirm) it's time to enable this again by default.
> > > > 
> > > > Real goal here is to have 1 configuration only that we fully
> > > > support,
> > > > instead of tons of different codes with every user/customer
> > > > tuning it
> > > > differently. And really, power stuff should work by default, and
> > > > should be enabled by everywhere where it is save to do so.
> > > > 
> > > > v2: Completely new commit message, a few years passed since v1
> > > > ...
> > > > 
> > > > Cc: Takashi Iwai 
> > > > Cc: Liam Girdwood 
> > > > Cc: "Yang, Libin" 
> > > > Cc: "Lin, Mengdong" 
> > > > Cc: "Li, Jocelyn" 
> > > > Cc: "Kaskinen, Tanu" 
> > > > Cc: "Zanoni, Paulo R" 
> > > > Signed-off-by: Daniel Vetter 
> > > 
> > > lgtm,
> > > 
> > > Reviewed-by: David Weinehall 
> > 
> > Been testing a bit; test results are a bit discouraging when it comes
> > to
> > idle power consumption.
> > 
> > Our nightly test suite logs idle power consumption before running any
> > tests, after running all tests, and then finally after running
> > powertop --auto-tune.
> > 
> > The before and after cases are similar with and without patch,
> > but not so for the auto-tune case.
> > 
> > Without this patch, powertop --auto-tune yields a massive improvement
> > (on NUC6i5 the power consumption drops with more than a factor of 3),
> > while with this patch the power consumption just drops with 10% or
> > so.
> 
> What happens if you keep the autosuspend delay to 1?

The problem with the extra hpd triggering a render and flip still
remains, but less frequent.

Remove compiz + desktop manager from the picture and see if that cures
it. Then obviously you have to try each of the main desktop managers /
display servers to see which have good/bad behaviour (if my hunch is
correct). And if it does, we can't proceed with an aggressive default,
but will have to recommend that the display managers set it according to
their needs.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

[Chris Wilson]

Quoting Ville Syrjala (2017-11-16 19:14:47)
> From: Ville Syrjälä 
> 
> The current code is trying to be lazy with fences on scanout buffers.
> That looks broken for several reasons:
> * gen2/3 always need a fence for tiled scanout

Which it already gets. All gen2-gen4 are given a fenceable vma.

> * the unpin doesn't know whether we pinned the fence or not so it
>   may unpin something we don't own

Then track it correctly.

> * FBC GTT tracking needs a fence (not sure we have proper fallback
>   for when there is no fence)

Debatable as whether that is worth forcing a fence; the argument being
that you don't want to stall your flip upon eviction which is the
situation you are already in if you didn't get a fence in the first
place.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Add a FIXME about FBC vs. fence. 90/270 degree rotation

[Chris Wilson]

Quoting Ville Syrjala (2017-11-16 19:14:50)
> From: Ville Syrjälä 
> 
> Currently we're pinning the fence for the rotated GTT view. That doesn't
> acually make any sense since the fence is used only for the FBC GTT
> tracking. For that we would want the fence for the normal GTT view
> instead of the rotated view. Too lazy to fix this now so just add a
> FIXME.

The rotated view can't have a fence as its vma is not fenceable.
-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 pre-production pooled-EU w/a for Broxton

[Rodrigo Vivi]

On Thu, Nov 16, 2017 at 09:22:23AM +, Jani Nikula wrote:
> On Wed, 15 Nov 2017, Chris Wilson  wrote:
> > Quoting David Weinehall (2017-11-15 18:01:41)
> >> On Tue, Nov 14, 2017 at 01:51:16PM +, Chris Wilson wrote:
> >> > WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported
> >> > since commit 0102ba1fd8af ("drm/i915: Add early BXT sdv to the list of
> >> > preproduction machines").
> >> > 
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Jani Nikula 
> >> 
> >> Reviewed-by: David Weinehall 
> >
> > Ta, hope your sdp is ok in the bin ;)
> >
> > Any volunteers for IS_GLK_REVID, IS_KBL_REVID ?
> >
> > I see one IS_SKL_REVID that can easily be removed.
> 
> Need to know what the first shipped rev was. For example with bxt we
> apparently can't remove some of the rev checks.
> 
> Seems like we should add more checks to intel_detect_preproduction_hw()
> too.

With the IS_*_REVID in place I'd advocate to leave the workarounds around.

I understand that codes get cleaner if we remove them from here,
but usually previous pre-prod workarounds are useful reference for
new platforms power-on...

Thanks,
Rodrigo.

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

[Rodrigo Vivi]

On Thu, Nov 16, 2017 at 07:14:47PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The current code is trying to be lazy with fences on scanout buffers.
> That looks broken for several reasons:
> * gen2/3 always need a fence for tiled scanout
> * the unpin doesn't know whether we pinned the fence or not so it
>   may unpin something we don't own
> * FBC GTT tracking needs a fence (not sure we have proper fallback
>   for when there is no fence)

Ohh! I wonder if this would also solve few of old PSR cases... PSR re-uses
FBC GTT tracking...

And "fallback" for both is the frontbuffer_tracking

> 
> So to fix this always use a fence for gen2/3, and for primary planes on
> other platforms (for FBC). For sprites and cursor we never need a fence
> so don't even try to get one.  Since we now know whether a fence was
> pinned we can safely unpin it too.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c  |  4 +--
>  drivers/gpu/drm/i915/intel_display.c | 55 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  7 +++--
>  drivers/gpu/drm/i915/intel_fbdev.c   | 17 +--
>  drivers/gpu/drm/i915/intel_overlay.c |  2 +-
>  6 files changed, 66 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2158a758a17d..8c6d0b7ac9a5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3783,7 +3783,7 @@ int __must_check
>  i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool 
> write);
>  struct i915_vma * __must_check
>  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> -  u32 alignment,
> +  u32 alignment, bool needs_fence,
>const struct i915_ggtt_view *view);
>  void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
>  int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 61ba321e9970..af18168e48e3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3944,7 +3944,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
> void *data,
>   */
>  struct i915_vma *
>  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> -  u32 alignment,
> +  u32 alignment, bool needs_fence,
>const struct i915_ggtt_view *view)
>  {
>   struct i915_vma *vma;
> @@ -3997,7 +3997,7 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>* happy to scanout from anywhere within its global aperture.
>*/
>   flags = 0;
> - if (HAS_GMCH_DISPLAY(i915))
> + if (HAS_GMCH_DISPLAY(i915) || needs_fence)
>   flags = PIN_MAPPABLE;
>   vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e6fcbc5abc75..0657e03e871a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2154,8 +2154,21 @@ static unsigned int intel_surf_alignment(const struct 
> drm_framebuffer *fb,
>   }
>  }
>  
> +static bool intel_plane_needs_fence(const struct intel_plane_state 
> *plane_state)
> +{
> + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + struct drm_i915_gem_object *obj = intel_fb_obj(plane_state->base.fb);
> +
> + if (i915_gem_object_get_tiling(obj) == I915_TILING_NONE)
> + return false;
> +
> + return INTEL_GEN(dev_priv) < 4 || plane->id == PLANE_PRIMARY;
> +}
> +
>  struct i915_vma *
> -intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, unsigned int rotation)
> +intel_pin_and_fence_fb_obj(const struct drm_framebuffer *fb,
> +unsigned int rotation, bool needs_fence)
>  {
>   struct drm_device *dev = fb->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2189,11 +2202,16 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer 
> *fb, unsigned int rotation)
>  
>   atomic_inc(_priv->gpu_error.pending_fb_pin);
>  
> - vma = i915_gem_object_pin_to_display_plane(obj, alignment, );
> + vma = i915_gem_object_pin_to_display_plane(obj, alignment,
> +needs_fence, );
>   if (IS_ERR(vma))
>   goto err;
>  
> - if (i915_vma_is_map_and_fenceable(vma)) {
> + if (needs_fence) {
> + int ret;
> +
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

[Paulo Zanoni]

Em Qui, 2017-11-16 às 20:24 +0200, David Weinehall escreveu:
> On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote:
> > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote:
> > > Now that we have CI, and that pm_rpm fully passes (I guess the
> > > audio
> > > folks have implemented proper runtime pm for snd-hda, hooray, pls
> > > confirm) it's time to enable this again by default.
> > > 
> > > Real goal here is to have 1 configuration only that we fully
> > > support,
> > > instead of tons of different codes with every user/customer
> > > tuning it
> > > differently. And really, power stuff should work by default, and
> > > should be enabled by everywhere where it is save to do so.
> > > 
> > > v2: Completely new commit message, a few years passed since v1
> > > ...
> > > 
> > > Cc: Takashi Iwai 
> > > Cc: Liam Girdwood 
> > > Cc: "Yang, Libin" 
> > > Cc: "Lin, Mengdong" 
> > > Cc: "Li, Jocelyn" 
> > > Cc: "Kaskinen, Tanu" 
> > > Cc: "Zanoni, Paulo R" 
> > > Signed-off-by: Daniel Vetter 
> > 
> > lgtm,
> > 
> > Reviewed-by: David Weinehall 
> 
> Been testing a bit; test results are a bit discouraging when it comes
> to
> idle power consumption.
> 
> Our nightly test suite logs idle power consumption before running any
> tests, after running all tests, and then finally after running
> powertop --auto-tune.
> 
> The before and after cases are similar with and without patch,
> but not so for the auto-tune case.
> 
> Without this patch, powertop --auto-tune yields a massive improvement
> (on NUC6i5 the power consumption drops with more than a factor of 3),
> while with this patch the power consumption just drops with 10% or
> so.

What happens if you keep the autosuspend delay to 1?


> 
> Judging by the powertop output it seems as though we're getting a lot
> of
> interrupts from i915.
> 
>  *  *  *   Top 10 Power Consumers   *  *  *
> 
> With patch:
> 
> Usage;Events/s;Category;Description
>   0,5%; 75,1;Interrupt;[124] i915
>   0,3%; 48,4;Process;/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth
> /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
>   0,1%; 42,8;Timer;hrtimer_wakeup
>   0,0%; 34,9;Timer;tick_sched_timer
>   4,2%;  1,1;kWork;i915_hpd_poll_init_work
>   0,1%; 14,0;Process;python2 /opt/scripts/dut/dutlaunch/launch2.py --
> workspace=/opt/jenkins/workspace/Custom_test --iterations=1
> idlepower_before un
>   0,0%; 13,3;Process;[rcu_preempt]
>   0,8%;  1,7;Process;python /opt/scripts/dut/perf-meter.py --avgskip
> 1 --name perf-meter --infofile /tmp/testname GLBenchmark testfw_app
> synmark2 he
>   0,0%;  3,0;Process;compiz
>   0,7%; 0,11;kWork;output_poll_execute
> 
> Without the patch:
> 
> Usage;Events/s;Category;Description
>   0,0%; 29,1;Timer;tick_sched_timer
>   0,1%; 19,9;Process;python2 /opt/scripts/dut/dutlaunch/launch.py --
> workspace=/opt/jenkins/workspace/Nightly_kernel_test/kernel/151077366
> 5/SKL_6260U
>   0,0%; 13,2;Process;[rcu_preempt]
>   0,8%;  1,6;Process;python /opt/scripts/dut/perf-meter.py --avgskip
> 1 --name perf-meter --infofile /tmp/testname GLBenchmark testfw_app
> synmark2 he
>   0,0%;  2,5;Process;compiz
>   0,0%;  1,5;Process;java -jar slave.jar
>   0,0%;  1,2;Interrupt;[3] net_rx(softirq)
>   0,0%;  1,0;kWork;pci_pme_list_scan
>   0,0%;  0,9;Interrupt;[121] xhci_hcd
>   0,1%;  0,5;Process;perf-meter
> 
> As can be seen the i915 driver doesn't even show up without the
> patch,
> while it's the main culprit with the patch.
> 
> Just to eliminate DMC issues I'm going to do another run, but with
> DMC
> v1.27 instead of v1.26.
> 
> 
> Kind regards, David
> 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 8315499452dc..dc24d008d8d4 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -3232,7 +3232,7 @@ void intel_runtime_pm_enable(struct
> > > drm_i915_private *dev_priv)
> > >   struct pci_dev *pdev = dev_priv->drm.pdev;
> > >   struct device *kdev = >dev;
> > >  
> > > - pm_runtime_set_autosuspend_delay(kdev, 1); /* 10s */
> > > + pm_runtime_set_autosuspend_delay(kdev, 100);
> > >   pm_runtime_mark_last_busy(kdev);
> > >  
> > >   /*
> > > @@ -3251,6 +3251,8 @@ void intel_runtime_pm_enable(struct
> > > drm_i915_private *dev_priv)
> > >   pm_runtime_use_autosuspend(kdev);
> > >   }
> > >  
> > > + pm_runtime_allow(kdev);
> > > +
> > >   /*
> > >    * The core calls the driver load handler with an RPM
> > > reference held.
> > >    * We drop that here and will reacquire it during
> > > unloading in
> > > -- 
> > > 2.15.0.rc2
> > > 
> > > 

Re: [Intel-gfx] Supporting Intel GPU tracing in gpuvis

[Michael Sartain]

On Wed, Sep 6, 2017, at 02:09 AM, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-09-06 08:46:50)
> > Hi Pierre,
> > 
> > On Tue, Sep 5, 2017 at 11:15 PM, Pierre-Loup A. Griffais
> >  wrote:
> > > Hi Daniel,
> > >
> > > In the past couple of months we've been working on gpuvis, a GPU tracing
> > > tool similar to GPUView on Windows. It's lower level than other API-based
> > > tracing tools and lets you debug system-wide GPU scheduling issues, eg.
> > > interaction between several processes using the GPU, which is pretty
> > > critical for VR usecases.
> > >
> > > It's all based on ftrace; we've initially developped it with support for
> > > amdgpu, and had to patch the kernel code there to change what tracing 
> > > events
> > > are reported and how. Now that we have a good idea of what's needed and 
> > > it's
> > > more or less proven in production, we were wondering if you had any 
> > > interest
> > > in adding a similar set of events for Intel GPUs so we could read them and
> > > present them the same way? We have pretty specific requirements, but this
> > > work-in-progress documentation should give a good idea of what they are:
> > >
> > > https://github.com/mikesart/gpuvis/wiki/Overview
> 
> We already have those tracepoint equivs and a script to generate a
> similar visualisation: intel-gpu-tools/scripts/trace.pl, but only
> looking at the scheduling issue from the gpu pov. But it's really only a
> dev toy atm, plugging the gap between userspace and the gpu has been on
> the perennial wishlist.
> -Chris

I added Intel event visualization to gpuvis based on your trace.pl
script. Screenshot at the top of the wiki page here:

https://github.com/mikesart/gpuvis/wiki/TechDocs-Intel

In that screenshot the mouse is hovering over the ctx=30,seqno=1900 bar
which selects those events in the event list and shows a tooltip with
the submit, execute, etc info.

For the amdgpu driver, we're able to get the submit information from
user space and associate those events to specific processes. Example of
that is here:

https://github.com/mikesart/gpuvis/wiki/TechDocs-AMDGpu

If you ever get a chance to try gpuvis and have any feedback, we'd love
to hear it.  Also if you ever get userspace tracepoint data in, let me
know and I'd be happy to hook that up as well.

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

Re: [Intel-gfx] [GIT PULL] gvt-next for 4.16

[Rodrigo Vivi]

Hi Zhenyu,

On Thu, Nov 16, 2017 at 09:20:07AM +, Zhenyu Wang wrote:
> 
> Hi,
> 
> As we missed 4.15 cycle, here's the bigger initial 4.16 gvt-next pull,
> which includes many improvements as noted below.
> 
> thanks
> 
> --
> The following changes since commit 34cc9efc27e2623c76a69d2ad1fa2b972e27a2c1:
> 
>   drm/i915: Remove pre-production pooled-EU w/a for Broxton (2017-11-15 
> 18:04:18 +)
> 
> are available in the Git repository at:

this capital "G" broke dim here... It took me a while to figure out what
was going wrong.

How did you generate this pull request? Why this "g" is in capital?

Anyway I workarounded it here and pulled your changes into dinq.

But for next time please make it in a way that dim runs smoothly or
consider submitting a change to dim to accept git or Git.

Thanks,
Rodrigo.

> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-11-16
> 
> for you to fetch changes up to f2880e04f3a5419366926182fc97a3c2e4fd8f2a:
> 
>   drm/i915/gvt: Move request alloc to dispatch_workload path only (2017-11-16 
> 11:51:55 +0800)
> 
> 
> gvt-next-2017-11-16
> 
> - CSB HWSP update support (Weinan)
> - GVT debug helpers, dyndbg and debugfs (Chuanxiao, Shuo)
> - full virtualized opregion (Xiaolin)
> - VM health check for sane fallback (Fred)
> - workload submission code refactor for future enabling (Zhi)
> - Updated repo URL in MAINTAINERS (Zhenyu)
> - other many misc fixes
> 
> 
> Changbin Du (7):
>   drm/i915/gvt: Add basic debugfs infrastructure
>   drm/i915/gvt: Add mmio iterator intel_gvt_for_each_tracked_mmio()
>   drm/i915/gvt: Add new debugfs tool mmio_diff
>   drm/i915/gvt: Reduce rcs mocs switch latency
>   drm/i915/gvt: Don't dump partial state in cmd parser
>   drm/i915/gvt: Make gvt_vgpu_err use pr_err
>   drm/i915/gvt: Emulate PCI expansion ROM base address register
> 
> Colin Ian King (1):
>   drm/i915/gvt: ensure -ve return value is handled correctly
> 
> Shuo Liu (1):
>   drm/i915/gvt: Use dyndbg for gvt debug info
> 
> Weinan Li (1):
>   drm/i915/gvt: update CSB and CSB write pointer in virtual HWSP
> 
> Xiaolin Zhang (2):
>   drm/i915/gvt: Add support for opregion virtualization
>   drm/i915/gvt: opregion virtualization for win guest
> 
> Xiong Zhang (2):
>   drm/i915/gvt: Limit read hw reg to active vgpu
>   drm/i915/gvt: Let each vgpu has separate opregion memory
> 
> Zhenyu Wang (2):
>   MAINTAINERS: Update gvt-linux.git new repo place
>   Revert "drm/i915/gvt: Refine broken PPGTT scratch"
> 
> Zhi Wang (28):
>   drm/i915/gvt: Make elsp_dwords in the right order
>   drm/i915/gvt: Rename intel_vgpu_{init, clean}_gvt_context()
>   drm/i915/gvt: Move workload cache init/clean into intel_vgpu_{setup, 
> clean}_submission()
>   drm/i915/gvt: Introduce intel_vgpu_submission
>   drm/i915/gvt: Move tlb_handle_pending into intel_vgpu_submission
>   drm/i915/gvt: Fix a memory leak in cmd_parser.c
>   drm/i915/gvt: Rename reserved ring buffer
>   drm/i915/gvt: Move ring scan buffers into intel_vgpu_submission
>   drm/i915/gvt: Do not allocate initial ring scan buffer
>   drm/i915/gvt: Factor out vGPU workload creation/destroy
>   drm/i915/gvt: Factor out prepare_workload()
>   drm/i915/gvt: Move common workload preparation into prepare_workload()
>   drm/i915/gvt: Move common vGPU workload creation into scheduler.c
>   drm/i915/gvt: Remove one extra declaration in scheduler.h
>   drm/i915/gvt: Introduce vGPU submission ops
>   drm/i915/gvt: Introduce intel_vgpu_reset_submission
>   drm/i915/gvt: Move clean_workloads() into scheduler.c
>   drm/i915/gvt: Use BIT() to make klockwork happy
>   drm/i915/gvt: Refine find_bb_size()
>   drm/i915/gvt: Refine shadow batch buffer
>   drm/i915/gvt: Factor intel_vgpu_page_track
>   drm/i915/gvt: Export intel_gvt_render_mmio_to_ring_id()
>   drm/i915/gvt: Use I915_GTT_PAGE_SIZE
>   drm/i915/gvt: Let the caller choose if a shadow page should be put into 
> hash table
>   drm/i915/gvt: Fix a bug of unexpectedly clear scratch page table
>   drm/i915/gvt: Introduce page table type of current level in GTT type 
> enumerations
>   drm/i915/gvt: Introduce ops->set_present()
>   drm/i915/gvt: Refine broken PPGTT scratch
> 
> fred gao (6):
>   drm/i915/gvt: Change the return type during command scan
>   drm/i915/gvt: Add VM healthy check for workload_thread
>   drm/i915/gvt: Add VM healthy check for submit_context
>   drm/i915/gvt: Move vGPU type related code into gvt file
>   drm/i915/gvt: Refactor vGPU type code in kvmgt part
>   drm/i915/gvt: Move request alloc to dispatch_workload path only
> 
>  MAINTAINERS   |   2 +-
>  drivers/gpu/drm/i915/gvt/Makefile |   2 +-
>  

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3)

[Patchwork]

== Series Details ==

Series: series starting with lib/igt_kms: Add igt_display_reset function, v3. 
(rev3)
URL   : https://patchwork.freedesktop.org/series/33934/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip   -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-snb) fdo#102707 +1
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-snb) fdo#102848
Test kms_plane_multiple:
Subgroup atomic-pipe-c-tiling-x:
skip   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060

shard-hswtotal:2584 pass:1472 dwarn:2   dfail:1   fail:10  skip:1099 
time:9449s
shard-snbtotal:2584 pass:1257 dwarn:3   dfail:1   fail:12  skip:1311 
time:7912s
Blacklisted hosts:
shard-apltotal:2584 pass:1616 dwarn:5   dfail:1   fail:26  skip:936 
time:13244s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Always pin the fence for scanout 
on gen2/3 and primary planes
URL   : https://patchwork.freedesktop.org/series/33960/
State : failure

== Summary ==

Series 33960v1 series starting with [1/5] drm/i915: Always pin the fence for 
scanout on gen2/3 and primary planes
https://patchwork.freedesktop.org/api/1.0/series/33960/revisions/1/mbox/

Test chamelium:
Subgroup dp-hpd-fast:
skip   -> INCOMPLETE (fi-ivb-3520m)
skip   -> INCOMPLETE (fi-ivb-3770)
skip   -> INCOMPLETE (fi-byt-j1900)
skip   -> INCOMPLETE (fi-hsw-4770)
skip   -> INCOMPLETE (fi-hsw-4770r) fdo#102332
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-gdg-551) fdo#102707
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#103479
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)

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

fi-bdw-5557u total:289  pass:267  dwarn:1   dfail:0   fail:0   skip:21  
time:452s
fi-bdw-gvtdvmtotal:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:222  dwarn:2   dfail:0   fail:0   skip:65  
time:382s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:289  pass:182  dwarn:1   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:258  dwarn:1   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:289  pass:228  dwarn:1   dfail:0   fail:0   skip:60  
time:438s
fi-gdg-551   total:289  pass:177  dwarn:2   dfail:0   fail:1   skip:109 
time:264s
fi-glk-1 total:289  pass:260  dwarn:1   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770r total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ilk-650   total:289  pass:227  dwarn:1   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7500u total:289  pass:263  dwarn:2   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:289  pass:269  dwarn:1   dfail:0   fail:0   skip:19  
time:534s
fi-kbl-7567u total:289  pass:268  dwarn:1   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:289  pass:221  dwarn:2   dfail:0   fail:0   skip:66  
time:582s
fi-skl-6260u total:289  pass:268  dwarn:1   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:561s
fi-skl-6700hqtotal:289  pass:262  dwarn:1   dfail:0   fail:0   skip:26  
time:573s
fi-skl-6700k total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:268  dwarn:1   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:265  dwarn:1   dfail:0   fail:0   skip:23  
time:464s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:248  dwarn:1   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cfl-s2total:289  pass:260 

[Intel-gfx] [PATCH 2/5] drm/i915: Clean up fbc vs. plane checks

[Ville Syrjala]

From: Ville Syrjälä 

Let's record the information whether a plane can do fbc or not under
struct inte_plane.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 36 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_fbc.c | 29 +++--
 drivers/gpu/drm/i915/intel_pm.c  |  2 --
 4 files changed, 44 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0657e03e871a..f4b773a4caf7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13244,6 +13244,31 @@ static const struct drm_plane_funcs 
intel_cursor_plane_funcs = {
.format_mod_supported = intel_cursor_plane_format_mod_supported,
 };
 
+static bool i9xx_plane_has_fbc(struct drm_i915_private *dev_priv,
+  enum plane plane_id)
+{
+   if (!HAS_FBC(dev_priv))
+   return false;
+
+   if (IS_G4X(dev_priv) || IS_GEN5(dev_priv) ||
+   IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
+   return true;
+
+   if (IS_GEN4(dev_priv))
+   return plane_id == PLANE_A || plane_id == PLANE_B;
+   else
+   return plane_id == PLANE_A;
+}
+
+static bool skl_plane_has_fbc(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (!HAS_FBC(dev_priv))
+   return false;
+
+   return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
+}
+
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13286,6 +13311,15 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->plane = (enum plane) pipe;
primary->id = PLANE_PRIMARY;
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   primary->has_fbc = skl_plane_has_fbc(dev_priv,
+primary->pipe,
+primary->id);
+   else
+   primary->has_fbc = i9xx_plane_has_fbc(dev_priv,
+ primary->plane);
+
primary->check_plane = intel_check_primary_plane;
 
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
@@ -14654,6 +14688,8 @@ int intel_modeset_init(struct drm_device *dev)
}
}
 
+   intel_fbc_init(dev_priv);
+
intel_shared_dpll_init(dev);
intel_update_fdi_pll_freq(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c13f15ef342b..472e37f00402 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -855,6 +855,7 @@ struct intel_plane {
enum plane_id id;
enum pipe pipe;
bool can_scale;
+   bool has_fbc;
int max_downscale;
uint32_t frontbuffer_bit;
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 1a0f5e0c8d10..81a2526c445e 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -46,16 +46,6 @@ static inline bool fbc_supported(struct drm_i915_private 
*dev_priv)
return HAS_FBC(dev_priv);
 }
 
-static inline bool fbc_on_pipe_a_only(struct drm_i915_private *dev_priv)
-{
-   return IS_HASWELL(dev_priv) || INTEL_GEN(dev_priv) >= 8;
-}
-
-static inline bool fbc_on_plane_a_only(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) < 4;
-}
-
 static inline bool no_fbc_on_multiple_pipes(struct drm_i915_private *dev_priv)
 {
return INTEL_GEN(dev_priv) <= 3;
@@ -1082,13 +1072,10 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
struct intel_crtc_state *intel_crtc_state;
struct intel_crtc *crtc = to_intel_crtc(plane_state->crtc);
 
-   if (!intel_plane_state->base.visible)
-   continue;
-
-   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
+   if (!to_intel_plane(plane)->has_fbc)
continue;
 
-   if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
+   if (!intel_plane_state->base.visible)
continue;
 
intel_crtc_state = to_intel_crtc_state(
@@ -1346,7 +1333,7 @@ static bool need_fbc_vtd_wa(struct drm_i915_private 
*dev_priv)
 void intel_fbc_init(struct drm_i915_private *dev_priv)
 {
struct intel_fbc *fbc = _priv->fbc;
-   enum pipe pipe;
+   struct intel_plane *plane;
 
INIT_WORK(>work.work, intel_fbc_work_fn);
INIT_WORK(>underrun_work, intel_fbc_underrun_work_fn);
@@ -1367,12 +1354,10 @@ void intel_fbc_init(struct 

[Intel-gfx] [PATCH 3/5] drm/i915: Require fence only for FBC capable planes

[Ville Syrjala]

From: Ville Syrjälä 

Since only a subset of primary planes are FBC capable there's no need to
waste fences on all of them. So let's skip the fence if the plane
isn't even fbc capable.

In the future we might extend this to skip the fence even for FBC
capable planes if the crtc and/or plane state isn't suitable
for FBC.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f4b773a4caf7..3b7021b39fdf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2163,7 +2163,7 @@ static bool intel_plane_needs_fence(const struct 
intel_plane_state *plane_state)
if (i915_gem_object_get_tiling(obj) == I915_TILING_NONE)
return false;
 
-   return INTEL_GEN(dev_priv) < 4 || plane->id == PLANE_PRIMARY;
+   return INTEL_GEN(dev_priv) < 4 || plane->has_fbc;
 }
 
 struct i915_vma *
-- 
2.13.6

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

[Intel-gfx] [PATCH 4/5] drm/i915: Add a FIXME about FBC vs. fence. 90/270 degree rotation

[Ville Syrjala]

From: Ville Syrjälä 

Currently we're pinning the fence for the rotated GTT view. That doesn't
acually make any sense since the fence is used only for the FBC GTT
tracking. For that we would want the fence for the normal GTT view
instead of the rotated view. Too lazy to fix this now so just add a
FIXME.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3b7021b39fdf..25050bfce5d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2202,6 +2202,12 @@ intel_pin_and_fence_fb_obj(const struct drm_framebuffer 
*fb,
 
atomic_inc(_priv->gpu_error.pending_fb_pin);
 
+   /*
+* FIXME presumably with FBC and 90/270 degree rotation we
+* should pin the fence on the normal GTT view, and tell FBC
+* to monitor that one instead of the rotated view. Would
+* need changes to the FBC fence Y offset as well.
+*/
vma = i915_gem_object_pin_to_display_plane(obj, alignment,
   needs_fence, );
if (IS_ERR(vma))
-- 
2.13.6

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

[Intel-gfx] [PATCH 5/5] drm/i915: Extract intel_plane_{pin, unpin}_fb()

[Ville Syrjala]

From: Ville Syrjälä 

We've replicated the fb pin/unpin code in a few places. Pull it into
convenint helpers.

This results in a slight change in behaviour on account of the cursor
path now dropping struct_mutex and reacquiring it later.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 25050bfce5d1..8e1e1dd7f4af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12705,6 +12705,51 @@ static void add_rps_boost_after_vblank(struct drm_crtc 
*crtc,
add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
 }
 
+static int intel_plane_pin_fb(struct intel_plane_state *plane_state)
+{
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
+   struct i915_vma *vma;
+   bool needs_fence;
+
+   if (plane->id == PLANE_CURSOR &&
+   INTEL_INFO(dev_priv)->cursor_needs_physical) {
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   int align = intel_cursor_alignment(dev_priv);
+
+   return i915_gem_object_attach_phys(obj, align);
+   }
+
+   needs_fence = intel_plane_needs_fence(plane_state);
+   vma = intel_pin_and_fence_fb_obj(fb, plane_state->base.rotation,
+needs_fence);
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
+
+   plane_state->vma = vma;
+
+   return 0;
+}
+
+static void intel_plane_unpin_fb(struct intel_plane_state *old_plane_state)
+{
+   struct intel_plane *plane = to_intel_plane(old_plane_state->base.plane);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   struct i915_vma *vma;
+   bool needs_fence;
+
+   vma = fetch_and_zero(_plane_state->vma);
+   if (!vma)
+   return;
+
+   needs_fence = intel_plane_needs_fence(old_plane_state);
+
+   mutex_lock(_priv->drm.struct_mutex);
+   intel_unpin_fb_vma(vma, needs_fence);
+   mutex_unlock(_priv->drm.struct_mutex);
+}
+
 /**
  * intel_prepare_plane_fb - Prepare fb for usage on plane
  * @plane: drm plane to prepare for
@@ -12779,23 +12824,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
return ret;
}
 
-   if (plane->type == DRM_PLANE_TYPE_CURSOR &&
-   INTEL_INFO(dev_priv)->cursor_needs_physical) {
-   const int align = intel_cursor_alignment(dev_priv);
-
-   ret = i915_gem_object_attach_phys(obj, align);
-   } else {
-   bool needs_fence =
-   
intel_plane_needs_fence(to_intel_plane_state(new_state));
-   struct i915_vma *vma;
-
-   vma = intel_pin_and_fence_fb_obj(fb, new_state->rotation,
-needs_fence);
-   if (!IS_ERR(vma))
-   to_intel_plane_state(new_state)->vma = vma;
-   else
-   ret =  PTR_ERR(vma);
-   }
+   ret = intel_plane_pin_fb(to_intel_plane_state(new_state));
 
i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
 
@@ -12839,18 +12868,8 @@ void
 intel_cleanup_plane_fb(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
-   struct i915_vma *vma;
-
/* Should only be called after a successful intel_prepare_plane_fb()! */
-   vma = fetch_and_zero(_intel_plane_state(old_state)->vma);
-   if (vma) {
-   bool needs_fence =
-   
intel_plane_needs_fence(to_intel_plane_state(old_state));
-
-   mutex_lock(>dev->struct_mutex);
-   intel_unpin_fb_vma(vma, needs_fence);
-   mutex_unlock(>dev->struct_mutex);
-   }
+   intel_plane_unpin_fb(to_intel_plane_state(old_state));
 }
 
 int
@@ -13122,7 +13141,6 @@ intel_legacy_cursor_update(struct drm_plane *plane,
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_framebuffer *old_fb;
struct drm_crtc_state *crtc_state = crtc->state;
-   struct i915_vma *old_vma, *vma;
 
/*
 * When crtc is inactive or there is a modeset pending,
@@ -13181,26 +13199,11 @@ intel_legacy_cursor_update(struct drm_plane *plane,
if (ret)
goto out_free;
 
-   if (INTEL_INFO(dev_priv)->cursor_needs_physical) {
-   int align = intel_cursor_alignment(dev_priv);
-
-   ret = i915_gem_object_attach_phys(intel_fb_obj(fb), align);
-   if (ret) {
-   DRM_DEBUG_KMS("failed to attach phys object\n");
-   goto out_unlock;
-  

[Intel-gfx] [PATCH 1/5] drm/i915: Always pin the fence for scanout on gen2/3 and primary planes

[Ville Syrjala]

From: Ville Syrjälä 

The current code is trying to be lazy with fences on scanout buffers.
That looks broken for several reasons:
* gen2/3 always need a fence for tiled scanout
* the unpin doesn't know whether we pinned the fence or not so it
  may unpin something we don't own
* FBC GTT tracking needs a fence (not sure we have proper fallback
  for when there is no fence)

So to fix this always use a fence for gen2/3, and for primary planes on
other platforms (for FBC). For sprites and cursor we never need a fence
so don't even try to get one.  Since we now know whether a fence was
pinned we can safely unpin it too.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gem.c  |  4 +--
 drivers/gpu/drm/i915/intel_display.c | 55 
 drivers/gpu/drm/i915/intel_drv.h |  7 +++--
 drivers/gpu/drm/i915/intel_fbdev.c   | 17 +--
 drivers/gpu/drm/i915/intel_overlay.c |  2 +-
 6 files changed, 66 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2158a758a17d..8c6d0b7ac9a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3783,7 +3783,7 @@ int __must_check
 i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write);
 struct i915_vma * __must_check
 i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
-u32 alignment,
+u32 alignment, bool needs_fence,
 const struct i915_ggtt_view *view);
 void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
 int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 61ba321e9970..af18168e48e3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3944,7 +3944,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
  */
 struct i915_vma *
 i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
-u32 alignment,
+u32 alignment, bool needs_fence,
 const struct i915_ggtt_view *view)
 {
struct i915_vma *vma;
@@ -3997,7 +3997,7 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 * happy to scanout from anywhere within its global aperture.
 */
flags = 0;
-   if (HAS_GMCH_DISPLAY(i915))
+   if (HAS_GMCH_DISPLAY(i915) || needs_fence)
flags = PIN_MAPPABLE;
vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e6fcbc5abc75..0657e03e871a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2154,8 +2154,21 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
}
 }
 
+static bool intel_plane_needs_fence(const struct intel_plane_state 
*plane_state)
+{
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   struct drm_i915_gem_object *obj = intel_fb_obj(plane_state->base.fb);
+
+   if (i915_gem_object_get_tiling(obj) == I915_TILING_NONE)
+   return false;
+
+   return INTEL_GEN(dev_priv) < 4 || plane->id == PLANE_PRIMARY;
+}
+
 struct i915_vma *
-intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, unsigned int rotation)
+intel_pin_and_fence_fb_obj(const struct drm_framebuffer *fb,
+  unsigned int rotation, bool needs_fence)
 {
struct drm_device *dev = fb->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2189,11 +2202,16 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, 
unsigned int rotation)
 
atomic_inc(_priv->gpu_error.pending_fb_pin);
 
-   vma = i915_gem_object_pin_to_display_plane(obj, alignment, );
+   vma = i915_gem_object_pin_to_display_plane(obj, alignment,
+  needs_fence, );
if (IS_ERR(vma))
goto err;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (needs_fence) {
+   int ret;
+
+   WARN_ON(!i915_vma_is_map_and_fenceable(vma));
+
/* Install a fence for tiled scan-out. Pre-i965 always needs a
 * fence, whereas 965+ only requires a fence if using
 * framebuffer compression.  For simplicity, we always, when
@@ -2210,7 +2228,11 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, 
unsigned int rotation)
 * something 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with lib/igt_kms: Add igt_display_reset function, v3. (rev3)

[Patchwork]

== Series Details ==

Series: series starting with lib/igt_kms: Add igt_display_reset function, v3. 
(rev3)
URL   : https://patchwork.freedesktop.org/series/33934/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
936b97165308e179880fc0f218192881953f2544 lib: Dump 
/sys/kernel/debug/suspend_stats after suspend failure

with latest DRM-Tip kernel build CI_DRM_3354
3878ad19ccd4 drm-tip: 2017y-11m-16d-15h-48m-14s UTC integration manifest

Testlist changes:
+igt@kms_chamelium@common-hpd-after-hibernate
+igt@kms_chamelium@common-hpd-after-suspend
+igt@kms_chamelium@dp-crc-fast
+igt@kms_chamelium@dp-crc-multiple
+igt@kms_chamelium@dp-crc-single
+igt@kms_chamelium@dp-edid-change-during-hibernate
+igt@kms_chamelium@dp-edid-change-during-suspend
+igt@kms_chamelium@dp-edid-read
+igt@kms_chamelium@dp-frame-dump
+igt@kms_chamelium@dp-hpd
+igt@kms_chamelium@dp-hpd-after-hibernate
+igt@kms_chamelium@dp-hpd-after-suspend
+igt@kms_chamelium@dp-hpd-fast
+igt@kms_chamelium@dp-hpd-storm
+igt@kms_chamelium@dp-hpd-storm-disable
+igt@kms_chamelium@hdmi-crc-fast
+igt@kms_chamelium@hdmi-crc-multiple
+igt@kms_chamelium@hdmi-crc-single
+igt@kms_chamelium@hdmi-edid-change-during-hibernate
+igt@kms_chamelium@hdmi-edid-change-during-suspend
+igt@kms_chamelium@hdmi-edid-read
+igt@kms_chamelium@hdmi-frame-dump
+igt@kms_chamelium@hdmi-hpd
+igt@kms_chamelium@hdmi-hpd-after-hibernate
+igt@kms_chamelium@hdmi-hpd-after-suspend
+igt@kms_chamelium@hdmi-hpd-fast
+igt@kms_chamelium@hdmi-hpd-storm
+igt@kms_chamelium@hdmi-hpd-storm-disable
+igt@kms_chamelium@vga-edid-read
+igt@kms_chamelium@vga-frame-dump
+igt@kms_chamelium@vga-hpd
+igt@kms_chamelium@vga-hpd-after-hibernate
+igt@kms_chamelium@vga-hpd-after-suspend
+igt@kms_chamelium@vga-hpd-fast
+igt@kms_chamelium@vga-hpd-without-ddc
-igt@chamelium@common-hpd-after-hibernate
-igt@chamelium@common-hpd-after-suspend
-igt@chamelium@dp-crc-fast
-igt@chamelium@dp-crc-multiple
-igt@chamelium@dp-crc-single
-igt@chamelium@dp-edid-change-during-hibernate
-igt@chamelium@dp-edid-change-during-suspend
-igt@chamelium@dp-edid-read
-igt@chamelium@dp-frame-dump
-igt@chamelium@dp-hpd
-igt@chamelium@dp-hpd-after-hibernate
-igt@chamelium@dp-hpd-after-suspend
-igt@chamelium@dp-hpd-fast
-igt@chamelium@dp-hpd-storm
-igt@chamelium@dp-hpd-storm-disable
-igt@chamelium@hdmi-crc-fast
-igt@chamelium@hdmi-crc-multiple
-igt@chamelium@hdmi-crc-single
-igt@chamelium@hdmi-edid-change-during-hibernate
-igt@chamelium@hdmi-edid-change-during-suspend
-igt@chamelium@hdmi-edid-read
-igt@chamelium@hdmi-frame-dump
-igt@chamelium@hdmi-hpd
-igt@chamelium@hdmi-hpd-after-hibernate
-igt@chamelium@hdmi-hpd-after-suspend
-igt@chamelium@hdmi-hpd-fast
-igt@chamelium@hdmi-hpd-storm
-igt@chamelium@hdmi-hpd-storm-disable
-igt@chamelium@vga-edid-read
-igt@chamelium@vga-frame-dump
-igt@chamelium@vga-hpd
-igt@chamelium@vga-hpd-after-hibernate
-igt@chamelium@vga-hpd-after-suspend
-igt@chamelium@vga-hpd-fast
-igt@chamelium@vga-hpd-without-ddc

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:279s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:517s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:519s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:490s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:435s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:441s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27 

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add igt_display_reset function, v3.

[Maarten Lankhorst]

A lot of code duplicates this, but it should be handled in the core.
Add it and use it after igt_display_init(), the tests have to be
converted one by one.

Changes since v1:
- Merely reset rotation to HW value.
Changes since v2:
- Compile.

Signed-off-by: Maarten Lankhorst 
---
 lib/igt_kms.c | 164 +-
 lib/igt_kms.h |   1 +
 2 files changed, 106 insertions(+), 59 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 1d26b8ddbf43..becd77ce19aa 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1549,29 +1549,14 @@ static void igt_output_refresh(igt_output_t *output)
   -1);
}
 
-   if (output->config.connector) {
+   if (output->config.connector)
igt_atomic_fill_connector_props(display, output,
IGT_NUM_CONNECTOR_PROPS, igt_connector_prop_names);
 
-   if (output->props[IGT_CONNECTOR_BROADCAST_RGB])
-   igt_output_set_prop_value(output,
- IGT_CONNECTOR_BROADCAST_RGB,
- BROADCAST_RGB_FULL);
-   }
-
LOG(display, "%s: Selecting pipe %s\n", output->name,
kmstest_pipe_name(output->pending_pipe));
 }
 
-static bool
-get_plane_property(int drm_fd, uint32_t plane_id, const char *name,
-  uint32_t *prop_id /* out */, uint64_t *value /* out */,
-  drmModePropertyPtr *prop /* out */)
-{
-   return kmstest_get_property(drm_fd, plane_id, DRM_MODE_OBJECT_PLANE,
-   name, prop_id, value, prop);
-}
-
 static int
 igt_plane_set_property(igt_plane_t *plane, uint32_t prop_id, uint64_t value)
 {
@@ -1582,15 +1567,6 @@ igt_plane_set_property(igt_plane_t *plane, uint32_t 
prop_id, uint64_t value)
 DRM_MODE_OBJECT_PLANE, prop_id, value);
 }
 
-static bool
-get_crtc_property(int drm_fd, uint32_t crtc_id, const char *name,
-  uint32_t *prop_id /* out */, uint64_t *value /* out */,
-  drmModePropertyPtr *prop /* out */)
-{
-   return kmstest_get_property(drm_fd, crtc_id, DRM_MODE_OBJECT_CRTC,
-   name, prop_id, value, prop);
-}
-
 /*
  * Walk a plane's property list to determine its type.  If we don't
  * find a type property, then the kernel doesn't support universal
@@ -1601,14 +1577,112 @@ static int get_drm_plane_type(int drm_fd, uint32_t 
plane_id)
uint64_t value;
bool has_prop;
 
-   has_prop = get_plane_property(drm_fd, plane_id, "type",
- NULL /* prop_id */, , NULL);
+   has_prop = kmstest_get_property(drm_fd, plane_id, DRM_MODE_OBJECT_PLANE,
+   "type", NULL, , NULL);
if (has_prop)
return (int)value;
 
return DRM_PLANE_TYPE_OVERLAY;
 }
 
+static void igt_plane_reset(igt_plane_t *plane)
+{
+   /* Reset src coordinates. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_X, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_Y, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_W, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_H, 0);
+
+   /* Reset crtc coordinates. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_X, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_Y, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_W, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_H, 0);
+
+   /* Reset binding to fb and crtc. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_FB_ID, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_ID, 0);
+
+   /* Use default rotation */
+   if (igt_plane_has_prop(plane, IGT_PLANE_ROTATION)) {
+   plane->values[IGT_PLANE_ROTATION] =
+   igt_plane_get_prop(plane, IGT_PLANE_ROTATION);
+   igt_plane_clear_prop_changed(plane, IGT_PLANE_ROTATION);
+   }
+
+   igt_plane_clear_prop_changed(plane, IGT_PLANE_IN_FENCE_FD);
+   plane->values[IGT_PLANE_IN_FENCE_FD] = ~0ULL;
+}
+
+static void igt_pipe_reset(igt_pipe_t *pipe)
+{
+   igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_MODE_ID, 0);
+   igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
+   igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
+
+   pipe->out_fence_fd = -1;
+}
+
+static void igt_output_reset(igt_output_t *output)
+{
+   output->pending_pipe = PIPE_NONE;
+   output->use_override_mode = false;
+   memset(>override_mode, 0, sizeof(output->override_mode));
+
+   igt_output_set_prop_value(output, IGT_CONNECTOR_CRTC_ID, 0);
+
+   if (igt_output_has_prop(output, IGT_CONNECTOR_BROADCAST_RGB))
+   igt_output_set_prop_value(output, IGT_CONNECTOR_BROADCAST_RGB,
+ BROADCAST_RGB_FULL);
+}

Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm

[David Weinehall]

On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote:
> On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote:
> > Now that we have CI, and that pm_rpm fully passes (I guess the audio
> > folks have implemented proper runtime pm for snd-hda, hooray, pls
> > confirm) it's time to enable this again by default.
> > 
> > Real goal here is to have 1 configuration only that we fully support,
> > instead of tons of different codes with every user/customer tuning it
> > differently. And really, power stuff should work by default, and
> > should be enabled by everywhere where it is save to do so.
> > 
> > v2: Completely new commit message, a few years passed since v1 ...
> > 
> > Cc: Takashi Iwai 
> > Cc: Liam Girdwood 
> > Cc: "Yang, Libin" 
> > Cc: "Lin, Mengdong" 
> > Cc: "Li, Jocelyn" 
> > Cc: "Kaskinen, Tanu" 
> > Cc: "Zanoni, Paulo R" 
> > Signed-off-by: Daniel Vetter 
> 
> lgtm,
> 
> Reviewed-by: David Weinehall 

Been testing a bit; test results are a bit discouraging when it comes to
idle power consumption.

Our nightly test suite logs idle power consumption before running any
tests, after running all tests, and then finally after running
powertop --auto-tune.

The before and after cases are similar with and without patch,
but not so for the auto-tune case.

Without this patch, powertop --auto-tune yields a massive improvement
(on NUC6i5 the power consumption drops with more than a factor of 3),
while with this patch the power consumption just drops with 10% or so.

Judging by the powertop output it seems as though we're getting a lot of
interrupts from i915.

 *  *  *   Top 10 Power Consumers   *  *  *

With patch:

Usage;Events/s;Category;Description
  0,5%; 75,1;Interrupt;[124] i915
  0,3%; 48,4;Process;/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
  0,1%; 42,8;Timer;hrtimer_wakeup
  0,0%; 34,9;Timer;tick_sched_timer
  4,2%;  1,1;kWork;i915_hpd_poll_init_work
  0,1%; 14,0;Process;python2 /opt/scripts/dut/dutlaunch/launch2.py 
--workspace=/opt/jenkins/workspace/Custom_test --iterations=1 idlepower_before 
un
  0,0%; 13,3;Process;[rcu_preempt]
  0,8%;  1,7;Process;python /opt/scripts/dut/perf-meter.py --avgskip 1 --name 
perf-meter --infofile /tmp/testname GLBenchmark testfw_app synmark2 he
  0,0%;  3,0;Process;compiz
  0,7%; 0,11;kWork;output_poll_execute

Without the patch:

Usage;Events/s;Category;Description
  0,0%; 29,1;Timer;tick_sched_timer
  0,1%; 19,9;Process;python2 /opt/scripts/dut/dutlaunch/launch.py 
--workspace=/opt/jenkins/workspace/Nightly_kernel_test/kernel/1510773665/SKL_6260U
  0,0%; 13,2;Process;[rcu_preempt]
  0,8%;  1,6;Process;python /opt/scripts/dut/perf-meter.py --avgskip 1 --name 
perf-meter --infofile /tmp/testname GLBenchmark testfw_app synmark2 he
  0,0%;  2,5;Process;compiz
  0,0%;  1,5;Process;java -jar slave.jar
  0,0%;  1,2;Interrupt;[3] net_rx(softirq)
  0,0%;  1,0;kWork;pci_pme_list_scan
  0,0%;  0,9;Interrupt;[121] xhci_hcd
  0,1%;  0,5;Process;perf-meter

As can be seen the i915 driver doesn't even show up without the patch,
while it's the main culprit with the patch.

Just to eliminate DMC issues I'm going to do another run, but with DMC
v1.27 instead of v1.26.


Kind regards, David

> 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 8315499452dc..dc24d008d8d4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -3232,7 +3232,7 @@ void intel_runtime_pm_enable(struct drm_i915_private 
> > *dev_priv)
> > struct pci_dev *pdev = dev_priv->drm.pdev;
> > struct device *kdev = >dev;
> >  
> > -   pm_runtime_set_autosuspend_delay(kdev, 1); /* 10s */
> > +   pm_runtime_set_autosuspend_delay(kdev, 100);
> > pm_runtime_mark_last_busy(kdev);
> >  
> > /*
> > @@ -3251,6 +3251,8 @@ void intel_runtime_pm_enable(struct drm_i915_private 
> > *dev_priv)
> > pm_runtime_use_autosuspend(kdev);
> > }
> >  
> > +   pm_runtime_allow(kdev);
> > +
> > /*
> >  * The core calls the driver load handler with an RPM reference held.
> >  * We drop that here and will reacquire it during unloading in
> > -- 
> > 2.15.0.rc2
> > 
> > ___
> > 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 

Re: [Intel-gfx] [PATCH 0/7] WRPLL fixes for HDMI 2.0 on Cannonlake.

[Rodrigo Vivi]

Merged to dinq. Thanks for all reviews and comments.

On Tue, Nov 14, 2017 at 07:47:52PM +, Rodrigo Vivi wrote:
> With these fixes and clean-ups around wrpll plus
> extending HDMI 2.0 from GLK to CNL we could finally
> get a functional HDMI 2.0 display with 4k60Hz.
> 
> Thanks,
> Rodrigo.
> 
> Rodrigo Vivi (7):
>   drm/i915/cnl: Remove spurious central_freq.
>   drm/i915/cnl: Remove useless conversion.
>   drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.
>   drm/i915/cnl: Fix wrpll math for higher freqs.
>   drm/i915/cnl: Don't blindly replace qdiv.
>   drm/i915/cnl: Write dco_fraction calculation as spec.
>   drm/i915/cnl: Extend HDMI 2.0 support to CNL.
> 
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 42 
> ++-
>  drivers/gpu/drm/i915/intel_hdmi.c |  7 +++---
>  2 files changed, 21 insertions(+), 28 deletions(-)
> 
> -- 
> 2.13.6
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)

[Patchwork]

== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)
URL   : https://patchwork.freedesktop.org/series/33823/
State : success

== Summary ==

Test drv_selftest:
Subgroup mock_sanitycheck:
pass   -> DMESG-WARN (shard-snb) fdo#103717
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_flip:
Subgroup vblank-vs-suspend-interruptible:
pass   -> DMESG-WARN (shard-snb) fdo#100368

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

shard-hswtotal:2584 pass:1473 dwarn:1   dfail:1   fail:10  skip:1099 
time:9532s
shard-snbtotal:2584 pass:1258 dwarn:3   dfail:1   fail:11  skip:1311 
time:8012s
Blacklisted hosts:
shard-apltotal:2565 pass:1598 dwarn:2   dfail:1   fail:26  skip:937 
time:12996s
shard-kbltotal:2526 pass:1673 dwarn:10  dfail:4   fail:23  skip:813 
time:10125s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Fix init_clock_gating for resume (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix init_clock_gating for resume (rev2)
URL   : https://patchwork.freedesktop.org/series/33718/
State : warning

== Summary ==

Test drv_selftest:
Subgroup mock_sanitycheck:
pass   -> DMESG-WARN (shard-snb) fdo#103717
Test kms_cursor_crc:
Subgroup cursor-64x64-dpms:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623

fdo#103717 https://bugs.freedesktop.org/show_bug.cgi?id=103717
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2584 pass:1470 dwarn:3   dfail:1   fail:10  skip:1100 
time:9486s
shard-snbtotal:2584 pass:1258 dwarn:2   dfail:1   fail:12  skip:1311 
time:8022s
Blacklisted hosts:
shard-apltotal:2550 pass:1597 dwarn:2   dfail:2   fail:24  skip:924 
time:13192s
shard-kbltotal:2565 pass:1689 dwarn:17  dfail:2   fail:23  skip:833 
time:10597s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7159/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 WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)

[Patchwork]

== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev4)
URL   : https://patchwork.freedesktop.org/series/33823/
State : success

== Summary ==

Series 33823v4 WRPLL fixes for HDMI 2.0 on Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/33823/revisions/4/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:383s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:500s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:496s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:433s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:266s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:436s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:532s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:577s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:512s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:465s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s
Blacklisted hosts:
fi-cnl-y total:216  pass:195  dwarn:0   dfail:0   fail:0   skip:20 

1fc4fe8ac97eee86a4fe2dc1239a350aa3f13371 drm-tip: 2017y-11m-16d-12h-57m-10s UTC 
integration manifest
7484ce150d2c drm/i915/cnl: Extend HDMI 2.0 support to CNL.
c8b6992b7f7c drm/i915/cnl: Simplify dco_fraction calculation.
7ee6c6f3682a drm/i915/cnl: Don't blindly replace qdiv.
7591bc02cd94 drm/i915/cnl: Fix wrpll math for higher freqs.
890b9013c560 drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.
fb457f5b2b19 drm/i915/cnl: Remove useless conversion.
874fa2bcab3b drm/i915/cnl: Remove spurious central_freq.

== Logs ==

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

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> > 3D to 2D mode in a timely fashion if the source simply stops sending the
> > HDMI infoframe. The suggested workaround is to keep sending the
> > infoframe even when strictly not necessary (ie. no VIC and no S3D).
> > HDMI 1.4 does allow for this behaviour, stating that sending the
> > infoframe is optional in this case.
> >
> > The infoframe was first specified in HDMI 1.4, so in theory sinks
> > predating that may not appreciate us sending an uknown infoframe
> > their way. To avoid regressions let's try to determine if the sink
> > supports the infoframe or not. Unfortunately there's no direct way
> > to do that, so instead we'll just check if we managed to parse any
> > HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
> > sink will accept the infoframe. Also if the EDID contains the HDMI
> > 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
> > the infoframe.
> I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which 
> talks about
> switch from 3D to 2D.  To me it looks like:
> If (sending_to_hdmi2_sinks) {
>  - for 3d modes send HF-VSIF
>  - for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
>When you switch from 3d->2d {
>   - send_HF-VSIF with 3D_valid bit = 0/1
>   }
> } else { /* HDMI 1.4b sinks from Appendix F */
>  -  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
> }
> 
> Should we add a is_hdmi2 check and separate these cases ?

We don't support the HDMI forum infoframe. Maybe someone forgot to
implement that when adding the rest of HDMI 2.0 support? ;)

> 
> >
> > v2: Fix the getting has_hdmi_infoframe from display_info
> >  Always fail constructing the infoframe if the display
> >  possibly can't handle it
> >
> > Cc: Shashank Sharma 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
> >   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
> >   drivers/gpu/drm/drm_edid.c| 34 
> > +--
> >   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >   drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
> >   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
> >   drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
> >   drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
> >   drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
> >   drivers/gpu/drm/zte/zx_hdmi.c |  1 +
> >   include/drm/drm_connector.h   |  5 +
> >   include/drm/drm_edid.h|  1 +
> >   12 files changed, 57 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> > b/drivers/gpu/drm/bridge/sil-sii8620.c
> > index b7eb704d0a8a..4417276ba02e 100644
> > --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> > +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> > @@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge 
> > *bridge,
> > union hdmi_infoframe frm;
> > u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
> >   
> > +   /* FIXME: We need the connector here */
> > drm_hdmi_vendor_infoframe_from_display_mode(
> > -   , adjusted_mode);
> > +   , NULL, adjusted_mode);
> > vic = frm.vendor.hdmi.vic;
> > if (vic >= ARRAY_SIZE(mhl_vic))
> > vic = 0;
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index a64ce7112288..b172139502d6 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1437,7 +1437,9 @@ static void 
> > hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> > u8 buffer[10];
> > ssize_t err;
> >   
> > -   err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);
> > +   err = drm_hdmi_vendor_infoframe_from_display_mode(,
> > + >connector,
> > + mode);
> > if (err < 0)
> > /*
> >  * Going into that statement does not means vendor infoframe
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 749d07a01772..9ada0ccf50df 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3393,6 +3393,7 @@ static int
> >   do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
> >

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Update names of submission related static functions

[Michal Wajdeczko]

On Thu, 16 Nov 2017 10:53:51 +0100, Sagar Arun Kamble  
 wrote:



i915_guc_submit, i915_guc_dequeue, i915_guc_submission_park and
i915_guc_submission_upark are functions internal to GuC submission
hence remove "i915_" prefix.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't sanitize frame start delay if the pipe is off

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 08:17:21PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-15 20:04:42)
> > From: Ville Syrjälä 
> > 
> > Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is
> > actually on. Should cure some unclaimed register accesses.
> 
> While using crtc->active is consistent with other sanitization, is this
> really a fix for unclaimed register access?
> 
> We should be holding all the powerwells at this moment in bringing up
> the hw, right? So the only unclaimed access would be if the reg didn't
> exist. So are we looking at an invalid cpu_transcoder?

I was thinking we'd have dropped the power references already. But
I guess not. And that should definitely then give unclaimed register
accesses during driver init.

I think these fails are in the "pretend display gets clobbered by GPU
reset" path. And there we don't actually seem to grabbing the init power
reference, which could well explain this. 

Not sure we want to add the init power there either. Most of the readout
code now has the power domain handling in place, so maybe we're close
to being able to nuke the init power thing entirely?

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

[Intel-gfx] [PATCH] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

[Rodrigo Vivi]

Starting on GLK we support HDMI 2.0. So this patch only
extend the work Shashank has made to GLK to CNL.

v2: The version that compiles :/
v3: Invert order to newer || older platforms check. (Ville).

Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2d95db64cdf2..9d5e72728475 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1235,7 +1235,7 @@ static int intel_hdmi_source_max_tmds_clock(struct 
intel_encoder *encoder)
_priv->vbt.ddi_port_info[encoder->port];
int max_tmds_clock;
 
-   if (IS_GEMINILAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
max_tmds_clock = 594000;
else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
max_tmds_clock = 30;
@@ -1511,7 +1511,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->lane_count = 4;
 
-   if (scdc->scrambling.supported && IS_GEMINILAKE(dev_priv)) {
+   if (scdc->scrambling.supported && (INTEL_GEN(dev_priv) >= 10 ||
+  IS_GEMINILAKE(dev_priv))) {
if (scdc->scrambling.low_rates)
pipe_config->hdmi_scrambling = true;
 
@@ -2033,7 +2034,7 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
 
-   if (IS_GEMINILAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
connector->ycbcr_420_allowed = true;
 
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 04:44:54PM +, alexander.le...@verizon.com wrote:
> On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
> >On Wed, Nov 15, 2017 at 02:45:43AM +, alexander.le...@verizon.com wrote:
> >> From: Ville Syrjälä 
> >>
> >> [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
> >>
> >> The watermark should never exceed the FIFO size, so we need to
> >> check against the current FIFO size instead of the theoretical
> >> maximum when we clamp the level 0 watermark.
> >>
> >> Signed-off-by: Ville Syrjälä 
> >> Link: 
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com=DwIDAw=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is=
> >> Reviewed-by: Maarten Lankhorst 
> >> Signed-off-by: Sasha Levin 
> >
> >Why are these patches being proposed for stable? They're not straight up
> >fixes for known issues, and there's always a chance that something will
> >break. Who is doing the qa on this?
> 
> Hi Ville,
> 
> They were selected automatically as part of a new process we're trying
> out. If you disagree with the selection I'd be happy to drop it.

How does that automatic process decide that a patch should be backported?

drm and i915 are very fast moving targets so unintended side effects from
backported patches is a real possibility. So I would recommend against
backporting anything that isn't fixing a real issue affecting users. We
do try to add the cc:stable to such patches.

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

Re: [Intel-gfx] [PATCH v2 02/10] drm/uapi: Validate the mode flags/type

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 06:02:59PM +, Jose Abreu wrote:
> Hi Ville,
> 
> On 15-11-2017 15:49, Ville Syrjala wrote:
> >  
> > +#define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> > +DRM_MODE_FLAG_NHSYNC | \
> > +DRM_MODE_FLAG_PVSYNC | \
> > +DRM_MODE_FLAG_NVSYNC | \
> > +DRM_MODE_FLAG_INTERLACE |  \
> > +DRM_MODE_FLAG_DBLSCAN |\
> > +DRM_MODE_FLAG_CSYNC |  \
> > +DRM_MODE_FLAG_PCSYNC | \
> > +DRM_MODE_FLAG_NCSYNC | \
> > +DRM_MODE_FLAG_HSKEW |  \
> > +DRM_MODE_FLAG_BCAST |  \
> > +DRM_MODE_FLAG_PIXMUX | \
> > +DRM_MODE_FLAG_DBLCLK | \
> > +DRM_MODE_FLAG_CLKDIV2 |\
> > +DRM_MODE_FLAG_3D_MASK)
> > +
> >  
> 
> I see this doesn't include the picture aspect ratio flags.
> Shouldn't we add this now so that userspace can start using them?

Not until we have the client cap to keep them hidden from userspace that
isn't prepared to see them.

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

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > If the user mode would specify an aspect ratio other than 4:3 or 16:9
> > we now silently ignore it. Maybe a better apporoach is to return an
> > error? Let's try that.
> >
> > Also we must be careful that we don't try to send illegal picture
> > aspect in the infoframe as it's only capable of signalling none,
> > 4:3, and 16:9. Currently we're sending these bogus infoframes
> > whenever the cea mode specifies some other aspect ratio.
> >
> > Cc: Shashank Sharma 
> > Cc: Sean Paul 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_edid.c | 23 +--
> >   1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 00aa98f3e55d..bafb3ee4ea97 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> >  const struct drm_display_mode *mode,
> >  bool is_hdmi2_sink)
> >   {
> > +   enum hdmi_picture_aspect picture_aspect;
> > int err;
> >   
> > if (!frame || !mode)
> > @@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> >  * Populate picture aspect ratio from either
> >  * user input (if specified) or from the CEA mode list.
> >  */
> > -   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> > -   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
> > -   frame->picture_aspect = mode->picture_aspect_ratio;
> > -   else if (frame->video_code > 0)
> > -   frame->picture_aspect = drm_get_cea_aspect_ratio(
> > -   frame->video_code);
> > +   picture_aspect = mode->picture_aspect_ratio;
> > +   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> > +   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> This is slightly going in the loop.
> - During the modeset the driver cant specify the aspect ratio 
> information, as DRM layer lacks this support.
> - So we fill the VIC field, by comparing the mode with the 
> DRM_CEA_MODES[] list. This will pick the first mode
>available in the list (regardless of its aspect ratio), and fill the 
> VIC, as we don't consider aspect ratio while comparing timings.
> - Again, now while sending the aspect ratio, we are picking up the VIC, 
> which may not be correct.
> 
> So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is 
> first in list, we will always pick 4:3 aspect ratio.

Yes. The user didn't care about the aspect ratio (or rather couldn't
specify one) so we just pick one. Which is exactly what we've been
doing ever since we started sending the VIC in the infoframe.

> 
> - Shashank
> >   
> > +   /*
> > +* The infoframe can't convey anything but none, 4:3
> > +* and 16:9, so if the user has asked for anything else
> > +* we can only satisfy it by specifying the right VIC.
> > +*/
> > +   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> > +   if (picture_aspect !=
> > +   drm_get_cea_aspect_ratio(frame->video_code))
> > +   return -EINVAL;
> > +   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> > +   }
> > +
> > +   frame->picture_aspect = picture_aspect;
> > frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> > frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
> >   

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

Re: [Intel-gfx] [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
> > cause us to not send out any VICs in the AVI infoframes. That commit
> > was since reverted, but if and when we add aspect ratio handing back
> > we need to be more careful.
> >
> > Let's handle this by considering the aspect ratio as a requirement
> > for cea mode matching only if the passed in mode actually has a
> > non-zero aspect ratio field. This will keep userspace that doesn't
> > provide an aspect ratio working as before by matching it to the
> > first otherwise equal cea mode. And once userspace starts to
> > provide the aspect ratio it will be considerd a hard requirement
> > for the match.
> >
> > Also change the hdmi mode matching to use drm_mode_match() for
> > consistency, but we don't match on aspect ratio there since the
> > spec doesn't list a specific aspect ratio for those modes.
> >
> > Cc: Shashank Sharma 
> > Cc: "Lin, Jia" 
> > Cc: Akashdeep Sharma 
> > Cc: Jim Bride 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_edid.c | 18 ++
> >   1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 7220b8f9a7e8..00aa98f3e55d 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
> > drm_display_mode *mode)
> >   static u8 drm_match_cea_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >  unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> This doesn't look right. This means we are expecting a CEA mode without 
> a pic aspect ratio field,
> which is invalid.

No, it's perfectly valid. It's what we currently get from userspace.

> Ankit is going to publish the aspect ratio patch 
> series again, with proper DRM cap and flags check. Would it be
> ok if we have a look that handling first ?

This patch will be needed by that work. Otherwise we're going to stop
sending a VIC for CEA modes with current userspace.

> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> >*/
> >   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> same here, and probably in other CEA match functions.
> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> > *to_match)
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct 
> > drm_display_mode *hdmi_mode)
> >   static u8 drm_match_hdmi_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >   unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with lib/igt_kms: Add igt_display_reset function, v2. (rev2)

[Patchwork]

== Series Details ==

Series: series starting with lib/igt_kms: Add igt_display_reset function, v2. 
(rev2)
URL   : https://patchwork.freedesktop.org/series/33934/
State : failure

== Summary ==

IGT patchset build failed on latest successful build
936b97165308e179880fc0f218192881953f2544 lib: Dump 
/sys/kernel/debug/suspend_stats after suspend failure

make  all-recursive
Making all in lib
make  all-recursive
Making all in .
  CC   igt_kms.lo
igt_kms.c: In function ‘igt_plane_reset’:
igt_kms.c:1609:4: error: implicit declaration of function 
‘igt_plane_get_prop_value’ [-Werror=implicit-function-declaration]
igt_plane_get_prop_value(plane, IGT_PLANE_ROTATION);
^~~~
igt_kms.c:1609:4: warning: nested extern declaration of 
‘igt_plane_get_prop_value’ [-Wnested-externs]
cc1: some warnings being treated as errors
Makefile:738: recipe for target 'igt_kms.lo' failed
make[4]: *** [igt_kms.lo] Error 1
Makefile:761: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
Makefile:580: recipe for target 'all' failed
make[2]: *** [all] Error 2
Makefile:533: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:465: recipe for target 'all' failed
make: *** [all] Error 2

___
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: Fix init_clock_gating for resume (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix init_clock_gating for resume (rev2)
URL   : https://patchwork.freedesktop.org/series/33718/
State : success

== Summary ==

Series 33718v2 drm/i915: Fix init_clock_gating for resume
https://patchwork.freedesktop.org/api/1.0/series/33718/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:384s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:279s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:502s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:496s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:435s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:268s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:442s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:481s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:589s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:549s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:467s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:565s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:557s

1fc4fe8ac97eee86a4fe2dc1239a350aa3f13371 drm-tip: 2017y-11m-16d-12h-57m-10s UTC 
integration manifest
cd58fee2b180 drm/i915: Fix init_clock_gating for resume

== Logs ==

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

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
> > when switching from 3D to 2D mode, even if the infoframe isn't strictly
> > necessary (ie. not needed to transmit the VIC or stereo information).
> > This is a workaround against some sinks that fail to realize that they
> > should switch from 3D to 2D mode when the source stop transmitting
> > the infoframe.
> >
> > v2: Handle unpack() as well
> >  Pull the length calculation into a helper
> >
> > Cc: Shashank Sharma 
> > Cc: Andrzej Hajda 
> > Cc: Thierry Reding 
> > Cc: Hans Verkuil 
> > Cc: linux-me...@vger.kernel.org
> > Reviewed-by: Andrzej Hajda  #v1
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/video/hdmi.c | 51 
> > +++
> >   1 file changed, 31 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 1cf907ecded4..111a0ab6280a 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
> > hdmi_vendor_infoframe *frame)
> >   }
> >   EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
> >   
> > +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe 
> > *frame)
> > +{
> > +   /* for side by side (half) we also need to provide 3D_Ext_Data */
> > +   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > +   return 6;
> > +   else if (frame->vic != 0 || frame->s3d_struct != 
> > HDMI_3D_STRUCTURE_INVALID)
> > +   return 5;
> > +   else
> > +   return 4;
> > +}
> > +
> >   /**
> >* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
> > buffer
> >* @frame: HDMI infoframe
> > @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
> > hdmi_vendor_infoframe *frame,
> > u8 *ptr = buffer;
> > size_t length;
> >   
> > -   /* empty info frame */
> > -   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> > -   return -EINVAL;
> > -
> > /* only one of those can be supplied */
> > if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> > return -EINVAL;
> >   
> > -   /* for side by side (half) we also need to provide 3D_Ext_Data */
> > -   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > -   frame->length = 6;
> > -   else
> > -   frame->length = 5;
> > +   frame->length = hdmi_vendor_infoframe_length(frame);
> >   
> > length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> >   
> > @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
> > hdmi_vendor_infoframe *frame,
> > ptr[5] = 0x0c;
> > ptr[6] = 0x00;
> >   
> > -   if (frame->vic) {
> > -   ptr[7] = 0x1 << 5;  /* video format */
> > -   ptr[8] = frame->vic;
> > -   } else {
> > +   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
> > ptr[7] = 0x2 << 5;  /* video format */
> > ptr[8] = (frame->s3d_struct & 0xf) << 4;
> > if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
> > +   } else if (frame->vic) {
> Please correct me if I dint understand this properly, but for a HDMI 2.0 
> sink + 3D transmission, wouldn't I be sending
> HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

That vic will be in the AVI infoframe. Here we're concerned about the
VIC in the HDMI vendor infoframe.

> 
> - Shashank
> > +   ptr[7] = 0x1 << 5;  /* video format */
> > +   ptr[8] = frame->vic;
> > +   } else {
> > +   ptr[7] = 0x0 << 5;  /* video format */
> > }
> >   
> > hdmi_infoframe_set_checksum(buffer, length);
> > @@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
> > hdmi_vendor_any_infoframe *frame,
> >   
> > if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
> > ptr[1] != 1 ||
> > -   (ptr[2] != 5 && ptr[2] != 6))
> > +   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
> > return -EINVAL;
> >   
> > length = ptr[2];
> > @@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
> > hdmi_vendor_any_infoframe *frame,
> >   
> > hvf->length = length;
> >   
> > -   if (hdmi_video_format == 0x1) {
> > -   hvf->vic = ptr[4];
> > -   } else if (hdmi_video_format == 0x2) {
> > +   if (hdmi_video_format == 0x2) {
> > +   if (length != 5 && length != 6)
> > +   return -EINVAL;
> > hvf->s3d_struct = ptr[4] >> 4;
> > if (hvf->s3d_struct >= 

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix init_clock_gating for resume

[Chris Wilson]

Quoting Ville Syrjala (2017-11-16 16:02:15)
> From: Ville Syrjälä 
> 
> Moving the init_clock_gating() call from intel_modeset_init_hw() to
> intel_modeset_gem_init() had an unintended effect of not applying
> some workarounds on resume. This, for example, cause some kind of
> corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS
> screen after hibernation. Fix the problem by explicitly calling
> init_clock_gating() from the resume path.
> 
> I really hope this doesn't break something else again. At least
> the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549
> didn't make a comeback, even after a hibernate cycle.
> 
> v2: Reorder the init_clock_gating vs. modeset_init_hw to match
> the display reset path (Rodrigo)
> 
> Cc: sta...@vger.kernel.org
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it 
> was")
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3423d873123a..fb584b821fb3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1709,6 +1709,7 @@ static int i915_drm_resume(struct drm_device *dev)
> i915_gem_resume(dev_priv);
>  
> intel_modeset_init_hw(dev);
> +   intel_init_clock_gating(dev_priv);

The repetition of GT stuff here shouldn't be a problem, since they
should match the values in the reloaded context. (If not, we have bigger
problems!) And the bits that aren't in the context do need to be
restored.

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

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add igt_display_reset function, v2.

[Maarten Lankhorst]

A lot of code duplicates this, but it should be handled in the core.
Add it and use it after igt_display_init(), the tests have to be
converted one by one.

Changes since v1:
- Merely reset rotation to HW value.

Signed-off-by: Maarten Lankhorst 
---
 lib/igt_kms.c | 164 +-
 lib/igt_kms.h |   1 +
 2 files changed, 106 insertions(+), 59 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 1d26b8ddbf43..d51aba50e3d1 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1549,29 +1549,14 @@ static void igt_output_refresh(igt_output_t *output)
   -1);
}
 
-   if (output->config.connector) {
+   if (output->config.connector)
igt_atomic_fill_connector_props(display, output,
IGT_NUM_CONNECTOR_PROPS, igt_connector_prop_names);
 
-   if (output->props[IGT_CONNECTOR_BROADCAST_RGB])
-   igt_output_set_prop_value(output,
- IGT_CONNECTOR_BROADCAST_RGB,
- BROADCAST_RGB_FULL);
-   }
-
LOG(display, "%s: Selecting pipe %s\n", output->name,
kmstest_pipe_name(output->pending_pipe));
 }
 
-static bool
-get_plane_property(int drm_fd, uint32_t plane_id, const char *name,
-  uint32_t *prop_id /* out */, uint64_t *value /* out */,
-  drmModePropertyPtr *prop /* out */)
-{
-   return kmstest_get_property(drm_fd, plane_id, DRM_MODE_OBJECT_PLANE,
-   name, prop_id, value, prop);
-}
-
 static int
 igt_plane_set_property(igt_plane_t *plane, uint32_t prop_id, uint64_t value)
 {
@@ -1582,15 +1567,6 @@ igt_plane_set_property(igt_plane_t *plane, uint32_t 
prop_id, uint64_t value)
 DRM_MODE_OBJECT_PLANE, prop_id, value);
 }
 
-static bool
-get_crtc_property(int drm_fd, uint32_t crtc_id, const char *name,
-  uint32_t *prop_id /* out */, uint64_t *value /* out */,
-  drmModePropertyPtr *prop /* out */)
-{
-   return kmstest_get_property(drm_fd, crtc_id, DRM_MODE_OBJECT_CRTC,
-   name, prop_id, value, prop);
-}
-
 /*
  * Walk a plane's property list to determine its type.  If we don't
  * find a type property, then the kernel doesn't support universal
@@ -1601,14 +1577,112 @@ static int get_drm_plane_type(int drm_fd, uint32_t 
plane_id)
uint64_t value;
bool has_prop;
 
-   has_prop = get_plane_property(drm_fd, plane_id, "type",
- NULL /* prop_id */, , NULL);
+   has_prop = kmstest_get_property(drm_fd, plane_id, DRM_MODE_OBJECT_PLANE,
+   "type", NULL, , NULL);
if (has_prop)
return (int)value;
 
return DRM_PLANE_TYPE_OVERLAY;
 }
 
+static void igt_plane_reset(igt_plane_t *plane)
+{
+   /* Reset src coordinates. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_X, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_Y, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_W, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_SRC_H, 0);
+
+   /* Reset crtc coordinates. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_X, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_Y, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_W, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_H, 0);
+
+   /* Reset binding to fb and crtc. */
+   igt_plane_set_prop_value(plane, IGT_PLANE_FB_ID, 0);
+   igt_plane_set_prop_value(plane, IGT_PLANE_CRTC_ID, 0);
+
+   /* Use default rotation */
+   if (igt_plane_has_prop(plane, IGT_PLANE_ROTATION)) {
+   plane->values[IGT_PLANE_ROTATION] =
+   igt_plane_get_prop_value(plane, IGT_PLANE_ROTATION);
+   igt_plane_clear_prop_changed(plane, IGT_PLANE_ROTATION);
+   }
+
+   igt_plane_clear_prop_changed(plane, IGT_PLANE_IN_FENCE_FD);
+   plane->values[IGT_PLANE_IN_FENCE_FD] = ~0ULL;
+}
+
+static void igt_pipe_reset(igt_pipe_t *pipe)
+{
+   igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_MODE_ID, 0);
+   igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
+   igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
+
+   pipe->out_fence_fd = -1;
+}
+
+static void igt_output_reset(igt_output_t *output)
+{
+   output->pending_pipe = PIPE_NONE;
+   output->use_override_mode = false;
+   memset(>override_mode, 0, sizeof(output->override_mode));
+
+   igt_output_set_prop_value(output, IGT_CONNECTOR_CRTC_ID, 0);
+
+   if (igt_output_has_prop(output, IGT_CONNECTOR_BROADCAST_RGB))
+   igt_output_set_prop_value(output, IGT_CONNECTOR_BROADCAST_RGB,
+ BROADCAST_RGB_FULL);
+}
+
+/**
+ * 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Expose more GPU properties through sysfs

[Patchwork]

== Series Details ==

Series: drm/i915: Expose more GPU properties through sysfs
URL   : https://patchwork.freedesktop.org/series/33950/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
drivers/gpu/drm/i915/i915_sysfs.c: In function ‘i915_setup_topology_sysfs’:
drivers/gpu/drm/i915/i915_sysfs.c:644:2: error: ignoring return value of 
‘kobject_init_and_add’, declared with attribute warn_unused_result 
[-Werror=unused-result]
  kobject_init_and_add(_kobj->kobj,
  ^~
 _type,
 ~~~
 _priv->drm.primary->kdev->kobj,
 ~~~
 "topology");
 ~~~
drivers/gpu/drm/i915/i915_sysfs.c:659:3: error: ignoring return value of 
‘kobject_init_and_add’, declared with attribute warn_unused_result 
[-Werror=unused-result]
   kobject_init_and_add(_kobj->kobj,
   ^~~
  _type,
  
  _kobj->kobj,
  ~
  "slice%i", s);
  ~
drivers/gpu/drm/i915/i915_sysfs.c:675:4: error: ignoring return value of 
‘kobject_init_and_add’, declared with attribute warn_unused_result 
[-Werror=unused-result]
kobject_init_and_add(_kobj->kobj,
^~
   _type,
   ~~~
   _kobj->kobj,
   ~~
   "subslice%i", ss);
   ~
drivers/gpu/drm/i915/i915_sysfs.c: In function ‘i915_setup_engines_sysfs’:
drivers/gpu/drm/i915/i915_sysfs.c:758:2: error: ignoring return value of 
‘kobject_init_and_add’, declared with attribute warn_unused_result 
[-Werror=unused-result]
  kobject_init_and_add(_priv->topology.engines_kobj,
  ^~
 dev_priv->drm.primary->kdev->kobj.ktype,
 
 _priv->drm.primary->kdev->kobj,
 ~~~
 "engines");
 ~~
drivers/gpu/drm/i915/i915_sysfs.c:766:3: error: ignoring return value of 
‘kobject_init_and_add’, declared with attribute warn_unused_result 
[-Werror=unused-result]
   kobject_init_and_add(>kobj, _type,
   ^
  _priv->topology.engines_kobj,
  ~
  engine->name);
  ~
cc1: all warnings being treated as errors
scripts/Makefile.build:314: recipe for target 
'drivers/gpu/drm/i915/i915_sysfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_sysfs.o] Error 1
scripts/Makefile.build:573: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:573: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:573: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1024: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH v2] drm/i915: Fix init_clock_gating for resume

[Ville Syrjala]

From: Ville Syrjälä 

Moving the init_clock_gating() call from intel_modeset_init_hw() to
intel_modeset_gem_init() had an unintended effect of not applying
some workarounds on resume. This, for example, cause some kind of
corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS
screen after hibernation. Fix the problem by explicitly calling
init_clock_gating() from the resume path.

I really hope this doesn't break something else again. At least
the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549
didn't make a comeback, even after a hibernate cycle.

v2: Reorder the init_clock_gating vs. modeset_init_hw to match
the display reset path (Rodrigo)

Cc: sta...@vger.kernel.org
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was")
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3423d873123a..fb584b821fb3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1709,6 +1709,7 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
 
intel_modeset_init_hw(dev);
+   intel_init_clock_gating(dev_priv);
 
spin_lock_irq(_priv->irq_lock);
if (dev_priv->display.hpd_irq_setup)
-- 
2.13.6

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

[Intel-gfx] [PATCH 4/4] drm/i915: expose engine availability through sysfs

[Lionel Landwerlin]

This enables userspace to discover the engines available on the GPU.
Here is the layout :

/sys/devices/pci:00/:00:02.0/drm/card0/engines
├── bcs0
│   ├── class
│   └── instance
├── rcs0
│   ├── class
│   └── instance
├── vcs0
│   ├── class
│   ├── hevc
│   └── instance
├── vcs1
│   ├── class
│   └── instance
└── vecs0
├── class
└── instance

Further capabilities can be added later as attributes of each engine.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_sysfs.c   | 92 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +
 3 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44b807421af8..c4f6e8ecf212 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2749,6 +2749,7 @@ struct drm_i915_private {
 
struct {
struct intel_topology_kobject kobj;
+   struct kobject engines_kobj;
 
struct sysfs_slice {
struct intel_slice_kobject kobj;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 1d835f164d80..992aeaa91565 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -712,6 +712,92 @@ static void i915_teardown_topology_sysfs(struct 
drm_i915_private *dev_priv)
kobject_del(_kobj->kobj);
 }
 
+static struct attribute engine_instance_attr = {
+   .name = "instance",
+   .mode = 0444,
+};
+
+static struct attribute engine_class_attr = {
+   .name = "class",
+   .mode = 0444,
+};
+
+static struct attribute engine_hevc_attr = {
+   .name = "hevc",
+   .mode = 0444,
+};
+
+static ssize_t
+show_engine_attr(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+   struct intel_engine_cs *engine =
+   container_of(kobj, struct intel_engine_cs, kobj);
+
+   if (attr == _instance_attr)
+   return sprintf(buf, "%hhu\n", engine->uabi_id);
+   if (attr == _class_attr)
+   return sprintf(buf, "%hhu\n", engine->uabi_class);
+   if (attr == _hevc_attr)
+   return sprintf(buf, "%i\n", INTEL_GEN(engine->i915) >= 8);
+   return sprintf(buf, "\n");
+}
+
+static const struct sysfs_ops engine_ops = {
+   .show = show_engine_attr,
+};
+
+static struct kobj_type engine_type = {
+   .sysfs_ops = _ops,
+};
+
+static int i915_setup_engines_sysfs(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   kobject_init_and_add(_priv->topology.engines_kobj,
+dev_priv->drm.primary->kdev->kobj.ktype,
+_priv->drm.primary->kdev->kobj,
+"engines");
+
+   for_each_engine(engine, dev_priv, id) {
+   int ret;
+
+   kobject_init_and_add(>kobj, _type,
+_priv->topology.engines_kobj,
+engine->name);
+
+   ret = sysfs_create_file(>kobj, _instance_attr);
+   if (ret)
+   return ret;
+   ret = sysfs_create_file(>kobj, _class_attr);
+   if (ret)
+   return ret;
+   if (engine->id == VCS) {
+   ret = sysfs_create_file(>kobj, 
_hevc_attr);
+   if (ret)
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static void i915_teardown_engines_sysfs(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   sysfs_remove_file(>kobj, _instance_attr);
+   sysfs_remove_file(>kobj, _class_attr);
+   sysfs_remove_file(>kobj, _hevc_attr);
+   }
+
+   kobject_get(_priv->topology.engines_kobj);
+   kobject_del(_priv->topology.engines_kobj);
+}
+
 void i915_setup_sysfs(struct drm_i915_private *dev_priv)
 {
struct device *kdev = dev_priv->drm.primary->kdev;
@@ -762,6 +848,10 @@ void i915_setup_sysfs(struct drm_i915_private *dev_priv)
if (ret)
DRM_ERROR("Topology sysfs setup failed\n");
 
+   ret = i915_setup_engines_sysfs(dev_priv);
+   if (ret)
+   DRM_ERROR("Engines sysfs setup failed\n");
+
i915_setup_error_capture(kdev);
 }
 
@@ -771,6 +861,8 @@ void i915_teardown_sysfs(struct drm_i915_private *dev_priv)
 
i915_teardown_error_capture(kdev);
 
+   i915_teardown_engines_sysfs(dev_priv);
+
i915_teardown_topology_sysfs(dev_priv);
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5f96533e5341..0243a9e620da 

[Intel-gfx] [PATCH 3/4] drm/i915: expose EU topology through sysfs

[Lionel Landwerlin]

With the introduction of asymetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam. Here we introduce a more detailed
way of querying the Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because signals need to be accounted properly based on whether part of
the GPU has been fused off. The current aggregated numbers like
EU_TOTAL do not gives us sufficient information.

Here is the sysfs layout on a Skylake GT4 :

/sys/devices/pci:00/:00:02.0/drm/card0/topology/
├── enabled_mask
├── slice0
│   ├── enabled_mask
│   ├── subslice0
│   │   └── enabled_mask
│   ├── subslice1
│   │   └── enabled_mask
│   ├── subslice2
│   │   └── enabled_mask
│   └── subslice3
│   └── enabled_mask
├── slice1
│   ├── enabled_mask
│   ├── subslice0
│   │   └── enabled_mask
│   ├── subslice1
│   │   └── enabled_mask
│   ├── subslice2
│   │   └── enabled_mask
│   └── subslice3
│   └── enabled_mask
└── slice2
├── enabled_mask
├── subslice0
│   └── enabled_mask
├── subslice1
│   └── enabled_mask
├── subslice2
│   └── enabled_mask
└── subslice3
└── enabled_mask

Each enabled_mask file gives us a mask of the enabled units :

$ cat /sys/devices/pci\:00/\:00\:02.0/drm/card0/topology/enabled_mask
0x7

$ cat 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/topology/slice0/subslice2/enabled_mask
0xff

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  30 +++
 drivers/gpu/drm/i915/i915_sysfs.c | 159 ++
 2 files changed, 189 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8d239d8bfab..44b807421af8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2259,6 +2259,24 @@ struct intel_cdclk_state {
u8 voltage_level;
 };
 
+struct intel_topology_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+};
+
+struct intel_slice_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+   u8 slice_index;
+};
+
+struct intel_subslice_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+   u8 slice_index;
+   u8 subslice_index;
+};
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2729,6 +2747,18 @@ struct drm_i915_private {
} oa;
} perf;
 
+   struct {
+   struct intel_topology_kobject kobj;
+
+   struct sysfs_slice {
+   struct intel_slice_kobject kobj;
+
+   struct sysfs_subslice {
+   struct intel_subslice_kobject kobj;
+   } subslices[GEN_MAX_SUBSLICES];
+   } slices[GEN_MAX_SLICES];
+   } topology;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
void (*resume)(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 791759f632e1..1d835f164d80 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -559,6 +559,159 @@ static void i915_setup_error_capture(struct device *kdev) 
{}
 static void i915_teardown_error_capture(struct device *kdev) {}
 #endif
 
+static struct attribute mask_attr = {
+   .name = "enabled_mask",
+   .mode = 0444,
+};
+
+static ssize_t
+show_topology_attr(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+   struct intel_topology_kobject *kobj_wrapper =
+   container_of(kobj, struct intel_topology_kobject, kobj);
+   struct drm_i915_private *dev_priv = kobj_wrapper->dev_priv;
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+
+   if (attr == _attr)
+   return sprintf(buf, "0x%hhx\n", sseu->slice_mask);
+   return sprintf(buf, "0x0\n");
+}
+
+static const struct sysfs_ops topology_ops = {
+   .show = show_topology_attr,
+};
+
+static struct kobj_type topology_type = {
+   .sysfs_ops = _ops,
+};
+
+static ssize_t
+show_slice_attr(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+   struct intel_slice_kobject *kobj_wrapper =
+   container_of(kobj, struct intel_slice_kobject, kobj);
+   struct drm_i915_private *dev_priv = kobj_wrapper->dev_priv;
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+
+   if (attr == _attr) {
+   return sprintf(buf, "0x%hhx\n",
+  sseu->subslices_mask[kobj_wrapper->slice_index]);
+   }
+
+   return sprintf(buf, "0x0\n");
+}
+
+static const struct sysfs_ops slice_ops = {
+   .show = show_slice_attr,
+};
+
+static struct kobj_type slice_type = {
+   .sysfs_ops = _ops,
+};
+
+static ssize_t
+show_subslice_attr(struct kobject *kobj, struct attribute 

[Intel-gfx] [PATCH 0/4] drm/i915: Expose more GPU properties through sysfs

[Lionel Landwerlin]

Hi all,

Based on feedback on previous series by Tvrtko & myself, here is a
series that exposes EU topology & engines availability through sysfs.

Cheers,

Lionel Landwerlin (4):
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915: expose EU topology through sysfs
  drm/i915: expose engine availability through sysfs

 drivers/gpu/drm/i915/i915_debugfs.c  |  50 +++---
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  54 ++-
 drivers/gpu/drm/i915/i915_sysfs.c| 251 +++
 drivers/gpu/drm/i915/intel_device_info.c | 169 +++--
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   4 +-
 7 files changed, 455 insertions(+), 77 deletions(-)

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

[Intel-gfx] [PATCH 1/4] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  23 -
 drivers/gpu/drm/i915/intel_device_info.c | 169 ++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 161 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff8f508a7661..c96411dcf621 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4464,7 +4464,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4511,7 +4511,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4566,8 +4566,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4577,7 +4577,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4599,9 +4599,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4620,6 +4623,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4627,10 +4631,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,
+  s, sseu->subslices_mask[s]);
+   }
seq_printf(m, "  %s EU Total: %u\n", type,
   sseu->eu_total);
seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 11f73b69259b..52f3567de525 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -415,7 +415,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
 

[Intel-gfx] [PATCH 2/4] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c96411dcf621..2112e2cb7a7d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4479,11 +4479,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices],
+   eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4505,7 +4505,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4513,7 +4513,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4533,17 +4533,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], 
eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4558,7 +4552,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4569,7 +4563,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslices_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: exercise_ggtt may have nothing to do

[Chris Wilson]

Quoting Chris Wilson (2017-11-15 15:25:58)
> When operating on the live_ggtt we have to find a usuable hole for our
> test. It is possible for there to be no hole we can use, so initialise
> the err to 0 for the early exit.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index d9560d8a6cc8..3dcf886a2802 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -958,7 +958,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
> u64 hole_start, hole_end, last = 0;
> struct drm_mm_node *node;
> IGT_TIMEOUT(end_time);
> -   int err = -ENODEV;
> +   int err = 0;
>  
> mutex_lock(>drm.struct_mutex);
>  restart:

Pushed with a flyby irc review from Joonas, thanks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't sanitize frame start delay if the pipe is off

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 09:13:28PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-15 20:04:42)
> > From: Ville Syrjälä 
> > 
> > Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is
> > actually on. Should cure some unclaimed register accesses.
> + during reset, as we are rather cavalier in our approach to powerdomain
> management.

Amended, and pushed. Thanks.

> 
> > We don't have to sanitize this if the pipe is off since we will
> > overwrite the frame start delay anyway when turning the pipe on.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102249
> > Signed-off-by: Ville Syrjälä 
> Reviewed-by: Chris Wilson 
> 
> Let's not even get started on the handling of modesets vs display reset.
> -Chris

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't sanitize frame start delay if the pipe is off

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 09:17:01PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Don't sanitize frame start delay if the pipe is off
> URL   : https://patchwork.freedesktop.org/series/33901/
> State : success
> 
> == Summary ==
> 
> Test kms_busy:
> Subgroup extended-modeset-hang-newfb-with-reset-render-a:
> dmesg-warn -> PASS   (shard-hsw) fdo#102249
> Subgroup extended-modeset-hang-newfb-with-reset-render-b:
> dmesg-warn -> PASS   (shard-hsw) fdo#103038
> Test drv_module_reload:
> Subgroup basic-reload-inject:
> dmesg-warn -> PASS   (shard-hsw) fdo#102707
> 
> fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
> fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038

Oh we had two bugs for the same thing.

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

This one is the fb leak. Not fixed by the patch, just fails randomly it
seems.

> 
> shard-hswtotal:2584 pass:1473 dwarn:2   dfail:1   fail:9   skip:1099 
> time:9603s
> Blacklisted hosts:
> shard-apltotal:2565 pass:1602 dwarn:3   dfail:1   fail:22  skip:936 
> time:13167s
> shard-kbltotal:2500 pass:1613 dwarn:48  dfail:4   fail:23  skip:810 
> time:10513s
> shard-snbtotal:2584 pass:1259 dwarn:2   dfail:1   fail:11  skip:1311 
> time:8110s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7151/shards.html

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

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/selftests: Add a GuC doorbells selftest

[Chris Wilson]

Quoting Michel Thierry (2017-11-15 18:30:27)
> The first test aims to check guc_init_doorbell_hw, changing the existing
> guc clients and doorbells state before calling it.
> 
> The second test tries to create as many clients as it is currently possible
> (currently limited to max number of doorbells) and exercise the doorbell
> alloc/dealloc code.
> 
> Since our usage mode require very few clients/doorbells, this code has
> been exercised very lightly and it's good to have a simple test for it.
> 
> As reference, this test already helped identify the bug fixed by
> commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").
> 
> v2: Extend number of clients; check for client allocation failure when
> number of doorbells is exceeded; validate client properties; reuse
> guc_init_doorbell_hw (Chris).
> 
> v3: guc_init_doorbell_hw test added per Chris suggestion.
> 
> v4: Try to explain why guc_init_doorbell_hw exist and comment some
> details in the subtest.
> 
> Signed-off-by: Michel Thierry 
> Cc: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 

Rebase, resend with r-bs and lets land this monster.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for GuC submission functions/struct name/prototype update (rev3)

[Chris Wilson]

Quoting Patchwork (2017-11-16 14:56:50)
> == Series Details ==
> 
> Series: GuC submission functions/struct name/prototype update (rev3)
> URL   : https://patchwork.freedesktop.org/series/33679/
> State : warning
> 
> == Summary ==
> 
> Test kms_setmode:
> Subgroup basic:
> fail   -> PASS   (shard-hsw) fdo#99912
> Test kms_flip:
> Subgroup vblank-vs-suspend-interruptible:
> pass   -> SKIP   (shard-snb) fdo#100368 +1
> Test kms_chv_cursor_fail:
> Subgroup pipe-c-256x256-bottom-edge:
> pass   -> SKIP   (shard-hsw)
> Test kms_plane_multiple:
> Subgroup atomic-pipe-a-tiling-none:
> pass   -> SKIP   (shard-hsw)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> fail   -> PASS   (shard-snb) fdo#101623
> Test drv_selftest:
> Subgroup mock_sanitycheck:
> pass   -> DMESG-WARN (shard-snb) fdo#103717
> Test kms_busy:
> Subgroup extended-modeset-hang-oldfb-with-reset-render-b:
> pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1

And pushed, thanks for fixing this up! And for proofreading the patches.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 23 +--
  1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
  {
+   enum hdmi_picture_aspect picture_aspect;
int err;
  
  	if (!frame || !mode)

@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);

This is slightly going in the loop.
- During the modeset the driver cant specify the aspect ratio 
information, as DRM layer lacks this support.
- So we fill the VIC field, by comparing the mode with the 
DRM_CEA_MODES[] list. This will pick the first mode
  available in the list (regardless of its aspect ratio), and fill the 
VIC, as we don't consider aspect ratio while comparing timings.
- Again, now while sending the aspect ratio, we are picking up the VIC, 
which may not be correct.


So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is 
first in list, we will always pick 4:3 aspect ratio.


- Shashank
  
+	/*

+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
  


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

[Intel-gfx] ✗ Fi.CI.IGT: warning for GuC submission functions/struct name/prototype update (rev3)

[Patchwork]

== Series Details ==

Series: GuC submission functions/struct name/prototype update (rev3)
URL   : https://patchwork.freedesktop.org/series/33679/
State : warning

== Summary ==

Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup vblank-vs-suspend-interruptible:
pass   -> SKIP   (shard-snb) fdo#100368 +1
Test kms_chv_cursor_fail:
Subgroup pipe-c-256x256-bottom-edge:
pass   -> SKIP   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-none:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test drv_selftest:
Subgroup mock_sanitycheck:
pass   -> DMESG-WARN (shard-snb) fdo#103717
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-b:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103717 https://bugs.freedesktop.org/show_bug.cgi?id=103717
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2584 pass:1469 dwarn:3   dfail:1   fail:10  skip:1101 
time:9434s
shard-snbtotal:2584 pass:1257 dwarn:2   dfail:1   fail:12  skip:1312 
time:7935s
Blacklisted hosts:
shard-apltotal:2565 pass:1600 dwarn:2   dfail:1   fail:24  skip:937 
time:13158s
shard-kbltotal:2488 pass:1598 dwarn:26  dfail:3   fail:23  skip:834 
time:9194s

== Logs ==

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

Re: [Intel-gfx] [PATCH igt v2] tools/error_decode: Print ASCII user buffers

[Tvrtko Ursulin]

On 16/11/2017 14:35, Chris Wilson wrote:

Look at the first 16 characters of the user buffer and if they are all
printable, assume that user buffer contains ASCII data (e.g. a debug log)
that we want to simply print out. Otherwise, we treat it as a binary data
and hexdump as before.

Tvrtko: you know you could just write this as a printf (d'oh)

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
  tools/intel_error_decode.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/tools/intel_error_decode.c b/tools/intel_error_decode.c
index cdef3b18..8924026a 100644
--- a/tools/intel_error_decode.c
+++ b/tools/intel_error_decode.c
@@ -51,6 +51,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "intel_chipset.h"

  #include "intel_io.h"
@@ -434,6 +435,16 @@ print_fault_data(unsigned devid, uint32_t data1, uint32_t 
data0)
  
  #define MAX_RINGS 10 /* I really hope this never... */
  
+static bool maybe_ascii(const void *data, int check)

+{
+   const char *c = data;
+   while (check--) {
+   if (!isprint(*c++))
+   return false;
+   }
+   return true;
+}
+
  static void decode(struct drm_intel_decode *ctx,
   const char *buffer_name,
   const char *ring_name,
@@ -458,6 +469,8 @@ static void decode(struct drm_intel_decode *ctx,
drm_intel_decode_set_batch_pointer(ctx, data, gtt_offset,
   *count);
drm_intel_decode(ctx);
+   } else if (maybe_ascii(data, 16)) {
+   printf("%*s\n", 4 * *count, (char *)data);
} else {
for (int i = 0; i + 4 <= *count; i += 4)
printf("[%04x] %08x %08x %08x %08x\n",



My r-b on the previous version was one of the disappeared e-mails from 
yesterday. Anyway, this is even better.


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
  static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
This doesn't look right. This means we are expecting a CEA mode without 
a pic aspect ratio field,
which is invalid.  Ankit is going to publish the aspect ratio patch 
series again, with proper DRM cap and flags check. Would it be

ok if we have a look that handling first ?

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
   */
  u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

same here, and probably in other CEA match functions.

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
  static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3020,7 +3029,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))

+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
  
@@ -3037,6 +3046,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_

   */
  static u8 

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

[Chris Wilson]

Quoting Sagar Arun Kamble (2017-11-16 13:32:37)
> intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related
> tasklet functions. Name them with "submission_tasklet" suffix and
> remove intel/i915 prefix as they are static. Also rename irq_tasklet
> as just tasklet for clarity.
> 
> v2: s/_bh/_tasklet (Chris)
> 
> Suggested-by: Michal Wajdeczko 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Michal Wajdeczko 
> Cc: Michal Winiarski 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Automatic i915_switch_context for legacy

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-16 14:00:13)
> Chris Wilson  writes:
> 
> > During request construction, after pinning the context we know whether
> > or not we have to emit a context switch. So move this common operation
> > from every caller into i915_gem_request_alloc() itself.
> >
> > v2: Always submit the request if we emitted some commands during request
> > construction, as typically it also involves changes in global state.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
> >  drivers/gpu/drm/i915/i915_gem_context.c   |  7 +--
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c|  8 
> >  drivers/gpu/drm/i915/i915_gem_request.c   | 18 +-
> >  drivers/gpu/drm/i915/i915_perf.c  |  3 +--
> >  drivers/gpu/drm/i915/intel_ringbuffer.c   |  4 
> >  drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 
> >  drivers/gpu/drm/i915/selftests/i915_gem_context.c |  4 
> >  drivers/gpu/drm/i915/selftests/i915_gem_request.c | 10 --
> >  drivers/gpu/drm/i915/selftests/intel_hangcheck.c  |  4 
> >  10 files changed, 20 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index a7979b74ce21..d885cf0d2943 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -5043,7 +5043,7 @@ static int __intel_engines_record_defaults(struct 
> > drm_i915_private *i915)
> >   goto out_ctx;
> >   }
> >  
> > - err = i915_switch_context(rq);
> > + err = 0;
> >   if (engine->init_context)
> >   err = engine->init_context(rq);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 2db040695035..c1efbaf02bf2 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -842,8 +842,7 @@ int i915_switch_context(struct drm_i915_gem_request 
> > *req)
> >   struct intel_engine_cs *engine = req->engine;
> >  
> >   lockdep_assert_held(>i915->drm.struct_mutex);
> > - if (i915_modparams.enable_execlists)
> > - return 0;
> > + GEM_BUG_ON(i915_modparams.enable_execlists);
> >  
> >   if (!req->ctx->engine[engine->id].state) {
> >   struct i915_gem_context *to = req->ctx;
> > @@ -899,7 +898,6 @@ int i915_gem_switch_to_kernel_context(struct 
> > drm_i915_private *dev_priv)
> >  
> >   for_each_engine(engine, dev_priv, id) {
> >   struct drm_i915_gem_request *req;
> > - int ret;
> >  
> >   if (engine_has_idle_kernel_context(engine))
> >   continue;
> > @@ -922,10 +920,7 @@ int i915_gem_switch_to_kernel_context(struct 
> > drm_i915_private *dev_priv)
> >GFP_KERNEL);
> >   }
> >  
> > - ret = i915_switch_context(req);
> >   i915_add_request(req);
> > - if (ret)
> > - return ret;
> >   }
> >  
> >   return 0;
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 435ed95df144..85c7e8afe26e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1115,10 +1115,6 @@ static int __reloc_gpu_alloc(struct i915_execbuffer 
> > *eb,
> >   if (err)
> >   goto err_request;
> >  
> > - err = i915_switch_context(rq);
> > - if (err)
> > - goto err_request;
> > -
> >   err = eb->engine->emit_bb_start(rq,
> >   batch->node.start, PAGE_SIZE,
> >   cache->gen > 5 ? 0 : 
> > I915_DISPATCH_SECURE);
> > @@ -1965,10 +1961,6 @@ static int eb_submit(struct i915_execbuffer *eb)
> >   if (err)
> >   return err;
> >  
> > - err = i915_switch_context(eb->request);
> > - if (err)
> > - return err;
> > -
> >   if (eb->args->flags & I915_EXEC_GEN7_SOL_RESET) {
> >   err = i915_reset_gen7_sol_offsets(eb->request);
> >   if (err)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index e0d6221022a8..445495f9893c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -624,6 +624,10 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> >   if (ret)
> >   goto err_unpin;
> >  
> > + ret = intel_ring_wait_for_space(ring, MIN_SPACE_FOR_ADD_REQUEST);
> > + if (ret)
> > + goto err_unreserve;
> > +
> >   /* Move the oldest request to the slab-cache (if not in use!) */
> >   

Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.
I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which 
talks about

switch from 3D to 2D.  To me it looks like:
If (sending_to_hdmi2_sinks) {
- for 3d modes send HF-VSIF
- for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
  When you switch from 3d->2d {
 - send_HF-VSIF with 3D_valid bit = 0/1
 }
} else { /* HDMI 1.4b sinks from Appendix F */
-  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
}

Should we add a is_hdmi2 check and separate these cases ?



v2: Fix the getting has_hdmi_infoframe from display_info
 Always fail constructing the infoframe if the display
 possibly can't handle it

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
  drivers/gpu/drm/drm_edid.c| 34 +--
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
  drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
  drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
  drivers/gpu/drm/zte/zx_hdmi.c |  1 +
  include/drm/drm_connector.h   |  5 +
  include/drm/drm_edid.h|  1 +
  12 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..4417276ba02e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
union hdmi_infoframe frm;
u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
  
+			/* FIXME: We need the connector here */

drm_hdmi_vendor_infoframe_from_display_mode(
-   , adjusted_mode);
+   , NULL, adjusted_mode);
vic = frm.vendor.hdmi.vic;
if (vic >= ARRAY_SIZE(mhl_vic))
vic = 0;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a64ce7112288..b172139502d6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct 
dw_hdmi *hdmi,
u8 buffer[10];
ssize_t err;
  
-	err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode);
if (err < 0)
/*
 * Going into that statement does not means vendor infoframe
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..9ada0ccf50df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3393,6 +3393,7 @@ static int
  do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
   const u8 *video_db, u8 video_len)
  {
+   struct drm_display_info *info = >display_info;
int modes = 0, offset = 0, i, multi_present = 0, multi_len;
u8 vic_len, hdmi_3d_len = 0;
u16 mask;
@@ -3520,6 +3521,8 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const 
u8 *db, u8 len,
}
  
  out:

+   if (modes > 0)
+   info->has_hdmi_infoframe = true;
return modes;
  }
  
@@ -4243,6 +4246,8 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector 

Re: [Intel-gfx] [PATCH igt] lib: Dump /sys/kernel/debug/suspend_stats after suspend failure

[Chris Wilson]

Quoting Arkadiusz Hiler (2017-11-16 14:31:03)
> On Tue, Nov 14, 2017 at 01:19:01PM +, Chris Wilson wrote:
> > I noticed that dpm was storing some information about which phase of
> > suspend failed inside suspend_stats. That will be useful to help debug
> > such failures, so automatically dump it after suspend fails.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  lib/igt_aux.c | 22 ++
> >  1 file changed, 18 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> > index ee53559c..0bcf792c 100644
> > --- a/lib/igt_aux.c
> > +++ b/lib/igt_aux.c
> > @@ -803,10 +803,24 @@ static void suspend_via_rtcwake(enum 
> > igt_suspend_state state)
> >   snprintf(cmd, sizeof(cmd), "rtcwake -s %d -m %s ",
> >delay, suspend_state_name[state]);
> >   ret = igt_system(cmd);
> > - igt_assert_f(ret == 0,
> > -  "rtcwake failed with %i\n"
> > -  "Check dmesg for further details.\n",
> > -  ret);
> > + if (ret) {
> > + const char *path = "suspend_stats";
> > + char *info;
> > + int dir;
> > +
> > + igt_warn("rtcwake failed with %i\n"
> > +  "Check dmesg for further details.\n",
> > +  ret);
> > +
> > + dir = open(igt_debugfs_mount(), O_RDONLY);
> > + info = igt_sysfs_get(dir, path);
> > + close(dir);
> > + if (info) {
> > + igt_debug("%s:\n%s\n", path, info);
> > + free(info);
> > + }
> > + }
> > + igt_assert_eq(ret, 0);
> >  }
> >  
> >  static void suspend_via_sysfs(int power_dir, enum igt_suspend_state state)
> 
> We can see it in action here:
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_496/shard-apl3/igt@gem_...@in-flight-suspend.html
> 
> (gem_eio:7686) igt-aux-DEBUG: suspend_stats:
> success: 10
> fail: 1
> failed_freeze: 0
> failed_prepare: 0
> failed_suspend: 1
> failed_suspend_late: 0
> failed_suspend_noirq: 0
> failed_resume: 0
> failed_resume_early: 0
> failed_resume_noirq: 0
> failures:
>   last_failed_dev:  
> 
>   last_failed_errno:-16
> 0
>   last_failed_step: suspend
> 
> 
> Reviewed-by: Arkadiusz Hiler 
> and pushed

Now we just need dpm to actually record the device. I about 95% certain
we did not report -EBUSY; if i915_pm_suspend returns an error it gets
printed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.

v2: Handle unpack() as well
 Pull the length calculation into a helper

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Reviewed-by: Andrzej Hajda  #v1
Signed-off-by: Ville Syrjälä 
---
  drivers/video/hdmi.c | 51 +++
  1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
hdmi_vendor_infoframe *frame)
  }
  EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
  
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)

+{
+   /* for side by side (half) we also need to provide 3D_Ext_Data */
+   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   return 6;
+   else if (frame->vic != 0 || frame->s3d_struct != 
HDMI_3D_STRUCTURE_INVALID)
+   return 5;
+   else
+   return 4;
+}
+
  /**
   * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
buffer
   * @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
  
-	/* empty info frame */

-   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
-   return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
  
-	/* for side by side (half) we also need to provide 3D_Ext_Data */

-   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
-   frame->length = 6;
-   else
-   frame->length = 5;
+   frame->length = hdmi_vendor_infoframe_length(frame);
  
  	length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
  
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,

ptr[5] = 0x0c;
ptr[6] = 0x00;
  
-	if (frame->vic) {

-   ptr[7] = 0x1 << 5;/* video format */
-   ptr[8] = frame->vic;
-   } else {
+   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5;/* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+   } else if (frame->vic) {
Please correct me if I dint understand this properly, but for a HDMI 2.0 
sink + 3D transmission, wouldn't I be sending

HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

- Shashank

+   ptr[7] = 0x1 << 5;/* video format */
+   ptr[8] = frame->vic;
+   } else {
+   ptr[7] = 0x0 << 5;/* video format */
}
  
  	hdmi_infoframe_set_checksum(buffer, length);

@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
  
  	if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||

ptr[1] != 1 ||
-   (ptr[2] != 5 && ptr[2] != 6))
+   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
  
  	length = ptr[2];

@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
  
  	hvf->length = length;
  
-	if (hdmi_video_format == 0x1) {

-   hvf->vic = ptr[4];
-   } else if (hdmi_video_format == 0x2) {
+   if (hdmi_video_format == 0x2) {
+   if (length != 5 && length != 6)
+   return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
-   if (length == 6)
-   hvf->s3d_ext_data = ptr[5] >> 4;
-   else
+   if (length != 6)
return -EINVAL;
+   hvf->s3d_ext_data = ptr[5] >> 4;
}
+   } else if (hdmi_video_format == 0x1) {
+   if (length != 5)
+   return -EINVAL;
+   hvf->vic = 

[Intel-gfx] [PATCH igt v2] tools/error_decode: Print ASCII user buffers

[Chris Wilson]

Look at the first 16 characters of the user buffer and if they are all
printable, assume that user buffer contains ASCII data (e.g. a debug log)
that we want to simply print out. Otherwise, we treat it as a binary data
and hexdump as before.

Tvrtko: you know you could just write this as a printf (d'oh)

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 tools/intel_error_decode.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tools/intel_error_decode.c b/tools/intel_error_decode.c
index cdef3b18..8924026a 100644
--- a/tools/intel_error_decode.c
+++ b/tools/intel_error_decode.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "intel_chipset.h"
 #include "intel_io.h"
@@ -434,6 +435,16 @@ print_fault_data(unsigned devid, uint32_t data1, uint32_t 
data0)
 
 #define MAX_RINGS 10 /* I really hope this never... */
 
+static bool maybe_ascii(const void *data, int check)
+{
+   const char *c = data;
+   while (check--) {
+   if (!isprint(*c++))
+   return false;
+   }
+   return true;
+}
+
 static void decode(struct drm_intel_decode *ctx,
   const char *buffer_name,
   const char *ring_name,
@@ -458,6 +469,8 @@ static void decode(struct drm_intel_decode *ctx,
drm_intel_decode_set_batch_pointer(ctx, data, gtt_offset,
   *count);
drm_intel_decode(ctx);
+   } else if (maybe_ascii(data, 16)) {
+   printf("%*s\n", 4 * *count, (char *)data);
} else {
for (int i = 0; i + 4 <= *count; i += 4)
printf("[%04x] %08x %08x %08x %08x\n",
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH igt] lib: Dump /sys/kernel/debug/suspend_stats after suspend failure

[Arkadiusz Hiler]

On Tue, Nov 14, 2017 at 01:19:01PM +, Chris Wilson wrote:
> I noticed that dpm was storing some information about which phase of
> suspend failed inside suspend_stats. That will be useful to help debug
> such failures, so automatically dump it after suspend fails.
> 
> Signed-off-by: Chris Wilson 
> ---
>  lib/igt_aux.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index ee53559c..0bcf792c 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -803,10 +803,24 @@ static void suspend_via_rtcwake(enum igt_suspend_state 
> state)
>   snprintf(cmd, sizeof(cmd), "rtcwake -s %d -m %s ",
>delay, suspend_state_name[state]);
>   ret = igt_system(cmd);
> - igt_assert_f(ret == 0,
> -  "rtcwake failed with %i\n"
> -  "Check dmesg for further details.\n",
> -  ret);
> + if (ret) {
> + const char *path = "suspend_stats";
> + char *info;
> + int dir;
> +
> + igt_warn("rtcwake failed with %i\n"
> +  "Check dmesg for further details.\n",
> +  ret);
> +
> + dir = open(igt_debugfs_mount(), O_RDONLY);
> + info = igt_sysfs_get(dir, path);
> + close(dir);
> + if (info) {
> + igt_debug("%s:\n%s\n", path, info);
> + free(info);
> + }
> + }
> + igt_assert_eq(ret, 0);
>  }
>  
>  static void suspend_via_sysfs(int power_dir, enum igt_suspend_state state)

We can see it in action here:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_496/shard-apl3/igt@gem_...@in-flight-suspend.html

(gem_eio:7686) igt-aux-DEBUG: suspend_stats:
success: 10
fail: 1
failed_freeze: 0
failed_prepare: 0
failed_suspend: 1
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
  last_failed_dev:  

  last_failed_errno:-16
0
  last_failed_step: suspend


Reviewed-by: Arkadiusz Hiler 
and pushed

-- 
Cheers,
Arek

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

Re: [Intel-gfx] [PATCH] drm/i915: Clear breadcrumb node when cancelling signaling

[Chris Wilson]

Quoting Joonas Lahtinen (2017-11-16 11:08:18)
> On Wed, 2017-11-15 at 12:14 +, Chris Wilson wrote:
> > When we call intel_engine_cancel_signaling() to stop reporting whether
> > or not a request is completed via an asynchronous signal, we remove that
> > request from the breadcrumb wait queue. However, we may be concurrently
> > processing that request in the signaler itself, the actual operations on
> > the request itself are serialised but we do not actually clear the
> > waiter after removing it from the tree allowing both parties to attempt
> > to do so and corrupting the rbtree. (Elsewhere removing from the
> > breadcrumb wait queue could only be done on behalf of i915_wait_request,
> > so this race could not happen).
> > 
> > Reported-by: "He, Bo" 
> > Fixes: 9eb143bbec7d ("drm/i915: Allow a request to be cancelled")
> > Signed-off-by: Chris Wilson 
> > Cc: "He, Bo" 
> > Cc: Tvrtko Ursulin 
> > Cc: Michał Winiarski 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Ta, I was debating how to wait for a t-b, but this is definitely a race
between canceling and signaling that needs to be fixed regardless.

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

Re: [Intel-gfx] [PATCH v6] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-11-16 14:00:50)
> 
> On 16/11/2017 10:50, Chris Wilson wrote:
> > We check whether the multiplies will overflow prior to calling
> > kmalloc_array so that we can respond with -EINVAL for the invalid user
> > arguments rather than treating it as an -ENOMEM that would otherwise
> > occur. However, as Dan Carpenter pointed out, we did an addition on the
> > unsigned int prior to passing to kmalloc_array where it would be
> > promoted to size_t for the calculation, thereby allowing it to overflow
> > and underallocate.
> > 
> > v2: buffer_count is currently limited to INT_MAX because we treat it as
> > signaled variable for LUT_HANDLE in eb_lookup_vma
> > v3: Move common checks for eb1/eb2 into the same function
> > v4: Put the check back for nfence*sizeof(user_fence) overflow
> > v5: access_ok uses ULONG_MAX but kvmalloc_array uses SIZE_MAX
> > v6: size_t and unsigned long are not type-equivalent on 32b
> > 
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
...
> Reviewed-by: Tvrtko Ursulin 

Ta. Certainly makes type-safe languages appealing.

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

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

[Michal Wajdeczko]

On Thu, 16 Nov 2017 14:32:37 +0100, Sagar Arun Kamble  
 wrote:



intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related
tasklet functions. Name them with "submission_tasklet" suffix and
remove intel/i915 prefix as they are static. Also rename irq_tasklet
as just tasklet for clarity.

v2: s/_bh/_tasklet (Chris)

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---




diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h  
b/drivers/gpu/drm/i915/intel_ringbuffer.h

index 0531d93..f867aa6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -194,9 +194,9 @@ struct i915_priolist {
  */
 struct intel_engine_execlists {
/**
-* @irq_tasklet: softirq tasklet for bottom handler
+* @tasklet: softirq tasklet for bottom handler


I hope that some day we provide some valuable description here
but I guess this can wait little more, so

Reviewed-by: Michal Wajdeczko 


 */
-   struct tasklet_struct irq_tasklet;
+   struct tasklet_struct tasklet;
/**
 * @default_priolist: priority list for I915_PRIORITY_NORMAL

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

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC submission functions/struct name/prototype update (rev3)

[Patchwork]

== Series Details ==

Series: GuC submission functions/struct name/prototype update (rev3)
URL   : https://patchwork.freedesktop.org/series/33679/
State : success

== Summary ==

Series 33679v3 GuC submission functions/struct name/prototype update
https://patchwork.freedesktop.org/api/1.0/series/33679/revisions/3/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#103163
Test kms_busy:
Subgroup basic-flip-a:
pass   -> FAIL   (fi-gdg-551) fdo#102654
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:384s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:550s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:502s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:491s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:436s
fi-gdg-551   total:289  pass:177  dwarn:1   dfail:0   fail:2   skip:109 
time:266s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:441s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:479s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:578s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:532s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:465s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:564s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:429s
Blacklisted hosts:
fi-cnl-y total:289  pass:259  dwarn:3   dfail:0   fail:0   skip:27  
time:581s

1fc4fe8ac97eee86a4fe2dc1239a350aa3f13371 drm-tip: 2017y-11m-16d-12h-57m-10s UTC 
integration manifest
8bff95d84050 HAX enable GuC submission for CI
ccd871357e56 drm/i915/guc: Rename i915_guc_submission.c|h to 
intel_guc_submission.c|h
0042877c9199 drm/i915/guc: Rename i915_guc_client struct to intel_guc_client
90714814d4fd drm/i915/guc: Update name and prototype of GuC submission 
interface functions
e30128dab7cd drm/i915/guc: Update names of submission related static functions
29dc80eae843 drm/i915: Update execlists tasklet naming

== Logs ==

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

Re: [Intel-gfx] [PATCH v6] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

[Tvrtko Ursulin]

On 16/11/2017 10:50, Chris Wilson wrote:

We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.

v2: buffer_count is currently limited to INT_MAX because we treat it as
signaled variable for LUT_HANDLE in eb_lookup_vma
v3: Move common checks for eb1/eb2 into the same function
v4: Put the check back for nfence*sizeof(user_fence) overflow
v5: access_ok uses ULONG_MAX but kvmalloc_array uses SIZE_MAX
v6: size_t and unsigned long are not type-equivalent on 32b

Reported-by: Dan Carpenter 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 66 +++---
  1 file changed, 43 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 435ed95df144..53ccb27bfe91 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2074,23 +2074,27 @@ static struct drm_syncobj **
  get_fence_array(struct drm_i915_gem_execbuffer2 *args,
struct drm_file *file)
  {
-   const unsigned int nfences = args->num_cliprects;
+   const unsigned long nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
struct drm_syncobj **fences;
-   unsigned int n;
+   unsigned long n;
int err;
  
  	if (!(args->flags & I915_EXEC_FENCE_ARRAY))

return NULL;
  
-	if (nfences > SIZE_MAX / sizeof(*fences))

+   /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+   BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+   if (nfences > min_t(unsigned long,
+   ULONG_MAX / sizeof(*user),
+   SIZE_MAX / sizeof(*fences)))
return ERR_PTR(-EINVAL);
  
  	user = u64_to_user_ptr(args->cliprects_ptr);

-   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
+   if (!access_ok(VERIFY_READ, user, nfences * sizeof(*user)))
return ERR_PTR(-EFAULT);
  
-	fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),

+   fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_KERNEL);
if (!fences)
return ERR_PTR(-ENOMEM);
@@ -2447,6 +2451,26 @@ i915_gem_do_execbuffer(struct drm_device *dev,
return err;
  }
  
+static size_t eb_element_size(void)

+{
+   return (sizeof(struct drm_i915_gem_exec_object2) +
+   sizeof(struct i915_vma *) +
+   sizeof(unsigned int));
+}
+
+static bool check_buffer_count(size_t count)
+{
+   const size_t sz = eb_element_size();
+
+   /*
+* When using LUT_HANDLE, we impose a limit of INT_MAX for the lookup
+* array size (see eb_create()). Otherwise, we can accept an array as
+* large as can be addressed (though use large arrays at your peril)!
+*/
+
+   return !(count < 1 || count > INT_MAX || count > SIZE_MAX / sz - 1);
+}
+
  /*
   * Legacy execbuffer just creates an exec2 list from the original exec object
   * list array and passes it to the real function.
@@ -2455,18 +2479,16 @@ int
  i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file)
  {
-   const size_t sz = (sizeof(struct drm_i915_gem_exec_object2) +
-  sizeof(struct i915_vma *) +
-  sizeof(unsigned int));
struct drm_i915_gem_execbuffer *args = data;
struct drm_i915_gem_execbuffer2 exec2;
struct drm_i915_gem_exec_object *exec_list = NULL;
struct drm_i915_gem_exec_object2 *exec2_list = NULL;
+   const size_t count = args->buffer_count;
unsigned int i;
int err;
  
-	if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {

-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   if (!check_buffer_count(count)) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
  
@@ -2485,9 +2507,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,

return -EINVAL;
  
  	/* Copy in the exec list from userland */

-   exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list),
+   exec_list = kvmalloc_array(count, sizeof(*exec_list),
   __GFP_NOWARN | GFP_KERNEL);
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Automatic i915_switch_context for legacy

[Mika Kuoppala]

Chris Wilson  writes:

> During request construction, after pinning the context we know whether
> or not we have to emit a context switch. So move this common operation
> from every caller into i915_gem_request_alloc() itself.
>
> v2: Always submit the request if we emitted some commands during request
> construction, as typically it also involves changes in global state.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
>  drivers/gpu/drm/i915/i915_gem_context.c   |  7 +--
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c|  8 
>  drivers/gpu/drm/i915/i915_gem_request.c   | 18 +-
>  drivers/gpu/drm/i915/i915_perf.c  |  3 +--
>  drivers/gpu/drm/i915/intel_ringbuffer.c   |  4 
>  drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 
>  drivers/gpu/drm/i915/selftests/i915_gem_context.c |  4 
>  drivers/gpu/drm/i915/selftests/i915_gem_request.c | 10 --
>  drivers/gpu/drm/i915/selftests/intel_hangcheck.c  |  4 
>  10 files changed, 20 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a7979b74ce21..d885cf0d2943 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5043,7 +5043,7 @@ static int __intel_engines_record_defaults(struct 
> drm_i915_private *i915)
>   goto out_ctx;
>   }
>  
> - err = i915_switch_context(rq);
> + err = 0;
>   if (engine->init_context)
>   err = engine->init_context(rq);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 2db040695035..c1efbaf02bf2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -842,8 +842,7 @@ int i915_switch_context(struct drm_i915_gem_request *req)
>   struct intel_engine_cs *engine = req->engine;
>  
>   lockdep_assert_held(>i915->drm.struct_mutex);
> - if (i915_modparams.enable_execlists)
> - return 0;
> + GEM_BUG_ON(i915_modparams.enable_execlists);
>  
>   if (!req->ctx->engine[engine->id].state) {
>   struct i915_gem_context *to = req->ctx;
> @@ -899,7 +898,6 @@ int i915_gem_switch_to_kernel_context(struct 
> drm_i915_private *dev_priv)
>  
>   for_each_engine(engine, dev_priv, id) {
>   struct drm_i915_gem_request *req;
> - int ret;
>  
>   if (engine_has_idle_kernel_context(engine))
>   continue;
> @@ -922,10 +920,7 @@ int i915_gem_switch_to_kernel_context(struct 
> drm_i915_private *dev_priv)
>GFP_KERNEL);
>   }
>  
> - ret = i915_switch_context(req);
>   i915_add_request(req);
> - if (ret)
> - return ret;
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 435ed95df144..85c7e8afe26e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1115,10 +1115,6 @@ static int __reloc_gpu_alloc(struct i915_execbuffer 
> *eb,
>   if (err)
>   goto err_request;
>  
> - err = i915_switch_context(rq);
> - if (err)
> - goto err_request;
> -
>   err = eb->engine->emit_bb_start(rq,
>   batch->node.start, PAGE_SIZE,
>   cache->gen > 5 ? 0 : 
> I915_DISPATCH_SECURE);
> @@ -1965,10 +1961,6 @@ static int eb_submit(struct i915_execbuffer *eb)
>   if (err)
>   return err;
>  
> - err = i915_switch_context(eb->request);
> - if (err)
> - return err;
> -
>   if (eb->args->flags & I915_EXEC_GEN7_SOL_RESET) {
>   err = i915_reset_gen7_sol_offsets(eb->request);
>   if (err)
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index e0d6221022a8..445495f9893c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -624,6 +624,10 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>   if (ret)
>   goto err_unpin;
>  
> + ret = intel_ring_wait_for_space(ring, MIN_SPACE_FOR_ADD_REQUEST);
> + if (ret)
> + goto err_unreserve;
> +
>   /* Move the oldest request to the slab-cache (if not in use!) */
>   req = list_first_entry_or_null(>timeline->requests,
>  typeof(*req), link);
> @@ -703,10 +707,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>   req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
>   

Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

[Sagar Arun Kamble]

On 11/15/2017 6:01 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-11-15 12:13:54)

From: Sourab Gupta 

Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports). This limits the ability to
correlate these samples with the system events.

An ability is therefore needed to report timestamps in different clock
domains, such as CLOCK_MONOTONIC, in the perf samples to be of more
practical use to the userspace. This ability becomes important
when we want to correlate/plot GPU events/samples with other system events
on the same timeline (e.g. vblank events, or timestamps when work was
submitted to kernel, etc.)

The patch here proposes a mechanism to achieve this. The correlation
between gpu time and system time is established using the timestamp clock
associated with the command stream, abstracted as timecounter/cyclecounter
to retrieve gpu/system time correlated values.

v2: Added i915_driver_init_late() function to capture the new late init
phase for perf (Chris)

v3: Removed cross-timestamp changes.

Signed-off-by: Sourab Gupta 
Signed-off-by: Sagar Arun Kamble 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Sourab Gupta 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_perf.c | 27 +++
  include/uapi/drm/i915_drm.h  |  7 +++
  2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3b721d7..94ee924 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -336,6 +336,7 @@
  
  #define SAMPLE_OA_REPORT   BIT(0)

  #define SAMPLE_GPU_TS  BIT(1)
+#define SAMPLE_SYSTEM_TS   BIT(2)
  
  /**

   * struct perf_open_properties - for validated properties given to open a 
stream
@@ -622,6 +623,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
 struct drm_i915_perf_record_header header;
 u32 sample_flags = stream->sample_flags;
 u64 gpu_ts = 0;
+   u64 system_ts = 0;
  
 header.type = DRM_I915_PERF_RECORD_SAMPLE;

 header.pad = 0;
@@ -647,6 +649,23 @@ static int append_oa_sample(struct i915_perf_stream 
*stream,
  
 if (copy_to_user(buf, _ts, I915_PERF_TS_SAMPLE_SIZE))

 return -EFAULT;
+   buf += I915_PERF_TS_SAMPLE_SIZE;
+   }
+
+   if (sample_flags & SAMPLE_SYSTEM_TS) {
+   gpu_ts = get_gpu_ts_from_oa_report(stream, report);

Scope your variables. Stops us from being confused as to where else
gpu_ts or sys_ts may be reused. For instance I first thought you were
using SAMPLE_GPU_TS to initialise gpu_ts

Yes

+   /*
+* XXX: timecounter_cyc2time considers time backwards if delta
+* timestamp is more than half the max ns time covered by
+* counter. It will be ~35min for 36 bit counter. If this much
+* sampling duration is needed we will have to update tc->nsec
+* by explicitly reading the timecounter (timecounter_read)
+* before this duration.
+*/
+   system_ts = timecounter_cyc2time(>tc, gpu_ts);
+
+   if (copy_to_user(buf, _ts, I915_PERF_TS_SAMPLE_SIZE))
+   return -EFAULT;

Advance buf.
Had kept advance logic only if there is new field to be added as this 
advance is missing for

SAMPLE_OA_REPORT currently in drm-tip. Will fix.
Thanks for the review :)

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

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Make request's wait-for-space explicit

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2017-11-15 13:51:13)
>> Chris Wilson  writes:
>> 
>> > At the start of building a request, we would wait for roughly enough
>> > space to fit the average request (to reduce the likelihood of having to
>> > wait and abort partway through request construction). To achieve we
>> > would try to begin a 0-length command packet, this just adds extra
>> > confusion so make the wait-for-space explicit, as in the next patch we
>> > want to move it from the backend to the i915_gem_request_alloc() so it
>> > can ensure that the wait-for-space is the first operation in building a
>> > new request.
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  drivers/gpu/drm/i915/intel_lrc.c|  8 ++---
>> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 56 
>> > +
>> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
>> >  3 files changed, 41 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index 58d050a9a866..ebd9596fe83b 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -1180,7 +1180,7 @@ static int execlists_request_alloc(struct 
>> > drm_i915_gem_request *request)
>> >  {
>> >   struct intel_engine_cs *engine = request->engine;
>> >   struct intel_context *ce = >ctx->engine[engine->id];
>> > - u32 *cs;
>> > + int ret;
>> >  
>> >   GEM_BUG_ON(!ce->pin_count);
>> >  
>> > @@ -1190,9 +1190,9 @@ static int execlists_request_alloc(struct 
>> > drm_i915_gem_request *request)
>> >*/
>> >   request->reserved_space += EXECLISTS_REQUEST_SIZE;
>> >  
>> > - cs = intel_ring_begin(request, 0);
>> > - if (IS_ERR(cs))
>> > - return PTR_ERR(cs);
>> > + ret = intel_ring_wait_for_space(request->ring, 
>> > request->reserved_space);
>> > + if (ret)
>> > + return ret;
>> >
>> 
>> We lose the wrap handling with this. What guarantees
>> at this point, that we dont need to wrap?
>
> We don't care. We wait for sufficient space to wrap, but we don't need
> to advance/wrap the ring pointer here as we are not emitting a packet.

Ok, and the request we alloced for, will do the needed ring_begin
and handle the wrap.

Reviewed-by: Mika Kuoppala 

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

Re: [Intel-gfx] [PATCH igt 1/2] lib/gt: Mark up engine classes

[Tvrtko Ursulin]

On 15/11/2017 13:32, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-11-15 13:26:09)


On 14/11/2017 13:19, Chris Wilson wrote:

We introduce the concept of classes that each engine may belong to.
There may be more than one engine available in each class, but each
engine only belongs to one class. Each class has a unique set of
capabilities and purpose (e.g. 3D rendering or video decode), but
different engines within each class may have different features (e.g.
only the first decoder instance may have the full set of fixed function
blocks, but most of the work can still be offload onto the other decoders
which shared the same ISA etc).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   lib/igt_gt.c | 16 
   lib/igt_gt.h |  7 +++
   2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 89727d22..8496fe4d 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -578,14 +578,14 @@ unsigned intel_detect_and_clear_missed_interrupts(int fd)
   }
   
   const struct intel_execution_engine intel_execution_engines[] = {

- { "default", NULL, 0, 0 },
- { "render", "rcs0", I915_EXEC_RENDER, 0 },
- { "bsd", "vcs0", I915_EXEC_BSD, 0 },
- { "bsd1", "vcs0", I915_EXEC_BSD, 1<<13 /*I915_EXEC_BSD_RING1*/ },
- { "bsd2", "vcs1", I915_EXEC_BSD, 2<<13 /*I915_EXEC_BSD_RING2*/ },
- { "blt", "bcs0", I915_EXEC_BLT, 0 },
- { "vebox", "vecs0", I915_EXEC_VEBOX, 0 },
- { NULL, 0, 0 }
+ { "default", NULL, 0, LOCAL_ENGINE_CLASS_INVALID, 0 },


A bit strange that you have marked it with invalid here. Will cause
random issues for tests which will use class_id from this array. On the
other hand maybe it is for the better since it will remove the "default"
engine from the subtests ran once we (hopefully) switch to
class-instance execbuf. Don't know, hard to guess, but it works so OK.


Default doesn't map onto a class-instance, it is vague and may map on to
whatever the kernel considers most convenient. And yes, when we are
iterating over HW engines and not I915_EXEC_$RING, we don't care for the
ambiguously defined uabi.


+ { "render", "rcs0", I915_EXEC_RENDER, LOCAL_ENGINE_CLASS_RENDER, 0 },
+ { "bsd", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 0 },
+ { "bsd1", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 1<<13 
/*I915_EXEC_BSD_RING1*/ },
+ { "bsd2", "vcs1", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 2<<13 
/*I915_EXEC_BSD_RING2*/ },
+ { "blt", "bcs0", I915_EXEC_BLT, LOCAL_ENGINE_CLASS_COPY, 0 },
+ { "vebox", "vecs0", I915_EXEC_VEBOX, LOCAL_ENGINE_CLASS_VIDEO_ENHANCE, 0 
},
+ { NULL }
   };
   
   bool gem_can_store_dword(int fd, unsigned int engine)

diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index 2579cbd3..4f13f86f 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -63,10 +63,17 @@ void igt_clflush_range(void *addr, int size);
   
   unsigned intel_detect_and_clear_missed_interrupts(int fd);
   
+#define LOCAL_ENGINE_CLASS_INVALID   -1

+#define LOCAL_ENGINE_CLASS_RENDER0
+#define LOCAL_ENGINE_CLASS_COPY  1
+#define LOCAL_ENGINE_CLASS_VIDEO 2
+#define LOCAL_ENGINE_CLASS_VIDEO_ENHANCE 3


Why not make a local copy of the enum to be consistent with the kernel
uPAI headers?


Shrug. It has to be temporary. #define have the advantage that the
compiler only complains when they differ, which was why I suggesting we
didn't use enum ;)


enum would have to be temporary and these ones can be left in "forever" 
you mean? I actually have no idea at the moment on how the enum 
namespace is handled in C. But anyway, none of this matters hugely.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

___
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/: Initialise trans_min for skl_compute_transition_wm()

[Rodrigo Vivi]

On Wed, Nov 15, 2017 at 10:50:35AM +, Chris Wilson wrote:
> clang spots
> 
> drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used 
> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> if (INTEL_GEN(dev_priv) >= 10)
> 
> but fortunately for us we skip the function unless on a gen10+ device.
> However, to keep the function generic in case we do want to re-enable it
> for gen9 again, initialise trans_min to 0.

Based on this comment:  /* Transition WM are not recommended by HW team for 
GEN9 */

I believe the function should be called cnl_compute_transition_wm

plus:

-  uint16_t trans_min, trans_y_tile_min;
+  u16 trans_min = 4, trans_y_tile_min;

-  if (INTEL_GEN(dev_priv) >= 10)
-   trans_min = 4;

Also Wa for CNL A0 can be removed... We never put our hands in on A0...

But in case you want to go with the quick fix:
Reviewed-by: Rodrigo Vivi 

up to you.

> 
> References: ca47667f523e ("drm/i915/gen10: Calculate and enable transition 
> WM")
> Signed-off-by: Chris Wilson 
> Cc: Mahesh Kumar 
> Cc: Maarten Lankhorst 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8c69ec9eb6ee..5d8babfaec30 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4649,6 +4649,7 @@ static void skl_compute_transition_wm(struct 
> intel_crtc_state *cstate,
>   if (!dev_priv->ipc_enabled)
>   goto exit;
>  
> + trans_min = 0;
>   if (INTEL_GEN(dev_priv) >= 10)
>   trans_min = 4;
>  
> -- 
> 2.15.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/3] drm/i915/guc: Omit guc_init_doorbell_hw during driver load

[Sagar Arun Kamble]

On 11/16/2017 12:00 AM, Michel Thierry wrote:

During driver load we create the GuC clients and allocate their
doorbells just before executing guc_init_doorbell_hw; but since we just
created these doorbells, how can they be out of sync?
This code has had more than enough refactoring (2 more still in progress)
so I would not be surprised if calling guc_init_doorbell_hw made sense at
some point, but not anymore.

The resume path is different, in this case the driver doesn't
recreate clients, and it is still reasonable to validate/reallocate the
doorbells in order to confirm that they still belong to the clients.
Planning to change this in upcoming series (allocate doorbells on resume 
when not needing uc_init_hw)
and then we can do away with this validation. Another problem I see is, 
this is time consuming and leads
to increase in the resume time (we also sanitize on resume hence this is 
unnecessary for all unused doorbells)

And probably guc_init_doorbell_hw is no longer the right name, but I'll
leave that to someone else.

Signed-off-by: Michel Thierry 

Change looks good to me.
Acked-by: Sagar Arun Kamble 

Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 5d6576e01a91..d6762ca42cf1 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1424,16 +1424,16 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
} else {
guc_reset_wq(guc->execbuf_client);
guc_reset_wq(guc->preempt_client);
+
+   err = guc_init_doorbell_hw(guc);
+   if (err)
+   goto err_free_clients;
}
  
  	err = intel_guc_sample_forcewake(guc);

if (err)
goto err_free_clients;
  
-	err = guc_init_doorbell_hw(guc);

-   if (err)
-   goto err_free_clients;
-
/* Take over from manual control of ELSP (execlists) */
guc_interrupts_capture(dev_priv);
  


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

Re: [Intel-gfx] [RFC 2/3] drm/i915/guc: Omit guc_init_doorbell_hw during driver load

[Daniele Ceraolo Spurio]

On 15/11/17 10:30, Michel Thierry wrote:

During driver load we create the GuC clients and allocate their
doorbells just before executing guc_init_doorbell_hw; but since we just
created these doorbells, how can they be out of sync?
This code has had more than enough refactoring (2 more still in progress)
so I would not be surprised if calling guc_init_doorbell_hw made sense at
some point, but not anymore.



I think the idea was to clean up the unallocated doorbells on takeover 
to be covered in case the previous occupant of the GPU didn't release 
them when leaving the HW. We do a full gpu reset during i915 load now in 
i915_gem_sanitize so the doorbell HW should be cleaned up by that, but 
there is still a possible issue when i915.reset=0. However, with reset=0 
this wouldn't be the only thing not sanitized and the only bad 
consequence would be extra irqs to GuC (which would be ignored), so I 
don't think it is worth worrying about that case.


Acked-by: Daniele Ceraolo Spurio 

Daniele


The resume path is different, in this case the driver doesn't
recreate clients, and it is still reasonable to validate/reallocate the
doorbells in order to confirm that they still belong to the clients.

And probably guc_init_doorbell_hw is no longer the right name, but I'll
leave that to someone else.

Signed-off-by: Michel Thierry 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 5d6576e01a91..d6762ca42cf1 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1424,16 +1424,16 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
} else {
guc_reset_wq(guc->execbuf_client);
guc_reset_wq(guc->preempt_client);
+
+   err = guc_init_doorbell_hw(guc);
+   if (err)
+   goto err_free_clients;
}
  
  	err = intel_guc_sample_forcewake(guc);

if (err)
goto err_free_clients;
  
-	err = guc_init_doorbell_hw(guc);

-   if (err)
-   goto err_free_clients;
-
/* Take over from manual control of ELSP (execlists) */
guc_interrupts_capture(dev_priv);
  


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

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

[David Weinehall]

On Mon, Nov 13, 2017 at 10:47:44AM -0800, Rodrigo Vivi wrote:
> On Sat, Nov 11, 2017 at 09:43:44AM +, Sharma, Shashank wrote:
> > Regards
> > 
> > Shashank
> > 
> > 
> > On 11/11/2017 3:56 AM, Rodrigo Vivi wrote:
> > > Starting on GLK we support HDMI 2.0. So this patch only
> > > extend the work Shashank has made to GLK to CNL.
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Shashank Sharma 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
> > >   1 file changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 2d95db64cdf2..1b22b587e98c 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1235,7 +1235,7 @@ static int intel_hdmi_source_max_tmds_clock(struct 
> > > intel_encoder *encoder)
> > >   _priv->vbt.ddi_port_info[encoder->port];
> > >   int max_tmds_clock;
> > > - if (IS_GEMINILAKE(dev_priv))
> > > + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > Would it be a good idea to create a new macro called IS_HDMI2_SUPPORTED() or
> > a function is_hdmi2_supported() where we keep all the GEN check ?
> 
> I asked myself the same question.
> I believe a IS_HDMI2_SUPPORTED or HAS_HDMI2_SUPPORT is a good idea...

Typically we use HAS_* to check whether a feature is available,
and IS_* to identify a platform, or whether the parameter passed is of a certain
type.

So I believe HAS_HDMI2_SUPPORT would be correct if it's to check whether
the platform supports HDMI2.

> > >   max_tmds_clock = 594000;
> > >   else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> > >   max_tmds_clock = 30;
> > > @@ -1511,7 +1511,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> > > *encoder,
> > >   pipe_config->lane_count = 4;
> > > - if (scdc->scrambling.supported && IS_GEMINILAKE(dev_priv)) {
> > > + if (scdc->scrambling.supported && (IS_GEMINILAKE(dev_priv) ||
> > > +INTEL_GEN(dev_priv) >= 10) {
> > >   if (scdc->scrambling.low_rates)
> > >   pipe_config->hdmi_scrambling = true;
> > > @@ -2033,7 +2034,7 @@ void intel_hdmi_init_connector(struct 
> > > intel_digital_port *intel_dig_port,
> > >   connector->doublescan_allowed = 0;
> > >   connector->stereo_allowed = 1;
> > > - if (IS_GEMINILAKE(dev_priv))
> > > + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > >   connector->ycbcr_420_allowed = true;
> > Looks good otherwise.
> > - Shashank
> > >   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> > 
> ___
> 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.BAT: failure for series starting with [1/4] lib/igt_kms: Add igt_display_reset function.

[Patchwork]

== Series Details ==

Series: series starting with [1/4] lib/igt_kms: Add igt_display_reset function.
URL   : https://patchwork.freedesktop.org/series/33934/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
88d6550795fad3974d77e4db2f563c5e2e8872e1 Revert "tests/kms_flip: Make 
flip-vs-panning-vs-hang change DSPSURF"

with latest DRM-Tip kernel build CI_DRM_3353
1fc4fe8ac97e drm-tip: 2017y-11m-16d-12h-57m-10s UTC integration manifest

Testlist changes:
+igt@kms_chamelium@common-hpd-after-hibernate
+igt@kms_chamelium@common-hpd-after-suspend
+igt@kms_chamelium@dp-crc-fast
+igt@kms_chamelium@dp-crc-multiple
+igt@kms_chamelium@dp-crc-single
+igt@kms_chamelium@dp-edid-change-during-hibernate
+igt@kms_chamelium@dp-edid-change-during-suspend
+igt@kms_chamelium@dp-edid-read
+igt@kms_chamelium@dp-frame-dump
+igt@kms_chamelium@dp-hpd
+igt@kms_chamelium@dp-hpd-after-hibernate
+igt@kms_chamelium@dp-hpd-after-suspend
+igt@kms_chamelium@dp-hpd-fast
+igt@kms_chamelium@dp-hpd-storm
+igt@kms_chamelium@dp-hpd-storm-disable
+igt@kms_chamelium@hdmi-crc-fast
+igt@kms_chamelium@hdmi-crc-multiple
+igt@kms_chamelium@hdmi-crc-single
+igt@kms_chamelium@hdmi-edid-change-during-hibernate
+igt@kms_chamelium@hdmi-edid-change-during-suspend
+igt@kms_chamelium@hdmi-edid-read
+igt@kms_chamelium@hdmi-frame-dump
+igt@kms_chamelium@hdmi-hpd
+igt@kms_chamelium@hdmi-hpd-after-hibernate
+igt@kms_chamelium@hdmi-hpd-after-suspend
+igt@kms_chamelium@hdmi-hpd-fast
+igt@kms_chamelium@hdmi-hpd-storm
+igt@kms_chamelium@hdmi-hpd-storm-disable
+igt@kms_chamelium@vga-edid-read
+igt@kms_chamelium@vga-frame-dump
+igt@kms_chamelium@vga-hpd
+igt@kms_chamelium@vga-hpd-after-hibernate
+igt@kms_chamelium@vga-hpd-after-suspend
+igt@kms_chamelium@vga-hpd-fast
+igt@kms_chamelium@vga-hpd-without-ddc
-igt@chamelium@common-hpd-after-hibernate
-igt@chamelium@common-hpd-after-suspend
-igt@chamelium@dp-crc-fast
-igt@chamelium@dp-crc-multiple
-igt@chamelium@dp-crc-single
-igt@chamelium@dp-edid-change-during-hibernate
-igt@chamelium@dp-edid-change-during-suspend
-igt@chamelium@dp-edid-read
-igt@chamelium@dp-frame-dump
-igt@chamelium@dp-hpd
-igt@chamelium@dp-hpd-after-hibernate
-igt@chamelium@dp-hpd-after-suspend
-igt@chamelium@dp-hpd-fast
-igt@chamelium@dp-hpd-storm
-igt@chamelium@dp-hpd-storm-disable
-igt@chamelium@hdmi-crc-fast
-igt@chamelium@hdmi-crc-multiple
-igt@chamelium@hdmi-crc-single
-igt@chamelium@hdmi-edid-change-during-hibernate
-igt@chamelium@hdmi-edid-change-during-suspend
-igt@chamelium@hdmi-edid-read
-igt@chamelium@hdmi-frame-dump
-igt@chamelium@hdmi-hpd
-igt@chamelium@hdmi-hpd-after-hibernate
-igt@chamelium@hdmi-hpd-after-suspend
-igt@chamelium@hdmi-hpd-fast
-igt@chamelium@hdmi-hpd-storm
-igt@chamelium@hdmi-hpd-storm-disable
-igt@chamelium@vga-edid-read
-igt@chamelium@vga-frame-dump
-igt@chamelium@vga-hpd
-igt@chamelium@vga-hpd-after-hibernate
-igt@chamelium@vga-hpd-after-suspend
-igt@chamelium@vga-hpd-fast
-igt@chamelium@vga-hpd-without-ddc

Test debugfs_test:
Subgroup read_all_entries:
pass   -> FAIL   (fi-bwr-2160)
pass   -> FAIL   (fi-elk-e7500)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> FAIL   (fi-bwr-2160)
pass   -> FAIL   (fi-elk-e7500)
pass   -> FAIL   (fi-ilk-650)
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-snb-2600)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-hsw-4770)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq)
pass   -> FAIL   (fi-skl-6700k)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
Subgroup basic-flip-b:
pass   -> FAIL   (fi-bwr-2160) fdo#103182
pass   -> FAIL   (fi-elk-e7500)
pass   -> FAIL   (fi-ilk-650)
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-snb-2600)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/kms_cursor_legacy: Rework the 2x tests.

[Patchwork]

== Series Details ==

Series: tests/kms_cursor_legacy: Rework the 2x tests.
URL   : https://patchwork.freedesktop.org/series/33933/
State : warning

== Summary ==

Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-bottom-edge:
skip   -> PASS   (shard-hsw)
Subgroup pipe-a-256x256-bottom-edge:
skip   -> PASS   (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_concurrent:
Subgroup pipe-c:
skip   -> PASS   (shard-hsw)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
fail   -> PASS   (shard-hsw) fdo#103375
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
fail   -> PASS   (shard-snb) fdo#102365
Test kms_cursor_legacy:
Subgroup short-flip-before-cursor-toggle:
pass   -> SKIP   (shard-hsw)
Subgroup flip-vs-cursor-toggle:
skip   -> PASS   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup rcs-wf_vblank-vs-dpms-interruptible:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
dmesg-warn -> PASS   (shard-hsw) fdo#102249
Test kms_vblank:
Subgroup wait-busy:
skip   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-wc:
skip   -> PASS   (shard-hsw)
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test pm_rpm:
Subgroup gem-mmap-cpu:
skip   -> PASS   (shard-hsw)

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2584 pass:1470 dwarn:2   dfail:1   fail:11  skip:1100 
time:9468s
shard-snbtotal:2584 pass:1259 dwarn:2   dfail:1   fail:11  skip:1311 
time:7994s
Blacklisted hosts:
shard-apltotal:2584 pass:1622 dwarn:1   dfail:2   fail:23  skip:936 
time:13319s

== Logs ==

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

[Intel-gfx] [PATCH v3 6/6] HAX enable GuC submission for CI

[Sagar Arun Kamble]

Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
 drivers/gpu/drm/i915/i915_params.h  | 4 ++--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f92a39f..5bbb3be 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3590,17 +3590,13 @@ int i915_ggtt_enable_hw(struct drm_i915_private 
*dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c729226..c38cef0 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -44,8 +44,8 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc_loading, 0) \
-   param(int, enable_guc_submission, 0) \
+   param(int, enable_guc_loading, 1) \
+   param(int, enable_guc_submission, 1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 5/6] drm/i915/guc: Rename i915_guc_submission.c|h to intel_guc_submission.c|h

[Sagar Arun Kamble]

With all component structures and functions named appropriately, change
the names of GuC submission source files. There were bunch of style issues
in guc_submission.c that are highlighted now by checkpatch. Fix those.
Update name in Documentation/gpu. (Joonas)

v2: Rebase.

v3: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Acked-by: Chris Wilson 
Acked-by: Joonas Lahtinen 
Acked-by: Oscar Mateo 
Reviewed-by: Michal Wajdeczko 
---
 Documentation/gpu/i915.rst  |4 +-
 drivers/gpu/drm/i915/Makefile   |6 +-
 drivers/gpu/drm/i915/i915_debugfs.c |2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c  | 1463 --
 drivers/gpu/drm/i915/i915_guc_submission.h  |   80 --
 drivers/gpu/drm/i915/intel_guc.c|2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c | 1477 +++
 drivers/gpu/drm/i915/intel_guc_submission.h |   81 ++
 drivers/gpu/drm/i915/intel_uc.c |2 +-
 9 files changed, 1566 insertions(+), 1551 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
 delete mode 100644 drivers/gpu/drm/i915/i915_guc_submission.h
 create mode 100644 drivers/gpu/drm/i915/intel_guc_submission.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_submission.h

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee03..21577ea 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -350,10 +350,10 @@ GuC-specific firmware loader
 GuC-based command submission
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/i915_guc_submission.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_submission.c
:doc: GuC-based command submission
 
-.. kernel-doc:: drivers/gpu/drm/i915/i915_guc_submission.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_submission.c
:internal:
 
 GuC Firmware Layout
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f2c6e30..49b9535 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -83,10 +83,10 @@ i915-y += intel_uc.o \
  intel_uc_fw.o \
  intel_guc.o \
  intel_guc_ct.o \
- intel_guc_log.o \
  intel_guc_fw.o \
- intel_huc.o \
- i915_guc_submission.o
+ intel_guc_log.o \
+ intel_guc_submission.o \
+ intel_huc.o
 
 # autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ce02358..ff8f508 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include "intel_drv.h"
-#include "i915_guc_submission.h"
+#include "intel_guc_submission.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
deleted file mode 100644
index 22dbc25..000
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ /dev/null
@@ -1,1463 +0,0 @@
-/*
- * Copyright © 2014 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 "i915_guc_submission.h"
-#include "i915_drv.h"
-
-/**
- * DOC: GuC-based command submission
- *
- * GuC client:
- * A intel_guc_client refers to a submission path through GuC. Currently, there
- * are two clients. One of them (the execbuf_client) is charged with all
- * submissions to the GuC, the other one (preempt_client) is responsible 

[Intel-gfx] [PATCH v3 4/6] drm/i915/guc: Rename i915_guc_client struct to intel_guc_client

[Sagar Arun Kamble]

GuC submission clients are currently being used in kernel only hence
update the structure name to intel_guc_client.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Acked-by: Chris Wilson 
Acked-by: Joonas Lahtinen 
Acked-by: Oscar Mateo 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  4 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 62 +++---
 drivers/gpu/drm/i915/i915_guc_submission.h |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 +--
 4 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ba08b0..ce02358 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2433,7 +2433,7 @@ static void i915_guc_log_info(struct seq_file *m,
 
 static void i915_guc_client_info(struct seq_file *m,
 struct drm_i915_private *dev_priv,
-struct i915_guc_client *client)
+struct intel_guc_client *client)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -2498,7 +2498,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = _priv->guc;
struct guc_stage_desc *desc = guc->stage_desc_pool_vaddr;
-   struct i915_guc_client *client = guc->execbuf_client;
+   struct intel_guc_client *client = guc->execbuf_client;
unsigned int tmp;
int index;
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 515505c..22dbc25 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -32,7 +32,7 @@
  * DOC: GuC-based command submission
  *
  * GuC client:
- * A i915_guc_client refers to a submission path through GuC. Currently, there
+ * A intel_guc_client refers to a submission path through GuC. Currently, there
  * are two clients. One of them (the execbuf_client) is charged with all
  * submissions to the GuC, the other one (preempt_client) is responsible for
  * preempting the execbuf_client. This struct is the owner of a doorbell, a
@@ -42,7 +42,7 @@
  * GuC stage descriptor:
  * During initialization, the driver allocates a static pool of 1024 such
  * descriptors, and shares them with the GuC.
- * Currently, there exists a 1:1 mapping between a i915_guc_client and a
+ * Currently, there exists a 1:1 mapping between a intel_guc_client and a
  * guc_stage_desc (via the client's stage_id), so effectively only one
  * gets used. This stage descriptor lets the GuC know about the doorbell,
  * workqueue and process descriptor. Theoretically, it also lets the GuC
@@ -82,13 +82,13 @@
  *
  */
 
-static inline bool is_high_priority(struct i915_guc_client* client)
+static inline bool is_high_priority(struct intel_guc_client *client)
 {
return (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
client->priority == GUC_CLIENT_PRIORITY_HIGH);
 }
 
-static int __reserve_doorbell(struct i915_guc_client *client)
+static int __reserve_doorbell(struct intel_guc_client *client)
 {
unsigned long offset;
unsigned long end;
@@ -120,7 +120,7 @@ static int __reserve_doorbell(struct i915_guc_client 
*client)
return 0;
 }
 
-static void __unreserve_doorbell(struct i915_guc_client *client)
+static void __unreserve_doorbell(struct intel_guc_client *client)
 {
GEM_BUG_ON(client->doorbell_id == GUC_DOORBELL_INVALID);
 
@@ -152,7 +152,7 @@ static int __guc_deallocate_doorbell(struct intel_guc *guc, 
u32 stage_id)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
-static struct guc_stage_desc *__get_stage_desc(struct i915_guc_client *client)
+static struct guc_stage_desc *__get_stage_desc(struct intel_guc_client *client)
 {
struct guc_stage_desc *base = client->guc->stage_desc_pool_vaddr;
 
@@ -166,7 +166,7 @@ static struct guc_stage_desc *__get_stage_desc(struct 
i915_guc_client *client)
  * client object which contains the page being used for the doorbell
  */
 
-static void __update_doorbell_desc(struct i915_guc_client *client, u16 new_id)
+static void __update_doorbell_desc(struct intel_guc_client *client, u16 new_id)
 {
struct guc_stage_desc *desc;
 
@@ -175,12 +175,12 @@ static void __update_doorbell_desc(struct i915_guc_client 
*client, u16 new_id)
desc->db_id = new_id;
 }
 
-static struct guc_doorbell_info *__get_doorbell(struct i915_guc_client *client)
+static struct 

[Intel-gfx] [PATCH v3 1/6] drm/i915: Update execlists tasklet naming

[Sagar Arun Kamble]

intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related
tasklet functions. Name them with "submission_tasklet" suffix and
remove intel/i915 prefix as they are static. Also rename irq_tasklet
as just tasklet for clarity.

v2: s/_bh/_tasklet (Chris)

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c| 10 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  6 +++---
 drivers/gpu/drm/i915/i915_irq.c|  2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 17 +
 drivers/gpu/drm/i915/intel_ringbuffer.h|  4 ++--
 6 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bf8fea7..61ba321 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2933,13 +2933,13 @@ struct drm_i915_gem_request *
 * Prevent request submission to the hardware until we have
 * completed the reset in i915_gem_reset_finish(). If a request
 * is completed by one engine, it may then queue a request
-* to a second via its engine->irq_tasklet *just* as we are
+* to a second via its execlists->tasklet *just* as we are
 * calling engine->init_hw() and also writing the ELSP.
-* Turning off the engine->irq_tasklet until the reset is over
+* Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_kill(>execlists.irq_tasklet);
-   tasklet_disable(>execlists.irq_tasklet);
+   tasklet_kill(>execlists.tasklet);
+   tasklet_disable(>execlists.tasklet);
 
/*
 * We're using worker to queue preemption requests from the tasklet in
@@ -3128,7 +3128,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.irq_tasklet);
+   tasklet_enable(>execlists.tasklet);
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 0ba2fc0..7f3e63d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -650,7 +650,7 @@ static void inject_preempt_context(struct work_struct *work)
if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {
execlists_clear_active(>execlists,
   EXECLISTS_ACTIVE_PREEMPT);
-   tasklet_schedule(>execlists.irq_tasklet);
+   tasklet_schedule(>execlists.tasklet);
}
 }
 
@@ -799,7 +799,7 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
spin_unlock_irq(>timeline->lock);
 }
 
-static void i915_guc_irq_handler(unsigned long data)
+static void guc_submission_tasklet(unsigned long data)
 {
struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = >execlists;
@@ -1439,7 +1439,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 
for_each_engine(engine, dev_priv, id) {
struct intel_engine_execlists * const execlists = 
>execlists;
-   execlists->irq_tasklet.func = i915_guc_irq_handler;
+   execlists->tasklet.func = guc_submission_tasklet;
engine->park = i915_guc_submission_park;
engine->unpark = i915_guc_submission_unpark;
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ff00e46..4fb183a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1404,7 +1404,7 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
}
 
if (tasklet)
-   tasklet_hi_schedule(>irq_tasklet);
+   tasklet_hi_schedule(>tasklet);
 }
 
 static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a42b738..9897c7f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1585,7 +1585,7 @@ void intel_engines_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id) {
/* Flush the residual irq tasklets first. */
intel_engine_disarm_breadcrumbs(engine);
-   tasklet_kill(>execlists.irq_tasklet);
+   tasklet_kill(>execlists.tasklet);
 
/*

[Intel-gfx] [PATCH v3 3/6] drm/i915/guc: Update name and prototype of GuC submission interface functions

[Sagar Arun Kamble]

i915 GuC submission is hardware interface and GuC APIs that are not user
facing should be named intel_guc* hence we change GuC submission related
functions name prefix to intel_guc. Also changed the parameter to these
functions to intel_guc struct.

v2: Using local guc variable in intel_uc_fini_hw. (Michal Wajdeczko)
Rebase.

Suggested-by: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Acked-by: Chris Wilson 
Acked-by: Joonas Lahtinen 
Acked-by: Oscar Mateo 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++-
 drivers/gpu/drm/i915/i915_guc_submission.h |  8 
 drivers/gpu/drm/i915/intel_uc.c| 16 +---
 3 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b7978a2..515505c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1253,9 +1253,8 @@ static void guc_preempt_work_destroy(struct intel_guc 
*guc)
  * Set up the memory resources to be shared with the GuC (via the GGTT)
  * at firmware loading time.
  */
-int i915_guc_submission_init(struct drm_i915_private *dev_priv)
+int intel_guc_submission_init(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
int ret;
 
if (guc->stage_desc_pool)
@@ -1302,10 +1301,8 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
+void intel_guc_submission_fini(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
-
guc_ads_destroy(guc);
guc_preempt_work_destroy(guc);
intel_guc_log_destroy(guc);
@@ -1391,9 +1388,9 @@ static void guc_submission_unpark(struct intel_engine_cs 
*engine)
intel_engine_pin_breadcrumbs_irq(engine);
 }
 
-int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
+int intel_guc_submission_enable(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_engine_cs *engine;
enum intel_engine_id id;
int err;
@@ -1451,9 +1448,9 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
return err;
 }
 
-void i915_guc_submission_disable(struct drm_i915_private *dev_priv)
+void intel_guc_submission_disable(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
GEM_BUG_ON(dev_priv->gt.awake); /* GT should be parked first */
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.h 
b/drivers/gpu/drm/i915/i915_guc_submission.h
index cb4353b..6bdb8fc 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.h
+++ b/drivers/gpu/drm/i915/i915_guc_submission.h
@@ -72,9 +72,9 @@ struct i915_guc_client {
u64 submissions[I915_NUM_ENGINES];
 };
 
-int i915_guc_submission_init(struct drm_i915_private *dev_priv);
-int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
-void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
-void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
+int intel_guc_submission_init(struct intel_guc *guc);
+int intel_guc_submission_enable(struct intel_guc *guc);
+void intel_guc_submission_disable(struct intel_guc *guc);
+void intel_guc_submission_fini(struct intel_guc *guc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index aec2954..2fb65eb 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -168,7 +168,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * This is stuff we need to have available at fw load time
 * if we are planning to enable submission later
 */
-   ret = i915_guc_submission_init(dev_priv);
+   ret = intel_guc_submission_init(guc);
if (ret)
goto err_guc;
}
@@ -217,7 +217,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (i915_modparams.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
 
-   ret = i915_guc_submission_enable(dev_priv);
+   ret = intel_guc_submission_enable(guc);
if (ret)
goto err_interrupts;
}
@@ -246,7 +246,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
guc_capture_load_err_log(guc);
 err_submission:
if